[Bf-funboard] 2.28 features

Christoffer Green bf-funboard@blender.org
Tue, 22 Jul 2003 11:51:51 +0200


Generally you should never expect a tutorial from a
previus version of any software to work with a never version of it.

Blender is a bit of an oddity here. To users, its ui have remained
basicly exactly the same for over 4 years, and over that time
it has not exactly developed a reputation for having the best possible
ui. Changing this as soon as possible is a good thing.

And the point of changing context does not apply, blender is
full of context changing buttons. The editbuttons is probibly one of best
examples.

And to why it should be in there is quite simple, it gets your work done
faster.
This vastly outweighs the drawbacks of confused newbies. Newbies are allways
confused.


----- Original Message -----
From: "Matt Ebb" <matt@mke3.net>
To: <bf-funboard@blender.org>
Sent: Tuesday, July 22, 2003 2:41 AM
Subject: Re: [Bf-funboard] 2.28 features


>
> ----- Original Message -----
> From: "Ton Roosendaal" <ton@blender.org>
> To: <bf-funboard@blender.org>
> Sent: Monday, July 21, 2003 11:01 PM
> Subject: [Bf-funboard] 2.28 features
>
>
> > Hi all,
> >
> > In the rush to get a 2.28 before Siggraph, I've copied a few features
> > from Tuhopuu. Which include:
> >
> > - the feature which automatic shows LampButtons or MaterialButtons when
> > you select an Object.
>
> I have to disagree with this one, as I mentioned to Ton earlier. I can
> understand the reasoning for it (makes things a little more
> context-sensitive), but I think it will cause way more problems than it
> solves, especially for new users.
>
> Firstly, it'll make all the tutorials and docs out of date. When a newbie
is
> doing a tutorial that involves lights, they'll look at the screen and
think
> "huh?? this version of Blender doesn't support lights!" since the light
> button only shows up if a light is already selected. I'm worried (and S68
> seems to be as well) about the  extra 'support problems' this will create,
> particularly over at elsyiun.com. It's also counter-intuitive to have the
> button changing all the time. Especially for something as major as the
> buttons headers (which is the main 'control panel' of Blender), it's best
> for things to remain stable, so the user can build an expectation of the
> system and 'get to know it'. If things are changing around, it leads to
> confusion and a feeling that the user is not in control of the system. See
> the remarkable UI failures of Microsoft's changing menus in Office..
>
> Secondly, it's not that logical. Perhaps if it doubled with Editbuttons in
> some way to make some sort of generic context-sensitive 'edit an object's
> properties' button, then it would make more sense, but sharing it with the
> materialbuttons doesn't make much sense to me since they're quite
different
> functionality-wise.
>
> And last, unless there are definite improvements to changing things, I
think
> most UI changes that break 'backwards compatibility' (especially with
older
> tutorials) should be saved until there are many things, and it can all be
> done in one big change. If we keep making changes in bits and pieces in
all
> the versions along the way, then you end up with a situation where the UI
is
> constantly changing, users must re-learn their old habits, tutorials made
> along the way get out of date, and people have to try to remember what
> version has what little idiosyncracy when trying to answer questions in
> Q&A..
>
> Anyway that's my little annoying nitpick The rest of the 2.28 stuff looks
> great, and I'm really looking forward to it. However for this one, I think
> the number of disadvantages greatly outweigh the advantages.
>
> Matt
>
>
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard@blender.org
> http://www.blender.org/mailman/listinfo/bf-funboard
>