Brainstorming for modern UI [Anki 3.0]

Perhaps we could make a special rule for deck names starting with a number (RegEx), so that they are sorted numerically?

I’d argue that’s still a special trick, it just exists on Anki’s side instead of the user’s.

Do they need to have a fixed order in the first place?

This I do agree with, assuming it’s part of a wider interface overhaul, though I do also think it’s not a priority.

Maybe the “natural” behavior, for most users that is, would be the one described for the string-version-lessp function here.

The advantage is that this one does not require regex, so it’s slightly faster, and much simpler for most users.

One can also quickly look at the source code for this particular implementation, and see it is mainly based on an already existing C library, which is very short (~200 lines for the core logic).

1 Like

Hey! Quick update on my UI/UX plans:

Main window rework

During and shortly after our discussion here in February, I wrote up a prototype that was almost feature complete. However, university got in the way and I had to put the project on halt. I hope to get back to it in July/August. Sorry for the long wait.

Editor / theme changes

I had some free time the last few days, so I started to do some work on the editor again. @oakkitten’s remark about de -fancifying the Editor motivated me to fix some of its visual noise issues:

What is visual noise?

Elaborate explanation (click to expand)

In UI/UX design, the sum of visual features that take away from our attention on the actual UI is considered visual noise. This screenshot shall serve as an (albeit rather extreme) example:


If you’re a human being and not a robot, you probably don’t feel like using this UI will be a pleasant experience. That’s because there are too many areas of interest to process, so we need to activate our slow thinking to use the software.

High contrast

The window color is gray, text areas are white and the title bar is an intense blue. Contrast can be a good thing to direct attention, but not if it is evenly spaced over the whole window. You might remember the fable “The Boy Who Cried Wolf” - a good example of how the value of information decreases with overuse.

Border lines

These are a few completely avoidable areas of interest that result from differences in contrast due to border lines:

image image image

Extra point

Showing info that is unasked for

Almost every checkbox has its keyboard shortcut written out, e.g. Force directories (-x). Every user, even the ones that know all the shortcuts, is forced to see them.

What to do about it?

The task of a good UI/UX-designer (and artist in general), is to direct user attention in a way that facilitates the use of the program. For example, instead of using two colors that battle for attention, gray out deactivated items:

Modern day example


How could we reduce visual noise in the editor?

Here’s a comparison between the status quo (current dev build) and the state of my current design proposal:

Status quo


Please vote, it helps a lot!

Multiple answers (max 3) allowed.

  • I like the new button design (slightly bigger, borderless, active button colored).
  • I like the new field design (more padding, smaller outline on focus, removed dashed border).
  • I like the theme changes (lighter background, custom scrollbar, lighter border color, box-shadows, off-black text).
  • I like the theme changes, but there’s too little contrast between the fields and the background.
  • I want to see changes to Anki’s editor, but there are better ways to go about it (please explain below).
  • I like Anki’s editor as it is and don’t see a need for changes.

0 voters

There are related PRs in the works:


Looks great! What do you think of removing the borders above and below the fields area as well?
Not sure about the Fields and Cards buttons, which don’t look very clickable. Actually, they don’t have any business there anyway. Maybe they could be grouped with the notetype selector somehow.

1 Like

Thanks for the feedback!

The Fields and Cards buttons certainly need some rethinking as well, which I didn’t get around to yet.

These borders are part of StickyContainer.svelte - which is used for the toolbar and tag editor (also in the deck options and change notetype screen). The purpose of those is to frame the scrollable area, which gets noticeable on vertical overflow:

Sample screenshots

with borders (actually box-shadows)


without borders


One alternative I can think of is to only fade the box-shadow in when there’s actually overflow in the scroll area.

1 Like

A few suggestions if I may:

  • Remove the border around both the title and the field. This is weird and unconventional. There’s a reason no other application does this. Only the input field should have the border.
  • Do not show eye/code/pin buttons unless the mouse is over the field or the button is active.
  • Please no field icons, this is just more clutter! Or at least make them disableable.
  • Do not show overscroll indicators (lines below and above input fields) unless you can scroll. Please do NOT use the CSS trick for this! (I have an add-on that sets the background image for the editor.)
  • Make the tag icon not filled—use the one that the Browser shows. In fact, use a single style everywhere.
  • Remove the weird empty space below the tag panel.
  • Make the distance between buttons constant, make everything aligned, well, more here.

Thanks for your honest feedback!

If you mean the Bootstrap icons before the field name, that’s from an add-on I’m developing (the screenshot from the dev build shows them too), so no worries :sweat_smile:
Personally, they help me find fields at a glance (I’ve always prepended field names with emoji), but if something like that were ever natively integrated, it would certainly be optional.

I’d use JS (Svelte) to determine the scroll state, but I’d be interested which CSS trick you mean.

I think that’s a margin of the Qt grid layout. Once the entire editor consists of a webview (see Henrik’s PR), we can remove the Qt margins entirely and use CSS instead.

That’s certainly the goal, however before fiddling with fine details, we need to get the rough stuff sorted out. The editor is still partly a Qt widget, so aligning stuff is a bit of a hassle.

I’d be interested which CSS trick you mean.

For the life of me I can’t look it up but iirc it consisted of a static background on a parent element and a moveable, attached to scrolling, background on the inside. Or something like that

I think that’s a margin of the Qt grid layout.

Well, yes, but the tag area also has bottom padding, that can be removed.

Your visual noise point made me realize something: most of the time, the user does not want to see all the text style options. They are not even useful for providing feedback on whether some styling is active or not on some text since the editor already renders the style. So, the question is: when does the user want to see them? The answer is: when they use it. Currently, the only (practical) way to use them is to select text and click on a button to toggle style. So why not moving this whole bar to a tooltip: when the user hovers some text, a small bar à la tippy tooltip appears above with a few standard options (ie. bold, italic, underline, …), and a three dots. If the user clicks on the three dots, a menu expands with more, named options, like how the firefox bar works (but simpler, of course). This is good because:

  • the options used more often are easy to access;
  • the options that are not generic for a text editor, but Anki specific, have names, so the user has a rough idea of what it does, and if not it knows what to search for (as opposed to try and guess what an icon mean — speaking for users that don’t know that hoovering hover a button shows some extra info, that is, most users)
  • the shortcuts for the most annoying buttons to be reached can be shown right away, so the user is encouraged to use them, which I think is good. Think about Google Drive, which still has a copy / cut / paste option in its contextual menu, but none of these buttons actually copy / cut / paste. Instead, they show a pop-up menu that explains the key shortcuts. If Google does that, it probably means it’s a good design choice to force teaching the user the most basic shortcuts. At least, Google probably puts a lot of effort in its UI / UX, so I don’t think it’s necessarily bad.

This would, right away, remove a lot of clutter, ie. most of the lower bar.

Something else to be moved are clearly the Type and Deck buttons, because they take too much visual attention (due to their border contrast, and their size) with respect to how much they are used. Most of the time, when adding a card, you should be focused on the fields. For this reason, I propose they are moved to a watchacallem-menu yes, you know, these ones… alt-accessible menu (I don’t know their name), that is, the ones that are usually File..., Edit..., above everything else. I could see something like a Type... menu, with a Manage entry (which would open the Manage pop-up), a Select > entry which would show a submenu from which you could chose a note type, and a Help entry. Similarly for the Deck... menu.

This would unify the UI (the browser and the main window already have this top bar, but not the add window), remove a lot of clutter and an annoying pop-up (clearly, the note type pop-up is very annoying).

Does it seem reasonable for you?


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 :sweat_smile:. Oh and here’s a diagram with a few notes on the good bits.

(This is a dialog from Anki-Connect, I used it as it has disabled buttons.)

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.

Great idea, people are used to such menus from their mobile OS anyway. Here’s a sample I created from Distraction-free editor example | Docs | TinyMCE.

@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:

Moving these to a toolbar like image is an interesting idea. Feel free to discuss this on Notetype and Deck selector in Svelte by hgiesel · Pull Request #1881 · ankitects/anki · GitHub.

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
image collapse/expand field toggle the collapsed state with a click on the field label and style it in a way that suggests this behavior
image 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
image toggle sticky ?
1 Like

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?

1 Like

Just a couple of quick points:

  • 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.
1 Like

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? :worried:
  • 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 :wink:

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 :stuck_out_tongue:)
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 :grimacing:. 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.