Update: Comments from people in our Slack group seem to confirm that this would be a waste of time. Colors are really a need for non-technical people right now, and this would be irrelevant to them. I’m so happy to be blogging. You all are helping me be so much less stupid.
Yesterday I outlined our updated priorities for colors in Workflowy, but something has been bothering me about it. Those priorities have two separate branches: first, the interface that makes it easy to add colors by clicking, tapping or typing; second, the mechanism to customize styles in Workflowy for people who know CSS. It feels inelegant to have these be unrelated and independent. This has been itching my brain.
At some point last nigh I came up with a first idea at how to address this, which I’ll now attempt to describe.
Unifying the colors interface with custom css
First, make the custom CSS system support independent chunks
If we make the custom css system support individual chunks that can be turned on and off, that might serve as foundation unifying our work with for the rest of it. A rough sketch might look something like this:
Second, make our interface for manipulating colors rely on our custom CSS system
Once we have that system, we can put any styles needed for our color display into it, rather than hard code these. This will mean we need to use meaningful class names and no inline styles, but that should be fine.
For example, if I bring up the color picker for the tag “#cool” and pick blue, we would:
- Add a class like
hash-coolto the tag itself, and to the node it is on (enable more flexibility in styling nodes as well) - Add a style to our CSS customization like
.hash-cool.tag { color: blue}.
Why would we do this?
There are a few reasons I’m interested in this:
- Coherence. To have the system be coherent seems like a value in itself.
- Discoverability. If users want to learn how to style Workflowy, the way we do it ourselves will be a great learning resource and jumping off point.
- Extensibility. If we force ourselves to build Workflowy in such a way, that we build it using the same tools other people can use people can customize it
Things we’ll have to consider
- Default styles (users should be able to change the default style of tags, for example, and it should apply to all tags)
- Users playing with the styles, messing them up, and wanting the original styles back.
- Color themes & variables (for example, to enable dark/light mode or changing palettes).
- Ids of rules. If we are manipulating rules via code, we’ll need to have strict IDs that the code knows about. Mixing this with user generated stuff could be tricky.
Will we actually do this?
I’m not sure. I’m trying to create fewer artificial barriers to progress these days, and perhaps this isn’t that important. Maybe we can figure out how to build one bit at a time. Maybe this is an example of a moment when I should focus on more important things and worry less about the elegance of some small part of the system. Maybe this is actually complicating not simplifying. I don’t know.