[Bf-taskforce25] Mockup note

[Rob Cozzens]

Hi,

One benefit of the "outside" version is that the information is clearly and
consistently separated. The label is always next to the button, and value is
always inside the button. There's no time lost visually separating that
info.

Lining things up can be an issue though... in the current "outside" mockup,
some of the labels in the dupliframe section are too far from their buttons.
They could be "right-aligned" but then there would be a jagged left edge,
and that might not look good.

Also, the embossed text is a little hard to read.

BTW, everything you developers have been working on for 2.5 is looking
great! I'm really excited.

-Rob

On Sat, Mar 14, 2009 at 5:49 AM, Ton Roosendaal <ton at blender.org> wrote:

> Hi,
>
> William showed this test he already did before;
> http://www.reynish.com/files/blender25/properties_text_outside.png
>
> Compare this to the inside version;
> http://wiki.blender.org/uploads/8/88/2_5_mockups_01.png
>
> I would definitely propose to not immediately reject this idea, and
> investigate layout opportunities with both concepts. For example;
>
> Checl the "Pass Index" button. In both mockups it has text outside,
> probably because it communicates well, right?
>
> Check in 2.48 panels like for SSS, which have longer and variated names
> inside the button, long names in number buttons don't make it easier to
> read.
>
> Now imagine translated UIs that might be even give worse cases. Try
> some translations in 2.48 and check how it looks?
>
> Without the label inside the button, the functionality of those buttons
> (= edit number values) are visually clearly communicated. (See
> start/end/on/off buttons in the mockups). I don't think fit's law fails
> on that really.
>
> And we also could prefer add the metrics types, or degrees, or
> percentage symbols inside the buttons.
>
> And then there's the fact that, if a button cannot hold the name +
> value anymore, stuff have to get truncated... is the name or value then
> going to be shortened?
> We should allow users to input things with the optimal precision
> possible, not being dependent on what the name of a value is.
>
> Also consider that using 'white space' is an important layout concept
> as well. Text outside buttons takes more space, but also allows a less
> crowded visual appearance, so you can find and read things easier.
>
> Further it gives a nice consistancy with other buttons, allowing
> alignment.
>
> -Ton-
>
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands
>
> On 14 Mar, 2009, at 2:14, Matt Ebb wrote:
>
> > On Sat, Mar 14, 2009 at 2:39 AM, Ton Roosendaal <ton at blender.org>
> > wrote:
> >> Hi William,
> >>
> >> http://wiki.blender.org/uploads/8/88/2_5_mockups_01.png
> >>
> >> For nice aligned layouts it would work better to more strictly
> >> separate
> >> button values (numbers, menu options, settings) from their labels.
> >>
> >
> >> They do this quite consistantly, only tool buttons get their entire
> >> text inside, which makes sense.
> >
> > I disagree here. For things that are redundant like 'Location X'
> > 'Location Y'
> > 'Location Z' , it definitely makes sense to drop the 'Location' and
> > leave it as a separate label. Repeating that text on every button
> > overcrowds things, and makes it harder to skim-read down the left edge
> > for the useful information (x/y/z).
> >
> > However for other buttons, I think it's better to keep the label on
> > the number field. The space in the UI that the text occupies is going
> > to be used anyway, and so putting it on the button itself keeps a very
> > clear connection between the value and the property (which can
> > potentially get messy and unclear in more complicated layouts), but
> > also, keeping the button size large is a good thing.
> >
> > The speed of accessing a target on screen with the mouse is a function
> > of distance to the target and the size of the target (Fitt's law), so
> > the larger the button, the easier it is to hit it quickly. Having
> > smaller buttons means you have to be much more exact with clicks,
> > which is a bit of a waste if the space is already being used by the
> > text, just not clickable. This is also the reason why the check-box
> > toggle buttons are currently drawn with the button background and not
> > just the checkbox - it's much easier to hit, and it's also apparent
> > that the entire region is clickable.
> >
> > cheers,
> >
> > Matt
> > _______________________________________________
> > Bf-taskforce25 mailing list
> > Bf-taskforce25 at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-taskforce25
> >
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090314/42adb146/attachment-0001.htm