Hello,

in Plasma Next we have this little issue with the new calendar - the arrows that change month are currently in the weekdays row (see the image link below, the "Original").

The issue is that they are not visually aligned with anything, they can get over the text easily (their position depends on the overall plasmoid size) and with their current position it looks like they are changing the days/week, not the month.

So I came up with two simple new ideas - "New 1" and "New 2". There are mixed feelings about both (and the original too) in the Plasma team, so I'd like to ask for a design advice on where to place the month changing arrows. Some completely different idea would be great too

EDIT: Please ignore the arrows' pixel-inperfect alignment, it was done quickly just to demonstrate the idea These are mockups only! So if your argument is "no because it's too close together", I don't take that because the final code can put enough space in between, also the arrows can be made bigger etc.
http://i.imgur.com/wVzoyKs.png

What's wrong with "New 2"? That's how most calendar/date picker widgets I know (including the one in KOrganizer) do it, and it makes sense: You switch the month with buttons to the left and right of it.

"one arrow per side feels more symmetrical/balanced"

Yeah, New 2 is fine I think. The alignment of the arrows are slightly off, left to right, in that pic though.

Also, I can see in the "New 1" proposal, the desire for maintaining consistent title alignment with other applets. So I'd be quite happy with New 1 as well.

Both provide the proper functional locality for the arrows (near the month label as Thomas pointed out). Both designs are also used in other calendar designs successfully. But either of the proposals are far better than having the arrows where they are now. Hope this helps!

mck182 wrote:"one arrow per side feels more symmetrical/balanced"

That's what "New 2" does, right?
I agree with Andrew that both New 1 and New 2 would work, though.

I prefer New 1 as if you click one month too far, you can go back.

I'd expect the calendar works in the same way as others. And the KDatePicker is like #2 (with some more features).
http://techbase.kde.org/Projects/Usabil ... me_Pickers

I think I like #2 more. The downside is of course that it breaks the normal title alignment, but then, it's not a title like all the others which generally do not change i.e. are not dependant on the displayed content.
#1 looks nice too, doesn't break the title alignment and is faster to navigate, but IMHO it looks less balanced compared to #2 and #statusquo.

My vote would be for #2.

I often use a graphics tablet instead of a mouse and in #1 it would be all to easy to hit the wrong button when 'tapping' multiple times (it's tricky to tap in exactly the same spot time after time). It's not a big deal & it's not an issue when using a mouse but #2 looks like what i'd expect to see anyway (but with either one it's obvious what the arrows do - that's the important thing).

So I take it as "VDG recommends #2" alright?

Any completely different ideas for this?

I would prefer (1) instead of (2).

a. Moving across months is easier
b. More consistent with the rest of the applets

(b) is quite important because all the main plasmoids (wifi, battery, notifications, device notifier) all align the text to the left. We don't want one plasmoid to stand out.

ken300 wrote:My vote would be for #2.

I often use a graphics tablet instead of a mouse and in #1 it would be all to easy to hit the wrong button when 'tapping' multiple times (it's tricky to tap in exactly the same spot time after time). It's not a big deal & it's not an issue when using a mouse but #2 looks like what i'd expect to see anyway (but with either one it's obvious what the arrows do - that's the important thing).

I'm not sure we should be taking "touch friendliness" into consideration. We are primarily designing all of this for the desktop right now.

New #2 is definitely better. Looks more symmetrical (= better) and accidentally hitting wrong button is completely out of possibility. My screen on X220 is just 12" and it really makes some UI elements make me squint my eyes and hard to hit already. I'd take few millimetres more mouse movement over having to micronavigate between two small buttons so close to each other. Besides, when opening the calendar, movement from there to both buttons is about the same.

#2 - it's more obvious what the arrows do.
about speed and mouse users: there's hopefully wheel support?

Everyone please keep in mind the screenshot are mockups to present the idea, not the final pixel-perfect solution. So if your argument is "no because it's too close together", I don't take that because the final code can put enough space in between, also the arrows can be made bigger etc.

daedaluz wrote:New #2 is definitely better.
<...>
Besides, when opening the calendar, movement from there to both buttons is about the same.

Well that's just not true, you can even see that from the screenshot Roughly same distance is the #1.