luebking wrote:about speed and mouse users: there's hopefully wheel support?

No, but good point.

For me new 1 is the clear winner.

new 1 wins because:
It sacrifices "clarity" for ease of use this is basically a fitts law issue it is far easier to mouse travel across a handful of pixels than to shoot to the other side of the widget which has no edge to stop the mouse. The clarity we would lose here it probably below marginal when compared to the usage pattern being better. How would to like it if in your web browser the back and forward arrows were on their respective side. You would at best call the design "ill-conceived" and that would be with an edge to help you stop on the correct spot.

It fits with the other widget designs. It's "unbalanced" look isn't its weakness, it is the strength of consistent and thoughtful styling.

By those measures, the arrows should be on the left (ie. attached to) the month label, but Fitt's law only applies for the case where you actually want to quickly change forth/back (when you just want to use one button once, it's actually getting worse) and in this case (and actually in general):
like the forth/back buttons on scrollbars and unlike the buttons in a browser i'd consider the entire arrow navigation suboptimal since you got that big fat label to use for either wheeling or dragging ("flicking") so

[i]me[i/] would just show them as mere indicators when hovering / touching the month label.

- A touch interface would then allow "flicking" the label, while
- a desktop interface would allow to
a) wheel (no mouse movement) and
b) open a selection box on click - for both is MUCH faster on direction/mass changes than clicking buttons. Only as "weird" addition the
c) buttons would also be available as click interface.

Since fading in the arrows on hover/touch won't work left aligned and i would not set them a block away from the label, me would go for the latter.

Please notice: "me". It's actually rather important to fit the general behavior of elements.

vHanda,

I wasn't suggesting that we all follow down the 'lets make it a touch interface' route like everyone else seems to be doing, just that the layout of the arrows in #2 to me just looks right & it doesn't seem like there are any huge objections to it other than 'i prefer #1'.

If #2 was chosen then that would suit mouse users, but help to include the tiny minority of users who have to (or choose to) use a graphics tablet - why on earth wouldn't you pick the option that includes everyone? I get RSI & have to use the wacom when it flares up, having to make the fine 'tap-tap-tap's with it to scroll through the months isn't ideal with the little arrows anyway but in #1 if i veer slightly off target i'll end up going in the opposite direction & that would be a bit of a pain - that's all, no hidden 'touch' agenda!

luebking wrote:By those measures, the arrows should be on the left (ie. attached to) the month label, but Fitt's law only applies for the case where you actually want to quickly change forth/back (when you just want to use one button once, it's actually getting worse) and in this case (and actually in general):
like the forth/back buttons on scrollbars and unlike the buttons in a browser i'd consider the entire arrow navigation suboptimal since you got that big fat label to use for either wheeling or dragging ("flicking") so

[i]me[i/] would just show them as mere indicators when hovering / touching the month label.

- A touch interface would then allow "flicking" the label, while
- a desktop interface would allow to
a) wheel (no mouse movement) and
b) open a selection box on click - for both is MUCH faster on direction/mass changes than clicking buttons. Only as "weird" addition the
c) buttons would also be available as click interface.

Since fading in the arrows on hover/touch won't work left aligned and i would not set them a block away from the label, me would go for the latter.

Please notice: "me". It's actually rather important to fit the general behavior of elements.

Interestingly, the Plasma 4.X Plasmoid had all that (except fading arrow buttons). It has worked very well for me, I don't even know why it was changed in Plasma 5.

ken300 wrote:having to make the fine 'tap-tap-tap's with it to scroll through the months isn't ideal with the little arrows anyway but in #1 if i veer slightly off target i'll end up going in the opposite direction & that would be a bit of a pain - that's all, no hidden 'touch' agenda!

There's nothing easier than just making the arrows bigger and/or more apart from each other and/or giving them bigger hit box

colomar wrote:Interestingly, the Plasma 4.X Plasmoid had all that (except fading arrow buttons). It has worked very well for me, I don't even know why it was changed in Plasma 5.

The plasmoid was rewritten from scratch, following completely different styling guide that is consistent across applets, something that kde4 never had. Popup menu when clicking the month name is already there, mouse scroll not yet (and honestly I never even knew that was possible at all).

vHanda wrote:I would prefer (1) ... [because of] ... More consistent with the rest of the applets

Shouldn't the applets follow generic controls? KDatePicker has rulers aligned to the left and right.

I don't think it should, in this case at least anyway; imo preserving consistency among applets is more important than preserving consistency between one applet and one widget.

On a personal note, I think that the KDatePicker looks horribly bloated, it's like 5 swiss army knife stucked into one while all you actually want is butter knife (but that's just me, not really relevant to this).

I vote for "New 2", because it makes it obvious that the arrows change the month. In "New 1" it's not apparent how one goes about changing the month from a quick glance (there's nothing indicating that the arrows are connect to the month).

I don't agree that the title has to be left aligned to be consistent with the system tray applets. Those applets have a static title, such as "Battery and Brightness". The month name element isn't the same, it's not a title, and you can even interact with it (click and hopefully scroll in the future). If you want to be consistent you would put something like "Calendar" on the top-left, but that's pretty redundant in my opinion; not every widget needs a title, for example, Kickoff doesn't say "Application Launcher". It's mostly the system tray applets that have titles.

Slightly off topic: Personally I also hope to see the year next to the month, like the current calendar, as well as the possibility to show the week numbers.

+1 for having the year with the month - that's a good idea. Maybe centred below the month or something, just have it in there somewhere

New 2 seems like the better option for me.
1 - More clear separation between the two arrows, therefore less chance of a misclick in wrong arrow in smaller screens or touch PCs,
2 - Symmetric - easier to understand what the arrows refer to.

I'm not too fond of adding the *current* year to the title. The year appears if you scroll out of the current year (so you'd see "January, 2015"), but for the current year...personally I feel it's a bit useless info, kinda like having AM/PM with 24h clock.

prosmaninho wrote:New 2 seems like the better option for me.
1 - More clear separation between the two arrows, therefore less chance of a misclick in wrong arrow in smaller screens or touch PCs,

For about 50th time, the arrows can be made bigger and more apart from themselves, please don't use this as a reason against it.

There is no clear winner here. Both variants have their advantages and disadvantages, but none would be problematic.

Luebking's idea to show the arrows only on hover would work as well, but since I don't see the arrows as very distracting, I'd vote pro clarity and keep them always visible.

We all agree that both New 1 and New 2 are clearly better than the current situation, so whatever you choose, you'll be fine.
Adding a dropdown on click of the name (like in the 4.X version) plus changing the month via mousewheel would be useful additions for quicker navigation to any version.