> 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. > > Ken Vermette wrote: > 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. > > Thomas Lübking wrote: > On the bottom line, this is the "KWin has no real GUI" problem. > > Aside the xkill (we're more talking about the feature built into KWin > than the x util here) there're several other kwin features only available > through shortcuts (eg. invert screen colors, a bunch of effects, random > scripts) and not even all window related actions (packing...) are somehow > announced in some GUI (too much pro stuff) > > Maybe the question is whether KWin needs an entry in eg. the systray > where it can show a window which exposes those features - including their > assigned shortcuts or - as alternative - a "global" section in the Alt+F3 > menu? > > Gregor Mi wrote: > Hi Ken, > > I go through your feedback paragraph by paragraph. I try to keep it short > so it might seem a bit abrupt. > > > 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? > > Because it would help users to find the feature. For me, it is one of > those features that I don't look for if I don't know it exists. The system > monitor which is able to kill processes is the most suitable place to > advertise this feature. > > > Why would someone who won't stop for a tooltip know to press the "V" > button? > > The tooltip should be used "where the function isn't clear from the > label" (said Thomas Pfeiffer above). This implies that when the user thinks > that the meaning of the button is clear he probably won't read the tooltip. > > > 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 > > I disagree: if I as a user am in a situation where I need help, I am glad > I get some, and be it a pointer to some manual. It is better than nothing. > For example gparted does this when you are about to move your systems hard > drive: it shows a message box with a short explanation and a link to a howto > of how to make your system bootable in case of problems. Good thing for me. > > Plus: if the system or application gives some hint of how one can do > things (better), one should be grateful and not grumpy. > > > Imagine if every application did this - would you use a system which > kept popping up with info boxes instead of doing the work? > > Surely not. I don't like that either. And I don't think if this RR was > accepted as is (see also below), a landslide will break loose and everyone > would adapt this pop-up pattern. ;-) > > > Anyway, I would propose one of these alternative solutions: > > Thanks for these suggestions. I'll comment on them: > > > - 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. > > This would advertise the feature very prominent. It could be extended > with a button to trigger the feature. Downside: the "hide permanently" option > must be properly implemented. What if I want the message back? > > > - Moving the information to the "help" menu. Help > "How to kill a > window". A little less discoverable, but much more appropriate. > > This was discussed but then it would not show up in the Ctrl+Esc "System > Activity" window because there is no Help menu. > > > - Have it actually perform the function. The option will launch an > [OK|Cancel] dialog ... > > I had this actually implemented. It did work fine. This is what I liked > best but sadly there were technical concerns of calling the DBus interface of > KWin (see explanations of Martin and suggestions of Thomas L in the first > thread). > > > I agree with you that the split button is not the best solution. I also > don't like it so much. Here is another option: > > Add a new button right next to the "End Process..." button, so it would > look like this: > > "[End Process...] [More...] [Quick search]" > > The More... button (instead of text it could be also an icon that looks > like "more") would open a menu with currently one item: > > - "Kill a window by clicking on it" > which would either call the feature directly (if technically possible) or > show a message box with the shortcut until it is technically possible. > > What do you think? > > Gregor Mi wrote: > > Maybe the question is whether KWin needs an entry in eg. the systray > where it can show a window which exposes those features > > A systray entry would be a GREAT thing! :-) Apart from the features you > mentioned one could have an easy entry point for features like the magifier > etc. Those features are really great. And there would be a visible entry > point for the "Desktop Effects" dialog and maybe even the "Display settings". > +1 from me! > > Thomas Pfeiffer wrote: > I'm sorry Gregor, but you still have not provided a convincing argument > for your patch. A "More" menu with only one entry that in turn opens a dialog > to explain what pressing a shortcut does? This may not make users grumpy, but > this is exactly the kind of bloated UIs that people associate - negatively - > with KDE software. > Xkill is really only useful in very edge cases. For full-screen > applications it's easy to find their name in the list since one usually > doesn't have more than one application running fullscreen at the same time. > If removing the decoration is the problem, then I'd rather show a > KMessageWidget in places where the user can configure this to explain "If a > borderless window becomes unresponsive, press <shortcut> and click it to kill > it". Also: Shouldn't pressing Alt-F4 on an unresponsive borderless window > still evoke KWin's kill feature? > > Cluttering the main UI with rarely-used features is bad enough. > Cluttering it with explanations for rarely-used features is worse. > > If this was a very importantbut still hard to discover feature, I'd > begrudgingly accept the solution to advertise it in a dialog, but for an > edge-case function? No, sorry. Unless you can make a case where xkill is the > only way to prevent data loss, I cannot accept this. > > Ken Vermette wrote: > While it would be great if the feature was advertised and I understand > the logic, the system monitor doesn't exist soley for killing applications - > that's just a major use-case. If we extend the UI for features which the > monitor doesn't even have, it's bloating it for an anti-pattern. While I > don't expect a landslide of applications will use the anti-pattern my point > is that we shouldn't add them knowing it's not acceptable practise, and it > holds us to a lower standard when we say "good enough". > > The main concern I have is the fact that it breaks the users trust in the > abilities of a program when it outright states you can't do something through > the UI. This is my biggest problem, and one I'd need addressed before giving > a thumbs up. If I tried to use Kate and the find/replace button opened a > popup saying "hit ctrl+r", I would drop that application faster than a bad > habit, I might even perceive it as trying to dictate my workflow. If I were a > new user to ksysguard and I encountered that dialog, I wouldn't use it. I > wouldn't trust it to be able to fufill functionality it claims to offer, I'd > question every UI element assuming it would let me down. > > Additionally if a user pressed this button or opened the menu, they have > learned. Now the button is useless to that user forever. So we have a UI > element burned into the interface which the user knows is not only useless, > but will spawn a popup that slows them down. In the case the user forgets the > shortcut it doesn't guarantee they'll remember which application told them > the information, or where in that application it told them. > > It's having a "tip of the day" button permanently embedded in a program, > but it only ever displays one tip. I'm sorry, xkill is great functionality, > but the monitor is not the appropriate place for advertising it. As I've > thought about it, it makes less sense to include any mention of it, I think > we'd be better off with a desktop-level overlay or application that displays > shortcuts where users can consistently reference important informaiton. Maybe > if it's an app, add it to the favourites in launchers by default. Again, I'm > sorry, but I just don't think this is the appropriate place to embed random > information.
> A "More" menu with only one entry that in turn opens a dialog to explain what > pressing a shortcut does? Ok, I added two new screenshots. One that shows the System Activity window which is triggered by Ctrl+Esc as is and the other one with an added "Tools..." button. When the button is clicked a menu could open with these items (more than one and each of them useful for diagnosing the system): * System Monitor --> opens KSysuard * KInfoCenter --> opens KInfoCenter which also has information about Memory and Energy usage * Run a command... --> lets the user enter a shell command * Kill a window by clicking on it (Ctrl+Alt+Esc) --> triggers the "xkill" feature (which is really a KWin feature and not the actuall shell command) or shows a message box if KWin is not available. What do you think? - Gregor ----------------------------------------------------------- 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 > >
