Software Center UI misses several visual hints and consistent hover behaviour

[Michele Kipiel]

I noticed that there are very little visual hints in the USC design:
- no "hover" status on nearly all elements
- no "onclick" effect on the elements listed in the New and Most voted sections
- no "onclick" effect on the little arrows next to the top three buttons (namely: all software, installed)
- no "hover" status for the elements listed in a software category

I would like to focus on the potential that the hover status holds in the application list screen (eg. the screen you get after a search action).
As of now, he user is left to stare at a plain list, with nothing to do and no visual hints. It would be interesting to have a hover event on each line which not only shades the focused line, but also reveals the "install" and "more info" buttons as well.

i belive this change could help users perform both install and uninstall actions in less time and give the USC a more polished and responsive look&feel.

[Michele Kipiel (michele-kipiel)]

A 2 step mock-up showing the hover behaviour i described in the bug report

[Matthew Paul Thomas (mpt)]

Michele, thanks for this thoughtful and well-illustrated suggestion.

You listed four distinct issues.

First, few hover effects. This is deliberate. In general, mouseover effects are affordances that you don't get until just after you need them. So we use them only as a last resort, when showing the affordance all the time would be too garish or cluttersome. There are few, if any, cases of that in USC.

Second, no onclick effect on tiles. This is a responsiveness problem, but already reported as bug 1017454.

Third, no onclick effect on the dropdown menus in the navigation bar. This is a problem, and we'd happily accept a fix. But usability testing shows that those menus are confusing in general, so time would be better spent removing them altogether (bug 1020521).

Fourth, no hover effect on list views. This might be a problem, though it has not come up in usability testing. If it is a problem, most of it can be solved by converting most categories and subcategories from list views to tile views (bug 1028106).

But that would still leave list views in a few categories and subcategories, and your suggestion would still apply there. One drawback I can see is that it could interfere with scrolling. A row with "More Info" and "Install" buttons is taller than one without. And if you were scrolling through a list with a trackpad or a mousewheel, the hovered item would be changing rapidly. Combined, that would mean rows were rapidly expanding and collapsing as you scrolled through them, which might be slow and distracting. We could work around that with a delay -- show the hover effect only if you had hovered for at least, say, 250 ms. But that in turn might lead to errors where you meant to click on the next row down, but instead accidentally clicked on a button that had just appeared.

Perhaps others here would like to identify benefits and drawbacks, or to suggest variations.

[Michele Kipiel (michele-kipiel)]

Hi Matthew,

maybe it is unclear from my mock-up, but i intended the rows to be all the same size: both the selected and unselected rows have enough room for the two buttons.

this in my opinion is the best option: it makes the UI look "rock solid" and makes it easy to scroll a list even with a trackpad.

unless we want those rows to become tiles :)

[Matthew Paul Thomas (mpt)]

If selected and unselected rows were the same height, unselected rows would need to be quite a lot taller than they are now. That would mean fewer results visible at a time.