Re: [Usability]Galeon feature implementation

[Jeff Waugh <jdub perkypants org>]

<quote who="Philip Langdale"/>

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

Hey Philip,

Thanks for sending this! Apologies for not replying sooner, but the 2.1.2
release (which I'm doing a final test run with now) was a big priority over
the last four or so days. :-)

Lots of good stuff in your email, I'll jump in straight away...

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

Small tangent: Other people have brought up their issues with a global
"Quit" menu item in web browsers. I also found the item utterly confusing
and detrimental to my browsing experience in NS4, so I'd agree with this.
Each Galeon window is a 'first class citizen' of its own, essentially, and I
can't recall ever having a reason to close the entire browsing application.

So that makes this particular (incredibly useful) feature somewhat harder to
place.

I've been thinking about bookmarks a lot recently (in fact I have a really
good idea for you guys that I should email soon), and mentioned a possible
relationship between bookmarks and sessions on galeon-devel a while back.
Yanko has described this discussion as "beating a dead horse", which is kind
of unfortunate - I like taking out my aggressions on expired equines. :-)

So, the idea: Galeon already has cool Smart Bookmarks (now "AutoBookmarks").
It's dynamic, clever, and will floss your teeth if you ask it nicely. So,
what if Galeon also handled your sessions for you, automagically? Go to
"Bookmarks > AutoBookmarks > Yesterday, 7pm" or "Bookmarks > AutoBookmarks >
Thursday, October 31st, 2pm".

You wouldn't need to save them, because GALEON REMEMBERS! :) You could open
them from the menu in a jiffy. This requires some more thought as to the
design, please don't object to random implementation issues I've brought up
here.

(Yanko also notes that extra session information cannot be saved with
bookmarks. Given that you're using XBEL, I say "Bollocks to that!" Throw in
an extra namespace for Galeon session information, and you're done.)

> 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 haven't used these before, mostly because my browsing is restricted to
sane websites. :-) They are *very* useful on a Free Software hostile web
though, so worth putting in. I'd advocate the return of the Tools menu for
specialised dynamic settings such as these.

> 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 don't understand Marco's reluctance to add developer oriented features in
a sensible fashion. It's not as if we can't design a usable way to provide
them... So, these could very well live in a "Developer" submenu in the Tools
menu, as well as being available as off-by-default toolbar buttons.

(I think that a lot of the "easy to get to" objections to deeper placement
of advanced features can be resolved with off-by-default toolbar buttons for
the users who like these features. Hey, you could even add an off-by-default
toolbar dedicated to web developer tools! Not worrisome for casual users,
easy to find for webhackers.)

> 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 really don't understand the objections to this, as it is a GREAT usability
and maintenance improvement. You guys want to write a web browser, so crazy
download manager features aren't really of interest. To me, it seems quite
obvious that this functionality could be split into a separate module, and
invoked if installed. That way, you guys don't have to worry about having it
around to maintain, and users won't see it unless they specifically install
it.

So, I think the preference can be simplified down to "Use advanced download
manager" boolean. If it's not installed, this is greyed out. If it's
installed, this can be turned on. (I'd advocate not bothering with the pref
at all, but multiuser systems will have users with different needs present.)

Go for this one, it's an excellent solution for usability and maintenance.

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

So, there's this cool feature in 1.3 (was it in 1.2?) in the context menu
for images. "Open Image with... > [The Gimp / Eye of GNOME]". That's *way*
cool. I guess I'm assuming that the features you describe above would work
somehow like that?

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

Could you explain some use cases of this, especially for different mime
types? I don't think I understand why you'd want it yet. :-)

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

What would it do? New tab / window drop down? If it's that, I see it as
unneccessary baggage on the toolbar which may harm the familiarity users
have with the back/next/stop/reload/home 'standard' format. Advanced users
will probably still use Ctrl-T anyway. Am I answering the right thing here?
:-)

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

Yeah. Definitely a preference if you do decide to keep it.

> Behaviours:
> 
> a) Toolbar behaviour. Right click context menus for toolbar buttons as
> with galeon1.

So, they'd pop up the same thing as the buttony menu, but on right click? I
can't see too much wrong with that, apart from losing the toolbar context
menu on those entries.

> History for back/forward/up as context menus and nice things like the
> reload context menu offering reload all/bypass cache.

What was the menu layout for these?

> thanks to the bonoboui folks moving to make this possible, I think we
> can make it happen.

Yeah, cool work from Michael on that front.

> b) Generally unconfigurable behaviour. I'm still unconvinced about
> disposing of prefs

Try looking at it the same way that you look at the external downloader
support. That's a great example of user/maintenance cost, and an effective
way to deal with (and come to a compromise on) both.

I timed myself setting up GNOME 1.4 and GNOME 2.0 the way I liked them from
scratch the other day: It took me an hour and a half for 1.4, and 4 minutes
for GNOME 2.0. I shit you not.

A lot of that time was saved by removing the umming and aahing factor, and I
consider myself an advanced user, with an unfair depth of knowledge about
GNOME. It's like royally fucking up and making a loss when you've got
insider information. ;-)

Anyway, my favourite points about getting the preferences problem right:

  - Stuff should Just Work

    There will come a day when I will start to lose hair. Luckily for me, I
    know that it will not start from the top and go in, because of my Dad's
    receeding hairly baldness pattern... and he still has a *lot* of hair.
    Until that time, I'd like to lose as little hair as possible, and my way
    of ensuring that is to do stuff the right way, once, and try not to deal
    with it again. I like my software to work the same way. :-)

  - A good default behaviour is worth a thousand preferences

    My new favourite window manager has about 2% of the preferences my
    previous favourite window manager had. Some people see this as a
    fundamental attack on freedom of choice that should be referred to the
    United Nations Committee for Narcotics Freedom. I don't. I see it as an
    abject waste of time lifted from my hands.
    
    I was not a normal Sawfish user either, I puffed on the crackpipe like
    an oxygen mask too. My fave was being able to make GIMP click-to-focus,
    whilst leaving everything else on sloppy focus. Sawfish configuration
    was a pretty large chunk of the 1 1/2 hours I spent on GNOME 1.4 config,
    too. CraaAaazy.
    
    Lots of people object to metacity though, because it does not really
    target them as users, so I'll use another example. The tasklist in 1.4,
    now called the Window List, used to have lots of preferences related to
    its size. How wide it was, whether it expanded to take up two rows, etc.
    When it was ported to 2.0, lots of that crap was taken out, and people
    ranted and raved about it. Trouble was, the default behaviour wasn't
    fixed at that stage... Once the Window List was fixed up to operate
    correctly by default, the ranting stopped. It Just Worked. Now it has,
    by my count, five user-visible preferences.

  - Large preferences boxes are like tone-dial phone menus

    So, I was consulting for a call centre company a little while ago. They
    were trialling a tone-dial menu system so that they could lay off half
    their staff (meanwhile, I was helping them implement Linux systems so
    they could lay off half their IT staff... ahem). They decided to put the
    "you may be recorded so we can fire rude call centre staff" message at
    the very front of the call, after the welcome, so they could record what
    people were saying during their interaction with the menu system.

    I was lucky enough to hear a series of clips they were planning to
    present to the state manager, most of which included the F word, some of
    which were surprisingly offensive, even to the ears of someone who has
    worked with the military on occasion.

    User-test subjects are generally well aware of their audience, so they
    won't hit the computer or swear profusely. (Unless they're the
    entertaining kind of tester who breaks down into a nervous wreck and
    starts blaming their parents or God for their utter failure to
    understand computers, and tells you to fuck off and stop being so
    supercilious and cruel when you attempt to explain that it's not their
    fault.) Which I think is a pity, because some software becomes usable
    only by changing preferences, and when you're faced with a situation as
    frustrating as tone-dial menu systems, you start getting shirty.

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

(I think mouse wheel issues need to be solved at the GNOME level. It's not
right that you guys should have to handle it separately in Galeon.)

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

I'm really glad you sent this email though, because I think we can work out
some pretty cool solutions to make Galeon appeal to you, and be appropriate
for GNOME. That's my hope, anyway, and I'd love to help.

Thanks,

- Jeff

-- 
                    The Unix Way: Everything is a file.                     
                 The Linux Way: Everything is a filesystem.