Re: [Usability]Galeon feature implementation

[Dave Bordoley <bordoley msu edu>]

On Sun, 2002-11-03 at 12:45, Philip Langdale wrote:
> Hi all,
> 
>. 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:
> 

Just to start off i don't think a plugin solution is necessarily bad for
adding "developer" functionality. This kind of solution allows you to
give users such as web developers, the tools needed for design, while
avoiding interface cruft in the general ui most users (who are not
developers) will interact with. Gedit has a nice plugin solution as well
I might add.

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

BAD. Is galeon all of a sudden the session manager too? Sessions are per
login to a gnome session, not per instance of galeon in memory. When a
user logs in their session begin and when they log out it ends. Sessions
are not per app.

Why force users to understand that all web browser windows are running
under one process and that when they close all web browser windows that
they have taken galeon out of memory. I would hope to see galeon avoid
netscape's big mistake of having a "quit" menu item as well (even filed
a bug). (good link on this
http://mpt.phrasewise.com/stories/storyReader$374)

A better solution to this problem specifically is to include a feature
that allows users to bookmark sets of tabs. It's easier for users to
comprehend and better ui overall.

What would be really cool is a vfolderish type view of bookmarks, so
that users can view their bookmarks folder in nautilus and choose which
bookmark "sets" they want to open in their web browser.

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

1. A tools menu for this stuff would probably be acceptable

2. This is exactly what plugins would be good for. All the functionality
you have  mentioned here is only useful to a small minority of users
(mostly web developers). Everyday users don't use this stuff.

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

This is prime example of a developer tool that would be best served as a
plugin as well. Most users do not need this functionality and this will
amount to interface cruft for them.

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

Whats the benefit? What does this fix? Why add the ui complexity? If
there was an actual official gnome downloader, i would expect galeon to
automatically use it, but there isn't. If the problem is that the galeon
downloader sucks (i'm not saying it does), fix it. I see absolutely no
reason for this preference.

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

The hig state that the first entry in a context menu ought to be the
default action for the object (same as double-clicking the object). In
galeon, this is open in new window. Based on this, I think that when you
click on a link it should automatically open and not pop up a dialog
(users hate dialogs) For bonus points use bonobo to your advantage and
view files inline. If a file can't be opened by a gnome default handler
than popping up a dialog asking the user if they want to try to open it
with another vfs app or alternatively save it would be appropriate.

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

This is what right click "save" is for. The first entry in the menu is
the same as the default action, hence it should always try to open it. 


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

Well since you have a decent toolbar editor i guess offering it as an
option would be ok, but it would be a really bad default. I'm not even
convinced that adding it as an option is a good thing, in my mind I
don't really consider a "new button" a tool

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

uggghhh, added complexity marginal if not negative net gain.

> 
> Behaviours:
> 
> a) Toolbar behaviour. Right click context menus for toolbar buttons as
> with galeon1. History for back/forward/up as context menus and nice

There is nothing inherently wrong with having right click context menus
for back and forward (I believe both moz and windows have these), the
main issue in the past was a messy implementation with bonobo i believe.
The pull down menus are definately better though and are easier to use.

> things like the reload context menu offering reload all/bypass cache.

It should just work. 

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

What possible preferences would you really need for mouse scrolling?
Anything useful should be a global default anyway. 

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

Its been consistently shown that an abundance of preferences makes them
useless.

dave