On 6/4/07, Andy Parkins <andyparkins@xxxxxxxxx> wrote:
On Sunday 2007 June 03, Marco Costalba wrote: > Care has been taken to allow the wheel browsing experience to be as > natural as possible, in particular a way to avoid to switch when user > just wants to scroll has been implemented. Also, getting a responsive > scroll and switch command avoiding false positives was not immediate. I'm really sorry to say it Marco, but it's really disturbing. You've obviously made great efforts to make it useable, but it just isn't. The scroll wheel behaviour being inconsistent is just annoying. Sometimes scrolling works, sometimes it doesn't, sometimes it switches content, sometimes it doesn't. It's obviously based on timeouts for the different functions, but that just means that I have no idea what a particular operation will do at any given time.
Thanks for your comment. I will try to do the following: - Allow to remove this possibility by unchecking a proper flag in settings dialog. - Change the color of the arrows, as example highlighting, when the switch behavior became active, i.e. at the top and bottom of scroll bar. So the user will know what a scroll action will do.
I'm not sure I like the labels with arrows either; and the fonts changing size and visibility is inconsistent and discomfiting.
Ok I can use same font for both labels, not a biggie. Regarding the arrows, any other idea to tell to the user something will happen when scrolling is welcomed.
On the plus side - I do like the idea of being able to perform these operations; jumping from revision to revision, or from log to patch is nice. However, I think it is unwise to invent a new graphical metaphor for an operation that already exists - the tabbed widget.
The tabbed widget is here to stay. I do not plan to remove it. But the tabbed widget is also slower then a well behaved scroll swicth or link clicking.
Similarly, the up and down are obvious candidates for toolbar buttons - an already established visual.
This could be added, but it seems not needed to me given that for the suer is faster to click on the previous/next revision in the revision list then reaching the toolbar.
So - I think that the non-standard methods should be dropped (sorry); and be replaced with tabs for the patch/log switch and toolbar buttons for the up/down. Also, the scroll-to-switch, while an interesting idea, gives unpredictable behaviour and so is uncomfortable to use. Sorry for being so negative; it's a shame after your obvious hard work.
Thanks for your comments. They are much more valuable and useful then a 'yes...it seems more or less nice'. Thanks Marco P.S: Scrolling is not based on timeouts. The rule is: if user starts a scroll action while not at the extremes of the content then only a scroll will occur. If the user starts a scroll action from one extreme of the view (top or bottom) and the scroll direction goes toward out of the screen then a switch will occur. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
