Challenge 1:
Explaining things hard to explain

Through conversations with Creative Commons and internally, we arrived at nine options we wanted to give Medium authors:

• One (default) license where the author keeps all the rights.
• One license for things already in public domain, now re-published on Medium.
• Six Creative Commons licenses where the author reserves some, but not all of the rights.
• One Creative Commons license where the author cedes all the rights and effectively puts a new creation in the public domain.

The universe of these nine options would be complicated even if licenses were common knowledge. They’re not. Most people have little idea what terms like “copyright” or “fair use” actually mean, let alone lesser-known concepts such as “share alike” or “copyright waiver.” (To be perfectly honest I struggle, too.)

The UI would combine two aspects, then: the mechanics of choosing the license, and the explanation of the value of licensing in general.

Exploration 1

Let’s start with something simple. We have nine licenses and we could just show all of them as radio buttons:

This has only seven options, actually, but it’s already unbearable. Therefore, we decided to explore grouping the licenses into a two-level hierarchy. This would ameliorate the option paralysis, and also provide a nice conceptual framework: choosing a license is really about deciding which rights you care about, and which you don’t.

Exploration 2

We thought three groups made most sense:

• All rights reserved: The one default license.
• Some rights reserved: The six Creative Commons licenses.
• No rights reserved: Two licenses for old and new public domain works.

The six Creative Commons “some rights reserved” licenses proved to be the most tricky to handle. Since they are expressed as a combination of one or more properties with distinctive, recognizable icons (Attribution, No Derivatives, Share Alike, and Non-Commercial), my first idea was a “license builder,” where you could use checkboxes to put together a license of any flavour. But this has many problems.

First and foremost, four checkboxes allow sixteen different options, but only six of them are actually valid. This means that the UI would have to deal with error states, which seemed awful.

Plus… we don’t use checkboxes on Medium! Which means in addition to designing and implementing the dead ends above, we would have to design and implement checkboxes just for this one dialog.

Lastly, all of those checkboxes look scary and complicated, and there are a lot of words here. (By the way, spot a mock-up typo!)

Explorations 3–5

After some deliberation, we decided to express the six licenses as a secondary list. The UI went into some dark places before emerging (somewhat) cleaner and nicer.

Above, you can also witness the evolution of an unsung hero of design: UI copy. We spent a lot of time cleaning up and tightening the explanations of licenses. We simplified them, refocused on the writer rather than the reader, and we also made everything sentence-cased (we love sentence case). As an example, this…

Attribution: You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

…became this:

Attribution: Others can distribute your work as long as they credit you.

However, there’s a big problem with the last interface there, given one of its goals was for people to be comfortable clicking and exploring all the licenses to understand the whole landscape. Can you spot it?

Yes, you’re right. Imagine interacting with some of those radio buttons. The way the dialog is constructed, the buttons would move from under your mouse pointer, which feels volatile and disorienting. So, onto more explorations to solve that particular problem.

Explorations 6–8

The last iteration is very close to the interface we eventually built. It has three levels: a basic all/some/no rights chooser, then a set of specific licenses, then a description of a chosen license. This felt nice. The default entry point is not too overwhelming, and choices you make only affect things below, making the UI feel more predictable:

More details

We felt our new interface did a good job of allowing to navigate the universe of licenses… but not exactly explaining why licensing matters. And, since we simplified the language and removed some information, we also felt we should provide a link to more details, for those interested.

So, we added a stalwart Learn more link, consistently pointing to a post that rounds up all the licenses together in a simple language — and for each one, sends people to a page with further information. This page is your guide to the world of licensing.

The power of the default

Lastly, we deliberately chose the default option, All rights reserved, to be the one on the right. This was done for two reasons:

• The left-to-right progression from “none” to “some” to “all” felt natural for a left-to-right language.
• We wanted to create a little tension in the UI that would prompt people to explore. “Why is the default on the right? Should I try to move it to the left?”

Challenge 2:
Finding a good balance

Having a design of the license picker is one thing, but knowing where it goes is another. Here, we needed to find a good balance between not annoying people who don’t care about licensing, and not burying the option so deep no one would ever find and use it.

We decided to put the license selection in a confirmation step just before publishing. We already had a little toggle there for visibility… so we decided to unify the two. Now, you can go straight into publishing, or take a detour and toggle visibility and license on the way:

Similar principles guided us as we were figuring out how to present licensing information in the footer of any story. We wanted people to be curious about unusual licenses, but also the information not to be in the way in an already dense space:

For those interested, we also provided a link going to a specific license, and a pop-up explaining it in more details without needing to go further:

We decided to show the distinctive CC icons there to draw a bit of attention. The icons have tooltips that change depending on whether it’s you or someone else looking at the article:

The new project is valuable even if the author goes with the default “all rights reserved” license — now, we’ll reaffirm that everything posted on Medium belongs to the author, not the platform:

Challenge 3:
Reusability and maintenance

One could imagine a much more impressive, customized version of the final interface we built. I definitely could. What if the top selector looked like a slider? What if we had new icons representing rights reserved? Shouldn’t the three radio buttons at the top be bigger? Wouldn’t it be cool to redesign the Creative Commons icons to match Medium’s style?

Yes, possibly. But this is a one-way street towards Not Invented Here. And one of the important goals of this one-day project was: we needed to limit ourselves to the reusable components we already had. Creating new UI parts or conventions would mean more work, more testing required, and more effort to keep them running smoothly in the future. Any extra work put into this on the web would have to be multiplied for other platforms, too.

The first two challenges are still much more familiar to me than this one. One of the important skills I had to develop as a designer in any resource-strapped environment was to know how to allocate the right amount of attention and care given the importance of a feature. Craftsmanship is awesome, but it needs reality checks. And working on a team means there are more timelines than just your own.

All things considered, a license selector is a niche proposition. It was more prudent and realistic to put a simple UI together and get it out there quickly, allocating more time to finesse or re-think more well-traveled parts of Medium’s user interface.

Here’s another variation on the same theme. You might ask: in the publish flow above, why doesn’t the initial pop-up expand to accommodate licensing, rather than crudely taking over?

It seems inelegant… no, it is inelegant, but that inelegance is there for a reason. If the license pop-up stands on its own, we could reuse it in other contexts, for example when people want to change them after publishing, or even in their story dashboard. Here, we deliberately traded some of the quality of the interface for its longer-term reusability.

Lastly, seeing a few similarly looking and behaving pop-ups, we coded their behaviour as one reusable UI pattern, so that they would be easier to maintain and improve together. (Bonus point if you can spot one inconsistency below.)

A different set of challenges

It’s hard to write about everyday design projects. They often seem pedestrian. Or boring. It’s so much more fun to share stories of going crazy for a perfect underline, resurrecting an old typographical mark, or fixing an exotic bug with an elaborate backstory.

But I also love the kinds of challenges provided by a project like the one above, no matter how much less exciting they may seem. This one gave us so many, asking to:

• use only simple UI components, and text, to go as far as possible
• deal with time limitations
• design something that’s easy to use, but also easy to build and easy to maintain
• be okay with all the compromises, and with seeing something imperfect but alive and used — rather than perfect but never built, or perfect and forever falling apart
• use one feature as an opportunity to improve things around it and leave the entire product in a slightly better place (which our CTO calls “the spirit of wilderness code”)

I believe it is those types of challenges that make me a better designer. And it feels great to have helped shipping license support I’m pretty proud of — a very rare one for a publishing platform, with a careful UI that people can use right now, today.

Fame and fortune will have to wait for v5.