GNOME Bugzilla – Bug 789855
Month view is hard to read
Last modified: 2017-11-24 22:44:42 UTC
Created attachment 362894 [details] mockup I currently find the month view quite difficult to read. It feels like a real effort to interpret the information that's being displayed - it takes work to scan the events and it's difficult to differentiate between different types of event. I think there are various reasons for this: * The default calendar colours are hard to differentiate from one another. * For me the date is in the wrong position - when I read a calendar I expect the date to come first, as that frames the rest of the information in each tile. * Within each event, the name of each event doesn't always come first, which makes it hard to quickly read down the list and identify each one. This kind of inconsistency creates additional cognitive overhead. * The brackets around the times are additional visual noise which you have to process out. * Everything is very squashed. I'm attaching a proposal which, to my eyes, makes the tiles much easier to read. It includes the following changes: * Move the date to the top left of the tile and make it bigger. * Change the default colours to be brighter and easier to differentiate. * Increase the height of each event. * Move the times to the right, so the event name is always the first bit of text.
Hey Allan, could you please try the git master version? The events changed substantially in master. Your proposed mockup misses two important cases too: - There are too many events, and the events overflow. - Weather forecast indication in Month view cells. Month view has a serious problem of information density. Increasing the height of the events would only make it worse. Right now, on my 1366x768 laptop, I can see at most 4 events, and that's the best I could achieve without damaging readability (too much.) The screenshot you attached shows a month cell relative to a 1080p monitor, which most people can't afford to. Let's optimize for the lower, common resolutions (my target is, of course, a 1366x768 monitor.)
A reference Month view mockup from Lapo: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/calendar/month-view.png
> For me the date is in the wrong position THANK YOU Allan! I needed someone to echo what I've been killing myself to argue in bug #768618
(In reply to Georges Basile Stavracas Neto from comment #1) > Hey Allan, could you please try the git master version? The events changed > substantially in master. Ah yes, I see that now. Do you have any information on the changes that have been made, like a bug report?
(In reply to Allan Day from comment #4) > Ah yes, I see that now. Do you have any information on the changes that have > been made, like a bug report? Not really. This is the current, probably unfinished state of things, partly motivated by Jeff's feedback. Let's use this bug report for that too.
(In reply to Allan Day from comment #0) > * Change the default colours to be brighter and easier to differentiate. While it's not possible nor desired to change users' already added calendars, I completely agree that we need a better default palette.
(In reply to Georges Basile Stavracas Neto from comment #5) ... > Not really. This is the current, probably unfinished state of things, partly > motivated by Jeff's feedback. Let's use this bug report for that too. OK, though I don't think the changes in master affect the proposals in my original report. These were: 1. Move the date to the top left - this is covered by bug 768618. 2. Change the default colours - I actually think that this is the most important one; I personally found Calendar unusable with the default colours. 3. Increase the height of each event - my feeling here is that the change would be good and that other changes could make the UI more space efficient. That said, I don't think this is the most important change to make. 4. Move the times to the right - this is still an issue with master and would be an improvement. Regarding the changes that are in master, I like the effort to try and lighten the visuals. However, I do think there are some issues: * The UI is actually more inconsistent than before, since all day events have a very different visual treatment from other events. This makes the events more difficult to scan than in 3.26. * The little bars of colour make it more difficult to identify which calendar an event belongs to. One way to resolve these issue would be to make the strips wider (so they're small squares or circles), and to use the same approach for all day events. That would have the disadvantage of taking horizontal space away from the event name though.
(In reply to Allan Day from comment #7) > (In reply to Georges Basile Stavracas Neto from comment #5) > ... > > Not really. This is the current, probably unfinished state of things, partly > > motivated by Jeff's feedback. Let's use this bug report for that too. > > OK, though I don't think the changes in master affect the proposals in my > original report. These were: > > 1. Move the date to the top left - this is covered by bug 768618. Lapo might have some comments on this issue. > 2. Change the default colours - I actually think that this is the most > important one; I personally found Calendar unusable with the default colours. > 3. Increase the height of each event - my feeling here is that the change > would be good and that other changes could make the UI more space efficient. > That said, I don't think this is the most important change to make. My point is, if the height is increased and the date moves to the top, in a 1366x768 screen (quite common) only 2 events will be visible at once. This is a really low number, and renders Month view useless :( > 4. Move the times to the right - this is still an issue with master and > would be an improvement. Sure > One way to resolve these issue would be to make the strips wider (so they're > small squares or circles), and to use the same approach for all day events. > That would have the disadvantage of taking horizontal space away from the > event name though. Hm, that might not play well with events that span multiple days. Fantastical [1] and Google Calendar [2] use the same approach, so while it hurts aesthetics, I'm sure the average user won't be shocked. [1] https://dncnhi2ob6sh.cloudfront.net/img2/fantastical2-mac-screenshot-dark.png [2] https://lh3.googleusercontent.com/aJetsFMWLOqJb5vXeNPA4XUaof-F_xsPq4CkupR9RqlUq0W_yktmlogSmXowGyUyRfVn9ZKt=w640-h400-e365
Agreed on all points. - For what it's worth, on the colors side, I always end up using the GNOME Tango palette's darker or middle colors for most of my calendars. The defaults provided by EDS are too pale and provide no contrast, to my tastes. - Regarding the "More events" overflow scenario, I just want a cleaner popover contents (see also bug #784999), and this popover, if it contains what is already shown in the cell in the month view's grid, should "cover" the cell (as if you were zooming in) instead of being a popover on the side/below/etc. However, I do like the separate visual appearance of all-day vs time-based events in git master, as was proposed in bug #753131. I find it less visually overloading and easier to distinguish what is "time-sensitive" from "fuzzy" (all-day). I tend to agree that the time-based events' "color squares" could be a bit larger to make it easier to see the color, though (last time I asked, Georges preferred to keep the event text labels black instead of coloring them).
The following changes landed in Git master: * The last week row is hidden when it's empty * Day number moved to the top * Overflow button shows a "+N" label, moved to the start of the cell * Overflow only happens when necessary (previously, the overflow area was always taken into account; now, only when overflow happens) The first bullet point is specially important, for it substantially increases the available cell space.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-calendar/issues/211.