Brainstorming for modern UI [Anki 3.0]

I agree with that. Even figuring out a single correct UI is hard, let alone having a bunch of for the user to choose from (because, in the end, the number of users who would actually customize Anki on their own, and not use a theme made by someone else, is probably very low, too low for that being worth it).

The point is also that a good UI design is not necessarily harder to code; it’s just hard to think of it, but once you have it, it may not be a big overhead to implement and maintain it. That’s what we should aim at.

3 Likes

Well, it would but the bulk of this work would be cleaning up the mess in the HTML. This is something you want to do regardless, don’t you? In the end, you could have something like this:

<toolbar id=editor_toolbar>
    <button-group id=links>
        <button id=fields class=text_button>Fields…</button>
        <button id=cards class=text_button>Cards…</button>
    </button-group>
    <button-group id=text_style>
        <button id=bold class=icon_button>
            <img src=… />
        </button>
        ...
    </button-group>
</toolbar>

And once you have that, you are basically done. CSS can deal with the rest. I do not think this would be hard to maintain?

What might look like a mess at first glance is the result of a rather well structured use of Svelte, Anki’s JS framework of choice.

It makes it a lot easier for devs to create and reuse dynamic UI components. Add-ons that are currently manipulating the DOM directly will have to start using the API instead. It’s for the better.

Choose any big web service and inspect its HTML - it will almost certainly be generated by some framework and have weird class names, deeply nested structures etc.

1 Like

Just go to google.com, click on View Page Source and convince yourself how much this is true (besides just the minimization step to make the page load faster; you can pretty-print the HTML to undo it).

I really wonder if this “well structured” approach helps. I may be grossly mistaken here since I don’t know Svelte and PyCharm doesn’t seem to support it, I have to wonder if not using Svelte would simplify things a lot. It greatly fragments the code. There’s a ton of boilerplate. It seems the main selling point of Svelte, reactivity, is barely used. I tried looking into where the issue of different distance between buttons comes from and I kind of gave up. I have to think that the way the editor UI is a mess of misaligned things is a direct result of using Svelte. I don’t see how this could happen if you had clean HTML and obvious places to look for CSS rules.

I bet most Svelte files have a single author. And, apparently you can’t write easily styleable HTML with it, or so I am told. Perhaps it’s a wrong tool for the job?

Don’t know what exactly Google is doing but they intentionally obfuscate and confuse thigs a lot. Their aim is kind of the opposite of writing consistent HTML. Besides, they don’t have to care for open source contributors, or people writing addons for their page. Their goal is to break your addons.

P.S. Having consistent HTML would also make Anki add-ons not to break so often, since Add-ons also do access it.

2 Likes

Not quite. It may be true that Google tries to obfuscate some of the code it provides, but not all of it, since some parts are just libraries (and, indeed, if you look at their source code, you’ll see it includes the copyrights of these libraries where their source code is present) What probably happens is that Google engineers use a framework (much like how Anki developers use Svelte) which then transpiles their code to a minified version that also includes whatever runtime their framework needs. Note that this step also includes open source libraries they use. This is the main reason you get an absolutely horrendous result when you try to read their page source. So, basically, when you start writing HTML / CSS / JS / whatever with an additional layer such as a framework, it’s quite easy to produce code that becomes unreadable. If think that’s what @kleinerpirat meant when he said “what might look like a mess at first glance is the result of a rather well structured use of Svelte, Anki’s JS framework of choice”.

Maybe I’m wrong, because I don’t know Svelte much, but it seems to me it’s more of a JS framework than an HTML / CSS framework, in the sense that Svelte source code is a super-set of HTML, which includes a “new” scripting language that gets translated to JS.

Not quite what exactly? I’m not saying that noone should be using frameworks or minification or obfuscation. Yes, Google are probably using something? Probably many things? But how is fact that Google is using something on their propietary web page that doesn’t offer any official support for customization is a reason to use similar techniques in an open-source app that officially supports addons? To me, these things are so wildly different—

It’s actually just devs not being super finicky with this stuff right now. As long as the translation of the editor into Svelte isn’t finished, polishing the UI isn’t a priority.

"One of the biggest traps for smart engineers is optimizing something that shouldn’t exist.” - Elon Musk


I feel this discussion is going off-topic. We will not see Anki suddenly drop its well-established framework.

5 Likes

…I think I wasn’t fair with Svelte. I took another look at the code, and I assume that what I see means, for instance, that

  • Text buttons get the class label-button, but the Svelte element styling is instead done on button so it becomes svelte-u7952r, so you can’t reuse it.
  • You can change to dark mode by adding the class night-mode to html, but this is not used to style the buttons, instead, somehow this goes through JavaScript, which adds the class btn-night to the buttons.
  • Stuff like button border radius is hardcoded in style= parameters, and is given for certain buttons exlicitly instead of styling button group elements such as :first-child. If I am grepping right, there are more than 30+ places in the code where the 5 pixel button radius is hardcoded…

Anyway, I only hope that Anki doesn’t get a very dark background color. Although— I’ve got a friend whose eyesight is even worse than mine; he’s using high contrast themes in apps, and swears by pitch black backgrounds. I guess he’d disagree with me. Thankfully he doesn’t use Anki :sweat_smile:

2 Likes

That’s one of the first things I’d like to fix with future theme PRs. Such values should be defined in a single Sass file :+1:

I would also prefer a more CSS-heavy approach over JS calculations and inline styles. Maybe this can be improved as well, but my gut tells me there are reasons for the current approach that I can’t think of currently.

2 Likes

Actually, I would like the ability to remove individual buttons. For instance, I never user underlining, but I often use bold and italics.

But I can imagine that I may want to use underline one day, just this once. Perhaps, instead of just hiding, I could press a special menu button (triple dots?) that opens a menu with all the hidden buttons. This could be similar to how e.g. Edge allows hiding extensions buttons from its toolbars. This would also help users to not forget that functionality that they have hidden exists in Anki.

I am sharing here the results of my work on Anki design and adding a lot of important features (in my opinion).

Everything is written in Hebrew because that is the language I speak. Can be translated using:

Maybe one day I will have time to translate it and upload here to everyone (especially not being hired for it).
I have so far uploaded one addon which is an extension of the deck menu.
https://ankiweb.net/shared/info/576235837

Much of my work is based on other addons such as Beautify_Anki.

1 Like

The interface is undoubtedly more appealing visually, but unfortunately it’s a bit hard to tell precisely what has changed, in the sense that when you show the features it’s hard to tell what is happening (at least for me because I don’t speak Hebrew, and because the UI is changed so much it’s hard to recognize buttons).

If you wish to submit these changes to see them implemented in Anki, could you please make a precise list of each change, so we can discuss them?

Here is a translation of a list I wrote for myself. If something is not clear write me and I will try to explain (Translated by Google Translate):
1 Update the software interface so that it is clearer
1 Edit menus throughout the software.
1 “Add Deck” button moved to the top row
1 Add a “Question Filter” button to create a filtered pack
1 Delete the buttons on the main screen below.
1 Option to click on any bar that displays the deck in the main window to start and right-clicking on the mouse will open the menu that was in the gear (several options have been added to the menu)
1 Change a selected deck on the main screen by navigating the keyboard
1 Add in the context menu of a filtered pack the options for emptying and rebuilding
1 Open a deck menu by right-clicking on the deck name or the entire row
1 Approval is required before deleting a deck
1 Add a glossary to the Help menu
Option to remove the progress bar 1
editor:
1 Removing useless buttons on the editor
1 Copy question content to a new question window using the menu option
1 Update all right-to-left tabs in the editor as well
1 Text enlargement and reduction button has been added
Showing questions:
1 Hide an answer after clicking “Show Answer” using a button in the More Options menu
1 Move the Push button to the right and change a translation that explains more what it is doing
1 in full screen mode test - hide the icons bar and display only the text and not display the words bar later
1 Change the text of “Back to previous question to” Cancel last action "
1 Hide the plugin’s toolbar in full screen
browsing:
1 Move the bar by scrolling to the right - a new profile needs to be opened
1 Add option to sub-tags (defined by writing the name of the parent tag and then double dots and then the tag. For example: Parent tag :: sub-tag)

Update 3
Shortcut Manager:
(Editing while reviewing - automatic change of all tabs to the enabling mode)
Add an option to create a subpack in the deck menu
The “Mark” button in the test was returned
Add links on the main screen for browsing and statistics
Fix the bug by deleting / emptying a deck of cards for treatment that disrupts the date

  • On the main screen - add a tultip above each of the things that will explain what it is.
    Add to the statistics on the main screen also “Late” “Today” and clicking on them and “Total” will start a test according to the clicked category.
    Allow the rows on the main screen to shrink so that more decks can fit on the screen
    Alert by clicking “Today” if there are too many questions late
    Also formulate in a circle the statistics on the test screen as on the main screen
    Add in the deck statistics an indication that there are tickets beyond the daily quota
    Convenient button for rescheduling
    Number of questions for tomorrow on the main screen.
    Option to print - design or just content - questions and then answers - numbering - by due date - check in the name of the tag and if there are no matching cards for printing - option to save an HTML file or just print. Create a filtered pack containing all the questions printed in the same order.
  • Date above the answer button When will there be a next return if he clicks on this button (and not just a day interval)
    Hovering main bar
  • Display according to a Hebrew calendar
    Improved appearance of buttons and menus
    Anky Zoom
    New installation program
    While studying the name of the pack in the title of the window
    Redesign for some of the records - support for built-in night mode
    Move to give a deck of another deck easily by a panel in the deck menu
    Statistics re-scheduled today were added to the statistics
    Full duplication of tickets including due date
  • Font size menu and font type in the editor
    Update the advanced settings to the back row of buttons
3 Likes

Some important points in my user interface:
I only have two menus on the main screen - “General” and “Help”. It is very effective in preventing confusion and searching for options.
2. The statistics are “clickable” - a related action such as opening a browser or review is performed on each statistic.
Point to think about - it is recommended that the order of the cards during the review be arranged from the beginning of the review to the end - from the beginning of the review (and not like now that after a few cards the order is updated.) This will help- Skip button and return to previous card and view all cards in the browser during the review

I would like to comment on the awkwardness of adding a question:

Opening a window with several fields, and moving from field to field in order to fill each field with text or image or audio, is something that is a bit suitable for “nerds”. (I mean in the positive sense of the word)
Today, people need a computer that will work according to their pace of thinking.

For example, I suggest that when a question is added, one “Question” field will appear. with the “next” or “back” key [where the default is “next”.]

When “next” brings you to the second field. When at the end of the fields, a “Preview of the question” will appear with the “OK” key, or “Choose a field to edit”.

There is no contradiction in this, there will be an option (by a dedicated key), which will bring you to the traditional editor.

Today the situation is that when you add a deck, apart from having to choose a record type, you also have to choose which deck to put it in.

I think it’s super outdated!!

What should be is just like in real life, adding a question to the deck should be from the deck.

Just like you open a folder/document in “windows”, you are inside the folder and add a new folder there. And so on.

My suggestion, that adding a question will be from the deck, then all that remains is to choose which type of record you choose.

Anki is made for nerds, though. The freedom provided with note templates is what separates Anki from other flashcard software.

Regardless, I don’t quite see the benefit of your suggestion to only show one input at a time. One field doesn’t always equate one question and the content of fields is usually related, so it’s best to see several of them at once :thinking:

This makes sense. However, you don’t need to choose between the status quo and that. We can simply make Anki pre-select the active deck when the Add-window is opened during review / from the deck overview and maybe add a + symbol somewhere next to the deck name in the main window - in sum, make the add-mode more accessible.

Or did I misunderstand your proposal?

2 Likes

I certainly agree with you on who Anki is for… still, I’d rather put my skills into memorizing the cards than making them.

Although, I would not want to reduce the freedom that exists in the hands of the user.

That’s why I focus on suggestions that will make it easier for the user without detracting from the existing features.
for example:

Surely you wouldn’t object to including an option, editing the CSS as usual with brushes, and stretching the boxes with the mouse, something like that (of course without canceling the code control option - as it exists today)

Since there is no objection to simplifying processes as long as they do not detract from the existing options

After you have entered the front side, > next, the question that appears in the previous fields will appear in the window as a title or as a reduced text (perhaps even including an option to enter editing!!) , and the input will focus on the answer side.

The benefit of this, that it clears the head and allows you to focus on the current field, even so there is a lot to deal with. (Text, HTML, audio, text design, etc.) Those like you who specialize in UI / UX know how much visualization affects the experience and learning.

thank you for the treatment!

Your suggestion will surely add benefit to the user, if only to keep the choice “to which deck to associate the card”

Another advantage can be obtained by completely removing the “add” button, when adding the cards will always relate directly to the deck.

The logic that guides my thinking about designing anki in the next generation, is the same logic that led Bill Gates when he launched “Windows”, to make the user understand that the software works like in the real world, that is, there is a desktop, documents and folders are placed on it, documents are placed inside the folder and so on .

In my opinion, this is also what anki should strive for, that the feeling of adding a card to the deck will be natural.

Sorry for the monologue… if there is a problem with it, you can split the topic for me :slight_smile:

1 Like

Thank you for elaborating!

This is very important for me too. I’m happy to implement any proposal that meets this criterion.

Regarding your suggestion on showing less inputs at once in the editor: Maybe we can come up with a mode that makes it easier to focus on the current input. It sounds like a challenge to get this right without losing ease of access and is certainly a “luxury problem” right now. There are more pressing issues to solve, but this thread is the right place to express such ideas, so thank you!

Actually I would probably object. WYSIWYG HTML editors are a bit uncanny to me. They often do not offer the same level of control over the final output as manual coding. This can result in code that is not as efficient or optimized as it could be.

Anki Palace have created an add-on that gives layman users a UI to style AnKing notetypes. I see the appeal and it seems to work well for their specific notetypes (haven’t tested), but doing something like this generally is a different ball game. We’d need to make sure our users are not accidentally bloating their content with inline styles or unnecessary HTML tags. Also, offering the userbase such a new feature to depend upon adds a major maintenance burden to the dev team.

TL;DR: I’d be very cautious with any sort of visual interface for HTML/CSS, as it might have unwanted consequences.

3 Likes