[Bf-committers] 2.5 release

Thomas Dinges dingto at gmx.de
Wed Nov 18 05:55:00 CET 2009


To be honest I don't understand the discussion at all. It will be a beta 
Release and will be claearly marked as one.
Why should we implement buttons that are not here yet? There are missing 
ones and thats also something why we release that beta, to get more bug 
reports about missing features and non working stuff.

I also strongly disagree about the Engine Toggle topic. As a Non Game 
Engine User i don't want to see a GE button at all, neither a "game 
menu". It's something new, this engine toggle, but in my oppinion a 
great feature to prevent the UI from being overpolluted with buttons the 
(non GE) Blender User don't want to see.

Thomas

joe schrieb:
> It's a bad idea to try and design everything about a UI ahead of time;
> you inevitably end up making changes once you actually implement
> things anyway.  I also disagree that we're risking making a bad
> impression, this is a *beta* after all, and plenty of software
> survives being in beta (just look at firefox).
>
> Joe
>
>   
>>> 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.
>>>       
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>>       
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>     
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>   



More information about the Bf-committers mailing list