Dogfooding Chandler 0.6 - Philippe's Notes

I'm a brave soul : I started dogfooding Chandler on September 7th 2005. I rapidly stopped though due to really icky roundtripping issues with my recurring meetings. I started again on September 23rd 2005 and I've been rather happy since. Not that I didn't run into bugs (I've been logging an average of 1 bug per day as a result of dogfooding...) but I've been able to work around most of the issues and found a workable way of using Chandler for all my scheduling needs. I haven't used Apple iCal since then which is a nice tribute to Chandler's stability (it rarely crashed on me, even running several days in a row without quitting).

Here under is a list of things I noted when using Chandler that are not really bugs (things that are currently "to spec") but need to be improved:

Perf when creating new event

That's my biggest performance issue. I'd like creating new event to be fast and snappy. A user who hesitates to double click a time slot because "it's going to take too long" is a lost user...

Checked vs. Selected collections

I find that somewhat confusing and, to be honest, now that I can select a collection by just clicking any displayed event, I never pay attention to the "selected" state, only the "checked" one is relevant to me. So, what's the point of having a "selected" state? The point is that when hitting "New event", Chandler will create a new event in thie selected collection. Irrelevant again most of the time except when you first create an empty collection and have no other way to make that collection "default". Another thing to remember is that, even if the difference between collections is clear in the Calendar View (because of the colored events), it may not be so in the normal tabled Summary View. To say nothing about people using (confusingly) the same color for several collections... So, all said and done, I understand why we have 2 states for collections (checked and selected) though I still find the way we display them somewhat inelegant.

Sidebar icon for OOTB collections

This is my most serious rant. As a user, I see a bunch of problems with the OOTB (Out Of The Box) Collections in Chandler (the "My Calendar/My Items", "Trash", "In" and "Out" collections) :

• Hover : The switch to a "normal" icon when hovering on OOTB collections is really puzzling. Frankly, it looks like a bug, as if some other collection icon were being drawn on top of the OOTB icon. It is actually a feature specified in the spec, or rather the spec suggests that the OOTB icon "could be replaced by a checked icon". So, what we have is really an experiment and, IMHO, it does not look great. I think that the icon should not switch wildly on hover. As a minimum, we should have a specific icon on hover, one that shows the regular OOTB icon with a superimposed "white check" so that users understand they can activate these collections too.
• Active State : Once activated, the OOTB icon is replaced by a colored check one (as suggested in the spec). Same issue as above and same recommendation: we need a specific OOTB icon. I understand that it is difficult to create several variations for each icons. Not only it's time consuming but it creates limitation to the kind of icons that can be created in the first place. As as alternative, one could have a side marker (a small dot for instance) placed to the right side of the icon (i.e. in another column) instead of superimposing an icon and a state on the same graphic.

Actually, considering that one should be prepared to have collections with customized icons (customized by users or may be through parcel code, one can imagine a specific Amazon icon collection or Flickr icon collection for instance) I think considering a side marker would be a good idea. This side marker (a simple dot for instance) would have the color of the collection. This would limit the number of colors present at the same time in the sidebar and provide a 1-to-1 color/collection relationship between the Calendar view and the sidebar.

Talking to Mimi about it, the problem with the side marker is that it does not convey the idea of "check-ness" very clearly. I can agree with that though, at the moment, I do not have a really better proposal.

Certainly the core of the problem is that we are using a single thing to superpose 3 meanings:

• Visual identity (the "icon" concept)
• Color (visual discrimination in the Calendar View)
• Check-ness (visible or not in the Calendar View), compounded by the fact that we have a hover state for this

That seems like a good idea (real estate wise) but it's just confusing as it is right now.

Stuff not committed to the repo often enough

I lost changes once when Chandler crashed. It's OK to loose the last change (although...) but I also lost edits I did hours ago on another collection. That's a heavy price I shouldn't have to pay. We should commit more often to the repository (when switching collections? on schedule?...)

Infinite recurrence

It's weird: does it make sense to see a Jan 10 2012 4pm meeting with Mitch? The probability of this event to really happen is vanishingly small but that's what I can see on my calendatr because of some unbound recurring events I created. So, why do we need unbound recurring events? Answer: to avoid the annoyance of recreating recurring meetings. OK, that is nice: I remember in a former company (using Outlook) how everyone ran scared because the weekly meeting disappeared on a regular basis having reached their end of life... and only the initial event creator (usually long gone from the group...) could change it... Still, it's unsettling to see that my calendar in 2015 is already packed with appointment. Can we rather address that by automatically (with a heuristic...) create recurring meetings from an "unbound" master up to a reasonnable date in the future but not beyond? Remember that for a user, unbound means: "I don't know when it'll stop and, please, recreate it automatically when it runs out (without me telling you)". It does not mean: "it will never stop".