This blog is part two of a three part series: Refactoring and Releasing the

new CC Chooser.

The Creative Commons Chooser 2025 refactor offers a number of improvements

across the surface of the application. Wherever possible we tried to consider

if the footprint or implementation could be more straightforward and simple and

then worked from there. The end goal being an application that would be

considerably more flexible in its upkeep and advancement.

Reevaluating core features and use

This was accomplished by first understanding and reestablishing what the core

set of functionality the Chooser should provide.

We started with the use cases that were present within the 2020 beta Chooser:

Provide a license recommendation

Passively educate the user about licenses and their properties/use-cases

Allow a user, who is an Author, to generate a "mark" in a variety of formats

(which generally meets the requirements of the license)

Allow a user, who is a reUser/reMixer, to generate an "attribution" mark

when not adequately provided from the original author

From the above four use cases, 1 & 2 were the original core aims of the Chooser.

Use case 3 was added as a mechanism to make applying the choice easier (but if

the Author doesn't adequately provide a mark with Attribution Information then

reUsers/reMixers may not be able to meet the spirit of the terms of the license

(Attribution being required). The Attribution Details being optional is true in

that it doesn't block a license recommendation, nor the passive education (1 &

2); but if a user is expecting 3 as a main use-case then the Attribution

Details become required, colliding with a contextual expectation.

Use case 4 was not an intention of the Chooser, but something users have ended

up using it regularly for, since Authors will often only use a general marking

statement, such as “This Work is licensed CC-BY”.

Moving forward we would hope to focus on use cases 1-3, with the initial MVP

scope of the Chooser refactor prioritizing 1, and then moving into the other

two as supporting use cases. Use case 4 will not be a primarily supported use

case, but we expect people will continue to use the Chooser for it until a

better tool comes along.

Turning scope into technical methods

The Chooser spirals outward from the core decision pathways in the stepper

guiding someone through a series of questions and resulting

recommendations.Those pathways have two main branches that fork at the

beginning (Do you need help? Yes/No), and regardless of what comes after,

eventually provide an appropriate recommendation once all required fields are

met.

From there, the Attribution Fields can be filled out and will populate the

Marking section to allow for easier work marking from all the available user

supplied data.

This means the decision stepper is the core piece of technical functionality

that we would need to stabilize first, and everything else would then build

from that standard setup.

We could employ a method of interwoven if/else and/or switch statements that

moved through a series of logic gates checking against combinations of

question/answer pairings combined together into certain recommendations, but in

the case of the Chooser we already know what all the answers are. We know that

the recommendation can be 1 of 7 possible legal tools, and that there are two

main pathways to get to each of those tools from the “Do you know which

license you need? yes/no” question.

If we work backwards from this premise we can standardize these pathways into a

format which can describe the complete decision tree, and then work backwards.

That then looks generally like this:

[step-1-question]/[answer]/[step-2-question]/[answer]/…/&tool=[tool-req-name]

This breaks down into 14 possible correct pathways.

This format lets us describe the pathway state throughout a particular UX, in a

uniform and easily parsable format.

From there we can set up the form to build out a state pathway as questions are

answered, and when a full path matches a possible correct path end state, a

particular recommendation can be accurately made.

Everything else can be assumed to be unknown (non matching).

This gives us a starting point to set up a simple state machine, and check

against routinely at specific events and provide recommendations and/or update

the interface.

Reducing the JavaScript footprint and overhead

Once we no longer needed a complex state management engine because we only have

14 possible correct “states” we’d like to handle, we could move away from

the need for a larger more complex state management framework like Vue.js.

The 2020 beta Chooser utilized Vue.js and its dependency chain, the newer 2025

Chooser refactor utilizes a single vanilla JavaScript (JS) file. This resulted

in approximately a 98% reduction in the amount of JavaScript!

This also lets us dramatically reduce the dependency chain, which in turn makes

the Chooser more secure, more stable, and more maintainable overall.

Running the project through the SCC tool shows the newer refactor

would be estimated to cost $113,716 to develop, take 6.02 months, and require

1.68 people to complete.

The refactor planning began in 2024, but the total time from initial refactor

to completion code-wise was approximately 3 months (half the estimated time),

with 1 person working on it part time (due to other obligations and

responsibilities).

The original 2020 beta Chooser run through the SCC tool shows an estimated cost

to develop of 8.88 months, and requiring 3.16 people to complete. This means

not only did the refactor overperform on cost on its own estimations, it

reimplemented the same degree of functionality with 1.8% of the code of the

original, and accomplished what would have taken 3 people to do in 9 months

full-time.

This is good, because the Chooser needs to be more maintainable and stable, but

also flexible enough to build out newer features over time.

The state paths and smaller footprint means that we are left with a minimal

amount of logic required to alter the visual state of the UX, and to allow a

user to move through the stepper, the attribution fields, and the various

marking formats and their individual functionalities.

Embrace native support and semantics

As the decision stepper is the main interaction element, the new markup was

first built from there, setting up a semantic form, grouped into fieldsets, and

labelled accordingly.

The classes in particular let the markup describe each component in a way that

can be more directly tied to the logic the JS will later perform.

There is some measure of dynamic “data + markup” being swapped within the

UX based on user selections. Previously Vue.js packages and their dependencies

would handle holding onto this data.

In the refactor we opted to make use of the element, which let us

lean on existing HTML and JS functionality, and also established a foundation

from which more robust Web Components could be utilized later if such a need

arose, giving us a stable path of complexity to follow down the line.

We also opted to avoid the use of popup modals and tabs, and instead leaned on

/ elements instead to accomplish similar behavior without

the

need for JS based behavior. Once again keeping our JS footprint much smaller.

Improving the UX

Reducing friction

We tried to reduce redundancy and better control friction within the UX

wherever possible in the 2025 refactor.

The prior 2020 beta Chooser had “Next” and “Back” buttons within the

interface which largely had no necessary purpose. The Tool Recommendation was

often updated live as fields were filled out, so the only reason to hit the

Next button was to get more of the input interface to appear, rather than to

get more useful output within the Recommendation area.

With the refactor we removed these buttons, giving the user the ability to move

from fieldset to fieldset within the UX without an additional step in the

process of input. Whether they move forwards or backwards the UX responds

accordingly without the added friction. This lets people move through to a

recommendation much more quickly. This change also lets us remove the

“Reset” button as well, since moving backwards through the fieldsets will

reset lower fieldset values automatically. We also get a boost in accessibility

with its removal, since it’s not advised as a solid use case within

accessible interfaces, due to it being too easily clicked.

“The Web would be a happier place if virtually all Reset buttons were

removed. This button almost never helps users, but often hurts them.” (Reset

and Cancel Buttons - NN/G)

We also removed the final "Done" button and its adjacent shaking behavior. The

“Done” button had an erroneous purpose, since the recommendation was

already available on the right, and it was unclear why the “Done” button

would be necessary to reach a final UX state.

The shaking behavior is also generally a UX convention deployed to indicate

that an error has occurred or that inadequate or incorrect information has been

input within a form. The original aim with the prior chooser was to draw

attention to the Tool Rec and marking areas being “finished”, but instead

communicated that some form of error had occurred. This was reported multiple

times by users, so this behavior was removed entirely to make things less

confusing and more clear.

The shaking behavior was accompanied by a form of “scroll jacking” which

would scroll the user’s viewport back to the top so the shaking behavior

could be visible when it occurred. This was also removed.

Overall, we also tried to remove the number of steps, clicks, or choices a user

might have to move through to get to a usable recommendation where possible.

One clear example of this is prepopulating the first question with the default

of “Yes”. This means returning users who are already familiar with the

choice can proceed more swiftly without adding any additional steps for those

that still need help.

Attribution marking now shows up as soon as a tool recommendation has been

provided, linking the two together better contextually, and not as a later

phase of the form’s state lifecycle.

Adding friction

To make the UX more usable we also added friction where it made sense. The

pathway that leads to a CC0 recommendation no longer provides a recommendation

without checking the two acknowledgement checkboxes, to ensure the user is

given the chance to fully understand what they are doing by utilizing CC0.

We also leaned more on the “Need Help?” section to provide deeper

explanations rather than adding more information in other areas. This

section’s newer placement lets it serve as a way to drill down further,

without having to increase the density of information in the fieldsets.

Better related UX element binding and separation

Despite being a rather simple interface the Chooser offers several overlapping

use cases, and as such we tried to find subtle ways to bind distinct areas of

input to related areas of output either with attention focus, or with some

measure of connective mechanisms.

The Attribution fields include descriptive placeholder data, which also shows

up within the various marking formats helping to bind the two areas together as

having an input/output relationship not just generally, but also more

specifically for the individual input fields and output tokens. This allows a

user to start with the Attribution fields and see the results in the Marking

formats, or first encounter the Marking Formats after reaching a Tool

Recommendation, and then make a connection back to the Attribution Fields as

the input source for them. The goal being a bi-directional relationship that is

intuitive.

Another area where this shows up is with the Tool Recommendation itself. When

it appears after a successful set of fieldsets align it is distinctive in its

appearance, but it also has a “waiting for required fields” placeholder

element for the zero state of the UX, so that the shift is more intuitive that

results will appear here once input, and that they are also distinct visually

from the Marking Formats section below.

Increasing plasticity

The final result of the refactor is a dramatically smaller and more manageable

codebase, a much narrower pathway of function and logic, better integration

with the Vocabulary Design system, and a robust use of semantic accessible

markup. This radical reduction in the code footprint and complexity overall

means the refactored 2025 Chooser is now much more agile and can more easily

grow or pivot in new directions.

Closing

Overall, the code footprint is now 57.52 times smaller! If the refactored

codebase's footprint was Earth, then the old codebase's footprint would be Neptune,

since Neptune's volume is 58 times larger than Earth (you can fit 58 Earths

within Neptune)

Despite the number of improvements throughout the refactor, one of the key

goals was clearing out enough bitrot and complexity to make room for the

project to grow sensibly and responsibly again. We weren’t just trying to

improve the Chooser for a static launch, but to reposition it so that it could

once again grow more easily in the directions that would benefit its users most.

We already have a bit of a roadmap in mind, and we’ll get into that in the

final installment, Part 3: Future Growth: What’s next for the Chooser,

and

what directions we hope to grow it.