[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Ctrl-Q vs. Ctrl-W vs. Alt-F4
From:       Maciej Pilichowski <bluedzins () wp ! pl>
Date:       2009-01-12 13:07:07
Message-ID: 200901121407.07564.bluedzins () wp ! pl
[Download RAW message or body]

On Monday 12 January 2009 10:57:10 Markus wrote:

> Closing an app is no harm, because no data is lost (if there is a
> chance of losing data, the "Save document?" dialog pops up) and
> nobody runs apps from slow floppy drives.

Accidental quitting is -- time. You can buy anything, powerful CPU, 
huge HDD, you cannot buy time.

> Why do you think that closing a Dolphin window with Ctrl-W is more
> harmful than closing a tab with Ctrl-W?

Because one is intentional, the other is not.

> > What is your aim -- close the app? So close the app. How hard is
> > that?
> My aim is consistency. Your's is not. 

It is -- within KDE. 

> > KDE is (unfortunately) very fragile environment, and users
> > already don't feel safe there, I don't want to see another excuse
> > "you have to be careful...".
>
> Nobody has to be careful on that one. Those shortcuts work
> everywhere else, too.

Everybody has to -- it is an effect of a button that if you push hard 
enough it eventually will break. I don't want to see that in KDE.

> > There is nothing broken with ctrl+q or similar,
> It is and I showed it in my initial mail.
> How would you quit Amarok with a shortcut when, by your logic,
> Ctrl-Q should only close windows, not quit apps?

If you want to close an app, press ctrl+q, if you want to close app 
window, press alt+f4. With non-resident application those are the 
same.

> > Quality, not quantity.
> Consistency is quality.

Consistently broken UI is no longer quality UI.

> So, a Dolphin tab is no document. 

There is the same metaphor because there was/is no need to treat 
documents and tabs differently. Document is data entity, tab is just 
a way to present the data (document).

> By your logic Ctrl-W should never 
> be used to close it....

Tab/doc? Nope. HIG is 100% clear on that.

> Is a Kopete chat window a document? What's the difference between a
> document and other windows? 

I don't use Kopete.

> > > and
> > > used by many apps, like Kopete and KMail.
> >
> > I don't use Kopete, for KMail it is not true.
>
> Of course it is. Read my initial mail (or look at the attached
> screenshot) instead of spreading lies.

Watch your language.

If you found something that violates HIG, post a report. And I believe 
this screenshot is not from KMail but from detached window of 
Composer, so you forgot to mention this. This is quite another story 
if detached documents are still documents or windows/applications on 
their own. I say the first, because otherwise you would have to use 
different shortcuts each time you detach/dock the window.

> > All other browser have flawed UI
>
> Wow, you are really arrogant.
> My initial mail show how inconsistent KDE apps behave. 

If you found something that violate HIG, post a report. However it is 
absurd to say HIG is bad because some app misbehaves.

> Instead of 
> working to improve the situation you just take the stance that
> everything is perfect in KDE land and everybody else is doing
> wrong.

Nope. I am all for making apps follow the HIG. I am against changing 
HIG in direction you propose.

> Newsflash: KDE is in no dominant position to dictate over others.

I don't care. My intention is to have absolutely great KDE. If XYZ 
wants to have broken UI, well, not my business really.


Now, about flawed UI. Actions should be simple, easy to understand, 
without too much doctrine, or metaphors.

Current HIG (intention -> action):
---------------------------------
open doc -> open doc. always

close doc -> close doc. always

open doc, close doc -> open doc, close doc. always

close doc, open doc -> close doc, open doc. always

Your proposal HIG ("close the app with the last tab"):
-----------------------------------------------------
open doc -> open doc. always

close doc -> sometimes close doc. sometimes impossible to do

open doc, close doc -> sometimes open doc, close doc. sometimes 
impossible to do

close doc, open doc -> in some cases close doc, open doc. In others 
open doc first, then switch, then close the doc. Or "just" quit 
application, launch it again, and then open the doc.


There are only three cases here:
a) current HIG is easier to grasp
b) they are equally easy
c) your proposal is easier to understand

Now, which takes longer to explain the user why there are so many 
limitations, and why the application is not as flexible as before (in 
case of not (a)).

And one more limitation of your proposal -- none app can have empty 
state (like opera) without any tabs/docs opened.
And strange effect -- you cannot have clear doc state (one empty doc) 
when you are finishing your work, but you can when you are just 
beginning? Why such asymmetry?

If you know any counter-examples (of _HIG_, not apps) I would be glad 
to hear about them (not irony).

I won't be convinced by number-arguments "Windows uses this..., and 
they are majority", sorry.

Cheers,
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]