[openbeos] Re: Visual design stuff again

  • From: "Simon Taylor" <simontaylor1@xxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Tue, 30 Sep 2003 13:32:02 +0100 BST

> "Simon Taylor" <simontaylor1@xxxxxxxxxxxx> wrote:
> > > Yes, and that's why OpenBeOS R1 won't 100% R5 - but it'll stay 
> > > pretty 
> > > close to it, it only augments certain areas where we couldn't 
> > > resist 
> > > (shame on us developers who are doing all this for the fun of it 
> > > :).
> > There are certain areas where little tidbits have been added (TIFF 
> > Translator)
> > But there are also more major changes (Networking being the main 
> > one)
> 
> That's not a good example; it's a binary compatible solution that 
> creates a much more usable networking environment (note, the 
> implementation *is* different from R5 everywhere as we are producing 
> all of the code of our own, the API is the important part). But since 
> this decision came before anything was started, there is no 
> duplication 
> of effort.

That is in essence my argument too though - in code, the implementation 
is different everywhere, whereas visually the "API" and 
"implementation" are == R5. The "API" in a visual context is the type 
of controls, what they do (ie with have something called a BButton, 
it's goal is to invoke an action when clicked, it's API is as defined 
in the BeBook) and the implementation visually is how the control looks  
R1 should be free to change that. 

> > However, you really are heading for something far beyond R5. 
> > Because 
> > you have a whole raft of great new features planned for future 
> > releases, there is a tendancy to assume that the improvements to R1 
> > are 
> > just minor - but they are not at all.
> > ...
> > What OBOS R1 will have over and above Zeta: newer kernel, 1 Gig bug 
> > fixed, mmap(), Select(), better POSIX support, nicer font 
> > rendering, 
> > etc, and of course the big one - it will be *open source and 
> > completely 
> > free*.
> 
> Zeta has select(), too (and also better POSIX support than R5 - just 
> like Dano).

I stand corrected.

But in picking up on small things, don't miss the essence of the 
argument - that R1 includes enough new stuff to be seen by most as a 
major new release. If Be had the list of improvements that R1 will 
have, I'm sure they would have released it as R6 and not as R5.0.5.

> > > Yes, and we've stated several times that R5 is our target - so 
> > > that's 
> > > what people are expecting from us anyway :-)
> > But that's not what they are going to get - they are going to get 
> > more. 
> > Why not tell them that? How many people have lost interest because 
> > "it's not out yet, and even then the first release is going to be *
> > identical* to R5, I can't be bothered to wait another 10 years 
> > until 
> > there's a release that actually works on my hardware".
> 
> Why is that a problem? We won't force people to use what we did :)
> When R1 is ready, we will certainly emphasize the differences between 
> BeOS and OpenBeOS.

I'm not saying we should force people to use it. But if a few hundred 
lines of code encourages more downloads, then I think it is worth it.

If you want to emphasise the differences between BeOS and OpenBeOS (as 
I *really* think you should), altering the look is definately the 
easiest way. A picture is worth a thousand words, as the old adage 
goes.

> I think you're missing one good point: a new look could also have a 
> negative impact on  those who want to have BeOS back: "now what's 
> this, 
> is it just another OS?". I think that it is important to look and 
> feel 
> like (or at least very similar to what) BeOS did. Just better.

I agree 100%.

That's why Stubear's design still uses yellow tabs, still has tracker 
and deskbar, etc.

Also, keeping the current code (no duplication of effort) and allowing 
users to switch back to the R5 look should solve the negative impact. 
As long as we show both looks in the screenshot section of the website 
, that will not put people off downloading if all they want is a 
replica of R5.
 
> Bye,
>    Axel.


Simon

Other related posts: