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

Status & Notification behavior

Tags: None
(comma "," separated)
User avatar
notmart
KDE Developer
Posts
220
Karma
1
OS

Re: Status & Notification behavior

Fri Oct 24, 2014 2:03 pm
could be the sidebar simply never shown, and have instead a back button near the title?
User avatar
ken300
Registered Member
Posts
314
Karma
0

Re: Status & Notification behavior

Fri Oct 24, 2014 2:10 pm
notmart,

having thought about it, i agree with you - it's just a needless change! I didn't include it in the bug report, now if you could just pretend that i didn't suggest it (and don't tell anyone else), that would be good ;)
User avatar
notmart
KDE Developer
Posts
220
Karma
1
OS

Re: Status & Notification behavior

Fri Oct 24, 2014 3:30 pm
This is how it currently looks with the current review request:
Image

already not bad, it may require the title to be re-aligned tough, since with the current alignment looks better if the tabbar is present, at the moment there is probably too much space on top (while if it's moved more on the top would look worse when the side tabs are present).
also if there would be a back button as i suggested before it could make the tile look more balanced (maybe, perhaps, don't know ;)
kdeuserk
Registered Member
Posts
207
Karma
0

Re: Status & Notification behavior

Fri Oct 24, 2014 3:59 pm
notmart wrote:already not bad, it may require the title to be re-aligned tough, since with the current alignment looks better if the tabbar is present, at the moment there is probably too much space on top (while if it's moved more on the top would look worse when the side tabs are present).


I think the space on top is okay. I would additionally increase the space on the left. The current review request is imho a regression design wise since the space margin proportions are not right.
User avatar
colomar
Registered Member
Posts
947
Karma
2
OS

Re: Status & Notification behavior

Fri Oct 24, 2014 4:07 pm
Thank you David for implementing this change!

I agree with Marco that the expander should stay on the right, too.

And I also agree that the title position now looks a bit odd. I'm sure we'll find a way to improve that :)

notmart wrote:could be the sidebar simply never shown, and have instead a back button near the title?


Hm, could make sense, given that users are unlikely to have to switch between hidden icons very often (because if icons are used often, they should not be hidden anyway).
User avatar
notmart
KDE Developer
Posts
220
Karma
1
OS

Re: Status & Notification behavior

Fri Oct 24, 2014 4:41 pm
colomar wrote:
notmart wrote:could be the sidebar simply never shown, and have instead a back button near the title?


Hm, could make sense, given that users are unlikely to have to switch between hidden icons very often (because if icons are used often, they should not be hidden anyway).

that's a rough attempt
i still don't like it 100% but that's the idea
Image
Image
kdeuserk
Registered Member
Posts
207
Karma
0

Re: Status & Notification behavior

Fri Oct 24, 2014 5:03 pm
notmart wrote:i still don't like it 100% but that's the idea


I like that idea!
Design wise imho the margins (spacing) still need work (I know its a rough version). Imho the Title and everything under it should have the same indentation.
I do not find that button left to "Clipboard" necessary though, since we have the arrow (expander) in the systray anyway and it would kinda loose its purpose, if I understand your idea right.
Apart from that I would rename "Status & Notifications" here since it only covers inactive/hidden items, because the others are accessible in the systray above. The hidden/inactive message should certainly be delivered.

Did I outline my points in an understandable way? Do you want to see mockups?
User avatar
notmart
KDE Developer
Posts
220
Karma
1
OS

Re: Status & Notification behavior

Fri Oct 24, 2014 5:20 pm
kdeuserk wrote:I do not find that button left to "Clipboard" necessary though, since we have the arrow (expander) in the systray anyway and it would kinda loose its purpose, if I understand your idea right.


the arrow button already opens/closes the menu.
If it goes to the full list when an applet is open, it would have several functions depending from the state, so clicking on it would be less predictable/consistent...

Did I outline my points in an understandable way? Do you want to see mockups?

mockups are always pretty :p
User avatar
ken300
Registered Member
Posts
314
Karma
0

Re: Status & Notification behavior

Fri Oct 24, 2014 5:34 pm
Just a suggestion but what about this:


Please ignore the colour variations - it's all supposed to be a nice even gray - the joys of cut & pasting!

The basic idea is that you click on the 'Hidden icons' arrow in the System tray to display the list of hidden icons & the arrow in the tray flips to point down so that you can close the list by clicking it (exactly as it currently is).

If you click one of the hidden icons in the list to view it (Battery & Brightness in the mockup), then the 'Hidden icons' arrow in the tray rotates to become a click-able 'Back' arrow - click it to be taken back to the list of hidden icons in the centre image of the mockup entitled 'Status & Notifications'.

This would avoid the small issue that the layout for each System tray icon would have to look good for both the times when that icon is hidden, and so a back arrow will be needed, and the times when it isn't hidden, so a back button won't be needed.

One downside of this suggestion is that it would be less intuitive & discoverable to go back to the list of hidden icons if you didn't know how!
kdeuserk
Registered Member
Posts
207
Karma
0

Re: Status & Notification behavior

Fri Oct 24, 2014 5:35 pm
notmart wrote:the arrow button already opens/closes the menu.


Clicking again on the selected item / somewhere else is also intuitive, so I think this should not be the purpose of the expander.
colomar, what do you think?
kdeuserk
Registered Member
Posts
207
Karma
0

Re: Status & Notification behavior

Fri Oct 24, 2014 5:40 pm
ken300 wrote:Just a suggestion but what about this:


Really neat idea (and the spacing in the mockup is much better and you also indented things below the title, which is exactly what I wanted to see).
I wanted to suggest something similar (though I did not have the arrow flip idea).
I think no need for me to make another mockup, this is it imho.
User avatar
ken300
Registered Member
Posts
314
Karma
0

Re: Status & Notification behavior

Fri Oct 24, 2014 5:43 pm
kdeuserk said:
I would rename "Status & Notifications" here since it only covers inactive/hidden items


I agree with that
kdeuserk
Registered Member
Posts
207
Karma
0

Re: Status & Notification behavior

Fri Oct 24, 2014 7:03 pm
ken300 wrote:


Just for clarification how I understand this: when clicking the arrow in picture 3 you would return back to picture 2 (even when you clicked a few other active items), this is how it was meant Ken, right? So the "Back" button is static right? The "clickable arrow" part confused me a little, because it sounded like it should act like a button.

EDIT: And what to do when somebody directly clicked an item in the systray? Then the "back" arrow logic makes less sense, but it is still much better than the current situation and anything I could think of. So I'd say we should go for it.

EDIT 2: Another point I would like to add: In nomart's screenshot the whole systray area was underlined blue, but imho it should only be arrow or nothing. I see the logic of selecting the systray area together with the title "Staus & Notifications", but that really makes only sense when the panel is beneath the popup.
User avatar
colomar
Registered Member
Posts
947
Karma
2
OS

Re: Status & Notification behavior

Fri Oct 24, 2014 8:26 pm
ken300 wrote:If you click one of the hidden icons in the list to view it (Battery & Brightness in the mockup), then the 'Hidden icons' arrow in the tray rotates to become a click-able 'Back' arrow - click it to be taken back to the list of hidden icons in the centre image of the mockup entitled 'Status & Notifications'.

This would avoid the small issue that the layout for each System tray icon would have to look good for both the times when that icon is hidden, and so a back arrow will be needed, and the times when it isn't hidden, so a back button won't be needed.

One downside of this suggestion is that it would be less intuitive & discoverable to go back to the list of hidden icons if you didn't know how!


Hm, I'm not sure about this. It does make sense to have the layout of the popups of visible vs. hidden icons the same, but I see two downsides of repurposing the expander as the back button
a) Users may fail to notice that the function of the expander has changed (I guess this is the downside you mentioned
b) It takes two clicks on the expander to close the popup altogether

Maybe we should put the "back" button in the popup after all, but come up with a layout that allows us to show or hide the back button without influencing the rest?
kdeuserk
Registered Member
Posts
207
Karma
0

Re: Status & Notification behavior

Fri Oct 24, 2014 8:36 pm
colomar wrote:Hm, I'm not sure about this. It does make sense to have the layout of the popups of visible vs. hidden icons the same, but I see two downsides of repurposing the expander as the back button
a) Users may fail to notice that the function of the expander has changed (I guess this is the downside you mentioned
b) It takes two clicks on the expander to close the popup altogether

Maybe we should put the "back" button in the popup after all, but come up with a layout that allows us to show or hide the back button without influencing the rest?


Do we really need that expand button for closing the popup? It's quite useless imho, since clicking on the selected object again should undo the selection. Keep in mind: The "expander" was in the 4.X series only intended to show/hide hidden items.
We could also simplify the 3 state arrow logic: only keep two states: show inactive items & do not show inactive items.


Bookmarks



Who is online

Registered users: Bing [Bot], daret, Google [Bot], Sogou [Bot]