Position of the Tag Editor in 2.1.50

I’ve already alluded to it here, but I wanted to make a proper case for it: I think the tag editor in the editor should go above the fields.

  1. The logical reason:

Tags are usually used to roughly categorize a note, put it into a wider context. This makes it the closest a note has to a title.
The following note is from the Anking deck:

To understand the note, it is the best to start from tags: (I might get some meanings wrong):

  • DELETE could mean that the card is going to be deleted soon: It might not be necessary to fix issues?
  • Neuro could mean that the card is generally about neurology

So to understand the note, the eyes first jump to the bottom of the window, and then back to the first field. This general idea of putting tags over content is also pervasive in other application I can think of (e.g. note-taking apps). The only case where tags are typically put after the content is tweets :grinning_face_with_smiling_eyes:

  1. Practical reason:

The tag editor is currently in a fixed (sticky) container at the bottom. At some point we will want to adopt this editor on AnkiMobile as well. I think a sticky container at the bottom of the screen would be a bad design choice on mobile.

I also think this reduces the visual clutter a little.

  1. The solution:

I think the best option is to put them above both the fields and the buttons. One problem with the tags in their current incarnation is that they look to similar to buttons. In the mock-up below, I’ve slightly adapted their look, that they stand out against buttons, but I’m also open for suggestions:

2 Likes

For me, a note title would the first field or fields that appear in the front of cards (the “prompts”). Note tags are more likely to be common to many other notes, so they don’t uniquely describe a single note, as I expect a title to do.

I personally find tags on top more cluttered, as they are now closer to many other GUI elements (editor buttons and deck/notetype choosers). The tag drop-down menu will also obscure other elements if opened downward, or have less space to expand if opened upward.

3 Likes

+1, that mockup seems a bit off. But we could make the tag input a multi-select (showing only a few tags, but expandable as dropdown) to prevent clutter up there.

I’ve been working on a simplified component based on https://svelte-multiselect.netlify.app/ for the Change Notetype screen and Deck Options, but had to pause that endeavour when uni caught up to me.

Unfortunately, I won’t be able to work on it til February. Perhaps I can send what I have to you @hengiesel to take a look at it?

Edit:

My experimental branch

I updated and published that branch: GitHub - kleinerpirat/anki at multi-select
This was a very rough proof-of-concept, basically a super-stripped down version of the original (especially regarding the logic, which I didn’t touch). It’s implemented as a single-select in the Deck Options and Change Notetype screen.

Add window

Putting the tags up there somewhere near the deck selector might give the tags a bit more attention from users who are currently using decks to structure their collections.

I often find myself forgetting to put tags in and have to add them afterwards from the browser. A more rigid system (with perstence after closing/reopening) would help, too.

2 Likes

Fair. Note title was the wrong way to describe it. They categorize the note.

Also fair. I already acknowledge in that I would certainly would want to change the look of the tags, to make them resemble the top buttons less.

I had a look at your experimental branch: Great work on the SelectButton component. Even though it still needs some tweaking, just by lacking that initial flash, it might be better than built-in <select>.

Integrating MultiSelectButton into the tag editor is also an interesting idea. In fact I think a tag editor and a MultiSelectButton are not that far apart. Probably a good portion of code could be shared between the two.

Yep I agree here.


Warning, some rambling ahead:

For post-2.1.50 I intend to port the Notetype/Deck buttons to Svelte, and here’s a rough mockup of what I imagine that to look like:

Maybe now you could see another motivation of why I’d want to put the tags on top :slight_smile:

The Cards… and Fields… buttons are now icons on the right side of the notetype. Clicking on the name, changes the current notetype. The second icon are the cardtypes, and the third button are the fields (after all, they are they characterize the notetype written to the left of them).

Another benefit of moving out the Fields… and Cards… buttons is, that now all off the formatting buttons are inactive, when the focus is outside of a field. So if the tag editor (or another component / window) is focused, we might as well collapse it:

In fact, we could actually give the notetype and deck buttons a similar design to the modified tags (disregard that a field is focused):

(Note that I don’t mean the above as an argument, to move the tags to the top now. If anything that change must make sense by itself :slight_smile: )

2 Likes

I’m not so sure about moving tags to the top. They are an optional feature, and many users don’t use them at all. For those that do use tags, if we consider the initial input stage, I wonder which order the majority of users would consider more logical - inputting content and then tagging it, or vice versa? The current approach mirrors things like Twitter where the tags tend to come at the end.

But ultimately what matters is what the majority of users think, not what I think :slight_smile: If we do consider changing this without an option to keep the tags on the bottom though, the ratio of people preferring on-top vs on-bottom will need to be pretty high, as I’m sure there will be people complaining that things have moved.

Regarding the deck/notetype selectors: 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”. There’s currently no distinction between the icons associated with the two dropdowns, and the icons that modify the active dropdown. Maybe some alternatives we could use there are to embed the cards/fields icons inside the white square like is done with the field labels, and/or we could switch them to a hamburger menu.

1 Like