From kde-usability Wed Jul 16 11:19:20 2003 From: Eron Lloyd Date: Wed, 16 Jul 2003 11:19:20 +0000 To: kde-usability Subject: Re: Konqueror delete unification X-MARC-Message: https://marc.info/?l=kde-usability&m=105835442121706 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