mmb pasting in Konqueror

Datschge datschge at gmx.net
Sat May 17 10:58:51 BST 2003


Anyone who actually took the time to read the discussion on that wish report 
(http://bugs.kde.org/show_bug.cgi?id=44931) should already have noticed that 
just saying "remove it, replace it, hide it away" is way too easy and 
insufficient for me (and others) to think that it can really be considered a 
solution usability and accessibility wise. Usability is *not* about removing 
features half of the crowd loves just because the other half can't stand it 
(unless the feature in question is inreversible destructive which is not the 
case here).

Following are all issues mentioned together with that particular wish report 
and my suggestions how I'd solve them while keeping in mind that it should 
satisfy the largest possible crowd:

(1)
> mmb click loading the URL in the clipboard or searching for a non-URL string
> in the clipboard is non-obvious and unintuitive

Wrong, it's fully consistent with the globally standardized "mmb click" == 
"clipboard paste" behavior.

(2)
> html pages are read-only, it makes no sense that pasting on them changes
> them

What you do by mmb paste is the same as when clicking on a link: you request 
another page. Neither of them involves "changing a read-only page".

(3)
> the content of the clipboard might be sensitive data: a password or a credit
> card number. 
 
While any action by the user should be considered a conscious action I agree 
that at that point a dialog window should appear warning you that you are 
about to send possibly sensitive data into the internet, just like done with 
unencrypted data transfers. This would also be a chance firstly for the user 
to cancel that action and secondly for educating him about that particular 
behavior. (Btw: passwords cannot easily be copied anyway unless they're 
readable as clear text already which alone is already a security issue.)

(4)
> this feature is non standard, highly unexpeted, dangerous, utterly
> confusing, work loosing, some websites don't let you go back

It's standard mmb paste behavior and as such easy to understand for everyone 
who knows the standard mmb paste behavior. Being a (put in your favorite 
system) convert by far doesn't mean KDE must behave the same way. So it might 
well be confusing for new user and new converts who don't know this feature 
yet. Computers are in general always confusing when you start with them for 
the first time, usually until you know the features. Within KDE those 
features are mostly highly consistent between applications and never 
destructive, which allows users to quickly get used to them.

It's not dangerous nor work loosing, you can always choose to go back one 
page. If you lose the form content this way it's a separate unrelated bug and 
should be filled as such. Also open a bug report if you can't go back on a 
particular page since that shouldn't happen.

(5)
> a user might try to mmb click on a link to open it in a new window/tab and
> misclick invoking a mmb paste instead

Again first and foremost we need to consider that by this the user actually 
might have done a conscious action, so this shouldn't be changed using some 
"intelligent" software behavior, nor will removing the mmb paste feature in 
this particular case change the fact that a misclick is a misclick.

A different case is the lack of accessibility of link targets for disabled 
people, this case is completely unrelated and asks for another kind of 
solution: increasing the link target size. My suggestion is a kind of zoom 
effect for link targets while the mouse pointer hovers the link, thus 
increasing the target size while decreasing the possibility that the pointer 
accidentally leaves the target area. Since this is completely unrelated to 
this topic though one should open this as a separate wish report.

(6)
> when scrolling with the scroll wheel it's surprisingly easy on some mouses
> to accidentally middle-click while scrolling

This is, excuse me, a completely bs and preposterous reason to remove a 
feature. This is clearly a hardware problem if it's indeed the case. Since 
when is software used to work around hardware problems? And how do we detect 
whether a click was a conscious action or an accidental click, possibily due 
to a hardware error or hardware design fault? It's simply nonsense to try to 
fix broken hardware with software workarounds.

(7)
> while still loading a page can still resize making users accidentally do an
> mmb paste instead an mmb click on a link

While this is basically the same like (5) I agree that this can happen more 
often. My suggestion has been that a mmb paste click while a page ist still 
loading won't paste the clipboard content but stop the loading progress 
instead avoiding further possible resizings. After that mmb click on a link 
and mmb paste should have the usual behavior.

(8)
> user wants to paste some text into a field box on a html page but misses the 
> edge of the box

Again a case of misclick, just like (5). My suggestion: Optionally allow mmb 
url paste to be opened in a new tab/window (and make that the default).

(9)
> users expect an "internet explorer style autoscroll" feature, not mmb paste

Completely unrelated to this topic, not even consistent with the current way 
KDE handles it globally. Please open a new wish report if you really want it 
nevertheless.

(10)
Further suggestions of mine improving usability and accessibility without 
removing features:
- Make mmb url paste only work when the current widget has the focus. 
- Allow to choose any search engine and to disable the automatic search which 
is invoiced whenever a text string is not detected as valid location by any 
kioslave.

For me mmb paste is Konqueror's most outstanding feature and the case where 
mmb paste is used most times. Nothing rocks more than selecting a text-only 
URL and loading it using mmb as well as selecting terms and searching for 
them right away. Simply taking it away completely as default would be a huge 
disappointment for me (and surely others as well).

Regards, Datschge



More information about the kfm-devel mailing list