Bug 1299985 - Cannot write directly to the Component picker
Summary: Cannot write directly to the Component picker
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs
Version: 4.5
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: PnT DevOps Devs
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-19 16:42 UTC by Milan Crha
Modified: 2019-01-30 05:55 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-01-30 05:55:53 UTC
Embargoed:


Attachments (Terms of Use)

Description Milan Crha 2016-01-19 16:42:11 UTC
I have one more (bug #1265079) usability issue with the Component picker. I manage evolution packages, that is for example evolution and evolution-ews. When users (or ABRT) fills bug to the evolution component, I'm supposed to move it to evolution-ews, if the crash happened due to it.

The current procedure is:
a) select the Component combo
b) press backspace to delete whole content of it
c) write: "evolution-ews"
d) wait for the autocompletion to complete
e) pick the right component from the list
f) save the changes

There are three problems:
1) the step b) forces me to write the prefix once again, even it was
   already there. This wasn't needed before, just the opposite, the combo
   content was sorted, thus it was matter of two/three arrow-down presses to
   get to the correct component; I'm currently forced to re-type the whole
   'evolution' word to get proper results

2) step d) is time consuming. I do not know how quick it is on your network,
   but mine is not that quick, thus I wait for several seconds till I get
   anything to pick from. Compare with already downloaded list of components
   and the above mentioned two/three arrow-down presses to get to the right
   component and follow the work

3) step e), I cannot move away from the Component picker without selecting
   autocompleted value from the list, even what I typed matches exactly one
   of the values; try to write something and press <tab>, you'll be presented
   with the previous value in the picker instead and forced to repeat
   the steps again

Thus while the "widget" is meant to make things quicker and more elegant (from my point of view), it's not the case, because it requires more work from the users and more time for things which could be basically instant. If you'd work with hundreds bugs per week/month you might get my view pretty quickly (I confess I luckily do not work with hundreds bugs per week/month).

Comment 1 Jeff Fearn 🐞 2016-01-21 00:42:29 UTC
The selectize widget [1] has a plugin "restore_on_backspace" which does the "backspace == edit what's there" behavior.

I'm not sure if we should default that on or make it a user preference, I'll chat with the team about that.

1: http://selectize.github.io/selectize.js/



The speed issue is something we are looking in to. It saves a similar time on page load so the net effect across all users is a positive. The widget does cache search results but of course the first search has an empty cache.

We could add a user option to preload the component list and not use ajax, but then you will pay the load time for that every time you load a bug, even if you aren't going to change the component. The component list is large and has a noticeable affect on page load times.



I think a lot of people would get miffed if we auto selected from the list if there was only one match. People make typos and it'd be very annoying if it auto selected a typo and you had to delete it and type again. We could probably make a user preference to do this if you really want it. There doesn't look to be an upstream plugin for this so we'd have to write our own.

I think we should address issue 1 in this bug and if you are still keen on having 2 and 3 addressed please open separate bugs for each of them.

Comment 6 Jeff Fearn 🐞 2019-01-30 05:55:53 UTC
In preparation for entering maintenance mode we are closing bugs that are unlikely to be scheduled in maintenance sprints.


Note You need to log in before you can comment on or make changes to this bug.