[MGNLUI-4823] Changes to highlighting & navigation in Findbar Created: 23/Nov/18  Updated: 16/Apr/20  Resolved: 01/Apr/19

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: 6.1

Type: Improvement Priority: Neutral
Reporter: Martin Drápela Assignee: Andrei Ichimescu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 3.5d
Time Spent: 3.5d
Original Estimate: Not Specified

Attachments: PNG File 03_02_suche_quellen.png     JPEG File 474104-search-from-the-windows-10-start-menu.jpg     PNG File Bildschirmfoto 2019-02-20 um 14.18.28.png     PNG File ff-findbar-search.png     PNG File find bar command.png     PNG File find bar live search.png     PNG File image-2018-11-23-16-23-55-026.png     PNG File image-2019-02-20-16-33-04-742.png     PNG File unity-lens-search.png     File vokoscreen-2018-11-23_15-17-43.mkv    
Issue Links:
Issue split
split to MGNLUI-5088 Changes to commands in Findbar Closed
Relates
relates to MGNLUI-4693 Find bar keyboard navigation: keyDown... Closed
relates to MGNLUI-4819 Make it clear how to stop voice recor... Closed
documentation
to be documented by MGNLUI-5162 DOC: Highlighting and navigation with... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Testcase included:
Yes
Documentation update required:
Yes
Date of First Response:
Epic Link: Periscope improvements
Sprint: Foundation 7
Story Points: 3

 Description   

The user doesn't understand current behavior when hitting enter in find bar it opens first item of result list.

Change behavior to the following:

  • Blank search term: no highlight (same as today and no opening of top result when hitting enter on blank search)
  • User types a search term: highlight top result (see mock up)
  • Hit enter: open highlighted result
  • Arrows Up & Down (also see MGNLUI-4693):
    • change selected line (same as today)
    • cursor remains on findbar, user can continue search (same as today)
    • when going up with the arrows, once the top result is reached, do nothing, i.e. keep top result highlighted even if the arrow up is pressed further
  • When the focus is not on top and the user changes or enhances the search term, the focus highlights the top result again


 

 



 Comments   
Comment by Anja von Gunten [ 28/Jan/19 ]

(Copied test above from mdrapela)

Discussed in slack surface room on Nov 23, 2018.

I'm not fully convinced the current UX behavior of entering a search term in the Find bar and hitting the ENTER key immediately after is UX-beneficial.

I start with some context and a question (basically a recopy from slack).

Use case No 1 (tested):

Look at the following breakpoint: 

  • The user has typed in "recognition" in the Find bar.
  • Some results have been suggested below by the suppliers, but
  • the cursor is clearly blinking at the end of the word. The action focus is now still "within the Findbar".

What do you expect to happen when the user hits ENTER now?

My logic would say that it will rerun the search with "recognition".

Currently, however, Magnolia opens the top suggestion - and it does that from whatever results it has already collected from the suppliers, meaning depending on how fast you type ENTER, the target that opens may always be different.

For fast typing users who are used to hitting ENTER after the search phrase this may lead to and indeed leads to some confusion. That was my first impression: I wondered why on Earth Magnolia took me immediately to the Preview app with path

http://localhost:8080/magnoliaAuthor/.magnolia/admincentral#app:preview:detail;/travel:view

when all I wanted was some suggestions for "recognition"?

See this recording:

vokoscreen-2018-11-23_15-17-43.mkv

Use case no 2 (tested)

Should there be a behavioral difference between these two user actions within the Find bar?:

  1. "pages app" + ENTER
  2. "open pages app" + ENTER

Now, the first one, - depending on how fast you type it -  (tested in EE pro webapp (non-demo)), opens either:

  • the Pages app

or

  • the /modules/pages/apps/pages node in the Configuration app.

 

The second typing sequence ("open pages app" + ENTER) - does what it should do: opens the Pages app.

The first one though ("pages app" + ENTER) IMHO should still stay at the list of suggestions for "pages app".

 

Comment by Cedric Reichenbach [ 20/Feb/19 ]

Here are my last 2 cents, after that I'm broke.

For what it's worth, I quickly tested common practice in similar tools:

  • Spotlight (OS X): Automatically pre-select top result, execute it on enter
  • Firefox & Chrome: Same as Spotlight
  • Windows start menu search: Same as Spotlight
  • Unity Lens (Ubuntu): Same as Find Bar currently - no auto-highlighting, but execute top result on enter

It looks like execution on enter is common practice among those.

Remember that Find Bar is not a one-off aim-and-shoot search tool (like Google) but a live, type-ahead, interactive one!
In particular, there's no manual triggering of search, it happens automatically and immediately, more like filtering. Removing the functionality of enter would mean placing a placebo for search triggering, but at the same time remove a valuable direct shortcut.

Comment by Anja von Gunten [ 20/Feb/19 ]

mdrapela creichenbach I initially proposed to implement it in the same way as spotlight, so - while you're typing - the first search result is highlighted (that's a must else user doesn't understand what happens after enter). However i'm not sure if we can call it the common practice. It seems that users generally rather expect "completion of the search query" than actually "opening a search result". Anyhow i don't know for sure but if i had to vote i would vote for "spotlight pattern".

Comment by Anja von Gunten [ 20/Feb/19 ]

"Spotlight pattern" would be like this: first search result is highlighted while typing

Comment by Anja von Gunten [ 20/Feb/19 ]

As we've been through this discussion before, i would propose to stick to what we decided (slutz) and implement how it's described in the ticket. I'd say it's easier to progress from this more conservative/safe pattern to the "spotlight version" - than the other way round. Let's test it and re-evaluate.

Comment by Cedric Reichenbach [ 20/Feb/19 ]

I think we've hit Google's former (now phased out) "I'm feeling lucky" functionality, which I have always tried to avoid - I never used that button - in order to have more control over which result I pick.

Noo, "I'm feeling lucky" picks the first result blindly, while find bar strictly only picks already visible ones.

Comment by Anja von Gunten [ 20/Feb/19 ]

ilgun It's described in the ticket. It was also part of previous discussions, not only my 2 cents. As for the commands i always found it was executed too fast without hitting enter. I propose to execute on 'enter'.

Comment by Cedric Reichenbach [ 20/Feb/19 ]

Regarding commands (I think this was suggested before as well): We could have a result entry that shows something like "Command XY detected -> execute", so it would be a same-class citizen as other results. Of course it would then need to be asserted that behavior with voice commands still works without additional friction.

Comment by Simon Lutz [ 19/Mar/19 ]

Issue split into:

MGNLUI-5088 Changes to commands in Findbar
Generated at Mon Feb 12 09:20:27 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.