Lenses icons should be next to the search field (at least the default ones!)

Bug #924923 reported by Michele Kipiel
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Invalid
Undecided
Unassigned
unity (Ubuntu)
Opinion
Wishlist
Unassigned

Bug Description

a quick scenario:
hit the super key, start typing, try to refine your search using the applications lens.
notice something? you have to move your mouse across half of your screen to reach the lens icon!

this is a usability issue that should be addressed as soon as possible. since the very idea of the dash is speed, it is nonsensical to place a filtering option so far away from the search box it is related to.

the filtering option should be placed _under_ the lenses icons since the kind of filters the user is allowed to apply depends on the lens he is using.

i attach a simple screenshot of what i mean.

Tags: needs-design
Revision history for this message
Michele Kipiel (michele-kipiel) wrote :
Revision history for this message
Omer Akram (om26er) wrote :

added ayatana-design as affects so we get feedback from design team.

Changed in unity:
importance: Undecided → Wishlist
status: New → Incomplete
tags: added: needs-design
removed: dash design filters lenses ux
Changed in unity (Ubuntu):
importance: Undecided → Wishlist
status: New → Incomplete
Revision history for this message
Michele Kipiel (michele-kipiel) wrote :

i attach an interactive mock-up of the concept.
you can explore it using the provided links (highlighted in pink)

Revision history for this message
Omer Akram (om26er) wrote :

about that, what happens when you install a third party lens(es)? how does filter results work for them? I predict big inconsistency if we go with the proposed change ;)

Revision history for this message
Michele Kipiel (michele-kipiel) wrote :

this is exacly what i am trying to figure out :)

filters are not a big issue since the drop down option can be set to inactive (or disappear) in case some custom lens does not provide filtering options.

the number of displayed icons is something that bugs me a little more, and i will sure try to figure out a fix for it.
one of the possible solutions i see is to make the dash auto-size its width based on the number of lenses installed, though i don't know if this is possible.
another idea could be to make the search box shrink according to the number of icons.

btw. it would be interesting to know how many custom lenses does the average user install, just to figure out how much effort should be thrown into this aspect.

Revision history for this message
Michele Kipiel (michele-kipiel) wrote :

slightly revised version of the concept, to address the "number of lenses" issue :)

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 924923] Re: Lenses icons should be next to the search field (at least the default ones!)

Nice work Michele. Can we also have some options with the lenses *above*
the search?

Mark

Revision history for this message
Michele Kipiel (michele-kipiel) wrote :

thank you very much :)
here is the "lenses on top" version

Revision history for this message
Christian Giordano (nuthinking) wrote :

While having the lenses navigation closer to the search box can bring some benefits, I wonder how much the use case where the user filters the results, leaving the Dash home after having input the search query, should be prioritized.
At the moment the Dash home results don't include all the results you can get from the individual lenses (eg. the available applications to download). Maybe the Dash home wants to be a place where you can quickly search things that you know already you can easily access from there.
Or maybe this use case could be better supported from a link to the specific lens which is closer to where its results are shown in the Dash home.

Revision history for this message
Michele Kipiel (michele-kipiel) wrote :

Hi Christian,

you say : "I wonder how much the use case where the user filters the results, leaving the Dash home after having input the search query, should be prioritized."
well, to me this means: "lenses are useless".

currently the only _truly_ lens-related feature is the "available in the store" list (which is present in the applications and music lenses only). this can be an interesting feature in terms of "discoverability" and "upselling", but does it add that much value to the search?

now consider my concept.
the idea of a home lens which displays only recent content is more in the spirit of "a place where you can quickly search things that you know already you can easily access".

this said, your comment points out what i consider to be a significant bug in the dash: the lack of search persistence across the lenses. when you hit the super key and then start typing, if you hit tab or click an icon to switch to another lens, the search box turns empty.

i guess this behaviour was implemented to let the user perform multiple searches in different lenses, but, based on my experience, this scenario is higly unlikely. as a user i expect the lenes to behave as filters and not as "tabs".

you might argue that once you know about this behaviour, you will want to pick the appropriate lens before typing.
but forcing the user to do so is clearly an "affordance" issue: if the first thing i see is a search box, i expect this search box to be the "leading" feature. i would never expect that something placed at the very bottom of the dash actually controls the behaviour of something that is placed at its top.

enabling search persistence across lenses could solve this issue, like in the following use case:

user hits super key -> dash opens -> user types "ink" -> user notices no results in "recent apps" (eg. recent = last 10 days) ->user hits tab to switch to the applications lens -> user sees inkscape icon -> user hits enter to launch inkscape

ps. sorry for the *long* post :)

Revision history for this message
John Lea (johnlea) wrote :

@michele-kipiel;

So out of the many use cases the Dash serves, at first glance following two use cases seem to be in competition:

Use Case A - User uses the music lens to listen to music, and frequently uses the file lens to find files. When the current album finishes playing they want to go back to exactly where they were in the music lens to find the next album to listen to. While the previous album was playing, they retrieved several files. As the file retrieval task has nothing to do with the music they are listening two, these two options should not share state. *this use case is currently well supported*

Use Case B - User searches for a file in the Dash Home, and then wishes to go to the File Lens to use the search filters to further refine their search. *Because the search term is not persisted between lenses, this use case is not currently well supported*

So currently we have a solution for Use Case A, but Use Case B is not optimal. The solution you are suggesting switches this around, so that Use Case B is supported, but Use Case A would then become problematic. As the number of specialised Lenses and Scopes grow, Use Case A will become more prevalent, so we cannot afford to regress in this area.

However there is another solutions that services both Use Case A and Use Case B equally well ;-) At the end of the results underneath each Category Header in the Dash Home, add a button that takes the user to the relevant lens persisting their search term. This means that if a user cannot instantly find what they want in the Dash Home and they need to transition to a lens, one click takes them straight to the relevant lens with their query persisted so that they can continue their search. At the same time, Use Case A is unaffected, so that searching in the "Comics" lens does not affect the current state of the "People" lens.

Revision history for this message
Michele Kipiel (michele-kipiel) wrote :

I see you point, yet i still don't see "Use Case A" as a truly significant use case (for me, at least).

in my experience i never _ever_ used the music lens in the way described in Use Case A.
what i do is click on the player icon which is pinned to my launcher, hit play and then let rhythmbox do the mixing.

Use Case B is much more likely to be a common search pattern than Use Case A, in my opinion.
Use Case B is actually already a standard pattern: consider firefox. you hit ctrl+k, then type something and hit enter. you see the results, but want another tab. what happens when you open another tab and go for the little search box? the keywords you input before are still there, highlighted. the user can choose whether to repeat the search or simply input new keywords.

i just find the current lens design to be less efficient, according to my own search and use habits.

it would be interesting to create a quick survey and ask ubuntu users which of the above mentioned use cases is closer to their needs and then discuss the results...

Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

Yes, I think there's an argument for more continuity between searches in
different lenses. John, let's rethink.

Andrea Azzarone (azzar1)
Changed in ayatana-design:
status: New → Invalid
no longer affects: unity
Changed in unity (Ubuntu):
status: Incomplete → Opinion
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.