Plasma Calendar data engine & widget future plans

[John Layt]

On Friday 29 January 2010 19:46:38 Aaron J. Seigo wrote:
> On January 29, 2010, John Layt wrote:
> > * Support multiple holidays on each day
> 
> i think we already do internally, but we don't visually display "this day
> has more than one holiday"

The data engine does read and return multiple holidays, but the calendar 
widget only uses a QHash to store them so no duplicates there. It's easily 
fixed by making it a QMultiHash and retrieving all keys.

> > * Tool-tip on hover over day showing any holidays
> 
> right now that's done with a click. it certainly has its draw backs, and a
> tooltip sounds like it might work, my only concern is covering the rest of
> the calendar which could be annoying.

I'm not a big fan of the current expander, especially how it flickers and 
jumps, not smooth at all, but it does have the advantage of leaving the entire 
month visible while having lots of room for a list of events.  The tool-tip 
could get in the way a lot and be a bit cramped.

> i think the kde pim people likely have more experience in these matters
> than we do, and so it would be good to bring them into the discussion
> early on as well. best would be if the plasma calendar and what we see in
> korganizer harmonizes visually.
>
> i think the plasma calendar should remain simple and provide more of an
> overview than korganizer does, but they should "work together" visually as
> well as functionally imo.
> 

Agreed.  I think the pim guys are working on KOrganizer this release cycle, so 
it will be a good time to co-ordinate.  Their current Month Table widget 
(KDateNavigator) is mostly intended to be used to navigate the main view 
displayed next to it so doesn't need the same level of detail and is rather 
static, but using the same visual cues for information would be good.

> > * Do we provide users the option of choosing the highlight method for
> > each holiday type, or not to highlight some types?
> 
> if we do, this should be desktop-wide imho.

Yes, I was thinking that, but I want to try it out at an app level first to 
see if it is practical before moving it to desktop level.

> we really want to be able to show, simultaneously:
> 
> * this day has holidays
> * this day has appointments
> * this day is a non-working day

That's a very clear summary of it, simple really :-)

Based on most common usage I've seen perhaps:
  Appointment = Bold day number
  Non-working = Darker shaded background (includes weekends)
  Holiday = halo with colour possibly varying based on type

The bold day number is almost universal (KOrg, Google, Gnome, Evolution, 
Orage, Sunbird), and shading is fairly common for weekends.

And possibly a fourth option:
  Religious day = Red day number

To that mix we could maybe add birthdays/anniversaries that may deserve a 
higher level of highlight than normal appointments, so also a halo?

Looking at S60 suggests two further options, underline the day number (S60 = 
today), and colour in a small triangle in the bottom right corner (S60 = 
appointment).  Different corners could mean different PIM types (appointment, 
todo, holiday, etc).  The iPhone apparently puts a dot below the day number 
for appointments.

> this sounds like a job for visual design: how to communicate three piece of
> boolean information in a small space using color and shape only.

What we need is Edward Tufte :-)

> maybe showing horizontal bars across the day itself showing when
> appointments take place would be best?

Hmmm depends on how many bars in a day, I assume you mean 1 per appointment or 
hour?  Could look a little crowded and be hard to read on a small monitor.  
And it's really only useful for today, it's useless for last Friday and 
limited use for next Friday.  Maybe it's trying to add too much information to 
too small a space for too few users?  The people who have schedules that busy 
would either have KOrganizer always open, or could use another larger widget 
better suited for the purpose.

Slightly simpler could be the Chandler 'busy-bars', a single vertical thin 
blue bar up the left side of each day cell with length in proportion to hours 
booked (like a bar chart).

Any increase in the detail in each day cell would probably mean removing the 
graduated fill to keep things looking clean.

> when clicking on a day, it could replace the calendar view with more
> information and some helpful buttons: calendar (return to the calendar
> view), next and previous days, open in $CALENDAR_APP
> 
> when the calendar is hidden, it could be reset to the month view.

Very nice, I like that a lot.

That does put me in mind of the Win7 panel clock/calendar (although they may 
have borrowed the idea from elsewhere).  It starts with the classic month grid 
view, but if you click on the month name header it zooms out to show a 4x3 
grid of month names for that year.  Click on the header again (now only 
showing the year) and it zooms out to a 4x3 grid of years in the decade.  
Another click on the header zooms out to a 4x3 grid of decades in the century.  
Obviously clicking on a decade/year/month in a grid zooms you in to that lower 
level grid view.  Very smooth visually and easy to quickly navigate with 
minimal mouse movement and no keyboard input.  Kind'a like the ZUI :-)

We would just add deeper zoom levels: click on the day number to zoom in to a 
simple day-by-hour view or event list view like in KOrganizer, click on an 
appointment to zoom in to the appointment details.  Clicking on the week 
number could show a week view.  The limiting factor of course is what fits 
inside the space of the default panel clock pop-up.  At each view level a 'Go-
to' button could open that level view in KOrg.  A on-hover tooltip would then 
just show your summary suggestion, so long as it doesn't keep getting in the 
way of the day you actually want to click on.

Anyway, I'll get on with the back-end, sort out the data engine, and plug it 
into the calendar using the existing extender to show the info.  Once we have 
data flowing we can experiment with the display.

Cheers!

John.