[Bf-committers] 2.5 release

blendenzo blendenzo at blendenzo.com
Tue Nov 17 18:39:17 CET 2009


I can attest to the amount of time which can be wasted looking for 
buttons that are not there.  I recently spent half an hour searching for 
the Texture Face settings which are used to give special properties to 
faces in the game engine, only to find that they have not yet been added 
(even though the functionality which they represent is already present 
in 2.5).

Personally I am in favor of having the UI as representative of the final 
UI as is possible, even if it means some grayed out buttons or "feature 
not yet implemented" popups.  However, I also recognize that this would 
mean a substantial amount of unplanned for work before first release, so 
I won't be surprised if it doesn't happen.

Knapp wrote:
> OK, I can see this point but the other side of it is that we (advanced
> users in both senses) are using it to try it out and to find bugs but
> also to learn it, so that we can help the next wave of users. If I see
> a button is missing, for example the play rendered animations button,
> I go looking for it. If I find it, then I know where it is and have
> learned that bit. If on the other hand buttons pop up later, I might
> already know that they are not there (falsely) or never think to look.
>
> I think to solve your point, a message should pop up saying something
> like, "Not Yet Implemented", just as it would on a beta web site.
>
> The other plus of this, from a design point, is that we have a well
> designed UI. Putting together a UI in bits is how we ended up with the
> mess that is the 2.49 UI. It was made by years of people adding bits
> here and there as best they could. 2.5 is a total redesign to address
> problems like this, at least I think it is. Why not decide where all
> the button will go early on? Maybe even plan for buttons that might be
> needed years down the road. (not saying they should be seen yet)
>
> Also the work is not useless, if the buttons go to planed but not yet
> implemented features. The UI is a totally key part of the puzzle of
> making a great work flow and a great piece of software. It should be
> one of the most thought out and tested bits of the whole thing.
>
> A bit of auto testing would not be a bad thing. :-)
>
> On Tue, Nov 17, 2009 at 4:31 PM, Roger Wickes <rogerwickes at yahoo.com> wrote:
>   
>> With all due respect, I disagree totally with the request to add
>> all button, even if they go nowhere. I think it is misleading,
>> and a lot of useless work, to put in buttons that go nowhere.
>> I would only agree if we were using an automated GUI testing
>> tool that clicked on certain coordinates in executing the script.
>> In that case, we would want to preserve those coordinates
>> for later regression testing. If the goal of the release was to
>> get feedback/work out UI placement and arrangement, cool,
>> but that is not one of the goals of the release, afaik.
>>
>> Users that see a button like to click it. Otherwise, you are
>> introducing a decision point into the process, which is "Is this
>> feature implemented in this beta?" and I would bet dollars to
>> donuts they would not know. Hence, if a feature WAS supposed
>> to be in there, but was broken, clicking the button with no response
>> masks the error, as the user will assume it was not in the release.
>>  ----------------
>> Sent by Roger Wickes for intended recipient. If you are not the intended recipient, please delete this message and contact Mr. Wickes immediately.
>>     


More information about the Bf-committers mailing list