[openbeos] Re: Visual design stuff again

 <snip>

> 
> There is some history, too, that many people who are newer to the 
> list may not be quite so aware of. Back in 8/01, there was a lot of 
very
> wild talk. True micro-kernels. Exo-kernels. Use X/not use X. Use 
> Linux/BSD/other kernels. Write the whole thing in Python. Lots of wild 
ideas.
> Not a lot of code, but a lot of wild ideas. That had to change. 

Hopefully this isn't so much a "wild" idea.

> At the same time, as we started implementing, we came to realize that 
> there are a lot of bugs and bad design decision that we could
> change for *FREE*. In fact, in some cases, we would have had to break 
> good code to replicate bad. Of course that is not a good idea. :-)

If by *FREE*, you mean that you could implement it right straight away 
- then I can agree with that. However, to allow switching the look back 
to R5, all the code currently written is needed anyway. I'm sure some 
of the "better" implementations take more code than doing the same "bad 
design decision" as R5 - so I see adding a new look as a change, that 
is not necessarily *FREE*, but not necessarily more expensive than some 
of the other changes.

I have also seen, through looking at the CVS changes, *complete* 
rewrites of certain parts of code, to have a better implementation. 
This proposal wouldn't even be as major as that, but would just be an 
addition to the existing code. There are also exapmles of where this 
has happened in OBOS (an R5 compatibile implemetation done, then extra 
features added). For those who are going to ask for an example, multi-
page support of the TIFF translator is one that I can remember.

> I would refer people to the AROS project. They had the same issue 
> that we have:
> http://www.aros.org/documentation/users/faq.php#why-are-you-only-
> aiming-for-compatability-with-3-1

As I've said many times before I agree with all that and 100% agree 
with R1 being binary compatilble with no new APIs or major new 
features. However, I put this in the category of "enhancing an existing 
aspect of R5", which is what R1 is all about for me.

> I know you don't like the answer. Trust me - there is no good answer 
> here. If someone came forward with some stunning design and all of the
> code already implemented for it, we might be having a different 
> decision. But the (sorry) vague notion that the UI needs 
"modernization" is a
> far cry from that. 

I'll show you the code when I've written it.

I don't think the notion itself is vague. I think R1 definately needs a 
new look to set it apart as a different project, to show people that it 
is different from R5, and to attract more users and developers to the 
platform.

What is vague is what should be changed and what it should be changed 
to - but this is no more vague for R1 than it will be for R2. It's not 
as though somebody is going to post on GE "I've worked it out! The 
perfect UI for R2 - we need curved tabs with a radius of 4 pixels, with 
a gradient going from rgb(234, 243, 100) at the top left corner to 
rgb(213,200, 92) at a point 4 pixels in from the bottom left..." - and 
then everyone will reply saying "Fantastic, that's perfect"!
 
> >To be honest.
> >IF there was to be a GUI change I'd say there's more to do than just 
> >change the way it looks (with nifty shadows, smoother widgets et.c) 
> > but 
> >also change a few things in the way it works.
> 
> 100% agreed. This is why we decided to put off big changes until we 
> all had the experience of writting the OS. None of the team, AFAIK, has
> ever written an OS before. I think that it is very safe to say that 
> we will end up knowing a whole lot more than when we started. And I am
> quite sure that some of the things that we thought were good ideas 
> when we started won't seem so good when we are done. That is part of
> the learning curve (Be, Inc certainly had that sort of an issue). 

I don't see this as a big change, I see it as a small change that will 
make a big difference to the reaction to R1. Personally, I don't see 
what needs changing in the way it works - but that it is a separate 
discussion (and one for GE - again changing functionality == R2, 
changing implementation of same functionality == R1). Where is the 
official law that says before you can change the way something looks, 
you have to change the way it works?

There is a learning curve - but the release of R1 of OBOS is many times 
more important (to the project's future) than the first release of BeOS 
was. OBOS is the flagship project for the recreation of BeOS - that is 
largely through your choice - the very professional website, the 
regular status updates, the newsletters, the open code repositry, the 
mentions in the press or on internet radio. Without OBOS, I'm sure the 
BeOS community today would be much smaller. However, that means the 
release of R1 is a VERY important milestone.

I'm sure all the people on this list would use it whatever (die-hard 
users). It's the other people I'm worried about. At the moment there 
are a lot of casually-interested, wait-and-see type people. R1 will be 
the crucial point that will turn them into users/developers, keep them 
as casually-interested, wait-for-R2 people, or make them completely 
lose interest in the project. You haven't got the luxury that Be Inc 
had, of nobody knowing who they were or what they were about when they 
released their first OS. I bet Be never got 2.7 million hits before 
they released their first OS. 

<snip>
> >Anyway... as a lover of nice GUI s, both UF and sleek, I have to say 
> > I'd 
> >rather be able to use OBOS faster than be waiting for a 
> > sleekification.
> 
> Me too. :-) But, believe me, the best is yet to come! :-)

And so would I! But I'd rather wait 2 weeks to have OBOS R1 received 
well by the world, than release 2 weeks earlier and have it dismissed 
by many on first impression alone. And anyway, this is a slighty unfair 
argument, as I am going to write the code no matter what for personal 
interest. It isn't a question of release earlier vs release with new 
look - or that certainly shouldn't be the main counter argument IMHO.
 
> >To the devs: I LOVE you people! :D
> Me too!
Me three!

Simon

Other related posts: