Updated wishlist items

Following the recent discussions of Galeon features here and elsewhere
(the SVLUG list), in particularly GNOME and 1.2 => 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.


General principles:
-------------------

  - Put the user first.  Ahead of webmaster.  Ahead of any one desktop
    environment.

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




Specific Requests
------------------------------------------------------------------------


1.2 => 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 => Web | Edit->Preferences.  
         - View->Source => File->Source.

       The latter in particular is annoying.

       Severity: 1

     - Detachable menus.  Controls.  IIUC, this is a Gtk option.  It
       would be nice to have detachable menus restored in Galeon.
       
       Severity:  2

     - 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 => fUll screen) would
       escape fullscreen mode in 1.2.  This should be restored.  Only
       current option appears to be killing the entire browser session.

       Severity:  4

     - View as dialogs.  Controls.  1.2.x allowed the user to specify:

        - Ask/don't for save / view option, setting default to one or
          the ohter.
        - Ask/don't ask for viewer, setting the default to a given
          viewer.

       Both features are missing from 1.3.x.  Restoring them would be
       appreciated.

       Severity: 3


Menus
-----

    Enable detachable menus.

    Rational:  simple method of letting use make currently useful
    controls immediately accessible.

    Severity:  2.



Confirmations
-------------

    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.

    Severity:  5.



Tabbed Browsing
---------------

  - Navigation.  Allow scrolling of tabslist *without* changing current
    tab focus.  Allow context-action (e.g.: right click)  on tab
    *without* changing current tab focus.  

    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
    dead.
    
    Severity:  4

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

    Severity:  3

  - Close button.  Allow disabling close button on all tabs, or all but
    current tab.

    Rationale:  State loss.  It's too easy to inadvertantly close a tab
    when right-scrolling the tablist.

    Severity:  4

  - 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)
    as session.

    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.

    Severity:  4

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

    Severity:  3



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.

    Severity:  3.

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

    Severity:  3.

  - Provide option to not ask for action again.  E.g.:  always save to
    disk, or always open with application, defaults.

    Severity:  4.



Session Management
------------------

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

   Severity:  4.


Bookmarks
---------

  - Restore sub-portal feature of My Portal.

    <strike>Severity:  2.</strike>
    Completed.


  - Provide a bookmarks search capability.  A keyword/filter similar to
    how the about:config window or history window would be useful.

    Severity:  2.

  - 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
    text), etc.

    Severity:  2.

  - Provide ability to publish/import/use an external bookmarks manager.
    This mostly calls for researching alternatives and providing
    interface to same.

    Severity:  2.


Cookies
-------

  - Current cookie management (Remove / Remove and block) 
    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.

    Severity:  4.

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

    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)

     - (Possibly) 
       Persistant Cookie Lifetime default:  [requested] [session-only]

     Discuss.


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

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

    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.



Passwords
---------

    Performance is as with cookies:  painfully slow.  Improve.
    Controls, Privacy.

    Ability to search for specific sites / users (e.g.:  history search)
    would be useful.  I need to weed out some dupe entries.

    Severity:  3



Privacy
--------

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


Search
------

  - Allow history in Smart Bookmarks searches, e.g.:  Google search.
    ...subject to privacy (above).
    Controls.



Preferences Dialogs
-------------------

   No specific recommendations at this point, but some of the controls
   are unweildy and/or unclearly labled and/or hard to find.
   Controls.

   Discuss.




Advanced features.
------------------------------------------------------------------------

The following features are advanced and/or somewhat undefined, but
should be kept in mind in looking at future Galeon development.



RSS
---

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

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

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

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

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

    I'd like to see *constructive* discussion of what Galeon's needs are
    vis-a-vis environment support, and alternatives to problematic GNOME
    infrastructure.



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
        http://www.uiweb.com.nyud.net:8090/issues/issue37.htm

        (Slashdot discussion)
        http://slashdot.org/article.pl?sid=04/12/14/1443203&tid=113


    The discussion is generally:

      - Understanding what people do with browsers
      - Understanding how browsers are used
          - People have repeating patterns of web usage. 
          - The rate at which people change the pile of sites they visit is
            slow. 
          - 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
         - Visualizations

     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.


Peace.

-- 
Karsten M. Self <[email protected]>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Strike while the iron is hot.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD4DBQFCFBDYefG8443k044RAtuhAJ4tK4D5rqY2WbrWeZC6EHMNu0WkIgCUD/gN
CFw5zsTwh/vueGQ+AbWR1g==
=VFKD
-----END PGP SIGNATURE-----