[Bf-taskforce25] Mockup note

[Ton Roosendaal]

Hi Sam,

Thanks for the mockups with hupulakuuta!

It does show quite clear how long labels in number buttons don't work 
well :)
Maybe compare with a text-outside version?

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands

On 16 Mar, 2009, at 11:55, Samuel Nicholas wrote:

> Matt Ebb wrote:
>> 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
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
> Hi,
>
> http://enetheru.aglargelair.net/files/number_fields_title02.png
>
> A bit of right and left alignment can help. ive added some highlight to
> also seperate but imho it adds too much clutter.
> space will always be limited so I think the value should stay, the txt
> truncated. perhaps on mouse hover over the truncated txt part it swaps
> so that the value is truncated instead this gives some more information
> quickly rather than wait for a tooltip.
>
> thx for reading
>
> Samuel.
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>