Flags and stars icons hover over text notification

Development & Design Design proposals
1

The Flags and stars label are not properly identified. Users cannot easily tell what the flags and stars label represents

Solution:
The UI interface can be designed to help user get a better and faster understanding of what the label icons represent such that when the icons are hovered on with the mouse, the name of what the icons represent should be displayed like an alert notification. @antonin_d @lozanaross @thadguidry

2

Hi, you may want to create a GitHub issue and tag the mentors to it and of you’re proffering solution, maybe add that too.

3

Ok. Thank you.
Canni use the link to this issue to record it on the contribution project to get registered?

4

Definitely. Use the link as the contribution link.

5

Technically, they don’t represent anything other than a way to mark or map a row/record to a “Category A or B or both”. It could be a green toad :frog: and a blue eye :eye:. However, the way the two icons are used by users is generally that to mark a row/record as “Category A” or “Category B” or both… and long ago in the initial designs we thought a generic blue flag and gold star might simplify the iconography for that purpose without offending anyone.

So I cannot think of a good generic labeling for them. Using “Category A” or “Category B” will likely more confuse even though it’s technically correct historically. Behind the scenes in the code, we represented the marked rows/records by carrying over the icon names themselves as “Flagged” or “Starred” rows/records, so in the code you will not see “Category A” or “Category B”.

I would not bother with hover text over each row, but would only do so in the header.
“Mark as flagged” “Mark as starred”?

1 Like
6

@thadguidry I underdtood the idea behind flag and stars better after going through sone tutorial videos on YouTube, and i realise that both meaning the sams thing can be confusing for users.

May i suggest that using label words like “Bookmark” for stars and “Important” for stars would make better name labelling? Hence the reason for the “Hover text” idea, and not on each row but over just a row for users to fully differentiate between the stars and flag icon.

7

Labeling with your suggested words would only be useful for less than 5% of our current user base who think in those terms with their data rows for alignment. The other 90% of our user base I think really do use them as buckets for workflow processes that change during a workflow. Some rows could be Flagged as “important” in the first 5 mins of working with a dataset, and then the Flags will be removed and reused for a different purpose of “Not Important at ALL because its Missing A Feature Pattern Don’t See” and the Stars used for maybe “No Country pattern in row columns thus far”, or could be anything they want or mentally model by their workflow needs thus far in working with a dataset.

  • Apples/Oranges
  • A/B
  • ReviewedItAlready/NotYetReviewed
  • HasTrueValueFromPreviousFaceting/DidNotHaveaTrueValueFromPreviousFaceting

I’d suggest to instead work on improving the docs area where this is covered to maybe make them more clear: Exploring facets | OpenRefine ?

@ostephens any thoughts?

8

@thadguidry Thank you for making this ckear and thank you for your kind suggestion. Should i raise an issue on github with the Topic “Improving the docs area for flags and stars”? Bearing in mind that i am a UI/UX designer.

9

It’s very tricky. By design, currently, the stars and flags are neutral in meaning - they only have meaning as far as the user decides to use them - basically they just provide a way of creating two arbitrary sets of rows

I describe how I sometimes use stars and flags at Hints, Tips and Tricks - #4 by ostephens

Based on this I definitely don’t like the idea of assigning specific meaning (like “important”) to either of these existing mechanisms. I can certainly see that being able to define an arbitrary number of different sets might be useful - which I think is what is being proposed by @thadguidry in this issue Idea to add better and new Selection Labeling for Rows/Records (not only Star and Flag) · Issue #4483 · OpenRefine/OpenRefine · GitHub. However - I’d also be a bit wary of over engineering this - the advantage of the flags/stars mechanism is it’s simplicity - as soon as it becomes more complicated I feel it loses it’s current utility

An approach I might see working (which I think goes beyond simple UX improvements) would be a tagging mechanism for rows which might be used in addition to the star/flag mechanism.

2 Likes
10

@ostephens Thank you on further explanation of the Stars and Flag. Further research has made me come to the conclusion that its usefulness is in its simplicity.

1 Like
11

I am stumbling on this issue also on my side, as I am working on keeping track of which columns are affected by each change recorded in the project history. Essentially, the stars and flags form two special boolean columns which are always present in projects. The fact that they are special means that, well, we handle them as special cases in the code, which is quite difficult to work with internally. Nothing that can't be overcome, but it feels a bit odd to be crafting all those special cases given that the feature isn't fully satisfactory from a user perspective:

  • as a new user, it's unclear whether those stars and flags have a particular function (see @Ebere 's first post in this thread). The intended use of those buttons is not self-explanatory.
  • as a user who understood the purpose of stars and flags, I am limited to two of those special columns (I cannot have a third one with another symbol). I cannot rename the existing two columns. I cannot remove them if I want to save space on my screen.

That being said, it's definitely a feature that is used and I don't think it can be just removed.

I think there are multiple ways we could get out of this situation:

  • let the user add or remove those special columns. Perhaps we can offer a collection of symbols that people can use to define new annotation columns. We could keep only one by default. The fact that users would be able to add more of those columns would perhaps make it clearer that it's up to them to decide what those mean (just like any other column in the project).
  • or remove them entirely, but make it super easy to use a regular column with boolean values instead. For instance using @Antoine2711's idea to render booleans as checkboxes that the user can modify just by clicking on the checkbox directly. We would also need to provide a similar option to "(un)tick all the checkboxes of the currently filtered rows in that column"

To me the second option would be pretty nice and flexible, because it would also ease the use case of working with any other boolean column, make it possible to move those annotation columns anywhere in the table, and so on. But one would need to design the UI changes pretty carefully, so that people are able to switch to this workflow easily and discover it in the first place.

What other designs can people think of?

It's not a blocker for my work, as I can work around the issue, but I did not want to miss the opportunity to give more steam to this interesting design problem :slight_smile:

1 Like