Brainstorming for modern UI [Anki 3.0]

Development
3

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:

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:
Screenshot 2022-02-11 at 00.37.13

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.).

5 Likes