Brainstorming for modern UI [Anki 3.0]

[kleinerpirat]

@dae

Updating the deck list and reviewer screens separately would be logical steps towards that goal, and if it’s done by creating a new code path that can be opted into with a feature flag, then it could be started right now.

I’d like to help unify the three separate webviews with Svelte for a more modern, responsive experience. My vision looks something like this:

The section to the right (Overview) is meant to display information on the currently selected deck (description, graphs), but could be expanded for a whole range of other purposes (shared decks etc).

My philosophy for a modern Anki UI (3.0):

1. Mobile First

Anki desktop is moving towards a cross-platform solution, so every UI element has to be touch-friendly. This does not mean that the desktop experience has to suffer. This approach leads to more thought about UX in general.

---

2. Use the available space

The main window and its webviews are wasting an awful lot of screen space currently. Responsive layouts will not just look better, they’ll ideally enhance workflows in many ways.

---

3. Prefer icons over labels

Lots of Anki features are triggered with labelled buttons or links.
In English, this might look okay, but take a look at more verbose languages like German - the whole UI looks awfully cluttered in comparison.

Labels can still be shown on hover, like in VS Code:

---

4. Reduce the amount of context menus | Place UI right where features act

E.g. renaming decks: instead of a context menu entry in a cogwheel on the opposite side of the deck name, which opens up a popup dialog, simply fade in a pencil symbol right next to the selected deck’s name which makes the deck name editable inline.

---

5. Get rid of as many extra windows/pages/dialogs as possible

The best dialog is the one that doesn’t exist. If a popup can be prevented, it should be prevented. If that’s not possible, tooltips or single-page layouts with scroll anchors are less intrusive alternatives.

---

6. Use cursor: pointer for interactive elements

I think most people will agree that hovering a button should be reflected on the cursor. Currently, many clickable UI-elements still use the default cursor for legacy reasons.

---

7. Use a white background for light theme

The current window background color is rather Windows XP-esque. While there are many beautiful shades of dark colors, the only clean light color is white in my personal opinion.

---

To see more of this philosophy in action, I recommend taking a look at the UI of Asana. It does a great job at making you feel directly in touch with your data.

What’s your vision?

Like Damien said in another thread, having such a rework as default is still a long way off due to the large number of affected add-ons, but we can create an experimental code path (similar to the v3 scheduler) for a modern main window, which can be opted in via the preferences.

I’d like to gather some ideas on what constitutes a modern, intuitive UI, so feel free to voice your opinions. Pointers to other software with good cross-platform, responsive user interfaces are also very helpful.

[roxgib]

I agree with:

• Icons
• Cursor
• Background

I wouldn’t say the context menus are excessive right now, although if the same UI ends up being used across mobile and desktop they’ll probably end up being reduced anyway, which I don’t have a problem with.

Can you suggest any specific dialogs that can be eliminated?

If Anki is sticking with web views for the main content, which seems likely, it’d be great to add support for add-ons that simply inject Javascript into particular web views without wrapping it in Python. Don’t get me wrong, I personally much prefer working in Python that Javascript, but there’s a lot of people out there who could design fantastic add-ons for the deck browser or review screen in Javascript but would currently have to learn Python and get familiar with Anki’s source code, and this is too much of a barrier. This feature would probably require better support for accessing Anki functions from Javascript, which would require a lot of work, but is definitely possible. It would also add a viable route for extending (some) add-on support to mobile.

[hengiesel]

Great write-up! I agree basically with all points.

3.

I agree that icons should be more widely used. In fact I’m trying to work with more icons in the editor buttons (using icons to designate “Note”, “Deck”, or “Notetype”, the same icons as in the browser). However, to quote Damien:

@dae

icons are more compact, but do make support a bit harder. “Click the Cards… button” becomes “click the icon with the square brackets inside it at the top”.

Using tooltips is great, but it conflicts with point 1 “Mobile first”, as there is no hover action on Mobile. One mobile app that goes heavy on “icons only” is the Obsidian note-taking app, and it does create some confusion while doing so. The idea seems to be: “If you know the desktop app, and you’re familiar with the icons and labels there, the unlabeled icons on mobile should also be familiar to you.”

---

7.

I agree that the current background color is too dark, however, to have a better contrast with the background color of input fields, a bright grey might be a better choice imo, e.g. here’s a screenshot of a window from Notion app:

You can see that the window (and toolbar) background color is ever so slightly darker than the input field (rgb(248, 248, 248) to be exact).

---

My own points:

8. Panes

To avoid extra windows, we could introduce panes. A candidate for a first pane implementation would the card info window in the browser, which could open as a pane to the right side of the browser editor. This goes well with 5., as it’s a viable way to avoid extra windows.

---

9. Sidebars

Maybe my favorite element of Anki as of today is probably the sidebar in the browser. It does a good at illustrating the connections between objects (e.g. a notetype has cardtypes and fields), while doing so in a space-efficient way.

I think many views would benefit from something like a sidebar, or could be turned into a sidebar:

1. The deckbrowser could be a sidebar to the reviewer / overview views.
2. The deck options would benefit if it had a sidebar, which illustrated, a list of the deck-options and its associated decks.
3. The window that appears when clicking on “Managing Note Types” would also work great as a sidebar, with a pane on the right, which allowed editing the current object. In fact, it could be quite similar to the sidebar in the browser.

Another example would be the fields editor window, where the top half is something akin to a sidebar, and the bottom half something akin to a single concern view (see 10.). The top half could be replaced with a sidebar as well:

Fields
> Field 1
> Field 2
etc....

The sidebar can be the location for those “list operations”, that are implemented as buttons in the field editor:

• Add: A plus icon next to the top object (“Fields” in this case)
• Cloning: An icon next to the individual object (e.g. “Field 1”).
• Delete: A trash can icon next to the individual field, or hidden behind a “more” button.
• Rename: A pen icon, like kleinerpirat suggested.
• Reposition: Ideally Drag’n’drop

These can work generally across views:

• Templates: Can also be added, deleted, renamed, cloned, and repositioned.
• Scheduler settings: Can be added, deleted, renamed, cloned, and repositioned (by associating with other decks).
• Decks: Can be added, deleted, renamed and repositioned.

---

10. Avoid “Multi-object dialogs”

There are a lot of dialogs which deal with a list of objects. For example, the template editor has a selector on the top to select a cardtype on the top, and then you can choose between editing the front card template, back card template, or the CSS.
Instead, we could have single-concern view, and a sidebar (see 9.), which would list:

Basic
> Card 1
> > Front template
> > Back template
> > Styling
> Card 2
etc....

Having “single-object” views allows for an easier UI logic when designing the components, and makes the view more multi-purpose (open the field editor as a modal invoked via a cog / more icon on the fields in the editor, e.g.).

[roxgib]

A sidebar for deck options would definitely be welcome, there are far too many options to all be on a single page. I agree that the overview and deck browser could be merged as well I also agree that Add, Rename, Delete etc should be changed to icons as you suggest. Ideally those would not pop up dialogs as they do now, but have the edits happen in place.

Regarding the template editor, could it be worth trying to integrate the fields dialog into that as well rather than still having a separate dialog? Currently note types has too many different daughter dialogs.

[dae]

@kleinerpirat

simply fade in a pencil symbol right next to the selected deck’s name which makes the deck name editable inline

Like the tooltips Henrik mentioned above, this approach wouldn’t work on mobile or touchscreen tablets. If we keep the separate overview screen, then maybe the pencil could always be visible next to the deck name on that screen instead?

[UTF-1F357]

I have some suggentions
To switch CARD TYPES (is that accurate? I've been using the Chinese version, I don't know how to express this in English) in Anki now , I have to click on this long bar and then a pop-up window will appear asking you to choose the card type, the position of this pop-up window is the same as the last time, which means it’s probably far from the “Add” window. And I also have to double click on the name of the template to select one.

I switch card types a lot when adding cards, and I think this is a bit annoying…
Maybe we could make it one of those drop-down option boxes (I don't know how to say this in English)? Like this
（I found a random picture, I do not think “Search” is necessary）

Or furthermore, let the user can pin a few card types they use a lot on the “add” window?

I don’t know much about WebView development, so maybe these suggestions are ridiculous, I hope you can understand.

Thanks。

[kleinerpirat]

@dae

If we keep the separate overview screen, then maybe the pencil could always be visible next to the deck name on that screen instead?

I would prefer to move the deck overview into a pane on the main view. If there’s not enough horizontal space (mobile), it could slide in from the side when you click on a deck.

Example from Asana

The pane that slides in from the right can contain all the information about the deck, with graphs etc.

[abdo]

@UTF-1F357

（I found a random picture, I do not think “Search” is necessary）

I prefer the search functionality to stay if the dialog is to be converted to a drop-down menu. I mostly select my note types by typing the first letters of the note type name and clicking Enter.

[UTF-1F357]

@abdo

I prefer the search functionality to stay if the dialog is to be converted to a drop-down menu. I mostly select my note types by typing the first letters of the note type name and clicking Enter.

Indeed, for users who have a lot of card types（me too😂）, this way of choosing by initials will be a great help for efficiency.

[UTF-1F357]

I just noticed that Anki already has a dropdown menu, can we apply it to the “Add” window as well? Looking forward to this!
Thanks！

[dae]

@kleinerpirat

I would prefer to move the deck overview into a pane on the main view.

Sorry, that was unclear. I just meant the concept of an overview area between the deck list and the review screen, not specifically a separate window/page.

@abdo

I prefer the search functionality to stay

Yep, I wouldn’t want to lose that functionality.

[BlackBeans]

In my opinion, one of the worst sides of the current Anki UI is the number of pop-ups. Just to give an idea: you are editing a field, an realize you should add an asset with the Asset Manager add on. You have to:

• click on Notes
• click on Manage Note Types, which opens a pop-up
• select the note type
• click on Assets, which opens a pop-up
• select the appropriate asset
• double-click on the asset, which opens a pop-up
• finally, make the wanted change
• click on Ok/Exit/Bring me back to where I was buttons a couple of times

I agree this UI/UX design is not entirely on Anki (the add-on developer also contributed), but this kind of over-popupification, coupled with several-layers-deep-nested menus, is something you meet quite often in Anki.
A simple way to tackle this would be to “flatten” menus and interfaces (which are currently much tree-like, which is good to locate the button you were looking for, but is slow once you know where it is).
Just as an aside, I once used a program (I’ll edit to add the name if I remember it) whose UI was so cluttered of pop-ups like these that it took ages to find buttons, so they finally added a search page for buttons (you could search the name of an UI element, and it would provide a list of links to the menu/pop up where you could find it)…
So, back to flattening, this could either be done with tabs, for instance like in Regressi:

This software is far from having a modern UI, but still I think that it has successfully taken advantage of tabs. This is a regression software with many technical options, whose degree of complexity may vary, and the user knowledge span about these options is quite broad, so it is quite necessary to make it easy to locate the most commonly used ones for the casual user. And, indeed, just with a few tabs (you can’t see it on the screenshot, but the Grandeur | Graphe | Fourier | Statistique buttons actually each switch to a different view, the current one being Graphe), Regressi has covered the main interesting views.
The current view (Graphe) also has a semi-hidden pannel on the left, with Modélisation written on it, vertically. If you actually click on it, or on a button which you should see on the screeshot next to Coord., but which seems to be hidden in this version, the panel spreads for about 15% of the window width, and uncovers other commonly used options.
This means that, from the mainly used view (the Graphe one), you can access pretty much 99% of the options casual users need in exactly 1 click, and this without a single pop-up.

An other way to get rid of pop-ups is to actually let the user chose whether they prefer to have a detached window or not. A good design example using this pattern is gimp. See their own explanation about it for more details. In short, it looks like this:

See how the tools options are a detached dialog, but the tool selection dialog is “docked”, meaning it was detached but the user chose to attach it on the left of their main window. You could also have several “container” windows, letting you take advantage of multiple monitor setups.

Finally, an other great example would be Emacs. Emacs separates entirely the content of a pop-up / menu / view / panel / whatever from how it is shown to the user. The main concept is that each of these elements has a dedicated buffer (we are mainly talking about text-only UI/UX, but the general ideas still apply), then the user chooses how to render them. Either they only look at one at the time, or they split the Emacs’ window in two, three, or however they like (just like a tiling WM), and put any buffer in any frame. It’s simple to switch from any buffer to any other buffer (it’s just a couple of keystrokes away, and you could even have special key bindings to switch-to-last buffer or things like that).
There is a special buffer, called the “minibuffer”, which acts as a universal feedback buffer. Essentially, whenever a component has to prompt some short input, or some message has to be given, there is no pop-up: instead, the bottom of the screen is simply dedicated to show these messages / prompt input. The main advantage is that the focus is handled so smoothly that you never have to move around, Emacs already places your cursors where it should be. (the minibuffer can be made recursive, in case you were wondering). Of course, all the messages are piled-up in a dedicated buffer, and the minibuffer usually only shows the last message.
This works so well that it is completely possible (and it’s even the default in text mode) to get rid of every button / bar / menu, and only keep the frames, and the minibuffer. There is also a powerline that indicates useful information, but I’m not sure what kind of information you could show in Anki that it would be useful to be permanently show.

---

Besides that, I agree with most of @kleinerpirat’s points, except for the first one. It seems to me that UI should not be though to work for every platform. Instead, every platform should have an UI that is though to be the most smooth for that platform. This is because different hardware / software lead to very different standards about what is a good UI, and these standards sometimes are in opposition. This is also true because having a native feel-and-look is an important point for most users, I think, so some effort should be put in that (I especially think about Windows / Mac, since their UI is usually quite different; Linux doesn’t really have a “native feel-and-look”, unless you plan to make Anki a cli app ).

[Rumo]

While I’m surprised to see Gimp as a positive UI example, I agree with your main point about the pop-ups. The Card, Field and Notetype dialogs should all be in the same window in my opinion.
Not sure what you mean by tree-like menus though. I believe they mostly have just one level, and occasionly a second one.

Regarding different UIs for different platforms, that would be ideal. However, unlike other suggestions that also require a lot effort to implement, this would in addition be a long-term maintenance burden. The same goes for supporting different menu modes (floating and docked).
While UI is important, I believe functionality should always come first. This is one of the reasons I love free software: it doesn’t have to advertise with superficialities. It may look worse, but only because of other priorities.

Don’t get me wrong, I’m excited about this undertaking. I only hope, and am optimistic, that it will be done in a way that doesn’t hamper Anki’s progress in stability and functionality.

---

@kleinerpirat

4. Reduce the amount of context menus | Place UI right where features act

Doesn’t a context menu do exactly that? I find them extremely efficient. If e.g. the cogwheel menu was a context menu instead, my eyes wouldn’t have to shift to the right, carefully keeping the horizontal line, lest I select the wrong options. I could much more intuitively click the object I want to edit.

---

I would also love to see improved support for keyboard navigation. Currently, you just can’t do without a mouse.

[BlackBeans]

@Rumo

I would also love to see improved support for keyboard navigation. Currently, you just can’t do without a mouse.

Yes.
Yes.
Yes.

[kleinerpirat]

@Rumo

Doesn’t a context menu do exactly that?

I agree that they can be efficient, but you need to know that the area you’re right-clicking on opens a menu beforehand. If someone never read the manual, that might not be obvious to that person.

Also, their efficiency drops dramatically with increasing numbers of entries and especially with multi-layered items (like in the browser table - cards/notes).

I think the context menu shouldn’t contain more than 4-5 items. Anything beyond that makes it less mobile friendly and hurts efficiency, because active thought has to be put into the selection, whereas discerning lower amounts of items happens without much cognitive effort (almost automatically).

“Outsourcing” some context menu entries to more discoverable positions would therefore be a desirable goal in my opinion.

---

Thanks everyone for the valuable input! Keep it coming

[dae]

@Rumo

I would also love to see improved support for keyboard navigation. Currently, you just can’t do without a mouse.

I’d like to think the common paths are already reasonably accessible with a keyboard - what sort of everyday tasks require a mouse?

[Rumo]

Opening deck options for example. Then selecting a deck is possible with the keyboard alone, and without endless tabbing, but again it requires a separate window and isn’t easily discoverable.

[roxgib]

Deck options can be opened with ‘O’ from the deck overview. Perhaps that can be added to the deck browser as well, opening it for the currently selected deck.

Arguably the search function in the study deck dialog could be added to the main screen, but the problem here seems to be people using an excessive number of decks rather than tagging their notes.

[kleinerpirat]

@roxgib

study deck dialog

Wasn’t even aware of that dialog. Seems like a search bar in the deck browser will make it redundant.

[Rumo]

@roxgib

Deck options can be opened with ‘O’ from the deck overview. Perhaps that can be added to the deck browser as well, opening it for the currently selected deck.

You’re right. I prefer to stay on the deck tree screen though, so I can keep an eye on the hierarchy, which is vital for adjusting settings. Adding the O shortcut there is an excellent idea.

@kleinerpirat

Wasn’t even aware of that dialog. Seems like a search bar in the deck browser will make it redundant.

Exactly. This dialog feels like a stopgap that shouldn’t be necessary after a thorough main screen rework.