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.
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.
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-sourceapp that officially supports addons? To me, these things are so wildly different—
…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.
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
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
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.
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.
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
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
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
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)
(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
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
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