Excellent work EraX!
I really like the information panel which combines the details and filter options.
I have a question though: How is the filter field going to transition from the main page to the position in with the list view? I'm not entirely sure that the category has to have a place next to the filter. I'd expect people want to just type and then refine their filter settings if they don't find what they were looking for. Also, maybe you can take a look at the query parser: https://techbase.kde.org/Projects/Usability/HIG/SearchPattern. Ideally we would end up with a situation where one can "simply" write "open source text editors with 4 stars" without having to check any boxes.
I see that one can close the information panel. When it's closed, how would the user to able to call it back again?

About toolbar, I think I prefer the one which use the whole width of the application.

EraX wrote:[…]
If/whet app will be able to place tabs on the titlebar it could look like:
https://dl.dropboxusercontent.com/u/633 ... _multi.jpg
https://dl.dropboxusercontent.com/u/633 ... ch_tab.jpg

That would really be nice, but I don't think that's how they are supposed to work. At least not yet, though we can always ask .
Again, awesome work!

@alake Ok

andreas_k wrote:can you make also the third page for the program details. I can also made it. would it be possible to upload the svg file.

It hasn't changed much from the first post
https://dl.dropboxusercontent.com/u/633 ... 0_page.jpg
https://dl.dropboxusercontent.com/u/633 ... 1_page.jpg
I'll post an svg in a day or two, need to clean it and move the panels as suggested.
The panel uses the same colors(background and text) as the titlebar

Blingy wrote:I thought the tabs where like in oxygen not tabs within the application, but other applications sharing one window.

For now they are like oxygen, but one day... who knows

Sogatori wrote:I have a question though: How is the filter field going to transition from the main page to the position in with the list view?

That is a good question. I don't think there is any need for fancy transitions, but that is something to think about.

Sogatori wrote:I'm not entirely sure that the category has to have a place next to the filter.

I think it's handy to have at least the ability to chose the category when starting the search.
In most cases typing the phrase and optionally choosing the category should be enough to find what you are looking for. The filter panel is there for the rare cases when that is not enough (the list of found items is to large or you are not sure what you are looking for).
But

Sogatori wrote:Ideally we would end up with a situation where one can "simply" write "open source text editors with 4 stars" without having to check any boxes.

That would be pretty cool.

Sogatori wrote:I see that one can close the information panel. When it's closed, how would the user to able to call it back again?

Toolbar button, menu, context menu, shortcut... haven't really thought about it

Great work EraX!
In the case of Muon, I'd definitely vote for an always-visible search bar. The HIG ( ) says:
"Use a static filter for functions related to the navigation (e.g. if finding an item out of a large list is the regular operation)."
A "static filter" is our way of saying "a filter field which is always visible".
Filtering is a very very regular operation in a package manager (yes, some people may just browse what's there, but I assume most people go to a package manager looking for a specific application), so it should always be shown.

colomar wrote:A "static filter" is our way of saying "a filter field which is always visible".
Filtering is a very very regular operation in a package manager (yes, some people may just browse what's there, but I assume most people go to a package manager looking for a specific application), so it should always be shown.

I entirely agree that the function (filter or search) should always be exposed. However, I'd like to suggest that we consider updating the guideline a touch to afford some visual design flexibility. An empty search field takes up a lot of layout space and does no better a job at exposing the function than something that takes up less space like an effective and recognizable search icon. It also requires no additional interaction steps.

alake wrote:

colomar wrote:A "static filter" is our way of saying "a filter field which is always visible".
Filtering is a very very regular operation in a package manager (yes, some people may just browse what's there, but I assume most people go to a package manager looking for a specific application), so it should always be shown.

I entirely agree that the function (filter or search) should always be exposed. However, I'd like to suggest that we consider updating the guideline a touch to afford some visual design flexibility. An empty search field takes up a lot of layout space and does no better a job at exposing the function than something that takes up less space like an effective and recognizable search icon. It also requires no additional interaction steps.

If the search button expands into a search field, it then takes up the same amount of space as if it was shown right away, doesn't it? I wouldn't use a layer for a filter because the user still needs to know what filter string led to the result shown.
Plus, I'd assume a visible filter field has a higher affordance to enter a string then a search button. Admittedly I haven't done a literature search on the topic yet, though. We could of course do a small usability test here, as well: Show people one of the two variants and ask them to search for a specific item, then see whether one variant is significantly faster than the other.

Ok as promised here is the svg file for those that want to play with it.
https://dl.dropboxusercontent.com/u/63396655/Muo02.svg
To view different configurations play with layers.
Because there are only few colors its easy to experiment with different color schemes.

colomar wrote:If the search button expands into a search field, it then takes up the same amount of space as if it was shown right away, doesn't it? I wouldn't use a layer for a filter because the user still needs to know what filter string led to the result shown.

Indeed. However, the moment that search button is clicked, the UI designer/developer has all the context needed to adjust the layout appropriately - move/hide visual elements not relevant to the immediate task and disclose + focus visual elements that are relevant to the task. For as long as there are results shown based on text in the search field, it would need be visible, certainly. This is a fairly straight-forward progressive-disclosure pattern and something I think we'll need to eventually tidy up a lot of visual clutter in many apps without losing functionality, especially in layouts where we may be constrained for space. It is also one example application of our design principle to "make it easy to focus on what matters".

Plus, I'd assume a visible filter field has a higher affordance to enter a string then a search button. Admittedly I haven't done a literature search on the topic yet, though. We could of course do a small usability test here, as well: Show people one of the two variants and ask them to search for a specific item, then see whether one variant is significantly faster than the other.

While I can certainly understand the idea that a text field might more clearly communicate that the function exposed is a text-based search/filter, I think a similarly credible suggestion could be made that, in practice, almost the entirety of the user experience of searching/filtering on the desktop are text-based. As such, I think it's reasonable to suggest that the default user expectation is for the search/filter function to be text-based, regardless of whether the function is exposed with a text-field or a search button. In terms of the number of interaction steps, properly designed, it would be exactly the same. For the text field, the user clicks then starts typing. For the search button, the user clicks then starts typing. That leaves the theoretical delay at recognition of the exposed function, which like you say can be easily evaluated by test. While I can accept the possibility that such a delay might be greater for a search button versus a text field, I do have some trouble imagining such a delay to be significant enough to prohibit its use in the design of any application.

To be clear, I'm not suggesting we do away with the text field. I'm simply suggesting that we accommodate a more flexible way of exposing the search function in the guidelines.

Sure, I'm all for trying things out

colomar wrote:Sure, I'm all for trying things out

Sorry, I didn't mean to filibuster with all those words Thomas. I just wanted to take the time to explain a little.

As for the Muon design, given that search might be a primary means of interaction with the application, I can see how it would make sense to taking up some room in the layout (with a text field if it makes sense) to give visual prominence to the search function.

alake wrote:

colomar wrote:Sure, I'm all for trying things out

Sorry, I didn't mean to filibuster with all those words Thomas. I just wanted to take the time to explain a little.

As for the Muon design, given that search might be a primary means of interaction with the application, I can see how it would make sense to taking up some room in the layout (with a text field if it makes sense) to give visual prominence to the search function.

No no it's fine, making people think is crucial for good design!

Actually, you made me re-think this and I found that my statement was based on an assumption which may or may not be true: That Muon Discover is used primarily to search for specific applications/packages to install.
Today I thought about it again and noticed that the name Muon Discover might point at something different. So before deciding whether the filter should always be visible, it is important to know the vision of the application.

It does allow for both browsing through applications/packages without knowing specifically what one is looking for, as well as looking for a specific one.

The question is: What is supposed to be its primary usecase: Browsing or searching? I just assumed it was searching because that's the way I use package managers (as there is way too much stuff available in most distributions for me to use browsing effectively), but that's not necessarily true.

So Aleix, could you please tell us whether Muon Discover should aim primarily at browsing or searching (while still allowing both, of course!)?

One of the most important decisions we took for the current design was that we wanted to mimic as much as possible the concepts the user has from the Web Browser, therefore leaving the bar always visible and the navigation on top, containing a back button a home button and such.

I'm a bit afraid of complicating the navigation in favor of a better visual design.

apol wrote:One of the most important decisions we took for the current design was that we wanted to mimic as much as possible the concepts the user has from the Web Browser, therefore leaving the bar always visible and the navigation on top, containing a back button a home button and such.

I'm a bit afraid of complicating the navigation in favor of a better visual design.

Okay, so I interpret from this that searching is indeed a central feature of Muon Discover?

If you think that showing the toolbar on the home screen will improve the usability then
https://dl.dropboxusercontent.com/u/633 ... -04-08.svg

EraX wrote:If you think that showing the toolbar on the home screen will improve the usability then
https://dl.dropboxusercontent.com/u/633 ... -04-08.svg

Are these tabs really needed then? We would display them all at the top. We don't need a breadcrumbs bar as long as the user hasn't clicked anything.

EraX wrote:Ok as promised here is the svg file for those that want to play with it.
https://dl.dropboxusercontent.com/u/63396655/Muo02.svg
To view different configurations play with layers.
Because there are only few colors its easy to experiment with different color schemes.

Thanks Erax, I was looking for this!