From kde-usability Sat May 17 07:59:37 2003 From: Datschge Date: Sat, 17 May 2003 07:59:37 +0000 To: kde-usability Subject: Re: mmb pasting in Konqueror X-MARC-Message: https://marc.info/?l=kde-usability&m=105315837720172 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 _______________________________________________ kde-usability mailing list kde-usability@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-usability