313: Suggestion: remove mouseclick requirement for field editing.
- Fixed
- Review Board
| ryan****@gmai***** (Google Code) (Is this you? Claim this profile.) | |
| Jan. 30, 2014 |
The autocompletion for reviews is an "ok" feature, but hitting tab to autocomplete moves the focus away from the reviewer field, so if one wishes to add more than one reviewer, it requires *several* more tab key presses to come back to the reviewer field, or a mouse-click to bring the user back to the field. In addition, the fancy "web 2.0" style interface may be kind of attractive and clean looking, but having to click a pencil graphic with the mouse just to edit a field with one word is a bit ridiculous. IMO, a better approach would be to select the appropriate field to auto-focus to when editig the page, and provide a logical tabbing order to tab and shift-tab between. This is supposed to be a productivity tool, not a web 2.0 community site. My background is web UI development and this interface drives me crazy. I can't imagine what more dyed-in-the-wool programmer types are thinking with all the mousing that is required...
Tab shouldn't move you away from the field during autocompletion. Can you at least provide some information on what browser you're using so we can figure out why this is happening? As far as the pencils go, this is a productivity tool and you're really the first to complain that I've seen so far. People will have different opinions of what works best. In my opinion, you rarely edit fields after the first time and clicking a pencil makes it very clear what you're going to be editing. You can click anywhere on the field, by the way. Usually when you look at a review request, even if you own it, you're there to read it and not modify it. This may include wanting to click the bug links, the reviewer links, whatever. Making these all fields automatically would remove the ability to click these links. In the future there will be more information in there and extensions will be able to add entries for display. They will be able to present whatever they wish but should be editable. The pencils would be required for this scenario to work out well. Now, I'm open to suggestions. Perhaps we put everything into field form for the review request before you first publish it. Maybe we somehow allow tabbing between fields. I would probably accept patches that implements these assuming they don't remove usefulness that we've intentionally put in there. I'd also like to point out that there are other productivity tools on the web that use this same model, and they're in use by thousands of people. Remember the Milk being one example. I have a background in web UI development and general interface development as well, but not everyone shares the same philosophies when it comes to that, and the idea of web UI development has certainly changed in recent years.
-
- Priority-Medium + Priority-Low + Component-Reviews
Yup, FWIW - not trying to be ugly about this, just expressing my opinion in case it were to add to a general opinion on certain elements. If no-one says anything... But you are probably a bit justified in reacting as if I was being reactionary - so I'll be a bit more constructive here. The browser I have been using is Mozilla-based Camino on Mac. I haven't tested the tabbing on other Mac browsers. As far as productivity goes, perhaps some added features would shore up some discrepancies. - We still have to create changesets in perforce somehow. Personally, I use the command line interface because it is usually easier. The bug listing gets imported into reviewboard -- it would be really helpful to import the reviewers as well. - Tabbing - perhaps a good addition would be the ability to tab-select the pencil links the same way that one would tab-select a link, so that key-press "clicking" on the pencil would activate the edit field and give it focus. - As for your comment regarding viewing vs. editing, I think that probably varies widely, but I see your point. - For the initial review post -- having just an open set of fields for editing drafts would be really helpful I think. It would also help to get around the confusion with the various confirmation panels that popup whenever anything has changed (Save change vs publish this vs. save *and* publish). I think I share the experience of wiping out changes by clicking publish without saving first.
The changeset scraping could definitely be improved. Though the reviewers field is meant for people who have already reviewed, it can contain expected reviewers. What we do have in place is support for adding default reviewers based on file paths in the diff. We could always add these for your team. The newer version of post-review in SVN support specifying default reviewers on the command line. We can definitely add tab spots for the pencils. The OK/Cancel buttons on each field are gone now and clicking Publish now saves every open field. This should make things a lot better. Hopefully that gets rid of a lot usability problems there. I'm okay with adding support for initially opening all fields ip-front too.
-
+ Usability + Keyboard
-
+ Confirmed
-
- Type-Defect + Type-Enhancement