Ubuntu

Navigating to item via search or "What's New" doesn't show its department/subsection

Reported by Matthew Paul Thomas on 2009-09-09
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
software-center (Ubuntu)
Medium
Unassigned

Bug Description

software-store trunk r216, Ubuntu Karmic
software-center trunk r2155, Ubuntu Ocelot
software-center-gtk3 trunk r2155, Ubuntu Ocelot

1. From the initial screen, search for "inks".
2. Navigate to the "Inkscape" result.
3. Look at the path button (GTK2), or the top of the software item screen (GTK3).

What you see:
* In the GTK2 UI, "Get Software > Search Results > Inkscape Vector Graphics Editor".
* In the GTK3 UI, only the application icon and title.

What you should see:
* In the GTK2 UI, "Get Software > Graphics > Drawing > Inkscape Vector Graphics Editor".
* In the GTK3 UI, "Graphics ▶ Drawing" links above the icon and title.

<https://wiki.ubuntu.com/SoftwareCenter#software-item-screen>:
"Except where specified elsewhere, a software item screen should contain: 1. A link to its primary category. 2. A triangle (▶) and a link to its primary subcategory, if it has one."

In user testing of USC on 2010-12-15, this showed up as a moderate usability problem: participants navigated to a "Featured" or "What's New" application from the main screen, then installed it without knowing what kind of application it was.

See also bug 554180 and bug 830218.

Tags: db Edit Tag help
Michael Vogt (mvo) on 2009-09-10
Changed in software-store (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Michael Vogt (mvo) wrote :

Thanks for your bugreport.

Was this in the spec? I am unable to find it there. What should happen if the user clicks on "Graphics"?

Matthew Paul Thomas (mpt) wrote :

I'm sorry I thought this was explicit enough from the mockups alone, which was not a good assumption. I've now made it explicit in the text. <https://wiki.ubuntu.com/SoftwareStore?action=diff&rev2=172&rev1=171>

To answer your specific question, clicking on "Graphics" would navigate to the "Graphics" section.

Michael Vogt (mvo) wrote :

Navigate to the Graphics section and clear the search? Or navigate to the Graphics section and use the current search terms in that section only?

Michael Vogt (mvo) wrote :

Its suprising to me that a action suddenly adds two navigation buttons, all other actions just add one. I'm fine adding it of course, but I don't think its obvious behaviour.

Matthew Paul Thomas (mpt) wrote :

This is how breadcrumbs work on every Web site I know of that uses them. Doing a search is a shortcut into the navigation hierarchy, so choosing a search result may take you down more than one level.

Whether navigating upward should clear the search results is a tricky question, though, and at the moment I don't know the answer.

User story 1: Jacinda is looking for something to play movies, so she searches for "movie" from the front page. She clicks on "Movie Player (GStreamer)" VLC" and reads the description, but decides it sounds too geeky. She realizes that "Sound and Video" is the right category, so she clicks on "Sound and Video". But she still wants to be seeing only those applications that have something to do with movies, so she wants the search to be retained.

User story 2: Jacinda gives up on searching for movie players, and now wants to install something completely different. So she clicks on "Get Free Software" to return to the main screen. She is disoriented to find that the Store is showing not the main screen, but the top-level search results for "movie". She did not want the search to be retained.

Matthew Paul Thomas (mpt) wrote :

User story 1 is now catered for by the Back and Forward buttons <https://wiki.ubuntu.com/SoftwareCenter#get-software-navigation>, while user story 2 is catered for by clearing the search whenever you navigate up or down. So, this bug should still be fixed.

description: updated
Changed in software-center (Ubuntu):
status: Confirmed → Triaged
description: updated
description: updated
summary: - Navigating to application via search doesn't show its department
+ Navigating to item via search doesn't show its department/subsection

Be careful, I saw a lot of packages in several departments at the same time. So it would not always be possible to show one "department/subsections".

Matthew Paul Thomas (mpt) wrote :

guilloip, that's bug 554180.

guilloip (guilleip) wrote :

Matthew, I am afraid you have misunderstood me. I was not showing that feature as a bug but as a reason why this bug (the bug #426999) is not really a bug. It is a consequence of an specific situation.

It is completely logical that a certain package could be classified under two different categories. For example, the drawing program of OpenOffice.org, should (and must) appear under "Graphics" and under "Office" categories. That is mandatory because it most be found by any user searching for a graphic program and by any user searching for an office program too.

Because of this, a package could belong to several categories, and that is why it is not possible to show its category in the "searching" screen. The only way is to define a "main category" for each software. I think.

Matthew Paul Thomas (mpt) wrote :

Yes, I've specified how it should be possible for an item to be in more than one department/subsection, using X-Ubuntu-Category-Secondary. <https://wiki.ubuntu.com/SoftwareCenter#Genre> As far as I know, that's not implemented yet, so the only reason that an item *currently* appears in more than once place is bug 554180.

When X-Ubuntu-Category-Secondary is implemented, it's obvious which department and subsection should be shown in the pathbutton after a search; the primary ones, not the secondary ones. But I've just realized that that's not appropriate when you navigate via the secondary department/subsection; in that case, the path button should show that secondary department/subsection instead. I've fixed the spec now. Thanks for helping me realize this! <https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=371&rev1=370>

description: updated
Changed in software-center (Ubuntu):
assignee: nobody → Gary Lasker (gary-lasker)
summary: - Navigating to item via search doesn't show its department/subsection
+ Navigating to item via search or "What's New" doesn't show its
+ department/subsection
Matthew Paul Thomas (mpt) wrote :

This bug makes it a bit harder to understand the purpose of items in "What's New". For example, in Maverick currently something called "ROOT" appears in What's New: "The ROOT system provides a set of OO frameworks with all the functionality needed to handle and analyse large amounts of data in a very efficient way." If navigating to it showed "Get Software" > "Science & Engineering" > "Mathematics" > "ROOT" instead of just "Get Software" > "ROOT", it would be easier to understand that it was talking about mathematical data analysis as opposed to analysis of Web server data or software profiling data or something else.

Matthew McGowan (mmcg069) wrote :

Hi,

I have a branch:
lp:~mmcg069/software-center/cats-for-carousel-activated-apps

While its still WIP everything is in place. There are some bugs to do with navigation_bar callbacks which i just need to come to terms with.

Changed in software-center (Ubuntu):
status: Triaged → In Progress
Matthew McGowan (mmcg069) wrote :

Lastest rev looks pretty good.

Matthew Paul Thomas (mpt) wrote :

Thanks Matthew! Testing r1105 of that branch, it does work well for the one case of clicking on "Featured" or "What's New" items on the lobby screen.

I'm surprised, though, that it was even possible to fix it for that one case without fixing all the other cases automatically. It seems to me that the code that calculates what elements the pathbutton should have in a software item screen, should be the same code no matter how you navigate to that software item screen (with that one exception I specified of "If the item was navigated to via a department/subsection..."). If that calculation needs to be reimplemented for every method of navigation, contributors implementing future methods of navigation (e.g. going from an application screen directly to the screen for one of its add-ons, or from the History section to the screen for one of the historic items) will be either copying and pasting, or forgetting to implement it at all. Does that make sense, or am I off-base?

Kiwinote (kiwinote) wrote :

Hi Matthew! It is probably worth pointing out that the current version of the branch causes s-c to crash on startup for opening deb files for which the pkg is not yet installed, and opening apturls when the pkg is not yet installed.

@mpt: yes that does make sense. The solution we choose needs to allow cats/subcats in the available pane, no cats/subcats in the installed pane, opening apturls on startup, opening apturls when s-c is already running, navigating from search, navigating from cats/subcats, navigating from an addons screen etc. In these situations it may (or may not?) differ as to which navigation steps we want to include in the history. All this makes fixing it potentially risky to do for maverick. Not to say that it wouldn't be nice though ;)

Cheers

Matthew Paul Thomas (mpt) wrote :

Just to be clear, the path button is not history, it is (supposed to be) hierarchy. :-) As for whether it differs, a software item screen in "Installed Software" should *always* have the same two path button elements, regardless of how you navigated to it. And a software item screen in "Get Software" should always have the same three or four path button elements, regardless of how you navigated to it, *except* in the case guilloip pointed out of an application being filed in multiple categories (in which case we should give preference to the categories you used when browsing to it, as covered by the first quoted bullet point).

Gary Lasker (gary-lasker) wrote :

Thanks mpt, you've clarified it nicely. Yes, the current pathbar design is more a combination of the two (history and hierarchy). The pathbar buttons reflect the physical movement through the various views from a viewpoint of hierarchy, and so navigating to a details view via a search is displayed exactly that way in the pathbar (that is, it includes an element for the search step).

On the other hand, the navigation history is literally that; a record of the screens visited. I think we want it to continue to work as it does now.

That's part of what makes this one a little tricky to implement; we need to create a logical mapping for a particular kind of navigation (to the software item screen), and overlay that on the current pathbar/history design in such a way that it works for all the cases that kiwinote lists. It's likely a fair bit of surgery to get this right, but more importantly it will represent some risk so it looks like this will have to come in Natty. Sorry! I know you've been looking for this fix for a long time.

P.S. Matthew McGowan, thanks for your branch! We'll keep it in our pocket and revisit this for Natty.

Changed in software-center (Ubuntu):
status: In Progress → Triaged
description: updated
Changed in software-center (Ubuntu):
assignee: Gary Lasker (gary-lasker) → nobody
description: updated
Kiwinote (kiwinote) on 2011-09-27
tags: added: db
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers