Reply to topic

Default Oxygen window control icons are illogical

-3

Votes
3
6
paulm
Registered Member
Posts
23
Karma
0
OS
The default window control icons that were introduced in the Oxygen theme with KDE 4 are illogical and seem like being different from MS Windows just for the sake of being different:

Image

Alex Faaborg (a former user experience designer on Firefox and now on Android) described what I am talking about in his section here on Designing Better Window Controls:
http://blog.mozilla.org/faaborg/2010/04 ... -personas/

He uses Ubuntu's old style as an example, but this is also relevant to the KDE Oxygen style:
Image

"The new Ubuntu controls say more to the user than OS X, but they don’t fare particularly well in being self describing either, visually they seem to communicate that one control will move the window upwards, and another control will move the window downwards, sort of like a scroll bar. They don’t communicate that the window will be transformed. The visual communication used in Windows is considerably more literal, choices include “big box” and “small thing at bottom.”


Therefore, should KDE by default not be implementing a logical "self-describing visual language" and therefore revert the default window control icons back to being like those on MS Windows? Being similar to classic MS Windows is no bad thing, especially given that the user base that KDE and Linux will be wanting to attract will mostly be coming from a Windows background, and even more so given the opportunity to attract such users with the mess that Microsoft has made with Windows 8. Linux users also don't remind me of the type who value form over function.
luebking
Registered Member
Posts
917
Karma
7
Image

Long story short: that's called "habits" or rather "conditioning" - not "logic".

MS introduced the current look to sell their back then newly introduced taskbar. It makes sense in that context, otherwise not at all (the green marble btw. does NOT maximize a window, stupid windows disease)

Now, ubuntu has a win95 similar look, but with a dash instead of the underline - yet their "taskbar" is on the left, so it should have been a left-aligned I-Beam, yesno?
-> they do it for the sake of making it simple for windows users, not logical reasoning.

The look of Oxygen icons is however not for the sake of being different. Triangles were used this way on various systems before many today users were even born.
A different approach (in CDE) was eg. a big and a small square (or dot) because there was no taskbar and windows got iconified (the ICCCM spec still speaks of iconification when you think "taskbar")

The plasma desktop is not limited to the windows layout (taskbar on bottom) at all, while one may argue that many ppl. use it, so whether or not one "should" use the win95+ look (by default) merely boils down to the question "how much are my users brainless lemmings" - logic isn't involved here.
User avatar Fri13
Registered Member
Posts
363
Karma
4
OS

Fri Jan 25, 2013 9:40 am
paulm wrote:Therefore, should KDE by default not be implementing a logical "self-describing visual language" and therefore revert the default window control icons back to being like those on MS Windows? Being similar to classic MS Windows is no bad thing, especially given that the user base that KDE and Linux will be wanting to attract will mostly be coming from a Windows background, and even more so given the opportunity to attract such users with the mess that Microsoft has made with Windows 8. Linux users also don't remind me of the type who value form over function.


The WIndows _ [] X setup doesn't make sense for user who has not used Windows earlier. And even after few times using those controls, avarage users don't even get why it is a "square" and "underline".

The arrows actually works way better, where user can right away understand that the arrow down means down, arrow up means up and cross to close. Once they see the effect, they do remember it easily because "I want this window to big" so they get the simple understanding
"I need to make this window bigger than it is now".
"I want to make this window to disappear but not to be closed"
"I want to close this window".

KWin as well offers multiple other features with those window controls.
Examples:

Right click the "grow" button and the window grows horizontally to maximal size.
Middle click (wheel button) "grow" button and the window grows vertically to maximal size.

The arrow has meanings "bigger" instead just "up". The square what Microsoft use isn't logical at all, as it just is "square" and windows already are square ones. It doesn't tell at all that user wants it to fill full display as logic that square would mean "Full display" isn't logical, just habit as users do separate display (the physical device) and window (software presentation of content) and they think "I want this content to be bigger".

The idea of Windows buttons doesn't actually work so well, as it demands user to think display and content together. With arrows (or color coding) user only needs to think the content itself. Meaning they think "I want this content to be bigger" instead "I want this content to be shown in full display presentation mode".

And Windows maximize button icon change dramatically once window is maximized. Two squares doesn't say user anything. They don't get why did it change its shape to two now. Instead them to think just that content, they need to think all other contents as well because there is two square and they fail in it because there is just one content visible.
In KDE feature the "bigger" buttons changes to diamond shaped that shows "restore".

The one big difference with OS X and Windows window controls are that Windows doesn't care about window content like OS X does.
Color coding is great (expect those who are totally color blind but they get the small icons in them when hovering and learn them quickly, and they can change colors if wanted) as red means "DANGER" like in nature. Yellow is "WARNING" and Green is "Go" or otherwise neutral / accepting color.
And when you click green button in OS X, the window will scale up depending the window content. It doesn't grow window bigger than it needs or it can. Meaning example WWW browser will scale up to web page width, instead wider where it would show lots of empty space around site itself. Thats why Apple implemented "Full Screen" feature that needs special functions from application itself and turn itself to special mode for that case.

KDE does fill same classification like what Windows does, KWin doesnt care about window content but thats why there are those special functions with left click middle click, what OS X or Windows doesn't have.
paulm
Registered Member
Posts
23
Karma
0
OS
Interesting that leubking posts a Windows 3.1 screenshot. Coming from a background on Atari ST GEM and early MacOS, I remember the first time I used Windows 3.1 20 years ago and could never understand why you would use the same icon for scrolling up and down as for making a window bigger and smaller -- I found it logically irritating right from the start. Why on earth should the same icon mean two completely different things; surely instead we should strive for logical clarity, especially when no other major window manager uses arrows in this manner today? It doesn't make sense to me that KDE would also adopt by default the Windows 95 style in KDE3 only to change to a less clear semi-Windows 3 style on KDE4.

Yes leubking, you have a point about Ubuntu's taskbar being on the left by default and their use of a "_" bar for minimise, but I gave up on logic and the Ubuntu UI designers a long time ago (hence why I'm posting here and not some Ubuntu forum!!). I don't see the argument that the taskbar can be moved as one that supports the illogical up/down arrows of Oxygen either (if your taskbar is at the top then you might also expect the "up" arrow to minimise!). If there is an issue with using the same bar icon with differing taskbar positions, then you could dynamically adjust the minimise bar icon so that it relates to the taskbar position. Even simpler, use the old CDE-style small square for minimise smaller and large square for maximise bigger -- these communicate a much clearer a transforming of a window to small or big than arrows do IMO.

Fri13, I think the Windows 2-square restore button also communicates effectively that it converts it into a floating window rather than fixed full screen in a better manner than the KDE diamond (though at least the diamond isn't used for anything else).
User avatar Fri13
Registered Member
Posts
363
Karma
4
OS
paulm wrote:Fri13, I think the Windows 2-square restore button also communicates effectively that it converts it into a floating window rather than fixed full screen in a better manner than the KDE diamond (though at least the diamond isn't used for anything else).


Yes it does follow (like I said) the logic but problem is that the icon means window is tied to display instead just to window itself like with arrows.
One of the best ones what I ever have seen although are four arrows pointing outside or inside depending the window position.
Minimization was a flat line bottom and arrow pointing directly from top to that line.
I don't anymore remember on what window manager or theme for what window manager implemented it but it was one of the Unix GUIs as far I remember.
But its problem was that it worked on 640x480 displays where it was big, today it would need to be smaller and it is too complex.

Still the logic in that the minimize button should present the location of panel where window gets minimized if clicking it doesn't work by my opinion. As then again we are in situation where user needs to think the content + environment, instead just the content.
Still it is the same wrong visual aid as with the oven knobs what the original poster links gave as "example of great design", as everyone should know, if the oven has 3-4 cookers, then knobs are not presenting any logic in their order and user is forced to check the markings in knobs what belongs to what cooker (mentioned in the link comments). If oven has just 2 cookers, then the logic works as long they are in same order (horizontal).

But then again example "B II" style gives two squares, one small and one big. Again they are as illogical what they do as is Windows button for maximization and underline.

I would drop the idea that minimize button needs to point interactively to location where window gets minimized as it is again window + environment instead the content itself.
There are many things what we could do but all works differently on different situations and none of them would be a perfect one. Thats why it is great we have settings so every user can set wanted options what works for them.

Example my settings usually are that top right corner to maximize window, closing a window happens by double clicking the decoration , mouse wheel shade/unshade window and meta+wheel sets window under others, default or top of others.

And then some people ask how do they minimize window as there is no such button?
Well... I follow the simple iron logic what is the task panel. There is the window in the first place located and there it gets minimized if somewhere. So to get window minimized, click the window task in taskbar. If window isn't active, you need to click two times.

Every time when user minimize window by doing this, it is easier to remember that it has been minimized there and user search it from there. There is no typical Windows problem "Where did the window go?" what causes users to launch application second time.

But it isn't actually so logical for most people as they see window as content and they think anything else outside of that window, like taskbar or display itself. They just typically think the "content" what is the window. What is reason why windows maximization button as big square and then as double square for restoring window size doesn't actually work.

There are gestures what can help some people like drag window top edge of display and it gets maximized, drag it down and it gets restored. But again peoples minds doesn't link that functionality as it isn't logical. That can be learned and then it might come as habit and expected functionality. Like difference of what should happen when user drags window to edge of screen? Should window get moved to another virtual desktop or should it take 50% of screen space? Should something else happen like window to be closed or even minimized? Gestures are not logical what is one big problem with today touch screen GUIs like Windows 8. Once you learn them, they can be effective but it is about how easily you learn them. So giving a tutorial at begin is huge help.

I would argue that KDE needs a tutorial for user at first time login. What explains how to close, minimize, maximize, move, resize window and many other things like application menu, notifications, taskbar etc.
As once gone trough a simple 10-30 second tutorial (6-9 slides) what gives all basics, it is way easier for user.
Microsoft has huge advantage here as they have single GUI and they can make the tutorial of gestures for Windows 8 Modern UI in Windows 8 installation process.
KDE can not use distribution installation time nor distributors can not focus just for one GUI if they ship with multiple ones or user install multiple one.



Oh, and one greatest things what actually help user to know where did the window get minimized, is the window manager animations. Many say "bling bling" but when user clicks minimize (or maximize) and 700ms animation shows it where it did go, it is very clear.
I would even argue on that point being that first time minimization the animation should be 2 second lasting as "presentation" and then being default 250ms.

ps. I would love to see window decoration what use text on buttons instead icons on buttons. It would work on many languages as well. So instead "X" for closing, the button really would be labeled as "Close".
paulm
Registered Member
Posts
23
Karma
0
OS
Another anecdote from my novice Windows 3 days: I remember repeatedly clicking the wrong button when I had a maximized window, always clicking "minimize" rather than "restore". To me, this is just another perfect example of why a down-arrow to mean "make smaller" isn't as clear as it could be, as with a maximized Window you actually have two options to "make smaller": you can either make the window smaller (which ISN'T the down arrow, but a diamond in KDE) or hide the window entirely (which is confusingly the down-arrow).
infoholico
Registered Member
Posts
1
Karma
0
Yes, they are Illogical, I don't like them, but I like the three colors OSX controls, and these are what I'm using right now.
pedroworcel
Registered Member
Posts
6
Karma
0
Also, take into account the following:

- The down arrow takes the window into the task bar, ergo down.
- If you drag the window unto the top of the screen it maximizes. The up arrow could be referring that behaviour.

not sure about the
/\
\/

sign to minimize though.

In my opinion the up and down arrows so far away from the screen do not suggest the user that the window is going to scroll whatsoever, after all it's waay out there in the chrome.

My 2c s an epic noob.

PS: These, in my view, are the clearest symbols invented so far, albeit not pretty. I like them because they catch your eye, even in the background:

Image
User avatar [Moviuro]
Registered Member
Posts
86
Karma
0
OS
I believe everyone who uses a computer for more than the first three times will understand that the main features provided by the title bar's buttons are: "clos, minimize and maximize/restore" (unles you were raised in a parallel universe).

The cross is explicit enough and as for the two other buttons, I believe everybody can infere from their more or less understandable form what they stand for.

Also, as shown in the screenshots, KDE's buttons are in the same place than M$'s evil W's ones.

Let's not make KWin look like some bad stuff... BTW a good idea could be to let the user chose which icon for which action? (eg plain, diamond, \/, /\ or whatever)


KDE 4.10.1 Archlinux x86_64 on both laptops :)
"Our life is the immortals' death"
molecule-eye
Registered Member
Posts
277
Karma
0
OS
I don't see that any *icon* is going to indicate max/min in the way suggested, save for having the words 'maximize' and 'minimize' embedded in the icon itself. Windows's icons surely don't do it any better than Oxygen's. Notice that on mouse hover-over, you receive a "max/min" tooltip anyway, and that 'x' pretty clearly indicates close. The default position of the only panel is at the bottom, so '\/' seems like a pretty good indication of minimize, leaving maximize the only thing left. Of course, users may move their panel, but if they have enough prowess to do so, they likely aren't concerned whether max/min could be more intuitively displayed to them, given the non-default location of their panel.

I also think that Oxygen's max/min/close buttons are stylistically nice, so there's another reason not to change them to the uglier Windows counterparts.
User avatar Fri13
Registered Member
Posts
363
Karma
4
OS

Wed Apr 24, 2013 10:47 pm
Have you people tested what happens if you middle or right click maximize button on Windows or OS X? ;)

 
Reply to topic

Bookmarks



Who is online

Registered users: Andreas Mair, Baidu [Spider], Bing [Bot], capslock, einar, Exabot [Bot], Google [Bot], Hans, koriun, Majestic-12 [Bot], rainbowgoblin, raymondsarver, rulet111, tparrott, urgo, Uri_Herrera, Yahoo [Bot]