[Bf-taskforce25] Mockup note

[Matt Ebb]

On Sat, Mar 14, 2009 at 11:49 PM, Ton Roosendaal <ton at blender.org> wrote:
> I would definitely propose to not immediately reject this idea, and
> investigate layout opportunities with both concepts. For example;

Ok, I'm not immediately rejecting it, sure it would be good to try and
see if there are other alternatives. There are negative aspects too
though, to be aware of.

> Now imagine translated UIs that might be even give worse cases. Try
> some translations in 2.48 and check how it looks?
...
> 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.

I'm not sure what you mean for the translation - I suspect you mean if
the string is too long it needs to be clipped off? If so, I agree,
this is a good argument for separating out. It's already quite
annoying when long names mean the button gets less precision than it
should. It would still be possible to clip the end of the title and
leave the numbers intact, with the label on the button, but yes, it
would be weird and potentially quite confusing.

> And we also could prefer add the metrics types, or degrees, or
> percentage symbols inside the buttons.

We can do this currently, in fact I already implemented it for RNA
'percentage' subtypes :) You can see it in datablocks outliner view,
but the only one it's implemented for is Render data resolution % :)
As a side note, I would have already added the degrees too, but it's
not an ASCII character and doesn't work with non-international fonts
atm...


Anyways, for the reasons I mentioned previously, I'm still not too
keen on the properties_text_outside.png mockup. I was thinking though
what possible modifications could be made to keep the advantages of
both methods:
* title spatially separated from value, for alignment, truncation etc
* large available space for manipulating the button
* clear visual connection between title and value, so you know exactly
what title a property has at a glance.

I did a few quick ideas here:
http://mke3.net/blender/interface/controls/number_fields_title01.png

The idea is that you still should be able to drag on the text area to
increment and decrement, giving a nice large click target. Photoshop
works in a similar way (
http://mke3.net/blender/interface/controls/ps_dragvalue.png ) but I
don't like their implementation much - it's not communicated clearly
and I only found out about this feature myself by accident, since it
just looks like a normal text label. I think we can improve on this by
showing that it's part of the number field somehow. Incidentally, XSI
also has this problem, but their solution is quite inelegant, drawing
huge dashed lines between the separated titles and values, so you have
at least a small hope of your eye tracking across and finding the
right UI control. This is really not good graphic design (
http://www.edharriss.com/xsi/4point0_images/prefs.jpg ).

Regardless of what happens, what I think is extremely important is
consistency. I really would not like to be in a situation where the
important information isn't always in a consistent place, and you
never really know where to look for it.

If it's all text-on-buttons, you know when looking for a setting that
the information is on a button and looks a certain way. Your eye can
then quickly scan all the items on screen that fit that visual pattern
and find the information. Otherwise if the text is consistently
outside the buttons, your eye knows to scan over the screen, finding
the button, and checking next to it at a certain offset. If it's a
mixture, it makes it harder to find things quickly, since your
eye/brain has to take more time processing things, its not as much
taking advantage of our abilities for visual pattern recognition, and
I would very much not like to see this happen unless it worked based
on some very clear rules that users can immediately understand and
predict.

cheers,

Matt