Re: [ANNOUNCE] qgit new "smart browsing" feature

From: Marco Costalba <mcostalba@gmail.com>
Date: Jun 4, 2007, 11:20 UTC
Message-ID: <e5bfff550706040420j22852e4btc41a88c79bffc49f@mail.gmail.com>
In-Reply-To: <200706040921.55861.andyparkins@gmail.com>

On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:

Show 15 quoted lines

> 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.

Show 7 quoted lines

> 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.