[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Konqueror delete unification
From:       Eron Lloyd <elloyd () lancaster ! lib ! pa ! us>
Date:       2003-07-16 11:19:20
[Download RAW message or body]

On Tuesday 15 July 2003 10:52 pm, David Hugh-Jones wrote:
> On Wed, 2003-07-16 at 02:28, Eron Lloyd wrote:
> > On Tuesday 15 July 2003 08:25 pm, David Hugh-Jones wrote:
> >
> > I think I do. I think we should keep *some* consistency with Mozilla,
> > which has the following structure:
>
> I don't really think consistency with Mozilla is a goal. The only
> advantage would be (1) if we were trying to take market share from Moz
> or (2) if users were likely to use both browsers. I think we should be
> aiming to take market share from IE, and to be the only browser anyone
> needs :-)

Hmm...well, my take on it is this:
1. Mozilla is the actual competitor in our "market" (haven't seen IE run in 
UNIX/Linux yet)
2. You can't take market-share from IE without replacing the full desktop 
*and* OS, too ;-)
3. Following IE's model lead to confusion and menu bloat in the first place 
(see the Encoding entry in IE)

> I suggest the following:
> > Up
> > Back
> > Forward
> > Reload
> > Stop
> > ---------
> > Add To Bookmarks
> > ---------
> > View Document Source
> > View Document Info

To add to this:

1. When hovering on a link, Copy Link Location, Save Link As..., and possibly 
Open In New > (Tab, Background Tab, Window) should be available

2. When hovering over an image, Copy, Save Image As.., View Image (img_name), 
and possible Copy Image Location should be available

> > for these reasons:
> >
> > 1. The navigation elements are by far the most used, thus should be
> > preserved
>
> Evidence!

I don't think either of us have empirical data to support our ideas ;-) 
However, if you look at any browser's RMB you will see at least Back, 
Forward, and Reload on the top. Up is quite handy for me, but I'm willing to 
compromise. Stop may be unnecessary, also.

> > 2. Tab elements are a power user feature and should not exist in the RMB
>
> Hmm. Not sure about this. I suspect the best thing is to have either
> "New window/new tab" depending on a general "prefer tabs/prefer windows"
> configuration setting, but this is complicated and needs further debate.

See above under menu additions. I don't mind keeping these options *only* if 
you are selecting a link. Also, what do you think about making the "Open In 
(Tab|Bg. Tab|New Window)" a submenu? Or perhaps an option for the default 
action is a solution.

> > 3. The others aren't really relevant to the average page (except for
> > maybe Select All). The animation stop item doesn't need such prominence
> > (as few pages use them)
>
> I think animation stop should be only when you click on an animated gif.

And just that one GIF, not the whole page of dancing bears which is flooding 
your CPU? :-)

> > 4. Security info should always be available in the status bar
> > 5. Encoding? Most people have no clue what that means.
>
> Agreed.
>
> > I think one of the most annoying things about the RMB is not even
> > discussed. The fact that when you select some text or images with the
> > cursor, there is no "Copy" command in the RMB. This should definately be
> > a priority.
>
> Fair point.
>
> > These comments only address the Web mode. I'll speak on the filemanager
> > when I have more time :-)
>
> If you can, check out CVS. Things have moved on a bit. Actually, for
> your reference, here are some screenshots and a useful image gallery.
> (Note that these reflect my patch, so the original version has
> delete/trash/shred. Also, I have no plugins installed with my cvs
> version, so for all I know various plugins make the whole thing worse).

Thanks. I'll have to start checking out CVS regularly...I though Shred was 
removed because it was a bad idea anyways (since it doesn't really do it's 
job...)

> http://www.zaygo.com/rmb_snapshots.tar.gz
>
> The iconviews are considerably improved, but the HTML menus are still
> way long.
>
> Ditching security and encoding would be good. This is relatively
> uncontroversial (ie we should only get about 500 votes on bugs.kde.org
> asking for it to be put back.)
>
> Ditching all the navigation apart from "back" seems a good idea to me
> and various others. I foresee a fight here.

No need for a fight...let's work as a usability team!

> The rest is more complex. I'm off to bed.

Yes, this is quite a complicated issue. I think there are too many things 
trying to be addressed here at once:

1. RMB menu, which will ultimately lead to discussion about all of Konqi's 
menus
2. The still-missing global desktop "trashcan" problem (which might be more of 
an OS/filesystem issue than anything)
3. Dealing with Konqi's multiple view modes and ensuring each is consistent 
with the task at hand (also, the policy on adding RMB menu items through 
plug-ins)

I think this discussion raises a serious question about how we address 
usability issues. What formal process should we use to handle all this? I see 
at *least* 3-5 different reports to tackle the Konqi issues alone. How much 
(if any) data should be compiled to reach a conclusion that something is 
unusable, and how should it be collected and presented? How should we 
document our recommendations, and in what format should they be in? When is 
an issue large enough (like in this case), where it should be broken out into 
multiple usability studies? I will think about these, and consult some of the 
materials I've been reading lately.

Get some good rest,

Eron

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]