Brainstorming for modern UI [Anki 3.0]

Development
22

I think the best way to figure that one out would be to try Anki for several weeks without using one’s mouse entirely.
However, it is still possible to have the feeling that Anki lacks keyboard support even though technically it is possible to do everything without a mouse. For instance, there are UX choices that implicitly favor mouse-usage:

  • keyboard shortcuts customization is hard. It’s not impossible (there are add-ons that solve this issue), but still it’s far from being smooth (I think that’s an easy fix);
  • sometimes, the easiest way to figure out how to perform an action with the keyboard is to find out which button corresponds to this actions, and reading the hover text, which inevitably requires the mouse;
  • the manual assumes you are using a mouse over keyboard-only, which means most of the instructions are of the form “find out that button” or “click that label”.

Basically, all these little details add up to the impression that Anki was though to be used with a mouse, and patch-worked later on to progressively make it theoretically possible to not use a mouse.
This is not a big issue in itself, so I don’t think Anki dev should mainly focus on this, but on the other end these are really small changes to be made so it wouldn’t be that much time-consuming. For this reason, I think it might be worth it to improve keyboard UX.

23

One that I just noted, so I post it here so it might get fixed: when you change a note type, the drop-down menu cannot be accessed (at least, not easily) with keyboard.

24

In all fairness, a lot (probably the overwhelming majority) of users use the mouse unless they have to use the keyboard, no matter how much you push them to the keyboard, and those that prefer to use the keyboard can figure out the commands easily enough (although a page in the manual that comprehensively details the keyboard shortcuts is probably needed - I might type one up and submit a PR).

The code that creates this dialog is actually used in a bunch of other places (e.g. for the deck selector in the new cards dialog) so I suspect the study deck dialog was just added since the basics were there already, whereas adding a filter to the main menu would have been a lot more work. But yes, you’re right of course that it would be better in the deck browser instead of a separate dialog.

2 Likes
25

Yes, that’s quite clear.

My point was not exactly that Anki is lacking a list of shortcuts written somewhere (although it does, and you writing one would surely help). My was is that using the keyboard has a poor UX compared to using a mouse, due to a combination of these factors:

  • keyboard shorcuts are not / poorly documented in the manual
  • it’s hard to customize them
  • it’s hard to find them without your mouse
  • keybindings are not always very ergonomic (for instance, moving with arrow keys is a bit annoying).

Of course, it’s possible for a user to find about them, and once you know them you’re fine. But the goal of a UI is not to make it possible, it’s to make it easy, or even, to make it so seamless that you don’t even notice Anki was though to be used with a mouse.

But I have to agree that this is probably not #1 priority in Anki development.

2 Likes
26

If the user sees a button or menu item in front of them in the GUI, surely it’s faster for them to hover the mouse over it to discover the shortcut, than go hunting for the shortcut in the manual.

3 Likes
27

All true, but at the point that making it more keyboard friendly involves redesigning the UI, I’m not sure the improvement is worthwhile any more, though arguably it shouldn’t interfere much if at all with other UI goals.

I don’t think anyone is suggesting that the tooltips be removed, but having them in the manual makes it easier for a new user to learn them in chunks when starting out. Edit: another point I just thought of is that often there are functions you aren’t aware of until you read the manual. The ‘S’ shortcut is an example - I could be wrong but I don’t think there’s a place to find that in the UI.

2 Likes
28

Hello!

I’ve looked at this topic and I’m quite sure that’s the right place (since you guys are gathering some ideas for what to change in future release of Anki, right?)

It’s not a big deal but imo it would be great if Anki recognised the numeric order - what I mean is that if you name your decks with numbers, let’s say 1-20, Anki places 10, 11, 12 … before 2, 3, 4 etc. Here’s a pic:

image

Thanks everyone and please, if that’s not the right place to post it, let me know where should I take it instead :slight_smile:

4 Likes
29

Anki adheres to alphanumeric order. Just start your decks with a leading 0, i.e. 01, 02, 03… :slight_smile:

3 Likes
30

You can achieve this by adding zero-width spaces as placeholders, e.g. this:

​1.
​2.
​3.
10.
11. etc..

Will look like this:

> 1.
> 2.
> 3.
> 10.
> 11. etc..
1 Like
31

I’d prefer not to use any special tricks to achieve sorting by ascending index. Perhaps we could make a special rule for deck names starting with a number (RegEx), so that they are sorted numerically?

Generally, it can be a bit cumbersome to order decks within Anki. Do they need to have a fixed order in the first place? I think a lot of people would be happy to be able to drag & drop decks wherever they please
(sorted by default, but customizable).

3 Likes
32

Drag and drop is unlikely to happen any time soon, as it would considerably complicate the way the deck tree and queues are built. A natural sorting of numbers is not out of the question, but it’s not without a cost as well.

2 Likes
33

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.

34

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
35

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:

image

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

image

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

image
image538×575 40.6 KB

Proposal

image
image538×575 35.5 KB

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:

2 Likes
36

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
37

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)

image

without borders

image

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
38

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

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.

40

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.

41

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?

2 Likes