FreeLists / openbeos / [openbeos] Re: UI Guidelines

["Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>]

I agree that UI Guidelines don't have to be about new APIs. I was focusing in 
on the end part - the "BAboutBox" comment.
I think that UI Guidelines are a good and important thing. I think that they 
will also take a really special person or team (maybe) to work on.
Be has provided us with some nice looking apps as guides, but also something of 
a mess.

Just to branch off for a moment... In spite of what *many* people think, there 
is not some sort of warped hero worship going on, here. None of us believe that 
the people at Be were perfect. Nor that everything from Be was perfect. That is 
not the point of OBOS at all. The *ONLY* two reasons for us replicating R5 down 
to binary compatability are 1) We had/have a plan. From the very first day of 
the project, we had a nearly perfect spec with a reference implementation that 
we know was/is/will be possible, and 2) that plan is something that we can all 
(minimally) agree on. Many people who criticize that plan were not on the list 
early on (before that decision). There was all sorts of debate over language 
(C++ 2.95.3 vs 3.0 vs 25 other languages that are percieved as better), kernels 
(Linux vs BSD vs NewOS vs whatever), GUI systems (X vs roll our own vs 
whatever), license (GPL vs closed source vs BSD/MIT, etc) and more. This plan 
was/is a comprimise. Not everyone is happy with i!
 t. Looking around the BeOS community, certainly you can see some outcomes of 
that. But given that there are 5 variables all with (average) 3 choices, that 
is 125 different possibilities. Everyone has/had a favorite of those 125. I 
chose the one that I thought 1) would get us something like BeOS, 2) Would 
least isolate current BeOS users and 3) had the best chance of success, both in 
getting done AND in succeeding in the "marketplace". 

Sorry about that, esp you Daniel - your question didn't spark that - my train 
of thought in my answer did.

Anyway - Be's apps aren't all the same. Different people wrote different styles 
of apps. Some liked certain things, others didn't (within Be). Example - some 
of the preferences apps write text based files. Some write flattened BMessages. 
Others dump their internal data structures to disk (eww!). Some apps have 
bezels, others don't.  There is a fair amount of app cleanup along those lines 
that should occur. Maybe coinciding with the release of a GUI "Rulebook". 
Honestly, right now, I am *far* more concerned about getting the preference 
apps written. Once we are to that point, I think that this stuff should be 
sorted out. There are a number of issues (and I am betting that we don't know 
half of them) that a UI guru could work on. I know that BU has started such a 
set of guidelines (I read a draft) that was VERY good. It wasn't close to done, 
though. I will check with them and see if progress is still being made.

Again - sorry for the rant. I just needed a release, I guess. ;-) Maybe I 
should just have had a beer. ;-)

>Creating UI Guidelines doesn't mean that there need to be any new APIs,
>but (as I understand this) some kind of a documentation for developers
>on how a good application could look like and what's important when they
>want to make a app with a consistent UI. It could also just be a ordered
>collection of screenshots.
>
>thx
>Daniel "Assimil8or" Furrer
>
>Am Don, 2003-07-03 um 15.02 schrieb Michael Phipps:
>> I agree. I think that BAlert is a good example. Here is a quick.easy to use, 
>> standard "hey - look at this" window.
>> No one has to use it. The UI police won't come and take you away if you 
>> don't.
>> But those things are so seductive... Most coders are looking at a problem 
>> that has to be solved:
>> "oh - what if the file has been deleted before I opened it" or something. 
>> BAlert is a 10 second solution to their problem.
>> BAboutBox would be the same kind of thing. Seductive because it is so simple 
>> to add to the app.
>> 
>> For R2+ (which is really where this thread should be), I think that what we 
>> need to ask ourself is "how many apps could use this potential API 
>> addition?".
>> Is the value to enough developers that it is worth adding another 
>> class/kit/whatever to the API. Since almost every app should have an about 
>> box, I would think that the answer on this one would be yes.
>> 
>> >i remember frequent responses to this type of question. jean-louis' 
>> >answer was always a derivative of this:
>> >
>> >we do not imply nor enforce any user interface guidlines - your 
>> >applications are yours and you should know best how your users should 
>> >see them.
>> >
>> >personally i think the Fearless Leader was right.  if user interface 
>> >guidlines ARE created, they should only be done for small subsets of 
>> >applications.  ie: the prefrences windows should all look similar.  it 
>> >should be considered detrimental if userinterface guidlines are drafted 
>> >as a broad and sweeping mandate
>> >
>> >now with my knee-jerk response done.... i think that example windows 
>> >like BeAboutBox would be a good idea.  examples, but not really 
>> >rules...seems UnBe to me - thats all
>> >
>> >-jared
>> 
>> 
>> 
>
>
>