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