what is the difference between openMoko and windows mobile based phones

[Jacob Peterson]

Hank,

 I want to thank you for stimulating such a great discussion.

 I think I have an understanding of where your trying to go with this and I
understand that having such a free and democratic process of creating an UI
for a mobile platform would be very difficult.  However, looking at other
open source projects that I perceive as having decent UI's, from what I can
tell it seems their success usually stems from the fact the project leaders
are talented graphical designers along with programmers who can decide on a
common graphical interface and build following that.  The enlightenment
project <http://enlightenment.org> seems to be a great example of this along
with the more recent versions of gnome <http://www.gnome.org/start/2.16/>.
Dare I suggest contacting people who are skilled at graphical design, and
would be willing to donate time, to help led the development of the UI?
They could be our "elected officials" to help moderate down all the
different ideas and requests to make them fit into a common vision and
hopefully a great UI.

--Jacob

On 1/18/07, hank williams < hank777 at gmail.com> wrote:
>
> I should clarify and say the issue that I am refering to specifically
> relates to UI/design. There are very few people that are good at it, so when
> those "good" people are not in absolute control and overly influnenced by
> committees, the design suffers. The good news about most open source
> products that have been successful is that they are more often API driven.
> Linux, the apache stuff, languages, etc, etc. Honestly, I havent yet seen an
> open source product whose UI I really like except firefox which is darned
> near commercial in the way that it is run.
>
> Graphics programs, Interface shells, video programs... I am not going to
> name names because then someone will either get upset or start
> misinterpreting. But I have yet to see something that I thought lived up to
> the best proprietary interface/UI designs. I cant say I have seen
> everything, but I have seen a lot. I think Open Source kills when it comes
> to creating high quality maintainable code. But I personally dont think the
> community process works as well for design and UI. I know people will
> disagree, and I really dont want to get into a back and forth with people
> getting upset and trying to prove me wrong. Its just my opinion. And of
> course there are always exceptions.
>
> Oh and by the way, I am not saying OpenMoko will have this problem. It
> specifically relates to the community process of development. But satisfying
> everyone's requests/demands in a UI is a sure sign of trouble and is much
> more prevalent in a more democratic process. Depending on how they manage
> the process and the form of the leadership it may not be an issue at all.
> They just have to be good designers themselves, and be willing to say "no"
> when warranted.
>
> Regards,
> Hank
>
> p.s. These are just my opinions. I have said it before, but many people
> have different perspectives on what it takes to make great products. I am
> not sure why anyone would care about my views on this subject.
>
> On 1/18/07, Richard Franks < spontificus at gmail.com> wrote:
> >
> > On 1/18/07, hank williams <hank777 at gmail.com> wrote:
> > > I believe too many cooks spoil the stew, which is often a
> > > problem in open source, in my opinion. Its also often also a problem
> > inside
> > > corporate development efforts. When there is no clear and absolute
> > > leadership, product design suffers. This is of course my opinion,
> > based on
> > > my 30 years of software development. It is, nevertheless an opinion.
> > Your
> > > mileage may vary.
> >
> > I see this being true for monolithic projects such as a kernel, or an
> > office productivity suite.. I would say that it's debatable whether
> > the same holds true for the types of micro-application which are going
> > to be created using the OpenMoko API (which as a foundation does
> > appear to have clear leadership).
> >
> > Monolithic product design I believe arose from distribution and OS
> > layer limitations - when you simply couldn't download weekly updates
> > or patches, the product had to get it right the first time. It didn't
> > always happen that way of course, but there was no real alternative as
> > the network infrastructure hadn't been built up yet.
> >
> > Communication accelerates standardisation, and standardisation paves
> > the way for smaller tighter applications. Given the diversity of
> > interests shown on this list, I don't think we'll run into the
> > too-many-cooks issue any time soon.
> >
> > Out of interest, which Open Source projects have fallen victim to the
> > too-many-cooks problem?
> >
> > Richard
> >
> > _______________________________________________
> > OpenMoko community mailing list
> > community at lists.openmoko.org
> > https://lists.openmoko.org/mailman/listinfo/community
> >
>
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/community
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20070119/dcf8b5db/attachment.htm