| • Jaredzimmerman-WMF | |
| Mar 3 2015, 11:43 PM |
| F54389: Screenshot_2015-03-03_15.37.49.png | |
| Mar 3 2015, 11:43 PM |
| F54391: Screenshot_2015-03-03_15.40.36.png | |
| Mar 3 2015, 11:43 PM |
In cases where many categories are present the interface to add categories is hidden on initial view
In general any case where a key part of the interface moves based on the content that is present can cause confusion for users. Establishing a consistent location for the control will help users feel the interface is stable, and that elements are in expected places.
Really? Why? This adds one to the end. It's in exactly the place it then gets "created". I agree that it should be in a better place, but at the top turns it into a search/filter piece, which is totally the wrong design metaphor.
Also note that add-at-the-end is the standard design metaphor across VisualEditor – in template parameters, transclusion components, etc., so if we're changing it in one we should change it in all.
I don't understand how search is the wrong metaphor here, you're searching through available categories to add, the fact that they are added to the end is fine, it will take a users about 1 second to understand that, I don't think anyone will be confused. (animation can help here)
Increasing consistency with other UI areas that, themselves may need to be rethought might not be the ideal way to judge this change.
We could do user testing with this, using a blank list of categories, a semi-populated list, and a full list of categories, with the add field on the top and on the bottom, and I think we can all easily guess which will test better on discovery.
I don't want to overthink mental models when just a little common sense will do.
At the weekly triage meeting today, we decided that this wasn't urgent for this quarter, so declined to accept it.