Re: A call to action

[colin z robertson <c z robertson ndirect co uk>]

On Sun, Oct 15, 2000 at 07:09:38PM -0700, Gerry Chu wrote:
> > I think we'd do better to tell people what we think and wait for them to
> see the
> > correctness of it. Then we let natural selection take care of those
> > who ignore us.
> 
> Look at ms windows.  _Horrible_ design compared to Apple. It sells well
> though.

True, but consider, MS has never given any guidance to Windows
developers about how the UI should be done. I think that if (when) we
create a guidelines document we'll be in a much stronger position than
MS in terms of UI. I believe that with a set of possible solutions,
the UI will be a strong factor governing how people choose. Windows,
on the other hand, has been dominated by MS Office (which doesn't even
follow MS's own UI conventions).

Perhaps I'm just an optimist.


> > I really don't think that without doing the coding ourselves we can
> > have anything more than an advisory role. Anything else really goes
> > against the grain of open-source development. Right now we're not
> > having much effect because we aren't doing much communicating. I'd
> > suggest trying harder on the communications front and then seeing if
> > that gets us anywhere.
> 
> Yes, it is an uphill battle.  That's why the process for implementing GNOME
> ui design should be written down and agreed to by all.

But that's not the way open-source works. If they did agree to it then
we wouldn't need them to agree to it, if they don't agree to it then
they don't agree to it. Essentially, developers do what they want.


>  That's also one of
> the reasons why I bought a C programming book yesterday, just to hedge my
> bets.  As for communications, you mean advertising what our list does,
> inviting more hackers to join the list, and seeing if any of our designs
> turn up in the next release of GNOME?  It might work.  But I'd rather make
> sure what we design actually get into the finished project, to save us from
> doing unneeded work.  Please say more about your idea, though, as I was just
> going off an assumption.

Ok, I think our first task should be the creation of a set of UI
guidelines much like Mac and KDE have. That's an example of the sort
of communication that we'll need to make. The fact that this wasn't
done a year ago is pretty depressing.

As Christopher Beland has pointed out in another post, there are
several classes of UI problems that such a document would not address.
Where these relate to an individual project one of the first things we
should do is approach the developers in as friendly a manner as
possible and suggest that they get involved in a discussion with us
about their UI. (If there's any part of our task that may require the
sorts of committees you're suggesting it'll be this, but I'm not even
convinced that committees would be neccessary here. I'd suggest trying
without committees first and seeing where it gets us.)


> > > Finally, when the component is redesigned, it would be
> > > put up on the www or shown to the greater mailing list itself
> > for comment.
> >
> > But what would be the point of that? Surely the list should be where
> > the discussion starts. There's no point discussing something at the
> > end of the design period.
> 
> Well, I might be wrong, but since we're losing and gaining new people on
> this mailing list often, the committee people would agree to a time
> committment.  The list-only people wouldn't have to.  I mean, look at the
> list archives from a year ago, and see how many people you recognize that
> still post once in a while.  It's hard to get a team up to design the ui if
> people are constantly coming in and dropping out.
> 
> But by no means do I envison this committee as some "elite" thing.  As I
> said before, the only reason I came up with this committee was high turnover
> rate on the list.  But if everyone on this list now can make such a time and
> participation committment, forget about the committee idea, and we'll just
> have all discussions on this list.

Time commitments are incredibly difficult to make, for UI people and
coders, but the coders seem to manage without making explicit
commitments. Requiring a commitment might drive away people who could
do good work but are too cautious to promise it, and of course it
would do nothing to deter people who over-estimate their time and
enthusiasm.

Also, it would be easier to keep people on this list if they felt that
what they were doing was worthwhile, and I think that will come when
people take more notice of us, and I think that will come when we
communicate our ideas better.


> Oh, and the other reason I orginally seperated committee from list is
> committee would focus at one component at a time, and list would discuss
> whatever, whenever, though I think all committee people should subscribe to
> the list also.

I think that focus could be achieved if people came to this list with
a specific set of objectives. Sure, there would be other discussions
going on at the same time and it would take a little effort on the
part of those with such objectives to prevent themselves getting
side-tracked into irrelevant issues, but that's not really a huge
problem.

colin

  _____________________________                            ____
  rtnl  http://rational.cjb.net     c z robertson ndirect co uk
  ak    http://kitching.cjb.net                    icq 13294163