[Usability]Re: [Galeon-devel] Galeon feature implementation

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

Sorry for not replying before, but I am having lot of real work these
days and real life is distracting me. 

Also, I was a bit unmotivated after the last round of discussions. I
need to find some new motivation.

El dom, 03-11-2002 a las 18:45, Philip Langdale escribió:
> Hi all,
> 
> Following up a conversation some of us (unfortunately sans ricardo and 
> yanko) had with jdub yesterday, I have been convinced to throw out my
> list of desired features and behaviours to get usability input on
> implementation. Whether marco's decision to resign as maintainer is a
> permanent one, and we hope it isn't, this is still a valid area for
> discussion.

I wish that Marco reconsiders his decision, but I'm not going to try to
convince him. He knows what's better for him.

> 
> As many of you are well aware, I have not been happy with the direction
> that galeon2 is going in, and I've said so many times in a less than
> constructive manner. jdub has convinced me that I shouldn't assume that
> my goals are completely incompatible with the gnome2 paradigm. We'd
> prefer to avoid any sort of plugin 'solution' and 'dump the feature'
> would probably be unhelpful. So, with that in mind, I offer the
> following for your consideration:
> 
> Features:
> 
> a) "Exit saving session", implemented as a File menu item in galeon 1.
> I can't really see any other place to put this, but perhaps you can.

I don't care about this anymore.

> b) Equivalent functionality to the Settings menu. I am told that an
> actual Settings menu isn't The Right Thing(tm) but as long as the
> items under it end up in the menu structure at the end of the day, I'm
> happy. In case you don't have galeon1 or are disinclined to look at it,
> the settings menu provides quick access to filtering configuration and
> toggles for such things are turning java and javascript on and off and
> forcing the usage of user defined colors and fonts.

I think that the best place for those items is the Settings menu,
because it is the most obvious choice... but I agree with you.

> 
> c) Java and Javascript Consoles. I simply hold a completely opposite
> position to marco on these. I would assume they would live under the
> Tools menu.

I completely agree with you.

> 
> d) External Downloader support. Well, we had this until the very last
> minute when marco commented it out... I'm not sure there's much of a UI
> issue here. It's a matter of some prefs (dirty word, I know) to indicate
> whether an external downloader is being used and what it is.

I don't use the external downloader and our internal downloader works
very well for small files. So, I don't care.

> e) Ability to choose helper app for unhandled files rather than being
> forced to use the gnome-vfs default. I have conceeded the point that we
> shouldn't persist the user's choice of helper app. It was felt that this
> was "creating our own mime database" which I'm not fully convinced of,
> but it's less work eh? Nevertheless, I consider it completely
> unacceptable to offer no choice and force the user to have to make a
> persistent change in the gnome-vfs capplet outside of galeon just to
> use xpdf for a stubborn file instead of ggv. My current view is that
> this should be done by extending the "What do you want to do?" dialog
> to allow the user to choose a helper from gnome-vfs's list. Simply
> clicking on Open without giving the issue any thought would launch the
> default helper as before.

Agreed.

> 
> f) As a related issue, I would however like the ability to persist the
> decision to save to disk, so that files can be saved simply by clicking
> on them without any other interaction. However, such persistence must
> take place on a mimetype by mimetype basis which brings us back to
> accusations of having our own mime db again. Creative ideas here would
> be much appreciated.

I think it would be enough if shift+click (or something else) always
saved to disk without asking anything. 

> g) A New button for the toolbar. I'm not sure whether there was a
> usability argument behind it's absence or whether if was the crippled
> nature of bonoboui toolbars. Now that we're getting traction on this,
> allowing for middle and right click actions on buttons, we can do a
> proper new button, I hope.

No usability issue here as far as I know. Maybe it is not for the
default toolbar, but there should be a new button. Unfortunately, it
required to be a control to be as useful as in galeon 1 (bonoboui).

> h) Gesture support. Not a lot to say here; we need prefs to turn it
> on and off.

I don't care about gestures anymore. I don't know why I ported them in
the first place, because I don't use them. I'm not going to maintain
that code, so unless someone wants to take care of it, it should be
removed.

> Behaviours:
> 
> a) Toolbar behaviour. Right click context menus for toolbar buttons as
> with galeon1. History for back/forward/up as context menus and nice
> things like the reload context menu offering reload all/bypass cache.
> thanks to the bonoboui folks moving to make this possible, I think we
> can make it happen.

Thanks to Michael. I need to look at it, but don't know when.

> 
> b) Generally unconfigurable behaviour. I'm still unconvinced about
> disposing of prefs, especially for highly idiosyncratic things such
> as mouse scrolling behaviour. I don't belive there is such a thing as
> a 'sensible default' in such cases. The best you can hope for is that
> defaults reflect the habits of one developer and everyone else has to
> make do as best they can. I'm not appreciative of programs that demand
> the user conform to it when it could easily provide flexibility; I don't
> want to be the one inflicting such a program.

Nobody has convinced me still why can't we have two prefs dialogs. Gconf
makes it very easy, and an advanced dialog would allow us to make a very
easy to use simple dialog.

I know that the word "Advanced" is tabu these days.


Ricardo




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