Re: Updated wishlist items

on Thu, Feb 17, 2005 at 01:02:27AM -0500, Adam Hooper ([email protected]) wrote:
> On Wed, 2005-02-16 at 19:34 -0800, Karsten M. Self wrote:
> > For discussion, it's probably best to pick a particular item, change
> > subject appropriately, and discuss it.
> 
> Bah, I'll just pick a few things which stand out to me (i.e., I
> generally agree with anything not mentioned below):

OK...
 
> >   - 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).
> 
> I don't understand this one. By "notification bar", do you mean the
> statusbar? Or that yellow bar below Firefox's and IE's toolbars? In
> either case, are you either:
> 
> a) advocating dialog boxes? If so, that's evil! If people expect dialog

No.

> b) advocating the statusbar? If so, that's evil! The statusbar is barely

No.

> c) advocating the yellow bar? 

Yes.

> If so, that's evil! It simply doesn't draw enough attention (I have
> yet to find myself actually *noticing* it when I browse with IE -- the
> only times I will are on web pages which say "If this doesn't work,
> look for a yellow bar asking to enable ActiveX controls"). And it
> leaves less room for the web page.

With sufficient creativity -- think bright yellow, and large, bold text,
with something flashing (I hate blink, but think it's appropriate in
this context) it might work.  An overlay, interstitial, or other effect
might also work.  Say:  superimpose the message over the page, which
itself is greyed out (onionskin effect).  Most of this can be
accomplished with stylesheet tricks, not sure what's supported in the
UI.

At least if people ignore a "yellow bar", they're ignoring it in
context.  I currently ignore popups and have *no idea* what I'm
ignoring.

See the further discussion of default actions and such in my previous
post.  

*Most* such dialogs are already pointedly useless:  

  - Most are cookies -- call it 90%, and can be safely ignored
    (defaulting to a session cookie)

  - About 9% are https notifications.  *Not* opening the page in an
    unadvisable situation might be considered, though in practice, I'd
    allow that 99.999542% of all users have no understanding of the
    issue, problems, or consequences.
  
  - The remainder are other -- download / open-as dialogs.  Putting
    these on a placeholder page associated with the URL in question
    rather than in a popup dialog _might_ be preferred, though that's a
    call.  On-page leads to ignoring.  Popup leads to confusion over
    what the download is associated with.

Only in the last case is the user actually losing useful information by
ignoring the notification area.

And with time, a significant number of users will be attuned to looking
for these notifications when things don't happen as anticipated.

> So IMO, all options are evil.

Yes, but some evil things are also fun and fattening....
 
> >      - Detachable menus.  Controls.  IIUC, this is a Gtk option.  It
> >        would be nice to have detachable menus restored in Galeon.
> >        
> >        Severity:  2
> 
> I get detachable menus. Look
> at /desktop/gnome/interface/menus_have_tearoff in GConf.

Ah, interesting.

Note that in "file_views", there are options for "show_backup_files" and
"show_hidden_files".  Latter apparently *doesn't* work in the save-as
dialog.
 
> >      - 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
> 
> Have you tried <alt>-V-F? Works for me in Debian unstable.

Not for me.  <alt>-V does nothing.  The 'f' starts find-in-page.
Feature conflict?

Now I've got to kill Galeon again.  <sigh>

Y'know, a context-menu item "toggle full-screen" would be *really*
useful about here.  As would being able to make menus visible in FS mode.

 
> > 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.
> 
> Epiphany, for one, removes C-q altogether. That solves the issue for me,
> since I almost never close windows with the little X in the corner (C-w
> all the way!)

That's another solution.

I'll also note a fav feature of WindowMaker.  My windows have _two_
buttons on 'em.  "Minimize" and "Close".  They're at opposite ends of
the titlebar.  Very hard to kill a window by mistake (though I do it a
few times a year -- busy desktop and slow system usually).  There's
times I really like minimal design, all evidence to the contrary
notwithstanding.

 
> >   - 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).
> 
> Staring into my crystal ball, I predict this will *never* happen in
> GNOME. File a bug for it and you'll get a WONTFIX right away.

May have to generate an autosubmit bug script....

Hrm.  Interestingly, looks as if Galeon has earned an independent status
for its proxy configuration, going through gconf-editor right now.

 
> >   - Provide ability to publish/import/use an external bookmarks manager.
> >     This mostly calls for researching alternatives and providing
> >     interface to same.
> 
> This could really benefit from Epiphany's extensions interface.

Details?

 
> >   - 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.
> 
> Some people might not appreciate that from a privacy perspective.
> Accepting a cookie and using it to load the rest of the page (maybe some
> images, for example), you would be allowing the cookie to do exactly
> what you don't want: invade upon your privacy.
> 
> *I* couldn't care less, but I think some privacy advocates might feel
> unsafe. Maybe someone who knows more about cookies can comment.

This is the sort of thing that is probably best approached from a "most
people" + "least harm" PoV.

Privacy issues are hard to communicate.  They're also generally most
visible to people who've got intimate familiarity with technology -- and
that familiarty breeds an exceptional level of contempt.

Short anecdote.  I just returned from the local PC (legacy MS Windows)
user group meeting.  Presentation was run by one of the more advanced
'doze guys, and he made a point of showing how he disallows and
regularly (manually) clears a bunch of saved history.  Then he mentioned
that his father-in-law, Sr. VP at a local stagecoach bank, *DOES NOT
USE* online banking.  And I thought _I_ was being paranoid.

Most of the crowed, largely silver-haired, totally loses this discussion
though.


Anyway:  allowing pageload w/ session-only cookies, as a default
setting, seems like a useful compromise.  A first-time wizard could
present various privacy options, and well allow that the tin-foil-hat
squad (WHO TOLD YOU!) will opt for no or minimal cookies.  An improved
privacy section in the preferences dialog would also help.

 
> > 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.
> 
> Look to Epiphany for a lot of work on extensions (including Python
> extensions). Most Firefox extensions can't be used out-of-the-box. (And
> most Firefox extensions are complete garbage, anyway.)

Agreed to the latter point.  However as a sandbox development feature I
think they're *exceptionally* useful.

What I'd *like* in my browser is a set of sane, useful, powerful
preferences, with minimal fuss (G12 won totally there).  Offering the
infrastructure to develop and deploy either freestanding or
proof-of-concept-for-later-integration tweak is a win.  The dev team can
cherry-pick for integration, or ignore.


Peace.

-- 
Karsten M. Self <[email protected]>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    So don't deal with it.  Don't use software that uses it.
    - Jeff Waugh, offering preferred GNOME usability workaround.
       http://zgp.org/pipermail/linux-elitists/2004-January/008588.html

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

iD8DBQFCFEcwefG8443k044RAqEWAKCKWAumWzIaweOym+JMrkPDKMfiPQCeMcOa
VpFilA2OPUJzRVGozmuFIxA=
=Hv+o
-----END PGP SIGNATURE-----