This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Design Request: a new Present Windows and Desktop Grid

Tags: None
(comma "," separated)
User avatar
alake
Registered Member
Posts
591
Karma
3
OS
colomar wrote:@Andrew: Would it be possible in the "All Desktops" view to drag windows between desktops? I think this is a very nice feature which would make moving windows between desktops a lot easier than via the Pager Plasmoid.


Yes, that would be the intent, just like Desktop Grid already does today. :-)
User avatar
ken300
Registered Member
Posts
314
Karma
0
Just a thought:

If there's going to be a 'Type to filter ....' thing (that's at the top of the 'All windows' screen - fantastic mockups by the way), then that could have an impact on what's being planned for DWD. We'd have to make sure that even with the DWD controls displayed in the title bar, the window's actual title was prominent enough so that it's obvious what you need to type to filter that window - that's particularly relevant when you've got several instances of the same application that all look the same.

Any text that DWD adds into the title bar shouldn't make it less obvious what that window's title is. A rethink of what goes into the window title itself (to make it as simple as possible whilst still being meaningful) might be good too - instead of displaying full paths, they could be abbreviated to file & app names (eg. Kwrite displays full paths, Dolphin displays just the single folder & app name) + don't put any unnecessary text in the window title (Gwenview puts the zoom % in there - nice to know but is that the best place for it?).
User avatar
hook
Registered Member
Posts
205
Karma
0
OS
alake wrote:Here is a design I've put together:





This looks very much like how I I use KDE 4 nowadays.

The “alt-tabbing” I exchanged for the “all windows” in VD and the only other effect I use now is the “grid view” of all the VDs in the Activity.

All that’s missing for me now is a better Activity switcher and associating windows through Activities. One problem is that a window cannot be on a different VD in different Activities.

A few thoughts:
  • To keep things from becoming too cluttered I divided up the workflow to help satisfy the Simple By Default - Make it easy to focus on what matters design principle. I tried multiple designs to put all of the possible workflows into one layout and it always ended up much too cluttered. So...
    • All Desktops is where the user can see all teh desktops, switch desktops, add/remove a desktop, move windows between desktops and switch directly to a window on another desktop - desktop stuff.
    • All Windows and Windows on [Desktop] is where the user can select/switch to a window, close windows, filter windows by typing - window stuff.
    • It's probably already obvious but, for completeness, All Windows shows windows across all desktops. Windows on [Desktop] shows the windows on the desktop named [Desktop].


+9000 ! :D


It's time to prod some serious buttock! ;)
User avatar
daedaluz
Registered Member
Posts
85
Karma
0
OS
alake wrote:Here is a design I've put together:

In all it is not a drastic redesign. After several days studying this, my own conclusion is that there are enough elements that the current design gets right that I couldn't justify a completely different approach, at least to myself. One thing that might be nice is a simple panel plasmoid to trigger one of the three modes - All Desktops, All Windows, or Windows on [Desktop] - when clicked.

Hope this helps! :-)


Yes, I think this is the correct approach. I love this! Echoes nicely with Plasma 5 in general being not too different from KDE4 series. It also addresses my all three (personal) grievances very nicely:
1) Workspace titles are not visible.
2) Border between different desktops is not easily distinguishable when using a dark background.
3) From window overlay view to desktops view and vice versa is impossible without returning to desktop currently.

From usability perspective, what I also would like to see are window close buttons in window overview always well visible as unfriendly red X's! I can't count the times I have accidentally closed a window I was hastily about to select. Same usability issue in GNOME overlay view. To augment that further, maybe provide red glow on windows when hovering over that close button.
planhths
Registered Member
Posts
9
Karma
0
Here is an update:
Image
https://share.kde.org/public.php?service=files&t=2551d1fa82210fd262a881f329bf952e

With panel hidden:
Image

Things that changed:
  • Desktop thumbnails are placed in an always hidden panel.
  • In selected desktop view, everything is centered to screen.
  • Below each window their is a big application icon and the title. (Could be tweaked in order to be more compact.)
  • If you hover over a window (in the mockup look at window A), it glows and a Close button is shown.

New ideas:
  • Window decorations are gone, they are not functional from the effect (you can't use their buttons and can't drag a window) and since they are zoomed out, it's difficult to read the title.
  • A pin button is used to pin the window to the current desktop, so you can drag and drop it to multiple others.
  • The desktop plasmoids are hidden from the main view too, since they are irrelevant.

Last edited by planhths on Sun Nov 09, 2014 8:32 pm, edited 2 times in total.
User avatar
anditosan
Registered Member
Posts
157
Karma
0
OS
I love the way that we are thinking about this idea so far. It seems that we are seriously looking to improve and devise new ways to interact with this effect and our open windows. My perception, and correct me if I am wrong, is that as we share ideas about how to handle windows across multiple desktops, our ideas become more complex. Our mockups start simple and then they get sprinkles on top that blur the initial simplicity of the design. For example, we went from this

Image

to this



Until Andrew came along and simplified the image to look much like it is now.

My suggestion is to take our UX design a little more critical and then start building an interface from it. Take all the elements that our team discusses and "then" build an interface around that. Get rid of current ideas and inspire yourself, not copy. You don't always have to be original in your ideas but the implementation of the suggestions needs to stick to a pattern. My personal idea is to always think in a reductionist approach. Once you turn a simple UI to one that has one too many features, you lose sight of its original purpose. Needless to say the amount of time that it would take to develop a more complex idea.

One cool approach you can take is by using real life objects to accomplish what you intend on the computer screen. See how hard/easy it would be to interact with objects at that level.
planhths
Registered Member
Posts
9
Karma
0
So I had an idea that the window decorations could be replaced by this tech: viewtopic.php?f=285&t=123480 so that their text is visible and the buttons clickable (only appearing in hover though).

Pro of this approach: Already known elements are used, so there is less confusion.
Con: The buttons are different than ones in the original decoration (minimize and maximize have no use in this effect).

There two versions, one with decorations
Image
https://share.kde.org/public.php?servic ... 7cd8ad2355

and the previous:
Image
luebking
Karma
0
ken300 wrote:If there's going to be a 'Type to filter ....' thing (that's at the top of the 'All windows' screen - fantastic mockups by the way), then that could have an impact on what's being planned for DWD. We'd have to make sure that even with the DWD controls displayed in the title bar, the window's actual title was prominent enough so that it's obvious what you need to type to filter that window


That's technically no problem - we can either filter for the DWD label or the app set caption string. And we can also display either (every detailed mockup here has label overlays) as well.
I'd likely go for displaying and filtering for the actual title rather than some DWD label. Former will usually provide more infromation and allow more fine grained search (eg. "kwrite")


ken300 wrote:A rethink of what goes into the window title itself (to make it as simple as possible whilst still being meaningful) might be good too - instead of displaying full paths, they could be abbreviated to file & app names (eg. Kwrite displays full paths, Dolphin displays just the single folder & app name) + don't put any unnecessary text in the window title (Gwenview puts the zoom % in there - nice to know but is that the best place for it?).


Kate/KWrite actually has an option on whether to display the full path.
Also you may try:
Code: Select all
kwriteconfig --file kwinrc --group Windows --key CondensedTitle true
User avatar
andreas_k
Registered Member
Posts
561
Karma
0
I like also the mockups from alake with the button separate toolbar with app icon, title text and the close button.

the only think I miss in alakes mockup are the desktop screenshots as planhths make. maybe you can interate one button sellect alls desktops and than you can select only one desktop or all desktops maybe with at + symbols select desktop 1 and 3.
apache
Registered Member
Posts
302
Karma
0
OS
I'm not in favour of the window title and icon below window. My eyesight is first directed on window but seems like I don't find the information I look for, which is recognizing what application is it, so I need to redirect eyesight below. Actually when I look at this mock-up it happens with every window. It feels very unnatural to me, it force me to do some additional search on the screen.

In my opinion title and icons should be in the window area and should be really big. How you recognize that this is the window you are looking for? I first look at icon, then on title. When previews are small because there are many of them it is hard to recognize window by its preview. That's why icon and title are a lot more important in the process of recognizing.

All this is very important when you work with application that have two, three or more windows. Then preview is practically useless.

Consider not only how beautiful it looks but also how your recognition process works.


I already wrote about it.
viewtopic.php?f=226&t=118058

Have a look at my old mock-up. Not very good, because I am not good at Gimp, but explains what I mean. And I should have made titles and icons bigger.

The way it is in KDE 4 is the reason I don't find it very useful.
User avatar
ken300
Registered Member
Posts
314
Karma
0
apache,

I agree about the icons being more central - when i've used Gnome shell the first extension that i installed was the 'Overlay icons' one that adds HUGE icons to the previews to make them instantly recognisable, here's a screenshot from Gnome's extension website:



From what i remember, the icons fade away when the mouse pointer hovers over them so that you can see the window preview contents which is a good idea
mgraesslin
KDE Developer
Posts
572
Karma
7
OS
concerning the huge icons presented in the comment above: on X11 we might not be able to present such large icons. Many application only provide icons of the size 32x32 or even smaller. It looks extremely ugly if we try to scale that. Hardly any application is offering icons larger than 128x128.
User avatar
andreas_k
Registered Member
Posts
561
Karma
0
my only problem with the actual desktop grid is that the text is across the app thumbnail and it is difficalt to recognize the thumbnail. At the desktop grid the app icon is nice to know but the feature of the grid is the thumbnail. the app icon is visible in the panel.
User avatar
hook
Registered Member
Posts
205
Karma
0
OS
I hope I’m not too annoying, but I’m quite excited to see this feature in Plasma 5 and was surprised that in the demo at FOSDEM it was not yet available.

…soooooo, what’s the status and is there an ETA or RoadMap for it? :excited_puppy_emoticon_we_desperately_need:


It's time to prod some serious buttock! ;)
User avatar
spleen
Registered Member
Posts
15
Karma
0
OS
Today i was thinking again on this...Is there any plain to merge exposè with a desktop view? (i know you devs are busy with more important stuff, just asking).

Otherwise, i could look at this myself...But i'd need some hints for that. First: is it possible with just a js based effect? Or should i go with a declarative one involving QML?
Or even C++ ?

Also, i'd need to know if there have been changes within kwin scripting API in case i can use either a javascript or QML.

Of course, i would first make a sketch. If i succeed we can discuss its details and design soon after :)




Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], kesang, Sogou [Bot], Yahoo [Bot]