Re: Galeon 2 usability

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.

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.

> 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.
> 
> 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.
> 
> 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.

> 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.

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

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
- configure options
- command line switches
- different binaries but with a large part of the code shared

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.

Marco

P.S. When replying to this mail it's probably worth to remove
usability/Havoc cc. It's getting galeon stuff that they may not be
interested to :)