Labels should be clear, concise, and action-oriented.
This also helps with accessability.
Example:
The label “FSRS” becomes “Enable FSRS”.
The label “FSRS parameters” becomes “Your current parameters”.
2. A hierarchy has been introduced
The FSRS options now have headings to separate sub-topics.
Rationale:
It should reduce cognitive load due to more clear relationships between those settings.
It helps with readability and thus accessability.
Issue:
I wanted to make the “Optimize” header a sub-topic of the “Parameters” header. This makes logical sense and has been done with <h2> and <h3> respectively. It isn’t as obvious as I would have liked, though, that <h3> is a sub-topic of <h2>. Better styling would be necessary.
3. The “Optimize current preset” and “Optimize all presets” buttons have been removed
Instead, I used a combo box which defaults to the string “Current Preset” and which can be clicked on. Clicking it allows the user to select “All Presets” instead. Due to this, only one optimize button is necessary.
Rationale:
It looks more clean compared to having two buttons doing the same thing.
Websites are usually designed in a way were there are as few buttons as possible, so that the users “knows what to click”. Though we could potentially remove emphasis on the “Optimize all presets” button (in the current design anki uses, not this mockup), to guide the users visually.
Issue:
I’m wondering whether “Optimize now” would be a better string for the “Optimize” button or if it should just be “Optimize” instead.
4. The “health check” checkbox has been slightly renamed and converted to a switch
Using a switch helps with consistency with other ui elements.
The rename makes it more obvious that the health check runs only during optimization, not during e.g. reviewing.
Issue:
In my opinion, “health check” isn’t really obvious. I wouldn’t know what it does just from reading that string. I’d prefer something else but cannot find a more fitting name.
5. The simulator got a description
Rationale:
A small description goes a long way with explaining what this feature does. This might help guide the user, otherwise the simulator might just be ignored.
Issue:
I initially wanted to use another string, but it turned out to be too long. Opinions welcome though. The original string:
With the simulator, you can try different study options. For example, you can see the impact of changing desired retention or introducing a certain amount of new cards per day. This tool helps you to visualize the amount of reviews, the time spent and the amount of memorized cards.
D) Further ideas
1. Switches could contain the word “On” and “Off”
Rationale:
Having those strings might help in making the switch more accessible.
Issue:
It might very well introduce more issues related to translations (and e.g. strings not fitting inside the view).
Example:
These are screenshots from pencil and are apparently used in iOS designs.
Maybe we should be moving params to the bottom (or even collapsing them by default)?
E) General Issues
I’d like to make the rows more distinctive from each other, to prevent users from looking at the wrong imaginary line (and thus changing something due to lacking visual clearness). I don’t know how to achieve this though. Sure, a e.g. grayish background could be used on every odd row. But it looks odd whenever I try that.
If you could give your opinion regarding things like the structure / hierarchy, the modified strings and the general design, that would be much appreciated. I’d also love to know your opinions regarding the D) Further ideas and E) General Issues sections.
I think you should move params to the end of optimise like dae said. And have the params collapsed by default. Currently, it has too much focus on this screen.
If I move the params down, I’m not quite certain how to get a logical structure. The following seems to make much less sense:
FSRS Options →Optimize (but what?) → Paramters
I think Danika_Dakika once stated that she’d prefer to see the params on a screenshot, because that might make it easier to help people. Do I misremember or is that correct @Danika_Dakika?
Well, we can just not have another heading for params. Rename “Optimise” → “Optimise Parameters”.
Oh, yes that did occur. If there’s still opposition (probably is), we can keep it uncollapsed. (Although, we could also do the hide params completely and have a keyboard shortcut to copy it.)
[I haven’t had a chance to go through the whole thing, but I’ll respond to the bit you asked about.]
You remember that correctly! It’s hard enough now since the default size of the params field is too small to show all of the params. I already ask for the params as text to get around the incomplete-screenshot issue, and so I can plug them in to the visualizer (because we shouldn’t have to be pulling text from a screenshot. But if they are collapsed, we would also have to direct the user where to find them.
It can be provided through the debug console? And as we are already going to do it for the evaluate feature so users will need to access debug console anyway.
As mentioned before, this is inconsistent with the rest of the deck options, which makes things look unprofessional. Things like trailing colons should be on all or no checkboxes.
“Choose what/which” seem superfluous. We need to find the sweet spot where the text is long enough to be understood, but short enough to read quickly.
Re the hiding of params, we do need to retain a way to provide support easily, though there are potential alternative ways to accomplish this, like a “copy debug info” somewhere that lists only options changed from default, the presets, etc. Asking users for that shouldn’t be more arduous than asking them for a screenshot?
Why not make a switch that turns on: after optimization, “Desired retention”=“Compute minimum recommended retention”.
But for this it is necessary that the preset remembers “Days to simulate”
