Re: [Usability]Galeon 2 usability

[Ricardo Fernández Pascual <ric users sourceforge net>]

El lun, 14-10-2002 a las 00:25, Marco Pesenti Gritti escribió:
> Hi,
> 
> Thanks a lot for this mail Havoc. It helped to clear up many things
> in my mind :)
> 
> Guys I think it's time to get a good decision about the future of the
> project. It's a lot of time that everytime we have to get a key decision
> about UI design we end up in flames without getting anything
> constructive out. Let's decide a direction and keep up with it, even if
> this is going to cause a fork.

We have already few developers. As discussed in IRC, forking is mad.

> 
> Il dom, 2002-10-13 alle 21:57, Havoc Pennington ha scritto:
> > 
> > Hi,
> > 
> > There's just a global decision here, IMO. You have to decide what
> > you're really interested in and stick to it. It's totally cool to make
> > a good alternative browser for technical users. It's also totally cool
> > to make a simple, slick, HIG-compliant browser.  Doing both is going
> > to be pretty hard, and you risk design-by-committee mediocrity.
> 
> This is what I tried to say during all the flamewar. We need to make a
> call, otherwise we will just end up with a bloat browser that will make
> no one happy (while the target was exactly the opposite, make happy all
> of them).
> 
> You already know what my personal decision is: I want to hack a simple,
> HIG compliant browser.

You know that I want to hack on something that I can use and like (as
Havoc says: this is the only sensible thing, otherwise I won't have any
motivation). 

I don't thing that both things are totally incompatible. So far we have
been able to agree after some flamage.

> 
> > If you go the "we want a good UI for 98% of typical, nontechnical
> > users" route, like metacity or Phoenix, then you have to hide most of
> > the silly stuff and technical terms by default.
> > 

this is offtopic, but metacity is still unusable for me. I have tried to
switch two times, but I can't. The damm thing wants to force me a
different way to work with windows. I used previously fvwm2 and sawfish
and both allowed me to work in my way. I guess I'm doomed to use sawfish
until it is totally unmantained and write my own wm afterwards.

Metacity/libwnck source code is great anyway, I hope to be able to use
it for writing my own in the future ;)

> > You can try "user levels" (maybe just two: "sane browser" and
> > "complicated browser"), but it's a lot of extra work, and if the
> > master-user-level toggle button is in the visible UI, kind of
> > confusing.
> > 
> > A better approach might be some kind of generic extension system. I
> > think that's what Phoenix is doing, and that's how Emacs stays
> > sort-of-sane. So people could load their own module that adds a
> > Settings menu or whatever.
> 
We don't want to rewrite mozilla, yet.

> > The danger there is that you spend all your time overengineering the
> > extension system, or in "complicated mode," and no time implementing
> > the good browser.
> > 
> > If you're focusing on a general-purpose browser, my opinion as you
> > know is that the best thing is to design primarily for the 98% case,
> > and then add the most useful/important technical/complicated features,
> > keeping them relatively unobtrusive.
> > For example, "geek features" in metacity include sloppy focus,
> > autoraise, lower-window-on-middle-click, Alt+click, rearranging button
> > layout, configurable keybindings. The list of such features that
> > _aren't_ included is much much longer, but many people are covered by
> > what's there. Metacity is also partly extensible, e.g. Ross Burton has
> > implemented matched windows and position remembering and
> > keep-panel-on-bottom all in an external add-on. Anyway, the idea is to
> > avoid including the complicated features that have high maintenance/UI
> > cost or that have only minor benefits.
> 
> Yeah I think it make sense to keep a small number of thecnical features
> as long as they are unobtrusive. Metacity have a very good approach 
> to the problem IHMO.

It's not about features. We all agree (more or less) about what features
we want. It's about how to arrange those features in the UI and what
fetures we want to be easily accesible.

> 
> > gnome-terminal is much more of a compromise; it's loaded up with geeky
> > features and not so good for general users. The idea being that
> > terminal users are relatively into computers. But I'm not that happy
> > with gnome-terminal, it's too complex for general users, and not as
> > featureful as multi-gnome-terminal and other alternatives for users
> > who love complexity.
> > 
> > Anyway, it's a hard choice. You just have to decide up front what your
> > goals are, and then stick to them. If people don't like your goals,
> > they can write their own browser, even using your code to do it. Or
> > use another browser. Let them. You are not obligated to make everyone
> > happy, because making everyone happy isn't even possible.
> > 
> > Have a vision - design by committee is no good.
> > 
> > Personally I would do what you want to use yourself. If you want to
> > use the highly configurable geeky browser, then write that. Trying to
> > write something else will just strip all your motivation.
> 

Fully agree.


> Here we come at the real problems. While I dont use any geeky feature
> galeon 1 had, Ricardo, Philip and Yaneti have strong feelings about
> keeping them mainly because they use them.
> So I dont see much hope to be able to agree on a common direction :(
> We MUST deal with it though and now. We are not in a hurry, but we cant
> delay this anymore.
> 
> My plan is to write, in the next few days, a short document about the
> lines galeon user interface development should follow (I'm not going to
> rewrite the HIG dont worry ;))
> 
> The main points are going to be:
> - HIG compliance
> - Simple design
> - Strong GNOME integration
> - Geeky, thecnical feature keep at minimum and anyway never obtrusive

You definition of obtrusive is not the same as mine and mine is
different of some other person. If we agreed on that we won't have these
problems ;)


> I'll try to be more concrete is possible :)
> 
> If the whole team agree with it well than we dont have a problem. (Not
> that I think this is going to happen but ...).
> Otherwise it might be better two have two different browser interfaces,
> sharing code in some way.
> This SUCKS but it's possible. A lot of code would be kept common and
> this is good for the project.
> 
> I see several possible approaches:
> 
> - plugins
No please.

> - configure options
Will be a deployment nightmare. Two rpms, two bininaries... 
I want to avoid this.

> - command line switches
This is my preferred option, and I think that philipl agrees too.

> - different binaries but with a large part of the code shared
Same as configure options.

> 
> I dont think we should introduce user levels because they add confusion
> to the user interface.
> Apart that I dont have strong preferences. But we need to think very
> well to it. 
> Let's handle the first part of the thing before: propose the lines of
> the "simple browser". I'm obviously open to feedback if someone on the
> list is interested to such a project.


-- 
Ricardo Fernández Pascual
ric users sourceforge net
Murcia. España.