Re: [Usability] UI design question

[Matthew Paul Thomas <mpt myrealbox com>]

Hi again Dave

Sorry for the slow reply.

On Jun 17, 2008, at 3:21 AM, Dave Foster wrote:
> Hi Matthew + Jacob -
>
> Thanks for the advice, some good stuff in here.
>
> On Mon, Jun 16, 2008 at 7:59 PM, Matthew Paul Thomas 
> <mpt myrealbox com> wrote:
> > My first thought is: That list of actions doesn't seem to include 
> > anything that requires it to be a dialog. Could it be an ordinary 
> > window instead?
>
> I guess I just didn't get the difference between the two.   I thought 
> a dialog was just a window with a pre-defined layout.  I'm guessing by 
> your reactions there is a bit more? 

A dialog is modal to its parent window, and has a row of buttons along 
the bottom, most of which close the dialog. Typically, a dialog asks 
for extra information on something you specified in the parent window.
<http://library.gnome.org/devel/hig-book/stable/windows-dialog.html.en>

> > Instead, try thinking object -> verb: present the list of themes 
> > first, with the actions afterwards. Like this:
> >
> > This is much calmer, even while it lets you see the complete list of
> > themes at a glance (which the radio-button-based design wouldn't).
>
> To be honest, it didn't strike me right away, but this could be a 
> pretty good way of looking at it. I'll fiddle with it a bit and see 
> what looks good.  Any other options for laying it out?  The buttons at 
> the bottom seem a bit.. eh, i don't know how to describe it.

Since this window would now mostly be a listing, the list could go 
right up against the top, left, and right edges of the window, like it 
does for folders in Nautilus. At the bottom of the window would be a 
panel in which the buttons would sit with the standard spacing. Imagine 
nautilus-cd-burner, rotated 180 degrees.

> Would it lose anything if they were on the right, arranged vertically? 

The main drawback (as you may have discovered by now) is that it would 
take up more space -- there would usually be a chunk of empty space in 
the bottom right corner.

> > Here's what would happen to the previous options:
> > *   "Create a new theme" ->  "New...", then type its name into the
> >     newly-created table row.
> > *   "Create a new theme based on an existing theme" ->  select theme,
> >     then click "Duplicate..." and type the name into the newly-created
> >     table row.
> > *   "Open an existing theme" ->  select theme, then click "Open".
> > *   "Edit current theme" -> open window, then click "Edit" (the
> >     current theme being selected by default).
> > *   "Open last edited theme" ->  select theme, then click "Edit...".
>
> I think the "edit" and "open" actions are really the same thing here, 
> so they can be combined into a single button.

Great. (I wondered if that was the case, but I don't know what kind of 
themes we're discussing.)

> Thinking about the (future) general users of this application, the 
> "new from scratch" option is going to be not used very often.  I think 
> the majority of themers start off by copying something (the duplicate) 
> and then tweaking it until it is unrecognizable, so I think the 
> "create based on an existing" or "edit existing" are the two most 
> important items on this menu.  With the "new theme" being so 
> prevalent, I think people will miss the functionality of "duplicate" 
> on first glance, until they try it a few times and see what happens.

Perhaps label it "Copy as New Theme…".

> I hope I'm being clear above.  With this info in mind, does it change 
> anything about what you said?
> ...

Not really. That there are fewer buttons makes me happier about the 
layout.

Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/


---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---