GNOME Bugzilla – Bug 763651
Deemphasize the Remove button in the app page
Last modified: 2017-10-23 16:27:41 UTC
Created attachment 323936 [details] Mockup with the proposal The Remove button in the app page is the first button shown, before even the Launch button. We have been analyzing the UX of GNOME Software at Endless and the design team suggests that the Remove button should be deemphasized, e.g. by moving it farther away from the Launch button. I have attached a mockup of a possible solution. An alternative could be adding the button even farther from the top area, e.g. at the level of the Website button, aligned to the right. I can submit a patch for it if the GNOME Design team agrees with the change, so please let me know your opinion about this suggestion.
The design for the buttons has evolved a little. In the beginning, we just had install and remove at the top. The idea was that the install button shows progress and turns into remove when installation is complete. Now that the launch button is also shown at the top, I agree that showing remove first looks a bit odd: it's rather negative to have it as the first button. I'd be happy to switch the position of the launch and remove buttons, so that launch comes first. I'm less sure about the proposal to move the remove button: it doesn't align properly with the screenshot thumbnails on the right, and makes the controls look a bit spread out. We could certainly explore other ideas though... do you have any, Jakub?
How about we align it with the right edge of the active (big) screenshot? Maybe it's not that easy to layout this though but I can check it out if you think it's a valid solution.
Created attachment 324224 [details] alternate button arrangement
Hi Robin, I like how compact your mockup looks, however I am worried that it looks too crowded if we have languages that make the description and buttons bigger. Usually latin languages always lead to longer words/text so it will likely look a bit crowded. It also doesn't leave space for more buttons if it needs to show e.g. an Update button.
(In reply to RobinT from comment #3) > Created attachment 324224 [details] > alternate button arrangement How would that look with star ratings being displayed? Jakub: what do you think of this layout?
I recall us steering away from the headerbar in the past, but I don't quite recall the reasons... Allan, can you refresh my memory why we don't want to do something like this? https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/software/version3/app-page.png
(In reply to Jakub Steiner from comment #6) > I recall us steering away from the headerbar in the past, but I don't quite > recall the reasons... Allan, can you refresh my memory why we don't want to > do something like this? > > https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/ > software/version3/app-page.png We used to have the install/remove buttons in the header bar, and moved them below the app title in response to user testing results: testers hadn't been noticing (and had been struggling to find) the install/remove buttons. This could well have been because the page content has a fixed width, and the header bar buttons can end up being a long way away from it.
(In reply to Allan Day from comment #5) > (In reply to RobinT from comment #3) > > Created attachment 324224 [details] > > alternate button arrangement > > How would that look with star ratings being displayed? Jakub: what do you > think of this layout? You're right, I didn't take into account cases where there are ratings, long descriptions of long titles. This solution probably won't work.
Created attachment 324897 [details] App Detail with launch button In this version the main button will either be launch or install depending upon whether or not the app is installed. The reviews are below the description leaving plenty of room for and length of app descriptions.
Created attachment 324898 [details] App Detail with Install button This is the same solution, just showing how it would appear if the app is not yet installed. Showing "Install" instead of "Launch"
Created attachment 324899 [details] Variation on placement of review and button
Created attachment 324900 [details] Another variation I personally like this solution, however I know there is danger of becoming overcrowded if the app has a long description, however most of the apps I looked at had relatively short descriptions. And we can have a line return and put the description on two lines in the cases where there are longer descriptions.
Created attachment 324901 [details] Proposed location for "remove" button This is my proposal for the "Remove" button. I think it will still be plenty discoverable. We can still make the button red if we think that helps discoverability, but this removes the focus on "Remove" as a primary action.
Hey Guys, I did a couple more studies to explore ways that we can de-emphasize the remove button while allowing a flexible lay-out to accommodate reviews, various lengths of descriptions and more actionable buttons when necessary . In all three solutions I have explored having one main button function at the top of the detail page that gives priority and focus to the most common function. Any other buttons move below the app description where the "history" button was and where the "website" button is. Let me know what you think.
(In reply to RobinT from comment #14) > ... Any other buttons move below the app description where the > "history" button was and where the "website" button is. Let me know what you > think. I'm not entirely sure about moving the remove button further down. It might make it hard to find, and it means that a functional control is mixed in with informational elements. Conceptually I like having dominant controls at the top. Does it give the remove button too much emphasis to leave it at the top, but to remove the red colour and change the order so launch comes first?
Yeah, now I see the separation between functional and informational. I think that would probably work.
I've iterated on some layouts as well, trying to contain the buttons in a sort of inline toolbar we use for action buttons adjacent to vertical lists. However, ended up liking the simple inline style we already have, just making sure we align nicely: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/software/version3/app-page-grid.png
New location for Jakub's wireframes: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/software/old/version3/app-page-grid.png We discussed these yesterday and everyone seemed to like them.
I'm fairly sure that this work was implemented.