> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote: > > > If someone has changed the shortcut, they should know what shortcut they > > > set it to, right? So having the tooltip just say "To kill a specific > > > window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" > > > should do the trick, right? > > > > In principle, I agree with you here. :) But... > > > > I have these premises in mind: > > > > 1. There might be a situation where the user can't remember what he has > > done. > > 2. I prefer precise over approximate information if it is reasonable easy > > to get (by fixing this https://git.reviewboard.kde.org/r/122981/ it is now > > easily possible and the patch is already written) > > 3. Somewhere I read that tooltips are to be avoided where possible => this > > patch factors some information out of a tooltip which in itself is > > desirable. > > 4. For the user, the discoverability of the feature after applying this > > patch is better than before (though not perfect, sure). > > Thomas Pfeiffer wrote: > 2. If we can get the current shortcut, why can't we get it for the > tooltip? > 3. Wait, are we talking about different tooltips? I do _not_ mean the one > you get when clicking the ? icon in the window decoration. Those should be > avoided because few people even notice that button. What I mean is the thing > that pops up when hovering over a control. Those are strongly encouraged in > the HIG, in fact they should be used on every control where the function > isn't clear from the label. > 4. Clicking a button just to get explained how to use a shortcut is just > not good. When users click a button (unless it's a help button), they expect > something to happen. And still: We're putting something in the UI which is > used only a single time (afterwards the user knows that the function exists) > > Gregor Mi wrote: > 2. "Put it into the tooltip": Yes, sure this can and should be done. But > also see point 5. > > > 3. "Tooltips": oh, I indeed meant the Tooltips which you say are strongly > encouraged in the HIG. My mistake, thanks for clearing that! > > > 4a. "Clicking a button": the original idea was that clicking the button > actually triggers the function but for current technical reasons it was > postponed. So, adding the menu item now might motivate someone to go a step > further and implement the rest. One step at a time. > > 4b. "only used a single time": I myself am a user and due to the > outstanding stability of the desktop I keep forgetting these shortcuts. ;-) > Seriously, often I found myself in a situation where I knew there is a > shortcut but could not remember which (and previously I was lost completely > because I did not know that the killing window function exists at all). By > now I think I will never forget it, though. :) > > 5. Funnily, the first time I actually saw that the shortcut is documented > in the toolip was when I began to change the code to prepare this RR to make > the shortcut more visible. :) Sure, this only a single user report but I > don't think I am the only who does not read the whole tooltip.
As I see it here, the current solution isn't good and I'd argue against changing things just because they feel stale. Mainly you're trading one less-than-ideal solution (using a tooltip) in exhange for a solution which is more complicated and bloats the UI. Why do we need to go so far out of our way to advertise XKill when we are capable of killing apps from the monitor? Users of the monitor familliar with the system chould not have purely informational menus burned into the main UI. Split buttons are also abused regularly, and it's not clear what the "V" menu offers until activated. Why would someone who won't stop for a tooltip know to press the "V" button? What if they assume it's for other actions like pause, suspend, and resuming the selected process? Users *still* won't click it if that's the case. This is essentially a much more convoluted tooltip which works under the assumption users will investigate it because it's disguised as functionality. I also dislike that it advertised as a feature and not a help option, and users with a crashing/frozen application will only be more frusterated if they think they have a solution - and are instead given a manual. Nowhere else do we use this pattern. Information should NEVER be disquised as functionality; it **severly** degrades user trust. Imagine if every application did this - would you use a system which kept popping up with info boxes instead of doing the work? Especially when you *need* the system to take care of a problem and the system tells you "I can't do this, try doing this" - I can think of no better way to shatter a users trust; one thing is already broken, we should not make it feel *more* broken. Finally, xkill is a separate utility entirely, I question if it should be advertised at all in ksysguard. One is a UI-oriented solution, one is a shortcut solution. Should Kate advertise KDevelop features? Should Juk advertise Amarok? Should the volume control widget advertise the Pulse command line utilities? Just because they do related things doesn't necessarily mean they should advertise each-other. Anyway, I would propose one of these alternative solutions: - Having a tip at the bottom of the window between the task list and status bar which goes: "(i) You can force close a specific window by pressing #shortcut#". This tip could be closed/hidden permanently by the user. - Moving the information to the "help" menu. Help > "How to kill a window". A little less discoverable, but much more appropriate. - Have it actually perform the function. The option will launch an [OK|Cancel] dialog with "You will force-close the next window you click on. Hit ESC to cancel at any time". When the user presses [OK] it properly executes the xkill utility. This is more future-proof in case Kwin offers a nicer KDE/Plasma-centric with the warnings and labels built-in, because we could just adapt this in the future to use that. - Clean out the tooltip. Remove the parts on right-clicking and what-if. Users will visit help if they need it, and right-clicking is common functionality. Instead of adding mroe to make thing visible, we remove noise. - Leave it as-is. *This is an option.* There are lots of places we could be tempted to tell users about our functionality, but the fact is there will always be things a computer can do that users don't know about. As far as code complexity and keeping it less complex, I personally beleive that if we're introducing code for *anything* it should at least be functional. To me increasing code complexity for a feature is acceptible, but incrementing the complexity even a little for half-measures isn't really justifiable. - Ken ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review91486 ----------------------------------------------------------- On April 20, 2015, 10:24 p.m., Gregor Mi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122249/ > ----------------------------------------------------------- > > (Updated April 20, 2015, 10:24 p.m.) > > > Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas > Pfeiffer. > > > Repository: libksysguard > > > Description > ------- > > Current situation: > The "End Process..." button has a tooltip which says "To target a specific > window to kill, press Ctrl+Alt+Esc at any time." The keyboard shortcut is > hardcoded. > > New: > Replace the "End Process..." button with a drop-down button and a action > named "Kill a specific window..." > > > Diffs > ----- > > CMakeLists.txt 66899e577a03786d894423a8f1ce5b3aeed6de8a > processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 > processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 > processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c > > Diff: https://git.reviewboard.kde.org/r/122249/diff/ > > > Testing > ------- > > > File Attachments > ---------------- > > New End Process button with drop down arrow > > https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png > new submenu > > https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png > > > Thanks, > > Gregor Mi > >
