[Bf-committers] UI changes from cycles branch

[Troy Sobotka]

Can we start a new thread discussing the design constraints on the default
typeface perhaps?

With respect,
TJS
On Oct 23, 2011 4:39 PM, "Matt Ebb" <matt at mke3.net> wrote:

> On Mon, Oct 24, 2011 at 10:21 AM, Brecht Van Lommel <
> brechtvanlommel at pandora.be> wrote:
>
> > Hi all,
> >
> > Here's a patch with a subset of the UI changes in the cycles branch
> > that I'd like to merge into trunk. Are there any objections to this?
> >
>
> I'd personally like to hear the rationale for these rather than just saying
> here's the patch. Some of it seems a bit more like a matter of taste too,
> rather than something that's designed for a wide audience, so I'm curious
> to
> hear the reasoning.
>
>
> > I don't think they would need any documentation updates, it's just
> > small things that wouldn't confuse anyone in screenshot:
> > * Remove emboss on areas and regions
> > * Remove button emboss
> > * More subtle colors and gradients on buttons
> >
>
> Most of these I don't think it would be a problem to make the embossing a
> bit more subtle, but I'm not keen on removing it all entirely. Even just a
> subtle hint of shape and shading really helps to distinguish the buttons
> from everything else - not just in the literal sense of give it an
> affordance 'this is a button, you can click on it' but mainly for some
> visual difference between the rest of everything else on screen.
>
> When everything is flat with single pixel outlines (not just buttons, but
> also other dividers, grids, scrollers, lines in other editors like the
> animation/timeline editors), it loses a sense of visual hierarchy and
> rhythm
> - it all tends to merge into one soup of lines and flat shaded areas, and
> makes it harder to find things quickly in the UI.
>
>
> > * Black arrows on menu button
> >
> -1, Way too low contrast, there's almost no point in having them there.
> Makes them look like other dark UI widgets like radio buttons, which is not
> good.
>
>
> > * Panel header changed look & smaller
> >
> Seems ok, but I would give it an extra pixel or so of padding both above
> and
> below, it's quite cramped and loses its sense of importance in wayfinding
> (becomes much more like just another button).
>
>
> > * Screen splitting widgets look
> >
> Not a fan of how it is now, but perhaps if it was the dark triangle with a
> hint of the 'gripper' lines blended on top it would work better.
>
>
> > * Toolbar/properties expand button look
> >
> Looks great
>
>
> > I'd still like to change the font in trunk, but it seems hard to get
> > an agreement on this. Some tests:
> >
>
> Again, I'd like to hear the rationale - I think the font in trunk right now
> is very good.
>
> If it's to make things smaller and more condensed, be wary of cutting off
> one's nose to spite one's face - you *need* whitespace in design, it's not
> just wasted areas where more can be crammed in.
>
> cheers
>
> Matt
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>