Microsoft-ui-xaml: CalendarView: Bad rendering for first-day-of-month buttons

[RBrid]

CalendarView shows first-day-of-month buttons with overlapping month and day captions.

1. Run the MUXControlsTestApp
2. Click its CalendarView button

Result:

Expected:
Month and day captions should not overlap.

Seen on 19H1 Desktop.

The additional month captions come from the setting IsGroupLabelVisible="True" in the page's XAML markup.

[jevansaks]

@kikisaints This has been the rendering for a while now, are there comps for how it should look where the text isn't overlapping?

[mdtauk]

I agree it looks bad, but it seems to be by design...

@jevansaks @kikisaints

[kikisaints]

@mdtauk I think so some degree it is by design, but it should be addressed. Legibility is important and this definitely rides the line.

I spoke to our design team a while ago about this and we ran into... issues that prevented us from finalizing it at the time.

Here were some of the solutions we cam up with at the time:

Label on the side

Pros:

• Clean
• Large text, so easier to read

Cons:

• Insets first item, but not the rest, could be difficult to do as a quick fix

Label in corner

Pros:

• Clean
• All items are homogeneous, making it easier to quick fix

Cons:

• If the developer enabled this, all day items would go from center aligned to offset suddenly, could be an undesired effect in some situations

Thoughts?

[mdtauk]

I am glad the team is willing to address this. I think this other feature needs to be tested with these control changes.

CalendarViewDayItem

[kikisaints]

Good point! They do need to work well with the density colors. I feel that kind of rules out the side label option.

[mdtauk]

Personally I think the Item backgrounds do a good enough job highlighting the current Month scope, but the feature is there, and should be designed well. On the plus side, only boxes with a Number 1 will display the month, so there is room to work with. I wonder if smaller text in a lighter colour would look good?

Or something like this:

[adrientetar]

Why is the label even needed, since the month is displayed at the top?

[kikisaints]

@adrientetar The month label at the top shows the current month, the labels in the days show which month is starting when a different month is in scope.

@mdtauk I like your designs, but a sticking point was offsetting the "1" on only one CalendarViewDayItem. All the items are created at once, homogeneously. So offsetting one would mean offsetting all the others.

I like the grayed out look, but it would need to meet the accessibility contrast ratio bar when over gray, which I don't think it would in the out of scope scenario you have above.

Sideways is interesting, but when we explored that a while ago we agreed it was a bit too difficult to read. Although cool looking.

[mdtauk]

@kikisaints Couldn't a Template Selector be employed to isolate the 1st day box?

There are resources for 20% Base colour, and 40% - the latter being a bit too strong, where 30% may work better.

I decided to try the text Sideways not to look cool, but solve the problem. The Month text, in All Caps, is shorter than it is wide. Having it to the side of the narrow number 1 digit, gives more space, so the box feels less cramped.

---

Offsetting was done before, on Windows Phone.

[shaheedmalik]

Personally I think the Item backgrounds do a good enough job highlighting the current Month scope, but the feature is there, and should be designed well. On the plus side, only boxes with a Number 1 will display the month, so there is room to work with. I wonder if smaller text in a lighter colour would look good?

Or something like this:

This one looks the best to me. It's very legible. I would just not make that single digit offset.

Like this:

Sideways is interesting, but when we explored that a while ago we agreed it was a bit too difficult to read. Although cool looking.

@kikisaints In regard to the sideways letters, they are only used as markers for the next month. They are supplementing the month listed at the stop of the screen.

[marb2000]

Some background history about this Calendar.

This Calendar was designed within the Office team to resolve all the scenarios of Calendar and Mobile Outlook a long time ago. For this timeframe, there were some scenarios that required no to have alternative background colors for the months. So the label of the first of the month was required.

About the first of the month label overlapping day number. It wasn't the original design. I believe it worked well in 10240 (TH1) version was working well. Perhaps some Text updates on the entire platform caused it at some point.

[mdtauk]

How often are these control designs audited and re-evaluate? Also how would a control handle the deprecation of a property or feature, if it no longer feels appropriate.

I am not saying this "First Day of the Month" feature should go, as it can be made to work. But if making that change needs a re-think in how the control works. The whole thing about not being able to target the first day control separate from the others - that could be re-engineered with the right resources.

But if the Office Team needed new things from an existing control, to avoid them going their own way with a custom control, how would their needs be folded into existing controls?

[kikisaints]

@mdtauk - designs are re-evaluated by PMs, but less often by the design team unless we find an error with the original design, or it becomes broken. Like this case.

As far as us ensuring we can fold in new requests into controls (like the Office team example you've given) it actually had more to do with our turnaround time rather than our iteration on the feature/control itself. This is one of the many reasons we chose to go open source - easier and faster for internal and external partners to consume our changes.

[mdtauk]

@mdtauk - designs are re-evaluated by PMs, but less often by the design team unless we find an error with the original design, or it becomes broken. Like this case.

As far as us ensuring we can fold in new requests into controls (like the Office team example you've given) it actually had more to do with our turnaround time rather than our iteration on the feature/control itself. This is one of the many reasons we chose to go open source - easier and faster for internal and external partners to consume our changes.

Ok so making a change to the way the control's template works, to allow the changes you want to make, _can_ be done?