Right now all Bike settings (font, color, etc) are global.
When you change a setting it will change that setting in all open and future documents. This approach is nice and simple to understand, but it’s also a bit limited and might cause problems.
For example:
Limited: If you regularly work with the same few documents it might be nice to use background color to differentiate between them.
Problematic: Some settings are pretty use case specific, and you might not really want them to stick or apply to all documents. For example Bike’s upcoming typewriter scrolling is great when you want it, but also probably not what you want most of the time. And could be pretty irritating if you open Bike and it’s enabled when you didn’t expect… then you would need to go dig around in menus to disable.
Any thoughts? Any apps that you think handle global vrs window specific settings particularly well?
Also given Bikes upcoming settings:
Font
Text Size
Text Color
Background Color
Text - Wrap narrow/medium/large/window
Enable spell check
Mark current line
Focus paragraph/sentence/word/none
Enable typewriter scrolling
Etc!
Which do you think should be global and which do you think should be window/document specific?
The only time not to use global settings is for settings that would be annoying as a global setting. For example consider opening Bike after not using for a few days … would the setting be annoying if enabled? If so then probably shouldn’t be a global setting. Or consider a new user playing with Bike settings… would they get confused by a setting that they enabled and then forgot about?
Eventually use themes as an escape hatch to override global settings. For example background color will remain a global setting, but when themes are eventually added background color can be set by theme… and each window can have custom theme applied.
The two category 2 (non-global) settings that I have so far are typewriter scrolling and focus mode. Both are nice when I’m really focusing on a particular document, but generally they are not what I want enabled when I start my computer in the morning. And the could both be quite confusing to a new user that enabled then while experimenting … and then got an app with odd behavior when they never disabled them.
Since you don’t want these category 2 settings always on I think that means you also need some easy access UI to see the status of these features and to enable/disable them. I guess that means some buttons in the window. So now that’s what I’m thinking about.
Let me know if I’m going off the rails before I start coding this up
The only time not to use global settings is for settings that would be annoying as a global setting. For example consider opening Bike after not using for a few days … would the setting be annoying if enabled? If so then probably shouldn’t be a global setting. Or consider a new user playing with Bike settings… would they get confused by a setting that they enabled and then forgot about?
Design for the engaged and not the confused. Bike, as designed, is intuitive and easy. You are overthinking this.
Eventually use themes as an escape hatch to override global settings. For example background color will remain a global setting, but when themes are eventually added background color can be set by theme… and each window can have custom theme applied.
That is pretty cool. I don’t know of any products which let you do that. The per window theme is not common. I can see the use-case for that, but I have never seen that applied. Sublime Text does a per extension/file-type theme assignment which is similar.
The two category 2 (non-global) settings that I have so far are typewriter scrolling and focus mode. Both are nice when I’m really focusing on a particular document, but generally they are not what I want enabled when I start my computer in the morning. And the could both be quite confusing to a new user that enabled then while experimenting … and then got an app with odd behavior when they never disabled them.
iA Writer does a good job of this. But it is not a non-global setting. It is a menu and the items are clear with appropriate keyboard commands.
Since you don’t want these category 2 settings always on I think that means you also need some easy access UI to see the status of these features and to enable/disable them. I guess that means some buttons in the window. So now that’s what I’m thinking about.
No buttons please. Just keyboard commands. Buttons make the interface busy and distracting. Keyboard commands reward immersion in the product and make the process of learning to use the product fulfilling. Helps increase users’ engagement with the product when you give them a small learning curve to climb.
Thanks for taking the time to think about these things.
Maybe!
I agree mostly.
I don’t use iA Writer daily, but I do refer back to it for design periodically.
In that context I never can make sense of the focus mode options. Playing with it now I guess if I have “Sentence” focus I also must have typewriter scrolling? Generally I think of those two modes as separate features that I would like to activate individually.
Anyway I like the big picture of the iA Writer design… focus is window specific and focus is available through menu items. I don’t like the menu items state machine.
I think unneeded and badly executed buttons do.
But take typewriter scrolling for example. Without any extra UI that’s completely hidden state, until you type and then get unexpected behavior.
Maybe more important, I feel like typewriter scrolling is very mood specific. Sometimes I’ll want it, but I may quickly decide that actually I want it off. If there’s no button then I’ll need to dig into a menu, and that’s almost more annoying then having typewriter scrolling when I don’t want it. Leaves me with two annoying options!
Also playing more with iA Writer and it does actually have a button for this state in the window titlebar. (in addition to normal menu items). Do you find that button distracting too?
For the case of Bike I expect that I’ll be adding a bottom status bar with word count to the right and some store of focus/typewriter status buttons on the left.
I’m not sure what the design will be, but I expect more text looking than button looking. The kind of UI that many programers text editors have… with git branch status, selection, etc. That’s the feel I’ll be going for, not button bar.
Love that you’re spending time considering such foundational ideas.
I always assume “settings” for me are “global” - if I change a setting and the next time I open it something has “reverted” (or feels like it because the setting was actually local) it feels like an error.
I like the way code editors separate global + local, where there’s the “editor settings” (global), but then also “project settings” (local). Though in Bikes case, I haven’t found myself wishing I could change anything on the per-document side yet. Not sure how often I’ll use something like that.
Though the other best settings experiences I’ve had are in video games, since most video games have had to be different, lots of engine features have only become more standardized in the last 10-20 years, so there’s a huge range from “this game has the best settings menu I’ve ever seen” and “this other game lets me make it fullscreen, and that’s it”. I can think of lots of instances where I open up a games settings menu, only to be disappointed that I can’t change mouse sensitivity by typing a number (some games make you change mouse sensitivity with the mouse that you’re changing the sensitivity for, and you have to drag a little icon across a bar of changing values… with the mouse that you are currently changing the sensitivity of??).
Off the top of my head, some of the best settings menus have:
Clear description of each setting is invaluable. The worst thing is having to open google while playing because a game has something like “West Hemisphere Aim-Swaying = ON or OFF?”. “Do you want to use Modern Movement Cushioning? Or Contemporary?”.
smoothly navigable with arrow keys or mouse, numbers can all by typed, pressing tab jumps to the next menu, etc
immediate preview of the change without having to re-navigate into the settings, so the user doesn’t have to change a setting, press escape 4 times to get back into the game, find out it’s not the change they wanted, go back into the 4 levels deep settings menu, change it again, press escape 4 more times, turns out it was fine the first time, repeat…
The final, most difficult thing is the game predicting all the different settings I’ll want to change. While playing I’ll occasionally have impulses (I’d like to make my player’s head bob less while moving, I’d like to turn off motion blur, I’d like to make the crouch button toggle instead of hold), and some games can meet all of these changes, other’s can’t.
Obviously video game settings menus don’t all apply to the use case of a fluid document editor, but often I’ve found that certain, niche, domain-specific problems that are still being worked on, have occasionally been solved long ago by game developers (usually by John Carmack 20 years ago)
Also playing more with iA Writer and it does actually have a button for this state in the window titlebar. (in addition to normal menu items). Do you find that button distracting too?
iA Writer has an interesting feature where the top bar fades when you edit. I don’t see the bar and the button when I am writing in it.
For the case of Bike I expect that I’ll be adding a bottom status bar with word count to the right and some store of focus/typewriter status buttons on the left.
That would work fine, I guess.
I’m not sure what the design will be, but I expect more text looking than button looking. The kind of UI that many programers text editors have… with git branch status, selection, etc. That’s the feel I’ll be going for, not button bar.
I think most of the “Editor” and “View” settings/options should be document specific. For example you might want your todo list to be very compact, and you might want a writing setup that has a different font, larger line- and row-heights, etc.
I don’t think you should solve this (particular) problem with themes. Each document I have open might want a slightly different setting and it would be annoying to have to create a new theme each time I want a document to have a slightly separate set of settings. Particularly if I’m working in an unsaved document that I will paste into and copy out of.
That’s not to say I don’t like the idea of themes, just that you should be able to adjust some things on a document-by-document basis.
BBEdit has a good system for this. In the settings there’s a section called “Editor Defaults” which have a bunch of options…
Interesting… this is more document specific options than I was planning on, but maybe it’s clearer this way… have one mechanism where you can override any setting at document level.
I think for the next Bike release I will just keep all settings global, getting to the point where I need to finish things up and release a new version. But I’ll keep this in mind when I do get to document specific settings.
