If the user completely erases a sticky field, that should automatically unstickify it

Suggestions
1

There are some cases where users accidentally turn on the “sticky field” icon, perhaps with a stray mouse click, and then are mystified and frustrated that the text in the field persists. Two recent examples are shown in the links at the bottom of this post.

Perhaps there is a simple solution.

If you intentionally stickify a field, that means you want to either keep its existing text or at most only edit it a bit. So if instead you completely erase the field and reset it to blank, that means the stickiness was a hindrance rather than a help to you. It caused you to take extra effort to achieve a result (a completely blank field) that you could have gotten for free by default. So if a user completely clears a sticky field, that strongly indicates that they probably did not want the stickiness in the first place.

So I suggest that if a sticky field is completely erased by the user, that should automatically unstickify it.

This will rescue the naive accidental sticky-icon clickers, and should not inconvenience users who intentionally use sticky fields, because this new behavior will be consistent with their intent. Indeed, they will now be able to unstickify a field without a mouse click, using only the keyboard (using Tab and Shift-Tab to move between fields).

Examples of hapless “stuck” users:

2

There’s still a chance of that - if the user want to add 3 notes with “foo”, then 3 notes without anything, then 3 notes with “bar”, the suggested approach would require them to turn the pin back on again after the empty input. The issue you’re trying to solve is a common pain point though, so perhaps it would be worth the trade-off.

2 Likes
3

Boolean fields only ever filled with “y” or nothing should always stay sticky.

1 Like
4

I can see how this could be useful, but, personally, I would find it quite inconvenient. My note type has many fields that I always want to be sticky, and having to pin them back every time they are emptied would disrupt my workflow.

If changes are to be made, I would appreciate if they were at least introduced as an option (maybe defaulting to yes, if that is the more “new user”-friendly behavior).

For example, something along the lines of:

image

1 Like
5

I’d prefer not to add yet another option. With two people voicing how the change would inconvenience them within an hour of my reply, I think it’s probably best we not make this change. Maybe we could make the pin more visually obvious when enabled, instead.

5 Likes
6

@Aleksej @jcznk Are there any situations in your normal workflow where you would completely erase the same sticky field twice in a row for creation of consecutive notes? Or three notes in a row?

I think with two or three consecutive erasures the probability of a frustrated user is very high.

7

The first field and the originaltext field of most of my note types is sticky. I create cards from the same phrase in different notes (helps with MorphMan), and cards with different pictures and the same name of a person.

8

Okay, but if the original “erasing the field (one time) unstickifies it” proposal would be disruptive to your workflow, how about “erasing twice in a row”?

In other words, when creating multiple notes one after another, would you ever find yourself completely erasing a stickied field again and again when creating two or more new notes in a row? I didn’t get a clear sense of that from your response.

We’d expect a frustrated and floundering user to keep erasing the stickied field over and over and wondering why the sticky text keeps returning. Would two erasures in a row be a high enough threshold to conclude that this is indeed that kind of user and probably not a sophisticated user using the stickied field as intended?

9

I would prefer the field to be sticky when I open the Add window. If it unsticks when I clear it twice in a row after that, it’s not a problem, but I doubt Damien would add that.

10

I suggest doing the same thing as the editor buttons, I think that would solve most of the issue.

image

1 Like
11

Yeah, I guess there are such situations, maybe even quite often. Since I usually keep the ‘Add’ window open in the background without ever really closing it, and I tend to use the same note type for all my cards, I do often end up adding multiple unrelated notes consecutively.

However, personally, this still does not make me feel the need to unstickify the fields. I prefer having to delete the content of the fields rather than going back to the Browser to fetch some text/media from the previous note, and/or having to remember to re-stickify a field before adding the note. Overall, I find it requires less mental effort.

This add-on also helps make clearing unwanted field content much less tedious: Clear all fields - AnkiWeb.

12

Hmm, what if it was two-pronged?

  • Completely erasing a stickied field twice unstickifies it,
    and
  • Stickifying an empty field automatically brings back the contents from the previously saved note.

That would eliminate the problems mentioned in the message text I quoted above.

Maybe some experimental add-on could eventually try to implement some of the above notions.

But yeah, perhaps highlighting the sticky pin is a simpler approach.

Some vague thoughts:

  • Moving the pin icon to the left-hand side instead of the right-hand side? That’s where users are looking when they’re entering text.
  • Making the icon look a bit more like the tilted emoji pushpin character? ( 📌 Pushpin Emoji ) The current version is perhaps bafflingly nondescript.
  • Making the icon itself inactive and putting a Qt checkbox next to it, which would do the actual function of turning stickiness on or off?
  • Having the checkbox floodfill with a pale off-white background color when turned on, which could perhaps even be echoed by having the stickied text field itself switch to that pale background color, as a visual cue of a different mode being in effect.
13

I’m sorry, it just feels too complicated.

That would mean the icons move depending on the length of the field name, which can look a bit untidy. I think the suggestion of using a color highlight may be the best - it would be easier to see out of the corner of one’s eye, if the user has the add screen maximized and is focusing on the left.

Adding color would be too distracting I think, but if someone with graphic skills can propose a tilted pin icon that better matches Anki’s current UI, I’d be happy to consider it.

Checkboxes increase visual noise, and would be inconsistent with the HTML editor toggle.

14

I have no graphic skills at all, but I found this pushpin SVG with a quasi-public-domain Creative Commons CC0 license, and just resized it to 11x11 (the current vertical pushpin icon is 8x11).

Here is the original hollow version and a filled-in version.

Screenshot 2023-12-26 031712
Screenshot 2023-12-26 031931

What do you think? They seem sort of OK to me. Anyways it was minimal effort on my part, so I don’t mind if it’s rejected. The source code (modified from the original) is below:

The hollow version:

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- Adapted from https://www.svgrepo.com/svg/4879/push-pin License: CC0 -->
<svg fill="#a0a0a0" height="11px" width="11px" version="1.1" id="Capa_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
         viewBox="0 0 490.125 490.125" xml:space="preserve">
                        <path d="M300.625,5.025c-6.7-6.7-17.6-6.7-24.3,0l-72.6,72.6c-6.7,6.7-6.7,17.6,0,24.3l16.3,16.3l-40.3,40.3l-63.5-7
                                c-3-0.3-6-0.5-8.9-0.5c-21.7,0-42.2,8.5-57.5,23.8l-20.8,20.8c-6.7,6.7-6.7,17.6,0,24.3l108.5,108.5l-132.4,132.4
                                c-6.7,6.7-6.7,17.6,0,24.3c3.3,3.3,7.7,5,12.1,5s8.8-1.7,12.1-5l132.5-132.5l108.5,108.5c3.3,3.3,7.7,5,12.1,5s8.8-1.7,12.1-5
                                l20.8-20.8c17.6-17.6,26.1-41.8,23.3-66.4l-7-63.5l40.3-40.3l16.2,16.2c6.7,6.7,17.6,6.7,24.3,0l72.6-72.6c3.2-3.2,5-7.6,5-12.1
                                s-1.8-8.9-5-12.1L300.625,5.025z M400.425,250.025l-16.2-16.3c-6.4-6.4-17.8-6.4-24.3,0l-58.2,58.3c-3.7,3.7-5.5,8.8-4.9,14
                                l7.9,71.6c1.6,14.3-3.3,28.3-13.5,38.4l-8.7,8.7l-217.1-217.1l8.7-8.6c10.1-10.1,24.2-15,38.4-13.5l71.7,7.9
                                c5.2,0.6,10.3-1.2,14-4.9l58.2-58.2c6.7-6.7,6.7-17.6,0-24.3l-16.3-16.3l48.3-48.3l160.3,160.3L400.425,250.025z"/>
</svg>

And the solid version:

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- Adapted from https://www.svgrepo.com/svg/4879/push-pin License: CC0 -->
<svg fill="#000000" height="11px" width="11px" version="1.1" id="Capa_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
         viewBox="0 0 490.125 490.125" xml:space="preserve">
                        <path d="M300.625,5.025c-6.7-6.7-17.6-6.7-24.3,0l-72.6,72.6c-6.7,6.7-6.7,17.6,0,24.3l16.3,16.3l-40.3,40.3l-63.5-7
                                c-3-0.3-6-0.5-8.9-0.5c-21.7,0-42.2,8.5-57.5,23.8l-20.8,20.8c-6.7,6.7-6.7,17.6,0,24.3l108.5,108.5l-132.4,132.4
                                c-6.7,6.7-6.7,17.6,0,24.3c3.3,3.3,7.7,5,12.1,5s8.8-1.7,12.1-5l132.5-132.5l108.5,108.5c3.3,3.3,7.7,5,12.1,5s8.8-1.7,12.1-5
                                l20.8-20.8c17.6-17.6,26.1-41.8,23.3-66.4l-7-63.5l40.3-40.3l16.2,16.2c6.7,6.7,17.6,6.7,24.3,0l72.6-72.6c3.2-3.2,5-7.6,5-12.1
                                s-1.8-8.9-5-12.1L300.625,5.025z"/>
</svg>
15

One more thing occurred to me just now:

The pushpin is positioned right next to the scrollbar. That might be a reason why some people activate it accidentally with a slip of the mouse. Perhaps the < > icon and the pushpin could trade places?

16

I’d need to see it in situ to know for sure, but in principle I have no objections to using that icon and switching the order (the latter may interrupt some people’s muscle memory which is unfortunate, but this is a common issue that would be nice to address). Anyone feel like working up a PR?