[Bf-taskforce25] Mockup note

Sun Mar 15 11:02:13 CET 2009

Hi,
I like it more when the text are outside so the they doesn't look like
it's editable/copyable.
And when editing numbers that are wider than text field it won't push
[XYZ]: off-view
nor need extra tweaks to keep the [XYZ] in it.

I'd love to have (-)(+) instead of (<)(>) too.
Just some thoughts.
Thanks!

2009/3/15 Rob Cozzens <robcozzens at gmail.com>:
> 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
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>

-- 
    .----.     Banlu Kemiyatorn
  /.../\...\   Free Software Yogi
 |.../  \...|  漫画家 GZSC
 |../    \..|  http://groundzerostudiocomplex.blogspot.com
  \/      \/   http://qstx.blogspot.com