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

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"?

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.

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?

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.

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.

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.

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".

guilloip, that's bug 554180.

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.

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>

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.

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.

Lastest rev looks pretty good.

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?

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

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).

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.