Consider adding ability to define amount of tints/shades generated

for example I would like to have 20 shades instead of 11

[edelstone]

Thanks @mevsme, I like this idea and it’s pretty common in other color picker apps.

This would add a significant amount of complexity to the code and interface so anyone considering a contribution for this should kick off a discussion here first.

[AleksandrHovhannisyan]

@edelstone In terms of UI complexity, I think it would remain simple because we currently scroll any horizontal overflows, right? So it's probably a matter of just adding an input somewhere, listening to it, and setting a variable in the script to dictate the number of shades to generate instead of using the hardcoded 10 here:

Thoughts?

[edelstone]

Yeah I tolerated the horizontal scrolling as a solution for smaller devices; not sure I’d love that for desktop browsers, although we could also widen the constraints generally (which are fairly narrow now).

We did just add the switch for hashtag copying and I’m thinking about having a dark mode switch somewhere in the interface so I want to be careful about all the inputs.

You want to contribute something on this @AleksandrHovhannisyan ?

[AleksandrHovhannisyan]

We did just add the switch for hashtag copying and I’m thinking about having a dark mode switch somewhere in the interface so I want to be careful about all the inputs.

Yeah, I agree; it may end up looking cluttered. Maybe some kind of settings menu?

You want to contribute something on this @AleksandrHovhannisyan ?

Maybe! Just throwing some ideas out there. Anyone else who wants to bite is more than welcome to do so.

[edelstone]

Yeah, I agree; it may end up looking cluttered. Maybe some kind of settings menu?

That's an option or I think these switches would logically fall in three different places in the interface:

1. The dark mode/light mode switch would probably be best near the top of the interface since it's a global setting; maybe the upper left corner.
2. The number of color swatches option should probably be just below the text area since, presumably, the number would need to be changed by the user before submitting the form (I'm assuming that once the form is submitted and color swatches are present that changing the number would require a re-submit of the form).
3. The copy hashtag setting remains where it is, just above the color swatches, and also ever-present (although we could consider hiding this until the form is submitted - not sure if that helps or confuses things more).

If we can truly persist all the options across a user's sessions, then a settings panel may work better. If we don't do that I'm not so sure it would be. As far as placement goes, perhaps a settings gear icon or text button would be at the top of the interface and open either in a dialog or its own page entirely.

So it's probably a matter of just adding an input somewhere, listening to it, and setting a variable in the script to dictate the number of shades to generate instead of using the hardcoded 10...

The correct percentages in the color calculations would also need to be calculated. Right now we multiple by .1, i.e. 10%, consistently; this number would need to be dynamic. You may have been implying that in your comment, just clarifying.

Just throwing some ideas out there. Anyone else who wants to bite is more than welcome to do so

Many thanks for the ideas and conversation!

[AleksandrHovhannisyan]

The correct percentages in the color calculations would also need to be calculated. Right now we multiple by .1, i.e. 10%, consistently; this number would need to be dynamic. You may have been implying that in your comment, just clarifying.

Yep, that's fine! You could calculate 1 / n in the code to get the right percentage, where n is either the default of 10 or whatever the user entered.

[AleksandrHovhannisyan]

Oh btw, one way to do this:

If we can truly persist all the options across a user's sessions

We could use localStorage (fully supported by all browsers) to cache a user's settings each time they change one of them. That way we don't have to worry about the settings getting cleared each time the page changes; we can just set the default values of the inputs with JavaScript by reading localStorage.

Since the UI is bound to get more busy, maybe we should mock something up and see what we like.

[edelstone]

I can do that. I’m thinking this local storage should perhaps just be its own issue. It seems like it can be easily decoupled from the other settings issues.

[edelstone]

Here’s option one (option two in next comment) where all the settings are present on the page.

It includes the dark mode switch from #31 which I'll probably do in my free time (since it's within my abilities). As we've been discussing, it would probably be good to do #33 (persist settings) before or in parallel with this, especially if we go with a settings menu dialog. I should have more designs up shortly, but feel free to comment.

Notes:

1. I've limited the number of tint/shade count options to even numbers between 6 and 20, and using a select menu. I think that makes the experience a little more controlled by preventing weird calculations and also eliminating the need for any error messaging (I think).
2. Select menus don't take many CSS styles cross-browser, so whereas the menu in the design is stylized I think we could go with browser default for this. However, we could use a library like Chosen since we're already pulling in jQuery. Open to alternatives if that's too old-school.
3. I'm implying we just leave the color swatch table as it is, that is, optimized for 10 tints/shades and let anything over that scroll horizontally. I guess anything under ten we either stretch the squares to fill the space or max each swatch at 6.5rem x 6.5rem and center the entire table. I'm flexible on this and we can play with that later. A little concerned that people on desktop might not know to scroll horizontally in the case of 12+ colors. Maybe we can do something in the UI to indicate this, like shake the table if there's overflow, although I don't know how much work that is.
4. I'll probably simplify the switch currently in use in the hashtag copy option to eliminate unnecessary text on the page. See designs.

Figma files here

Static page

Select menu selected

[edelstone]

OK option number two here.

Some notes:

1. I find this to be much cleaner. However it is more complex and perhaps more tedious for the type of user that changes settings a lot (if they will exist). For example, imagine someone that frequently toggles dark mode (likely to be common) or the hashtag copy option (probably less common).
2. Right now the copy hashtag option works without re-submitting the form. I assume it could still work that way, but now it's adjacent to the color number option. Can we change the color table in real time so the user doesn't need to click the submit button again for this setting? I think that would be the most logical, but not sure if that's a bigger/more complicated challenge code-wise.
3. I didn't bother with a success message, but if people think it's necessary I can add that.
4. Regarding other interface questions, check the comment above. Might have answered it in the context for design option one.

Figma files here

Cog/gear icon SVG

Static page

Hover effect

Modal activated

Select menu selected

[edelstone]

Feel free to comment or post alternate designs of any fidelity. I can go another round on this.