Following the recent discussions of Galeon features here and elsewhere
(the SVLUG list), in particularly GNOME and 1.2 =3D> 1.3 issues, some
thoughts on feature requests / additions / modifications, and future
directions for Galeon. This is intended to start discussions. Filing
specific bugs / requests pending on outcomes.
For discussion, it's probably best to pick a particular item, change
subject appropriately, and discuss it.
Severity is rated 1 (low) to 5 (high). They're my own general "this is
how much this annoys me" ratings, take with a grain of salt.
- Put the user first. Ahead of webmaster. Ahead of any one desktop
- Balance complexity and functionality.
- Avoid state-loss events. Don't inadvertantly close browser
sessions, windows, or tabs, where the user can lose data. Confirm
state-loss events if appropriate (e.g.: on user request).
- Provide ability to save user state in useful ways.
- Avoid repeating questions for common, non-state-loss actions.
- Put frequently used controls nearer the user, not buried in UI.
Allow user to "unearth" options (e.g.: detachable menus,
- Enhance user control over privacy (cookies).
- Improve user control over webpage actions / defaults.
- Keep notifications proximate to relevant events. Substitute
notification bar on web page with pop-up dialogs, where appropriate
(e.g.: cookie confirmation, authentication requests, SSL status,
SSL transition, SSL/non-SSL mixed data).
- Don't block on nonessential actions. If a requested action can be
completed and contingent requests deferred, complete the requested
action and defer other requests until later.
1.2 =3D> 1.3 Features
Major missing / changed features appear to be:
- My Portal. Sub-portals. (These have now reappeared, thanks.)
- Menu configurations. Controls. Several items have move:
- Settings =3D> Web | Edit->Preferences. =20
- View->Source =3D> File->Source.
The latter in particular is annoying.
- Detachable menus. Controls. IIUC, this is a Gtk option. It
would be nice to have detachable menus restored in Galeon.
- Toggling off full-screen option. State loss / Controls: F11 is a
reserved keybinding in WindowMaker. There should be a control,
hotkey, escape key, or other option. In 1.2.x, menu hotkeys
worked even when the menubar wasn't visible in fullscreen view.
In 1.3.x, they don't. So: <alt>-V-U (view =3D> fUll screen) would
escape fullscreen mode in 1.2. This should be restored. Only
current option appears to be killing the entire browser session.
- View as dialogs. Controls. 1.2.x allowed the user to specify:
- Ask/don't for save / view option, setting default to one or
- Ask/don't ask for viewer, setting the default to a given
Both features are missing from 1.3.x. Restoring them would be
Enable detachable menus.
Rational: simple method of letting use make currently useful
controls immediately accessible.
Allow specification for close confirmation.
Rationale: it's too easy to close a browser session by
inadvertantly hitting a window's close control, or by miskeying C-q
for C-w. This can result in significant loss of session state,
particularly as browser sessions are not saved by default and
cannot be saved conditionally. My own pref would be to have this
confirmation *on* by default, with a "don't ask me again" option.
- Navigation. Allow scrolling of tabslist *without* changing current
tab focus. Allow context-action (e.g.: right click) on tab
*without* changing current tab focus. =20
Rationale: scrolling a list of objects, and manipulating those
objects, are two separate functions. Tabs are objects. Lists of
tabs are a *representation* of objects. Changing tab focus when
scrolling the tab bar is like changing the currently open document
when scrolling through a list of files in a file manager. Brain
- Tab submenu. Provide tablist on tab context menu.
Rationale: Tog's law: make commonly-used actions/features easy to
reach. The tab context menu is effectively a target the width of
- Close button. Allow disabling close button on all tabs, or all but
Rationale: State loss. It's too easy to inadvertantly close a tab
when right-scrolling the tablist.
- Global tab list: there should be a way to list _all_ current tabs
in _all_ windows. Window title + URL. Selecting should navigate to
that window: raise window, may require navigating through
windowmanager workspaces / panes. Probably also want other tab
management actions: close, reload, move, bookmark, save (selected)
Rationale: I lose track of tabs. Currently I've got 8 workspaces,
seven Galeon sessions, and, if I've got 'em all, 105 open tabs.
Abiliity to track these would be helpful.
- Grouped tab actions. (Related to above) The user should be able to
perform sensible operations on arbitrary groups of tabs. E.g.:
close selected, close unselected, reload selected, bookmark
selected, move selected to new/other window.
Rationale: This is so fundamental to other GUI object management
tools (e.g.: file managers) that I'm surprised it's not present in
browsers yet. I suspect this will be a killer feature if/when
Example from today: I was closing out a large Galeon session in
order to reclaim system memory. Current actions to individually
close ~100 tabs on multiple windows is time consuming. Reason for
not closing the entire session was to identify any stateful pages
(e.g.: web forms) or pages needing bookmarking. Ability to group
operations (close this list of tabs...) would be very useful.
Note: this calls for a significant change to or addition to the tab
MIME types / Open With
- If MIME types are going to be managed within GNOME, *DO* provide
access to the GNOME MIME type editor from within Galeon. Similar to
the proxy configuration tool.
- Push upstream to GNOME request that MIME management be customizable
on a per-application basis. I may want different bindings for
different apps. Should also be able to reset to "user defaults" (app
takes user's MIME prefs) and "system defaults" (app *and* user take
system MIME prefs).
- Provide option to not ask for action again. E.g.: always save to
disk, or always open with application, defaults.
As discussed today on list: provide interface for users to be able
to save a session or sessions.
Rationale: Session state is useful information. Even if this is
implemented as a special case of bookmarks, it would be useful.
- Save current tab to session.
- Save current window's tabs to session.
- Save _all_ tabs to sessions, by window (subfolders).
- Restore sub-portal feature of My Portal.
- Provide a bookmarks search capability. A keyword/filter similar to
how the about:config window or history window would be useful.
- Provide a bookmark integrity test tool, similar to weblint. Looking
for dead links. Should be able to list same, offer to delete,
search for possible new location (e.g.: Google search of title
- Provide ability to publish/import/use an external bookmarks manager.
This mostly calls for researching alternatives and providing
interface to same.
- Current cookie management (Remove / Remove and block)=20
Controls, Privacy. Is _painfully_ slow. I'm seeing a minute or
more to delete a single cookie. Any reason for this? Makes
operations pretty much infeasible. Improve performance.
- On cookie query dialog: Controls/Privacy allow specification of
session vs. permanent cookie.
- Document thet current preference settings for cookie management.
"Cookie Lifetime' and 'Cookies' aren't clear, and are poorly
documented in online help. =20
What's the purpose of cookie management? Hrm:
- Sites I want to allow.
- Sites I want to deny.
- Maximum cookie persistance.
- Default allow/deny and persistance values.
- Cookie persistance query (ask on...)
- Wafers: feed bogus data to (selecte) blocked sites
Seems to me there should be:
- Allow cookies [yes] [no] [ask]
- Allow off-site cookies [yes] [no] [ask]
- Persistant Cookie Lifetime: [requested] [ask] [session-only]
(Doesn't apply to session cookies)
Persistant Cookie Lifetime default: [requested] [session-only]
- There's also the question of where cookie dialogs should appear. My
suggestion is that a separate popup window should be replaced with a
dialog bar across the requesting webpage or tab. =20
Rationale: the user may be opening a large number of sites,
potentially over a slow link. A pop-up window may not be
identifiable with the page/tab requesting the cookie. Put the
inforamation request with the requesting page.
- If the cookie dialog is cancelled, the cookie is discarded. If the
dialog is accepted, the cookie is retained as the
user prefers: session or persistant.
- Additionally, rather than the page load blocking on a new request,
the cookie should be provisionally accepted as a session cookie and
the page loaded. If the cookie dialog is cancelled, the cookie is
discarded. If the dialog is accepted, the cookie is retained as the
user prefers: session or persistant.
Rationale: when opening a large number of sites, particularly over
a slow link, a single unanswered cookie confirmation may block
one or more page loads. Complete the requested action (load the
page), store provisional data, and take subsequent action on
provisional data (the cookie) based on further user input.
Performance is as with cookies: painfully slow. Improve.
Ability to search for specific sites / users (e.g.: history search)
would be useful. I need to weed out some dupe entries.
- Provide options to clear selected histories/cache on browser exit.
- Provide options to clear selected histories/cache on demand.
- Other issues I'm forgetting at present.
- Allow history in Smart Bookmarks searches, e.g.: Google search.
...subject to privacy (above).
No specific recommendations at this point, but some of the controls
are unweildy and/or unclearly labled and/or hard to find.
The following features are advanced and/or somewhat undefined, but
should be kept in mind in looking at future Galeon development.
Galeon largely lacks RSS features. I'm not entirely sure what we
want to see here, but it's a topic which should be on the table.
Google is becoming one of the major factors in pushing web features,
with its smart search, gmail, maps, and other features, and is become
a de facto establisher of standards. Making Galeon compatible with
the tricks Google is shoving down browser-designer's throats is going
to be an increasing concern.
Firefox's extensions are useful. Documenting how to use same,
and/or providing ability to use same, and/or providing a similar
extensions interface into Galeon would be a major win.
Proprietary Multimedia Plugins
Flash, Java, Quicktime, and other plugins. Clearer guidance on how
where to get, and how to install plugins would be a win.
Pointing to free alternatives to proprietary plugins would be a win,
particularly for alternatives which offer largely equivalent
Offering user overrides to default plug functioning "press to play"
would be a *massive* win. Currently it is possible for sites to
override plugin controls (e.g.: removing 'play' from MMF menu), and
there is no way to default a plugin to "don't run" status.
Offering user overrides to block specific content, by site or by
pattern, would be a *massive* win.
Some of the two above features are addressed through Firefox plugins
and may require coordination with Mozilla proper. They are user
requests of very long standing.
Alternate Widget Sets
It's abundantly clear that:
- The Galeon dev team cannot single-handedly create all their own
- Existing widget sets offer much useful functionality.
- There are extreme differences of opinion over the utility and
appropriateness of GNOME to Galeon as a browser.
This last largely boils down to whether or not users are viewing
Galeon as a component of the GNOME environment, or a tool in its own
right. My own view is the latter, following the principle that
people identify software, not abstract software bundles, as having
I'd like to see *constructive* discussion of what Galeon's needs are
vis-a-vis environment support, and alternatives to problematic GNOME
How to Build a Better Web Browser
- This is a Microsoft developer's comments on future developments in Web
browser design. There's a few good points and a number of stinkers:
#37 - How to build a better web browser
The discussion is generally:
- Understanding what people do with browsers
- Understanding how browsers are used
- People have repeating patterns of web usage.=20
- The rate at which people change the pile of sites they visit is
- Bookmarks serve different purposes, despite how indifferent most
bookmark UIs are to them.
- Intelligent bookmarks
- Good side-bars and bad side-bars
- Supporting specialized tasks: Research & Annotations
- Credit cards, passwords and zip codes
- Red herrings and over-rated concepts
- Security and Stability
- Applications and Platforms
- RSS / Push
- Parental controls
The first two sections (Understing what / how) are the best, IMO.
There's a lot of intelligent work based on _experiential_ data
which can be incorporated. "Intelligent Bookmarks" in particular
is a recommended read.
The Red Herrings section is IMVAO mostly stinking fish. Security
and stability are what have suddenly lit a massive fire under
Microsoft's ass WRT MSIE. Some features (parental controls) are
probably best moved elsewhere (proxy). RSS may or may not be a
browser function, but it's useful stuff.
Most of the rest is interesting, but not imperative.
Just my thoughts.
Karsten M. Self <kmself@...> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Strike while the iron is hot.