By the way, I voted for transparent buttons here but then I thought, is that a problem with buttons, or with everything else? Perhaps if you fix all the other issues, the buttons will start look good.
I also have a few concerns:
Text buttons don’t look especially good without borders. You can get away with that if you only have one or two of those, but I don’t think mixing them with icon buttons like that works well. You can feel it in the screenshot above. Also, what if an addon adds a button with a space in it? Or perhaps there are translations with spaces?
It might be much easier to tell from a regular button that it’s disabled.
Button block separation is not as visible. Stuff like this might not seem important but I think accessibility matters.
This creates yet another button style. Anki has how many… 5 different button styles, and this adds yet another? I think we need to reduce the number of styles, not multiply it.
Take a look at this. Here, I tried to remove unneeded elements, reduce clutter, and, mainly, make things consistent with each other. More… same, if you will. I think it looks much cleaner. And the buttons suddenly start looking better. And it’s more compact. I have a small screen!
You could try prettifying this with shadows, lower contrast and whatnot. I didn’t go there, making this was already a big exercise in CSS . Oh and here’s a diagram with a few notes on the good bits.
I agree with that. Borderless buttons looked better because it was visually less cluttered, but it doesn’t quite work out for text buttons.
I’m not sure that making things more compact is necessarily better visually. However, there are major points in what you proposed:
Same distance between similar things. This is a must-have. Once you start noticing kerning in your everyday life, you realize there is a reason why everything should be regularly spaced out: otherwise, it’s really too ugly.
Sticky / visibility / HTML editor buttons only visible on hover. I actually never though about that, but it’s brilliant! When I look at the Add window now, I notice they somehow take a lot of space and some attention, while only one of them can be useful at a given time. Maybe with a little fading to prevent them from flashing out if you quickly change focus / hover among multiple fields.
I usually don’t really care for much coherence in buttons’ style, but I have to admit in the case of Anki this is getting out of hand. I agree that some effort should be put in trying to reduce (or, at least, not increment) the number of different button styles.
@hengiesel, is this something you’d be interested to implement? Interactive tooltips could be useful in other areas too - especially as a usable component for add-ons. I don’t feel comfortable enough with Svelte to do it myself.
@oakkitten@BlackBeans thanks for your detailed suggestions. They have been noted and I’m already experimenting with them. Just a few points:
Right. Text buttons are generally a bad idea, but you can’t prevent add-on authors from using them…
Without a defined design language, tackling the whole UI in one go would be a waste of time. The editor is a good place to experiment with new styles because it is a single webview with lots of different elements. Ironing out all the ugly parts of Anki is something I wanted to do for a long time, and once we’ve settled on a good design language, we can start thinking about a complete overhaul/cleanup of Anki’s screens.
I’ve thought about these buttons as well. Visibility on hover would be an improvement, but maybe we can get rid of them completely?
With the input styling @oakkitten suggested, they feel a tad bit too detached from the field imo. Here are my ideas of how to get rid of them:
button
action
alternative
collapse/expand field
toggle the collapsed state with a click on the field label and style it in a way that suggests this behavior
toggle HTML editor
show a little expand/collapse arrow (on hover) at the edge of the editing area that the HTML editor will expand from
I like your idea of getting rid of the sticky / visibility / html buttons. However, making the sticky button too discrete has its disadvantages: there are already people who didn’t notice it / do not know what it does, and therefore do not understand why the field does not get reset. Maybe if it ends up blending a little more with the rest of the UI, there should also be a stronger visual feedback that a field is pinned. Maybe, if it went back to the frozen field idea, there could be some freezing visual effects on the border of the field?
The intention is to share this editor across desktop, AnkiMobile and AnkiDroid in the future. Tablets and mobile devices typically don’t support a hover action, so the interface needs to be usable even without a mouse.
Some users apply styling as they’re typing, eg ctrl+b, type some text, ctrl+b again. Requiring a selection before formatting can be applied will break that workflow.
I find this very strange. Tipically, these devices have very different screen size, screen shape and input method from computers, so having a single UI for all of them seems a goo way to make it impossible to to adapt to each devices’ specificity. I may understand that this solution may require less code, so less hassle, but at the same time, it’s going to be much harder to design good UIs.
Yes, of course. Shortcuts would globally not change, just the buttons. What would become impossible would be to type some text, click on bold, type some other text, and click again on bold. I don’t think it’s a big loss, but maybe it’s arguable (I don’t know how many users currently work like that).
I am strongly against this. This interface is only used on mobiles, and I daresay only for two reasons: because phones have limited screen space, but mainly because you can’t right click, or press Ctrl-C, on a phone.
There’s a reason this interface is almost never used on a PC. I only know a single app that uses this, Edge, and it allows turning this behavior off. There are a few reasons to use this:
It saves some screen space. However, in the case of Anki this would be zero space saved, since the entire button row takes less than 600 pixels, and the users will rarely make the window more narrow than that.
Actually, I can’t think of any other reason.
And a few reasons to not use it:
It is unconventional;
We already have two places with buttons (toolbar, icons over fields), and this will make buttons appear in three places. Entia non sunt multiplicanda praeter necessitatem;
Buttons that change places, and that you have to wait to appear, are a bit harder to press. Pressing a button that’s always in the same place involves less brain activity;
Where do the keyboard hints go? The ones that say that button B makes the text bold and that it can be triggered by Ctrl-B? Did you say, show a tooltip on mouse over? So, we have a popup for a popup now?
The popup obscures text, and if you wonder, while selecting, that maybe you should also select another row above, you now have to clear the selection to take a look at it and select again;
If you select text with keyboard, you probably don’t want the annoying popup at all;
At the moment, you can type “foo”, press B, type “bar”, and have “foobar”. This will not be possible with the popup design. I hear you saying, but if the user is typing, surely they are going to press Ctrl-B instead? Well, I know a lady who’s been working on computers for the last 25 years daily and who still insists on pressing Caps Lock, then a letter, then Caps Lock again, to capitalize words. Not for the lack of my trying to convince her otherwise, mind. But this works for her, and this works everywhere. In the same way like the B buttons work the same everywhere. So maybe this is not the case similar to xkcd #1172.
While they might be visually detached, this is not confusing for the user. The icons are often placed above the field. Besides, if you only show them on mouse hover, there can be no mistake.
You can also make them more visually attached by placing them closer to the target input field. Or, even better, place them adjacent to the label.
However, I also like the idea of somehow ditching these buttons completely… If that means also ditching the labels as well. Instead, you could place the labels right inside the fields. In your screenshot, you have placed the description there. Imagine that it would say istead, “Medien: Images, videos, audio, PDF”.
While I would want to use this throughout Anki (did I mention that I love more screen space?), I imagine some users download a lot of premade decks, with the fields already filled, so not having labels might be confusing for them. So this could be an (editor) option, show or hide labels.
I experimented with the conventional look you want for fields (as you can see in posts above) and liked it - but when I worked on an accordion-type collapse/expand mechanism for the fields, I found the unconventional look to be more intuitive. See this screenshot:
Compare with input-only framing
Or with separators:
Even when collapsed, the field Origio is still clearly framed in the unconventional style, making it easy to spot and tap if you want to expand it again.
I made sure to also include :focus-within (for .editor-field), so mobile users will still see the controls when a field is focused. The screenshot shows how the first field is focused, but you also see all (remaining) badges on the third field because it is hovered. The current FieldState badges are too close together for mobile use anyway, so I thought an accordion style to collapse/expand is probably the most mobile-friendly solution. I put the chevrons in front of the field name as a placeholder, but I’m open for a different visual indication for the collapsed/expanded state.
I think we still need some space for the collapse/expand and sticky actions. Add-on authors might want to place field-specific UI elements into the LabelContainer:
Minimizing clutter is good, but one can also overshoot that peak of usability and end up in the valley on the other side.
Not quite so, but you mainly notice it on mobiles because it is very painful to use there, whereas it’s quite seamless on a computer. For instance, Discourse uses this feature, and you (seemingly) didn’t even notice it
The main purpose would be to unclutter the UI. I am not particularly fond of this way of editing text, but I am not particularly fond of using the mouse either way. The final objective would be to get rid of that bar altogether. Keep only what is useful for the user, and the let button appear as they become useful.
For instance, think about the “Quote” button that appears on discourse, when you select some text. It’s very handy, it doesn’t get on the way, and takes no place: it just is there when you need it, and nowhere to be seen when you don’t need it. I think it’s good design.
Indeed, but the goal would be to get rid of the button bar.
At the same time, a button that always appear where your mouse is requires less “mouse dexterity”, and thus less brain activity.
I am too lazy to can’t make an image to illustrate what that would be, but I can describe it. You would have a contextual menu that would appear if you click on the “more” button, at the end of the bar, similar to the right-click contextual menu. That would be similar to when contextual menus have submenus: this does not add a pop-up, but rather extends the menu. It’s much less aggressive that a pop-up, because it does not add an other window.
In this contextual menu, just like most contextual menus, buttons do not have icons, but a textual description (on the left), and the shortcut (on the right).
It’s true. Depending on how it is actually done, it can be more or less annoying. Cf. the “Quote” button of Discourse (pretty handy to test this feature while discussing it )
However, when you select with the mouse, you can’t anyways extend the selection without resetting it. So not that annoying (I think).
I don’t have an opinion about that. I’m not sure whether this is true or not, I think some testing is needed.
It goes without saying that selecting the text in the HTML editor would not open that tooltip.
I was going to quote that xkcd, but you got it before me . Anyways, I didn’t say if they are typing they while press Ctrl-B. It’s just that this is the most handy way to do that, and removing a not-so-practical way of doing it because it’s in the way of a different UI is just making choices. Every UI can’t have every feature at the same time. What I said is that it seems a good tradeoff to me. It’s arguable, and I am ready to hear counter arguments. But the fact that there exist an (hypothetical) user for which this tradeoff wouldn’t be so great is not really a great argument in itself…
Anyways, this whole point about “there are people for which the current workflow works, so just leave them be” seems similar to 1172 to me.
I like this idea, but I also like the fact that you can click on labels to collapse the field. Not sure whether these two can be made compatible…
Maybe you could get rid of the field label in the add window by making it the default, greyed text of an empty field, so that as soon as the user starts typing in that field (acknowledging they know what that field is), the label disappears.
In case you were wondering how these changes would look in dark mode:
compare with conventional input design @oakkitten
It’s important to remember what we’re trying to fix:
compare with current state of Anki
Notes:
text-fg is off-white (#f8f8ff)
toolbar and tag editor aren’t StickyContainers anymore, but the fields container is a ScrollArea (new component) with responsive box-shadows that indicate overflow
the blue highlight shadow on field focus is now inset, meaning it doesn’t cause irregularity in field width
the pin icon (toggle sticky) only changes in opacity (0 if deactivated, 0.4 when field is hovered/focused, 1 if activated), but not in shape (no strikethrough icon)
HTML-editor toggle is in the lower corner of the editing area and is only shown on focus (just an experiment, curious what you think) - this makes sticky the only icon to pop up in the label-container on field hover & focus
While I agree that it is a bit more intuitive (not a very big sort of a bit I should say), I think that the “conventional” design does a better job if the goal is to hide the field because you don’t quite care about it.
(Although to be honest I am not sure if that’s the reason users hide fields. I never used this feature, and I was assuming that collapsing fields is persisted. So, for instance, if I was learning kanji, I could have a field with Heisig index. Such a field would not be remotely interesting for me in the editor, I would never want to read or change it, but I still may want the field for sorting or lookup, for instance. So I imagine users would collapse this field and forget about it. But since collapsing doesn’t stay, it’d be useless in this case. So I have to wonder what people (who are actually using this feature often) are using this for.)
That’s why I said that this could be an option. There are certainly uses for the label area and the labels themselves.
I don’t think this example applies. The use case for the Quote popup is quite different. This design choice serves two purposes:
It allows to access a feature without a toolbar. Well, there is a “toolbar” for each post, but the post may be big and you may have to scroll to reach the toolbar.
Discoverability. A popup—stuff that jumps at you—is a great way of letting the user know that the application has this particular functionality.
Neither of these bullet points apply in text editors. Oh by the way, the one other app that shows a similar popup on select that I have is Edge (Edge is actually good!). It looks like this, collapsed, and expanded (it expands on hover over the triple dots):
Thankfully, you can hide this monstrosity for good. And, I should point out, you will not see this popup while editing text. It only appears when you select read-only text.
I understand, but I just don’t see how you can get rid of the toolbar altogether. There are buttons such as Fields…, there are buttons for lists, there are buttons placed by addons. I don’t see how you could remove these?
It requires less mouse movement, but you now have to wait for the buttons to appear instead of just moving your mouse to the accustomed place. I think moving mouse, even if that requires lifting the mouse off the mouse pad, employs the part of the brain that does not disrupt the thinking process. Muscle memory if you will. Well, this is probably not a big deal either way.
This could work… I guess? (Oh and by the way, Edge, again, in PDF mode shows… well, this:
Yep, this is a vertical buttoned menu that expands on hover. Thankfully you can turn this off as well.)
In 1172, user’s workflow was relying on a bug. Here, user’s workflow relies on conventional design that is used ubiquitously. Even if the workflow might be rare in the latter case, I don’t think it’s comparable?
P.S. Regardless of the above, I do like the >/v icon instead of the . I hope it rotates! And the HTML button looks neat! And the non-solid tag icon!
Also if you do go ahead with the borderless buttons (which I am still against),
The left edge of F in Field… probably should be vertically aligned with the left edge of the icon below it
Dropdown arrows should be of the same style
Distance between the separator | and elements around it should be the same
The above distance should be probably a bit bigger
Perhaps you could try arranging the buttons and separators in a way that they appear in a grid.
P.S. #2 If the goal is to reduce the number of buttons, perhaps add a way to removes groups of buttons via right click? As in,
Right click → menu with tickboxes:
Show character style buttons
Show character color buttons
Show list and text align buttons
Etc
Show buttons by add-on Foo
Show buttons by add-on Bar
P.S. #3 I think the sticky icon is not very indicative of its action. I’d use a snowflake icon. I think not knowing what an icon does is better than assuming that the icon does something it actually does not.
P.S. #4 This a whole lot of text. If you are still reading this, I like you <3.
P.S. #5 Regarding the dark mode screenshots above, I feel that the dark mode window color should be (much) brighter and field backgrounds should have more contrast… Or something, not sure, but white mode looks better imo.
So I don’t think we will change it to a snowflake. Why do you think the pin doesn’t indicate the feature properly?
Freezing (or locking) tells me that the text cannot be altered anymore - whereas sticking makes sense if you see the “Add” action as a gust of wind that blows all the fields away except those that are pinned:
The first color is Anki, then follows VS Code, the Google website, a macOS window, Slack, and last GitHub. You can see that Anki is particular bright in dark mode. For design purposes, it would be nicer, if the base color would be darker, because that would allow more in range in brighter colors.
I’m not a native english speaker, so it might be just me, but I feel this is somehow a wording problem. When I see a pin, I don’t think it will make the field sticky, right? I also think that the behavior of pinning fields in Anki is too specific for users to be able to guess right away, only looking at an icon and based on visual feedback, to understand what it does before trying it or reading about it.
So the best things to do, IMO, are:
Make the wording coherent (maybe it’s only me, but) if you use a pin as an icon, then you never refer to that action as sticking fields, or as sticky fields, but only as pinning field, or as pinned fields.
Document this feature in a place that the users that don’t go through the whole manual are likely to read. The probably won’t pay much attention to it, but at least when they see the icon, or, having clicked without realizing it on the button, see the behavior in action, have a chance to understand what happened.
Have some visual feedback, stronger than just the icon of the button changing color, that a field is pinned, so that users that inadvertently activated it see the effect right away, not only when they click on “Add”, which increases the odds of them understanding that feature is bound to that button (as opposed to: they are looking for some formatting (or whatever), click on some buttons, find the good one after some attempts, then later click on “Add” and see the field hasn’t emptied; now, they have no idea which button caused that).
As for the theme, at this point I think it would make sense not hard-coding values in Anki, but having some reasonable defaults and letting the users load a theme from a file (even just a CSS file). The next step would be to allow people to share their theme through AnkiWeb, as with decks and add-ons.
+1, that’s a fair point. Perhaps it’s too late to change it in the backend (?), but on the UI side it would totally make sense to call it “pinned” instead of “sticky”.
I’ll also experiment with better visual feedback.
I think the first step should be a small set of official themes (as offered by many popular apps) which can be chosen in the Preferences. Henrik’s PR about semantic color names, which I have cited several times in this topic, will probably serve as the starting point for further theme changes.
To be honest, a lot of application already have a lot of popular themes packaged with, so once there is a definite syntax for theme files, it would be pretty easy to write a script to convert these and quickly generate most used themes. For instance, there is this theme “database” where each theme is basically a lisp file containing a single pair list. I can translate these as soon as the target syntax is chosen.
The pin icon is super commonly used for, well, pinning stuff so that it don’t disappear from the screen. So I would expect that the field would become pinned similar to how the topic title is pinned in this forum.
And yes, perhaps the snowflake/lock icons are also not ideal for the reason you mentioned. Maybe some other icon that carries no meaning? I suppose most people voted for the pin because it is familiar, my point is, this might be the case for an icon that is not familiar. Although I can’t really think of anything better than a snowflake.
And it’s also darker than the dark themes of other popular services, e.g. Discord comes with #33343C, PyCharm with #3C3F41 , Edge with #3B3B3B. Also, most of these services allow choosing a brighter dark mode than the default one, so even if the default one is dark you are not stuck with it. My eyesight is not perfect and those super dark themes are really not pleasant for my eyes. :s
Anki is rather easily styleable, how about make different themes for Anki? In fact, how about making themes that can define button styles, the way fields look, etc? Since both Qt and its web stuff can be styled via CSS, what we basically need is:
a system that loads those CSS files
an official set of selectors that are guaranteed to not change in the current major version (heh major version)
reasonable built-in CSS rules that don’t interfere with themes.
(Now that I wrote this I see that everyone else is suggesting the same :D)
While it would be neat to provide such a level of customizability, it would also mean a lot more work for the developers. Anki is flashcard software, not Skyrim. Not every aspect of the app has to be modifiable. We do not get things right every time, hence it’s important to be able to make changes quickly sometimes. Locking the design/layout rules to cater to modders doesn’t seem like a smart move in that regard.
My personal goal with this thread is to find ideas to make Anki look and feel a bit less like the open source project with limited resources it is. I do not intend to add any functionality or put extra maintenance work on Damien et al. - just enhance the UI/UX of existing features. Of course everyone has different tastes, but there still are some areas we can all objectively agree need changes. These are the things I want to discuss here.
(Please don’t get me wrong, I really appreciate all the input you guys are bringing to this discussion - keep the ideas coming. I just felt the need to bring expectations to a more realistic level.)
. Oh and here’s a diagram with a few notes on the good bits.
is an interesting idea. Feel free to discuss this on 
)
. Anyways, I didn’t say if they are typing they while press Ctrl-B. It’s just that this is the most handy way to do that, and removing a not-so-practical way of doing it because it’s in the way of a different UI is just making choices. Every UI can’t have every feature at the same time. What I said is that it seems a good tradeoff to me. It’s arguable, and I am ready to hear counter arguments. But the fact that there exist an (hypothetical) user for which this tradeoff wouldn’t be so great is not really a great argument in itself…
. I hope it rotates! And the 
