Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0038821
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2018-06-22 16:022018-07-03 13:17
ReporterdbazView Statuspublic 
Assigned ToRetail 
PriorityhighResolutionopenFixed in Version
StatusnewFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0038821: [UX] Bad behavior in the automatic search

DescriptionThe automatic search of the selectors/SEARCH is behaving in a way totally different than any UI standard.

At this moment, it seems that the automatic search is launched only when the input has 3 characters or more, but the manual search (by pressing the magnifier glass) can be launched at any time. This is totally inconsistent and leads to confusion. The same rule should apply to both automatic or manual search, so if the manual search can be executed with no data in the input, the automatic search should be launched too with no data in the input. If n-characters are needed to be able to launch the manual search, the same n-characters should be needed to launch the automatic search (this restriction -n characters needed- should be notified to the user, by the way).

The other ugly point is that the automatic search is launched after X milliseconds. I am ok with that, just to avoid overload the server with requests, but the list of the results should be removed (switch to 'Loading...' state) just after the input value change, without waiting for the X milliseconds (although in the reality the request won't be performed until the user stops writing). This will allow the user to know that the values listed are not matching anymore with the text he is writing, while at the same time notice that the search is already taking place (although it is not true because of the X milliseconds).

Note that this last mentioned behavior should only happen if the automatic search is enabled; if not, the result list should remain there until the user presses the search button. In the special case that automatic search is enabled, but more than N characters are needed to launch the search, and the user moves from N characters to N-1, the result list should remain untouched because there is no automatic (or manual) search to be launched. (the message notifying the -N characters needed- restriction should be shown to the user).

Here there is a video showing how annoying is the current behavior, showing also how other solutions, like Google, behave:
https://www.youtube.com/watch?v=yAbTgif2seE [^]
Steps To Reproduce.
Proposed SolutionEnsure that the automatic search (when enabled) is always launched when the manual one is available too.

Once the input contents changes, and the automatic search is enabled, erase the result list even if the search has not been yet launched.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to defect 0037389 newTriage Omni WMS Modules [AWOFE][UX] "Minimum allowed characters" message text is not properly located 
related to feature request 0038808 newRetail Retail Modules [UX] Add more visual feedback while a search is being executed 

-  Notes
(0105547)
migueldejuana (developer)
2018-07-03 13:17

Finally, if automatic search is enabled:

- We will trigger the search in selectors after the time of the defined delay, only in local mode(remote disable) and we forget the 3 chars limitation.

- We will show 'Loading...' when the user changes the input in order to show that we are searching for the new value. The search will be triggered when the delay time finishes.

- Issue History
Date Modified Username Field Change
2018-06-22 16:02 dbaz New Issue
2018-06-22 16:02 dbaz Assigned To => Retail
2018-06-22 16:02 dbaz Triggers an Emergency Pack => No
2018-06-22 16:11 dbaz Relationship added related to 0038808
2018-06-22 16:11 dbaz Relationship added related to 0037389
2018-07-03 13:17 migueldejuana Note Added: 0105547


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker