[openbeos] Re: Visual design stuff again

[...]

> I am still not convinced that it is worth doing. 

lol - one final attempt then:

> Just so we are not too "clubby", I will say this:
> I 100% agree with Erik - if you want to contribute code, *PLEASE* do 
> something for R1. Please. We need people doing the work that we
> can all agree on.

This is for R1 ;-)

If I had any idea how my free time would pan out over the next few 
months, I would love to make more of a commitment. And oh yeh, if my c+
+ didn't suck too, that might help.

> Issues like these are *EXACTLY* why, at the beginning, I said "Let's 
> do R5 first and talk about anything else later". Because you
> have oh, about 100 messages, about what I would call the most trivial 
> of issues (code wise). Imagine if we had opened the door to *ANY*
> feature for R1? What sort of a mess would we have?

I absolutely agree, binary compatibility was always a very sensible 
decision in my view.

I do see there is a certain inconsistency though, in that all the teams 
knocking out "internal" code are happy to take the API and then 
implement it as they see fit, with whatever improvements they think 
work in that framework - whereas the UI "implementation" is pretty much 
pixel-for-pixel identical to R5. Changes in implementation go from the 
simple "I've added flag y to our function x to be more POSIX 
compatible", to "We're putting all the networking in the kernel" - 
these type of changes are almost always welcomed. Yet if someone came 
along tomorrow and said "I've made all the widgets look more modern, 
and the OS as a whole much more appealing to a wider audience", I think 
they would face a lot of resistance getting the code accepted. Am I the 
only one who sees this as an inconsistency?  
 
> I have written privately to Simon, warning him that *ANY* such code 
> would be heavily reviewed before being accepted, if it were to be
> accepted at all. But I would like to point out to everyone - look 
> what adding a feature like this costs... My time and someone else's 
(DW's or
> Erik's) to review the code. Discussion between the reviewers and the 
> submitter. 100 posts on this list. Compare all of that to the non-work
> generated by "Here is a class that works exactly like R5's and here 
> are my test cases. Please check them in."

Although often it's "Here is a class that works better than R5, and my 
test cases. Please check them in."

With UI's it is made more difficult as "better" and "worse" are all 
matter of taste - however I would say having an undoubtedly more modern 
design coupled with the possibility of switching back to the old look 
is a better implementation of a UI than the R5 one.
 
> Simon has some very good points about the marketing side of this. Our 
> decision to call it "R1" is not set in concrete. R1 was/is a good
> working name. Some people have suggested "Release Walter" as an 
> alternative. Hmmm.  I am not personally inclined to change the look and
> feel for R1/Walter/Whatever. I think (as Simon and I have discussed) 
> that getting a ton of new users is *NOT* a goal for R1. 
> 
> Look - our community has dwindled, somewhat. I don't think that will 
> shock anyone. Furthermore, many of the very knowledgable people have
> left. If we released R1 tomorrow and we had 10,000 new users all with 
> questions, we couldn't handle it. We need to rebuild a little more
> gradually than that. 

There needs to be a way of shielding the team doing the development 
from all the newbie questions. I think it's better that people download 
and try R1 and ask questions that maybe don't get answers, than not 
downloading it at all.

Any release will build up users gradually, to a certain extent. It's 
not going to be the case that on release day, everyone who is ever 
going to use R1 downloads it and bombards you with questions. We do 
need a better way of dealing with the support issue though.

I seriously think a lot more people could use R1, and like it, than you 
realise. A lot of people are still discovering R5, and by and large 
(assuming they have supported hardware) they seem to like it. I don't 
think you should be scared of attracting people to try it out.

Before I have tried the (flawed) argument that you shouldn't be trying 
to discourage users from trying R1. To which you obviously reply that 
you are not discouraging them, merely not encouraging them - an 
important distinction. However, lets turn this sentence round a bit, 
and it still seems a questionable reason: "We're not going to implement 
that, because it might encourage people to try the release!"

Support strikes me as something the users could do. Most newbie 
questions could be answered by any reasonably knowledgeable user - and 
there are lots of people who can't code itching to help out with OBOS. 
If the issue is "we don't want lots of people downloading because we 
can't support them", then let's try to work out the support issue, 
rather than trying to reduce the appeal to reduce the download count.
 
> R1/Walter > R5. Networking, no cruft, new Media Kit, new Kernel, 
> drivers, etc. We should be in good shape to draw in the departed and
> some new, brave people. I believe, and you can certainly tell me that 
> I am wrong, that for R1/Walter, we need few users (other than devs)
> and a lot more devs.

Maybe. There does need to be a healthy balance.

However, even if we only want devs - surely they are users too, and 
therefore attracted by the same things. OK, so users don't care about 
how good the API is, or the scripting support. But as devs are a subset 
of users, I argue that a developer cares about all the same things a 
user cares about (look and feel, responsiveness, even ease-of-use) and 
a few additional factors (API, POSIX support, etc).
 
> Devs understand "work in progress". Screenshots like Stubear's are 
> sufficient, I think, for devs. Devs get excited about working code and
> about momentum. We have both. Not completed code, but working code. 
> And momentum. Come R1/Walter, we will have a whole lot more of
> both. That is what draws devs. That and the chance to do great 
> things. That we can certainly offer.

If they take the time to research deeply into the project, I'm sure 
they will find plenty of stuff to get excited about. The new website 
should certainly provide more information on where you are and where 
you hope to go - Stubear's screenshots aren't even on the internet any 
more AFAIK!

However, devs are also unique individuals (yes, really ;-)) - some may 
be attracted by momentum, but it is solid fact that some will be 
attracted by working on an OS that looks nice. OBOS R1 can still 
provide momentum, working code, and the chance to do great things, but 
it can look great too! I don't see any conflict. And lets face it, 
people even considering downloading an alternative OS are at the very 
least "advanced users", if not devs. You could make it look as gorgeous 
as you want, but my Mum's still not going to download it. Because of 
that, I don't see increasing the appeal as a problem, provided we have 
a plan in place for how the new users/devs will be supported without 
affecting development.
 
> >As you imply, it is by no means certain that OBOS will ever provide 
> >full skinning support. I know from private mails that Michael and 
> > Erik 
> >are both opposed. That is obviosuly a discussion for GE. But if it 
> > is 
> >decided not to implement skinning support, will the widget set 
> > always 
> >look like R5?
> 
> While I did say that (and I will stand by it), there is a little 
> context necessary for public consumption. I am ***PERSONALLY*** opposed 
to
> skinning. I hate it desperately. That doesn't mean that it won't ever 
> happen, necessarily. I am not a Dictator for Life. That will be a 
decision
> made by the group when the time comes.

Yes. That's why I said it was a decision for GE.
 
> And I think that Simon might be a little disingenuous here (with an 
> arguement style that I love and have used myself) by setting up a false
> dichotomy. It is not a choice between skinning and never changing the 
> look. There are other choices, like setting the look in the OS and
> changing it between releases. Look at Windows 3.1-->Win95.

I didn't really intend that ;-)

I know there are other choices. I have spent dozens of hours pushing 
one of them ;-)

I meant that if for R2 the decision was taken that you wanted an 
updated look, but not full skinning support - I guess you would want to 
keep the old R5/R1 look so as not to alienate current users - you could 
well end up with very similar code to what I'm talking about. I knew 
the answer to the question at the end of that paragraph was always 
going to be "no", I just thought I'd leave it hanging to see what 
responses I got. Not a good tactic for trying to bring a thread to a 
close though :-P
 


Simon

Other related posts: