small changes to genotype management pulldown menu

[ValWood]

This menu isn't very popular, because if you don't have mouse control and go completely horizontally, the menu "slips" to the next gene.

We don't have any practical ~selections~ suggestions for an alternative. However, we think a couple of small improvements might help a little.

• [x] If at all possible can we increase the font size slightly here? Is the font size the same as the table, or slightly smaller?

• [x] Swap the order of the options so that the most frequently used are at the top. This would be: i) copy Edit ii) edit details the rest

[kimrutherford]

This menu isn't very popular

I don't like it because I think it's odd to have a menu that pops up when you mouse-over.

We don't have any practical ~selections~ suggestions for an alternative.

We could go back to how it was originally. We had an "actions..." link at the end of each row. When you click the link, the menu pops up.

[ValWood]

We talked about a similar option whereby if you click on a row the pop-up menu is stably associated with the row until used. This invokes an additional click and was vetoed by some because of this. The old "actions button" also requires an additional click. But maybe this is better. We can discuss today.

[kimrutherford]

I'd prefer a click either in the row or on a link to get the menu because it seems more normal to me. A link (like "actions...") is more obvious as it makes it clear to the user that they can click.

[jseager7]

My suggestion isn't really a small change, but have you ever thought about using icons for the row actions instead? Here's a mockup:

This makes the actions less obtrusive. We can still add tooltips to explain what the buttons do, similar to what GitHub and other sites do for their icons:

We could also add text with the icon when the action needs to be more obvious:

And because the icons can fit into the same vertical space as a row, we could have them visible all the time, meaning no extra clicks are needed. (Note the following example removes some styling to keep the interface less cluttered)

One disadvantage of having the buttons so tightly packed is that it's probably going to be easy to click the wrong one, but this is no worse than the menu we have at the moment (since the text and the line spacing is too small).

If anyone is bothered by the extra visual 'noise', we could make the icons very faint until the user mouses over a row, then the icons for that row become more obvious, for example:

[jseager7]

Otherwise, I'd support the idea of having an 'Actions...' link that shows the menu on click, although I agree the extra click could be irritating for expert users.

Maybe a better way to fix the efficiency problem for expert curators is to allow them to use keyboard shortcuts for common actions instead – unfortunately Canto doesn't really have any support for this at the moment.

[ValWood]

I don't really like the idea of icons because some will not be as intuitive as text for community curators. Keyboard shortcuts could be useful, but I'm not sure it would save clicks because you would need to select the row, and then the shortcut...

[jseager7]

I don't really like the idea of icons because some will not be as intuitive as text for community curators.

I agree it's not as intuitive initially; that's a common flaw of icon-only interfaces. I suggested the tooltips to get around this problem, but that still requires the user to have some intuition that they should mouse over the icons in the first place. Once the user memorises the functions of the icons then it's more efficient. Maybe we could make this feature optional for 'advanced' curators.

Keyboard shortcuts could be useful, but I'm not sure it would save clicks because you would need to select the row, and then the shortcut...

Selecting the shortcut wouldn't be necessary, because you'd have a hotkey for actions like 'annotate', 'edit', and 'copy and edit'.

Say it's possible to create a genotype with the keyboard (by creating an allele): Canto already automatically 'focuses' that row visually, so it should be possible to make the row automatically selected with the keyboard. Then all you have to do to start an annotation is hit a key – for example, A. You could probably tab between the genotypes in the list with the arrow keys too.

You can see this sort of functionality in action if you press Ctrl + B in the GitHub comment window: it automatically inserts markup for bold text. Google allows you to navigate through its search results with the arrow keys, so all this is technically possible to do. I have no idea how easy it would be to implement, though.

[ValWood]

but that still requires the user to have some intuition that they should mouse over the icons in the first place. Once the user memorizes the functions of the icons then it's more efficient. Maybe we could make this feature optional for 'advanced' curators.

The issue here though is more about how to make things obvious to the community. Unfortunately, they do not curate regularly enough to remember these things so for them it would be frustrating. I don't think it would benefit curators so much (we would be happy with text links but were avoiding that due to the visual clutter for our community users). It's difficult to get a good balance but provided it isn't really slowing curators down we can live with a little
hardship if it makes community curation easier.

[jseager7]

Is the font size the same as the table, or slightly smaller?

The font in the genotype actions menu is smaller than the font in the table. The size of the action menu font is 12.96 pixels, while the table is 14.4 pixels.

If at all possible can we increase the font size slightly here?

It's easy to do this. Here's how it looks when it's the same font size as the table:

Note that this slightly increases the risk that the popup will get crushed against the edge of the screen, but not by much.

Swap the order of the options so that the most frequently used are at the top.

I think rearranging the list options will be useful for frequent curators, but not so much for irregular curators and newcomers. I think anybody new to Canto should be shown the phenotype annotation as the first option, since phenotype annotation seems to be the primary focus for most Canto instances. Also, do we know what the most frequently used options are for all curators? Because they could be different.

---

With regards to the debate about clicking or hovering for showing the genotype actions, could we have it so that the actions show on hover by default, but by clicking a row you can 'freeze' the action menu to the row you clicked (meaning the action menu doesn't change when you hover over another row)? It might not be obvious to the curators that you can do this, but it would help solve the problem of 'slipping' to another row that Val mentioned. There is the slight problem of users then not knowing how to 'unfreeze' the action menu after clicking, but at least we already have a button that closes the action menu, so hopefully they can realise they should click that:

[ValWood]

I think anybody new to Canto should be shown the phenotype annotation as the first option, since phenotype annotation seems to be the primary focus for most Canto instances.

Yes good point.

Also, do we know what the most frequently used options are for all curators? Because they could be different.

this is true. but I'm pretty sure that copy/edit is used the most by curators and community (at least I hope otherwise they are doing lots of unnecessary work

could we have it so that the actions show on hover by default, but by clicking a row you can 'freeze' the action menu to the row you clicked

I'm not sure this would help too much, because the slipping is until selection and selecting the correct option is probably as easy as clicking. this combined with the unfreeze issue I'm not sure this would be better....

[jseager7]

I'm not sure this would help too much, because the slipping is until selection and selecting the correct option is probably as easy as clicking.

What do you specifically mean by 'slipping'? Do you mean:

1. the problem of the menu moving up or down to another row unless you move (nearly) perfectly horizontally across the row that you want the menu on, or;

2. the fact that the menu appears as soon as you mouse-over any row, leading to the menu 'rippling' up and down the edge of the table if you sweep the mouse cursor over the table?

[ValWood]

I think it's 1. that bothers us. it requires mouse precision @Antonialock @mah11 is this the case for you?

[Antonialock]

I think Val means 1 (this doesn't bother me btw)

I'm against having the menu pop up on a click - I am fairly certain Midori would hate this too (more clicking = bad)

[jseager7]

I'm against having the menu pop up on a click - I am fairly certain Midori would hate this too

I agree that having the menu only show on click is more inconvenient, and I wasn't ever suggesting we should do this – I was only suggesting also adding an action upon clicking the row that shows the menu more permanently, to help users who get annoyed by hovering other rows by accident.

---

Ultimately, we don't have many options to solve the problem of the menu slipping off the focused row, because it's an inherent usability problem with menus that appear on hover.

I've seen other websites solve this problem by making it so when you click the point of the screen that you would normally hover over, it locks the pop-up menu in place, and prevents it disappearing when the mouse is hovered over something else.

Note that we don't have to use the 'close menu' icon to close the menu after it's been locked in place: you could make it so clicking anywhere on the page except on the menu closes the menu again; that's how drop-down menus work on a lot of other applications (meaning, menus closing when clicking away from them).

The only other option I can think of is adding a delay before the menu moves to another row after that row is hovered, effectively making the pop-up menu more 'sticky' so it doesn't matter if you drift off the row momentarily. Unfortunately, I can see how this would be annoying for advanced curators, and having a delay on hover might seem like unexpected / unconventional behaviour for all users.

[mah11]

What do you specifically mean by 'slipping'?

"Slipping" isn't my word, but the thing that drives me crazy is no. 1, the RSI-inducing mousing precision required to bring up the links for the desired row and not a nearby row.

Ultimately, we don't have many options to solve the problem of the menu slipping off the focused row, because it's an inherent usability problem with menus that appear on hover.

Yes, indeed. To be honest, I've missed the previous version (from long before you joined, @jseager7) ever since the current hover-based interface was deployed. It simply had a set of links at the end of each row; it was more visually cluttered but there was less risk of clicking a link for the wrong row, and vastly less physical mousing stress. I was outvoted by the other curators, who were more bothered by the clutter than I was. (sigh)

I'm against having the menu pop up on a click - I am fairly certain Midori would hate this too

I agree that having the menu only show on click is more inconvenient

"more inconvenient" sounds like that fabled British understatement ;)

I was only suggesting also adding an action upon clicking the row that shows the menu more permanently, to help users who get annoyed by hovering other rows by accident.

As long as it's optional, it might help a bit.

The only other option I can think of is adding a delay before the menu moves to another row after that row is hovered ...

Can I stomp all over this possibility now? It sounds absolutely ghastly - all the problems of needing to mouse precisely, compounded by a lag between action and effect that will make it harder to tell what will happen if you click anything. Ugh.

Many thanks for thinking this through so much, though!

[jseager7]

It simply had a set of links at the end of each row; it was more visually cluttered but there was less risk of clicking a link for the wrong row, and vastly less physical mousing stress. I was outvoted by the other curators, who were more bothered by the clutter than I was.

Maybe this is something that could be ultimately solved by having per-user settings that Canto can remember (using browser cookies or something), because it sounds like the physical demands of moving the mouse precisely horizontally is one of the more contentious quirks of Canto's interface. If users could control the amount of 'clutter' based on preference (having links on hover versus having links on click versus having links always visible), then we wouldn't need to have these debates.

We should bear in mind that our current system could have accessibility implications for curators who physically can't move the mouse with the required level of precision. We can't even get around it with keyboard navigation, because Canto is generally pretty hopeless when it comes to that: for example, look at the selection order when using the Tab key when the genotype row actions are visible – you can't even focus the last four actions on the list.

I can't guarantee that adding per-user settings is going to be easy (that's more a question for @kimrutherford), but we've already added something like this with the Advanced Mode setting, so there's clearly a need for Canto to adapt to user preferences.

[jseager7]

I've opened a pull request to make the changes suggested in the first comment of this issue. You can close this issue if you think that covers everything, or we can leave it open as a place for future discussion about improving the actions menu.

[jseager7]

@ValWood These changes have finally been merged, so here's how the actions list looks on the latest version of Canto:

There's the usual disclaimer about how these changes won't be visible immediately in PomBase's Canto due to it being behind the latest version, but if you notice anything wrong with the new layout, please let me know and I'll fix it. Otherwise, feel free to close this issue.

[ValWood]

OK thanks. We should be able to test in our Canto on Monday if all goes to plan. So I think you can close this and if there are any problems we open new tickets?