[Bf-taskforce25] Mockup note

Samuel Nicholas nicholas.samuel at gmail.com
Mon Mar 16 11:55:27 CET 2009


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.


More information about the Bf-taskforce25 mailing list