Re: gnome-utils branched for GNOME 2.16

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On Wed, 2006-09-06 at 15:59 -0400, Bryan Clark wrote:

> > Last time the thread died out pretty quickly, and since I had to push
> > back the UI work on the screenshot app, I'd like to nail it down for
> > real this time.
> >
> > The first, obvious transition is to a save dialog window with the same
> > behaviour of the GtkFileChooserDialog, to use the tab completion + full
> > path editing of the destination file; the currently used layout (preview
> > + save stuff + (save, cancel, help) buttons can be bolted without much
> > effort on a GtkDialog with an embedded GtkFileChooserWidget in save
> > mode.  This is the structural change that I have in mind at the moment.
> > Using a vertical layout might be the next move - I think there's too
> > much wasted screen real estate in the current dialog.

> I think the tab completion is probably a good idea.  I'm wary of going 
> more towards a unified and consistent system vs. doing hacks that simply 
> make the screenshot dialog better.  For instance I believe someone 
> mentioned in a previous mail that the fact that the file extension is 
> included in this entry is a bit cumbersome.  You can't save as a jpg or 
> gif here so it's no use to require me to type in 'png', I hope that 
> doesn't get inherited from using the filechooser widget.

The extension is not selected by default so you have to actively select
it to change it; but the ability to save a screenshot as a type
supported by GdkPixbuf is another feature on the wish list for a while,
now.

[...]

The "wasted screen real estate" argument in this case is more about the
lack of a balance between the preview and the controls; it shows in the
mock up you attached: you've got a pretty big picture and two small-ish
controls on the left with a huge empty space.  I don't want to fill up
that space with controls, knobs, text, whatever; I'd like the dialog to
have a more fair balance between the elements inside it.

> Not to say that there couldn't be cleaning up of the dialog.  But one of 
> the elements I'd like see kept in the design is the left to right flow 
> of the dialog; this of course isn't internationalized.  We put the 
> screenshot preview on the left side of the dialog because when it first 
> opens you want to examine the screenshot preview first, then handle 
> changing the filename, then the lower buttons.  I don't have any eye 
> tracking usability tests to prove this is working, but that was the 
> intent of the design.  We had prototyped a number of mockups that I 
> aparently can't find now.  But if the dialog gets rearranged to have the 
> preview on the right hand side and all the other widgets on the left it 
> requires a person to scan over the whole dialog to check the preview, 
> then scan back to where they change the filename, then scan back over to 
> find the save button.

I was more attracted by the vertical layout, with the preview on top - a
bit larger than what it is now - and the actual FileChooserWidget below
it.  There's an ASCII art mock-up attached on a bug here[1], and I
attached a couple of PNGs[2] of how I think it should work both with
vertical and horizontal layouts.  The FileChooserWidget sizing
represents a problem in both cases, so we're going to need a minimum
size and test on lower resolutions.

Anyway, if we are to keep the current layout (image first, save control
after) then we must really rearrange it based on the text direction: as
you wrote, the whole point of having the current layout is to ease the
user into following a certain flow, mimicking the reading pattern.

> > Yep, and it works well - also, having drag and drop support makes the
> > "edit in GIMP button" feature kind of a moot point: I can drag the
> > preview on GIMP and have it ready to be edited.  This might pose a
> > problem for the a11y people, though.
> >   
> Wow, I actually had no idea you could do that.  That tends to save a bit 
> of time.  Perhaps it would be worthwhile to let people know that is 
> possible with a simple text area, see attached.

Indeed.  I already had to tell a couple of people that there was this
feature. :-)

So yes, definitely a help hint is needed.

+++

[1] http://bugzilla.gnome.org/show_bug.cgi?id=325708#c6
[2] http://bugzilla.gnome.org/attachment.cgi?id=72345&action=view
    and following

Ciao,
 Emmanuele.

-- 
Emmanuele Bassi,  E: ebassi gmail com
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net