[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: |
|
||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||
| 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:
|
| 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:
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?:
Now, the first one, - depending on how fast you type it - (tested in EE pro webapp (non-demo)), opens either:
or
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:
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! | ||
| 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 ] | ||
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:
|