overdeveloping your software

[Torsten Rahn]

> > Nah, he says "the user can be exploited by malicious code or unsrupulous
> > hackers intercepting data intended for another secure web site".
> > Intercepting data doesn't happen in this case but happens in the frame
> > injection which is why I'm assuming this is it. I can call the radio
> > station and ask if you think that makes more sense.

The point you guys seem to refuse to get is that this guy is talking about TWO 
seperate issues at the same time.

A.) he informs about bad press that we might have got via a radio station
B.) he complains (although by referring to the tab-feature as well) that he 
doesn't like the way konqueror developed during the last years (see subject).

where the 2. point is the main issue he likes to address. I just was at System 
fairs and we got a huge number of  complains that Konqueror has way too much 
overwhelming toolbar buttons, menu entries and bad designed dialogs.

Seriously we need to 

1). rearrange the toolbars by 

 a) removing buttons like the "print"-button which are usually rather seldom 
used compared to the navigation buttons or buttons which are usually used 
once (like the zoom-buttons) 

 b) put those buttons into further advanced toolbars.

 c) rearrange the other "advanced" buttons into task-oriented toolbars (like 
"web development" e.g.)  

 d) add ways to create user-customizable task-oriented toolbars (like Windows 
has since years) 

2.) rearrange the menu-entries so that 

 a) entries which are very seldomly used or used only once to set up the file 
manager disappear from the menu as well and are moved into seperate 
settings-dialogs.

 b)  the "Tools"-menu is removed altogether. It's just a menu where all 
plugins are moved. This doesn't make any sense to the user at all as the user 
does not know about "plugins". To the user this plugin menu just looks like a 
mess of actions which seem to be completely unrelated to each other and would 
fit much better into other places in the menu-hierarchy. 
So actually the "Tools"-menu entry is a work-around which had a valid reason 
to exist in the past to get the first plugins into the menus somehow. But 
these days it would be much more appropriate to add further specifications so 
that new plugins are moved into those places in the menu-hierarchy where they 
make sense

 c) Alternative Actions which are expected to have a strong preference by the 
user just deserve to have _one_ menu entries instead of multiple ones. 

Example: To delete files a user usually either uses "Delete" 99% of the time  
or "Move to trash" 99% of the time. 
Therefore I suggest to have one "Remove" item instead those two entries. This 
remove item would trigger a dialog on first use which asks whether the user 
would like those files to be 

i) moved to trash (recommended)
ii) deleted (beware destructive action!)
iii) the menu should always offer both options

Once the user has chosen i) or ii) he should be informed in a seperate dialog 
that he will be able to reconsider his choice in the kcontrol ->  
KDE-Components -> File Manager -> Behaviour dialog.

d) Multiple menu entries which are only (almost) used once and are strongly 
related to each other (like those half-dozen "Configure" options) should just 
be merged into one menu entry. 

Example: Right now we have "Configure Shortcuts" "Configure Toolbars" and with 
the more and more dynamic structure of the whole menu hierarchy we might soon 
have even "Configure Menu". Instead of having all those three we should have 
at least only one "Configure User Interface" item. With Shortcuts-, Toolbar- 
and menu- options merged into _one_ tabbed dialog we would get rid of another 
menu entry.

By merging "Configure Interface" and "Configure Konqueror" (and moving 
"Configure Spellchecking" somewhere else as well) we could end up with one 
single entry. Which would be appropriate as the main thing that the user does 
is not configuring konqueror all the time but navigation instead. And that's 
the thing that most menu entries should be focused on.  

3.) redesign and reconsider many of the dialogs in the configure section.

It go way too much into detail to write about this but as there are lots of 
ways for improvement here I leave it up for the usability team here to make 
specific suggestions. 

The whole redesign needs to be made severe enough. Otherwise we'll end up with 
the same level of clutter in the end as the number of options is expected to 
grow during that process and during the release-cycle anyways. 

Greetings,
Torsten Rahn



   

> Cheers,
> Waldo