Re: [RFH] QGit: how to cram a patch in a crowded screen

From: Marco Costalba <mcostalba@gmail.com>
Date: May 31, 2007, 04:39 UTC
Message-ID: <e5bfff550705302139q224ab949h7086478ab0045a8c@mail.gmail.com>
In-Reply-To: <1180571013.3582.32.camel@dv>

On 5/31/07, Pavel Roskin <proski@gnu.org> wrote:

Show 20 quoted lines

> On Wed, 2007-05-30 at 21:18 +0300, Marco Costalba wrote:
> > My (crazy) idea is:
> >
> > - Let switch from message to diff content scrolling down after the end
> > of message.
> ...
>
> I'll appreciate if you follow standard conventions for standard GUI
> actions and don't change the behavior of such basic keys as arrows.
>
> It would be better to use something more advanced for application
> specific behavior.  I belong to the post-vi generation, so my mind
> cannot easily associate letters (like 'i' and 'k') with up and down
> actions.  But we could use some key combinations with obvious
> "directional meaning", such as Ctrl-arrows.
>
> I've said it before, and it's worth repeating - any key must be
> discoverable through the GUI.  No key or feature should be discovered by
> accident - it would be a sign of bad design.
>

yes I agree with you. The only thing that until now stopped me to add buttons to tool bar is that it seems to me already over crowded. But I agree keys should be discoverable. Also regarding arrow keys, they still have the same good old action to go up and down in text content, and will keep that.

Show 12 quoted lines

> > So I imagine two labels for each content type:
> >
> > - for message content a top right label called "Up" and one in bottom
> > right position called "Diff"
> ...
> > I plan also to change the labels in something more intuitive with
> > scroll action, as example adding an up and down direction little
> > arrows next to them.
>
> I'm afraid it would misuse the paradigm of labels.  It should be
> buttons, perhaps in the toolbar.
>

The idea of labels comes from using gmail, where in long threads you can see the following with a coloured label with an arrow and the name of the sender.

The labels, used in this way and decorated with small up and down arrows, give more the meaning of "scroll down to see what's next" then using a button, but when yhe machinery is implemented it should be straightforward change from labels to buttons and test also with them.

Show 8 quoted lines

> > P.S: In case someone wonders what's the goal of this label madness. It
> > is to be able to browse a repo in either both sequential directions,
> > up or down, using only the mouse wheel.
>
> It may be a cool feature, but users don't expect the mouse wheel to
> change anything other than position of the text.  Switching the revision
> by the scrolling the wheel would be a feature discovered by accident.
>

Yes, this problem is still open. I think the key is the graphical rapresentation of the labels/butons and their placement inside the window to give the user the hint that when scrolling with the mouse he'll reach what's advertised in the label. Again gmail use of "go to next thread" labels gave me some ideas.

Thanks Marco