[chandler-users] After a few of weeks of Chandler...

Dave Cowen dave at kei.com
Thu Oct 18 15:57:30 PDT 2007


Howdy all --

Congratulations on preview!  I've been using Chandler regularly here  
on my first-gen MacBook Pro and have a few comments.  Wait, no, I  
have lots of comments.

The kudos:

Chandler and Cosmo *work*.  I don't mean that it's technically  
possible for me to run them, I mean that they're now genuinely  
usable, and I've been able to make them a part of my daily workflow.   
Chandler's evolution feels very similar to me to that of Firefox,  
where I'd download each milestone release, run it for a day, get  
frustrated, give up and wait for the next milestone release -- until  
that magic build where Firefox stayed in memory on my machine for  
more than a day without crashing and I knew it was going to be part  
of my life from then on.  Chandler's been in active use on my machine  
since 0.7.0.1 got released, and that's fantastic.  Great job everyone.

Also, migrating from iCal was incredibly painless.  The import  
functions "just worked."  Everything showed up the way it was  
supposed to.  I was able to import iCal, publish the collection to  
hub, send out a few URLs, and within minutes I was able to continue  
on with my calendaring.  Again, great job.

Things are generally very stable; I can tell that QA and the Bugzilla  
trawlers have kicked into overdrive here, because my experience has  
been nothing like past attempts.  It launches, it stays up, it does  
what it advertises without failing.  Wonderful work on firming things  
up.

Existing bugs I'd love to see priority given to:

The bug where you can't rename view-only calendars from  
hub.chandlerproject.org is very, very frustrating and can cause a lot  
of confusion.  I end up thinking "whose Work collection is yellow?"  
every day.  I know the issue is in Bugzilla, but I beg you, please,  
please fix this soon.

Invitations don't come up right in Outlook.  I don't use Outlook for  
my personal mail, but let's just say I know and work with lots and  
lots of people who do. ;)  Again, I know it's in Bugzilla. ;)

Overlaid calendars on Hub.  I know you guys are working on it.   
Godspeed.

Mac-specific gripes:

Chandler feels much slower than iCal.  There are three main places  
where this comes up: startup, shutdown, and in entering a new event.   
I know you guys are looking at decreasing startup and shutdown times,  
but in practical use, iCal is just a couple of bounces away even from  
a cold boot, while Chandler is from 3 to 10 times that.

Creating new events is always a bit frustrating.  A quick click-and- 
drag in iCal will get me an item from and to specific times -- a task  
that can take less than a second if I'm not fat-fingered.  Creating a  
new item in Chandler takes that quick click and drag, then adds a  
double-click and an awkward wait (often two seconds, which somehow  
feels like an eternity compared with iCal) for the event to appear.   
There seems to always be a point where I wonder "did I not double- 
click fast enough?"

Closing is awkward in a different way, because Chandler doesn't  
respect the typical Mac OS convention that closing a window doesn't  
quit the application.  I'm in the habit of keeping commonly-used apps  
running for quick load times but closing all unused windows to keep  
my desktop from becoming a cluttered mess.  With Chandler, I have to  
minimize, resulting in clutter in my dock.  If I accidentally decide  
to close -- which I do over and over because it's what I do with my  
other apps -- I end up having to wait for Chandler to close the  
repository.  (Then I have to wait for it to launch again!)

The most trivial of gripes: I miss the day's date in the dock icon  
that I get when iCal is open.  While many folks like pop-up windows  
or audible alerts, I'm in the habit of checking my dock for  
indications in the dock items that something has happened --  
bouncing, Mail.app's little red number, iCal's date and notification,  
Adium's variety of notifications.  Seeing the dock out of the corner  
of my eye for an immediate status of what's going on is part of my  
minute-by-minute work zen.

Some things that aren't really bugs or gripes, but I think are a  
little weird:

Outgoing mail defaulted to port 465 when I used auto-setup.  While  
that's technically accurate, since 465 is a valid outgoing mail port,  
I see a lot more organizations have 587 open these days.  As an IT  
guy, I generally recommend people try 587 first.

I can delete items in collections that sync with read-only sources.   
I understand how and why it's being done, but man, does that scare me  
-- especially since the item doesn't reappear on sync.  The ability  
to "lock or unlock" read-only sources for changes (never thought I'd  
say *that*) would be nice to ensure consistency.

Reply, Reply All, Forward and Send are greyed out until the  
conditions necessary to send are met.  IMHO, clicking on one of those  
should open up the menu to add E-mail addresses.

I find the behavior of the triage button to be kind of  mystifying  
even after finding out what it does; it feels unnecessary.  It's also  
not greyed out when it has no effect, so there are many situations  
you can click triage and nothing happens; there's no cue as to when  
it's *appropriate* to triage or from which you can figure out what  
it's doing.   Paul tells me that in usability testing folks didn't  
want auto-triage when status was changed so things didn't "jump  
away".  I'd personally prefer that model, with a multi-level undo.     
How 'bout an option to set it either way?

"I Want a Pony" requests:

Long event names are often obfuscated in some way, and there's no  
obvious way to scroll to see the full thing.  I realize I can click  
on it in the right-hand pane and use the arrow keys, but that's a bit  
on the awkward side.

The little man, the checkmark, the little clock are not intuitive,  
and many folks won't do the same "I'll create a collection I can  
screw up, set up test items and then click on these things just to  
see what happens" approach I'll often take.  There really need to be  
tooltips there, as I can never quite remember what each little symbol  
does.

Everybody asks for better recurrence, and I'm going to join the  
throng.  xth day-of-week of the month is something I use frequently,  
both at work and in my personal life.  Note that the KEI scheduled  
downtime is the Wednesday after the second Tuesday of each month; if  
you can get that level of recurrence working I'd be so happy.  That  
said, just being able to schedule the second Wednesday of the month   
typically would be OK.

I can't create/block out a multiple-day "all day" event by clicking  
across days in the upper part of the calendar.  I commonly do this  
for vacations or travel.

iCal "greys out" the early-morning and late-evening hours, which  
helps me focus on where to put something when jumping to new, empty  
days; the mark by Noon and the darkened bar on the right side is far  
less helpful, especially when I'm scheduling Fridays.  Customizable  
"greying out" of certain times on the calendar would be great.

Tools -> Select View -> Day View seems to be a strange place to put  
the view options instead of there being a toggle in the windows or  
from the View menu.

All-day events in a collection are a different color than timed  
events -- they're the lighter color they would be if the collection  
was not selected as the primary collection.  I'd love for this to be  
consistent; I sometimes glance over them as I believe they're part of  
a different collection.

Integration with Quicksilver would be completely awesome.

A (controllable) auto-update feature that downloads the new version  
would be nice, especially as you guys ramp up the release schedule. ;)

Lastly, there are some big, hairy issues:

*Scheduling meetings*

Setting up and finalizing a meeting between x number of arbitrary  
people is very, very difficult with Chandler.  Right now, you either  
need to be subscribed to everyone's calendar (which isn't practical  
once the number of calendars in an organization get past 10 or so)  
and select all of the calendars of the folks you want to invite, or  
you need to manually enter the E-mail addresses of everyone in the  
group and wait for responses, then send announcements as folks become  
tentative and you need to reschedule.

This is where Outlook (and Zimbra, to a certain extent) excel.  You  
can simply call up a grid where you enter the names of the parties  
you wish to invite, and you see a grid of free/busy information that  
you can add folks to and see where there's a time that most people  
are free.  When you select that free time, chances are that you can  
nail down a meeting time before even consulting with anyone.  If you  
need to schedule with someone whose calendar you don't have access  
to, chances are that their e-mail address is in your Outlook (or  
Zimbra) address book, so you don't have to do manual entry for the  
invitations.

My personal experience is that in the SMB arena, this manner of  
scheduling a meeting is rather popular -- and for many organizations  
I've both worked at, worked for, or known people who worked for, it's  
the "killer" feature of Exchange.

*Access Control Lists and Workgroups*

When "evangelizing" Chandler Desktop and Hub, there's a sticking  
point that really seems to bother folks.  If you publish a calendar,  
anyone who manages to obtain the URL for that calendar (including a  
ticket) can see it.  The common response is "what if that URL gets  
forwarded to someone who I don't want to give access to see personal  
information that may be on my calendar?"  Since there's no way of  
seeing or controlling who uses the Chandler Hub URLs, there's no way  
of restricting access short of removing that ticket and republishing  
it (to all of your contacts who want to subscribe) under a separate  
ticket.

There is an expectation, especially in this day and age of "friends  
networks" on various sites like Flickr, Myspace, FaceBook et al, or  
from using Exchange where you can create very granular restrictions  
on which accounts can do various things with your calendar, that  
there be a way to make information not just public or private, but  
restricted to a certain number of accounts who have private passwords  
(and who would either not want to share their passwords, or who would  
be accountable for a breach).  There's also some expectation that not  
only the calendar would be able to have access control lists, but  
also particular events -- just like a MySpace blog entry may be  
viewable by friends only, whereas other blog entries could be visible  
by the entire public.

In real life, people put a lot of private information in their  
calendars -- addresses, phone numbers, directions, flight numbers --  
and Chandler Hub's limited security model does not ensure that this  
information is secure beyond the possession of a URL.  Even basic  
users seem to understand how their information might be easily  
accessible without their knowledge if they send out the URL to their  
calendar even once.

As for workgroups, I know, I know, it's a pre-web buzzword.  But  
people really do use "workgroup" functions in software, especially  
with Exchange and Web 2.0 social networking sites.  Access control  
lists can be a real drag when they're large; the ability to sort  
contacts into groups helps alleviate that pain.  On Flickr, I share  
different photos with family (the ones where I'm squinting) than I do  
with friends (the embarrassing fun ones) than I do with the public  
(the nice, acceptable ones).  If I had to enter in accounts one by  
one I'd go crazy.

Similarly, we work in a world of departments and mailing lists for  
different purposes; a workgroup is a shorthand access control list.   
I'd love to see the ability to add accounts, E-mail addresses, or  
other accounts to be shared to in Chandler Hub to a workgroup so that  
I could send an invite to or share an event with a department.

*Now, Later and Done*

As many of you know, I do a lot of triage in my job, and manage an  
almost bewildering array of tasks.  I do a *lot* of tasklisting.  I  
deal with a large number of incoming e-mails, support requests,  
questions, invoices... I do a heckuvalot of triage.  As most of you  
know, I use RT for the bulk of this, but also use individual  
tasklists (similar to what is suggested in GTD but of my own design)  
and Chandler (these days) for things that have specific dates and times.

Now, Later and Done just aren't helpful to me for prioritizing and  
status.  While I often have multiple requests or projects running at  
one time, I rarely have more than 4 items that could reasonably be  
considered "Now" items.  I've found that except for a few rare  
people, most folks start to choke when they're working on more than  
3-4 things at one time.  When I see a dashboard or tasklist with more  
than 4 items marked Now, my emotional reaction is panicked -- "I have  
to do all that NOW??" -- and my rational reaction is that it's simply  
not possible to do all those things Now and so either the system is  
broken or I need to hire an assistant.  In that scenario, I'd end up  
reading all of the items -- a waste of time -- or I'd just choose an  
arbitrary thing labeled Now to do.  Doing "reverse triage" to get my  
Nows under control would likely not match the urgency of the Now  
items, so that may never get done!  IMHO, Now needs to be limited to  
a handful of items, or the actual meaning of Now is lost.

Given that Dones are often triaged out of the way, when I try to use  
the tasklist I just see an ocean of Later.  That's not very good for  
my motivation, to be honest.  "Now that I'm done with these 4 Nows  
that are Done, what should I do Later?"  The tasklist doesn't help me  
figure out what I should do.  I stall and start reading all of the  
headings and details for the Laters, trying to figure it out --  
which, again, is wasting time.

Here's what I do in real life (simplified for relative brevity): I  
sort requests by "should be done by" soft deadlines.  When I get a  
new task, it either has a hard deadline, or I assign it a realistic  
soft deadline:

1-4 hours from now
Today
Next business day
A few business days
End of this week
End of the next week
1-2 months

... and my tasklist is sorted in that order (with items that lack  
triage statuses at the top of the list in a separate area).  That  
way, I always know what I need to do next at a glance, since the  
things that need to be done sooner are at the top of the list. If for  
some reason I'm blocked from working the top one temporarily, the  
next most important tasks are just a few lines away.  You know how  
Quicksilver's tagline is "act without doing"?  Yeah, it's kind of  
like that.  I let the structure do a lot of the actual work for me,  
so I can work on tasks that actually require my intervention.  (Ever  
wonder how I get to all those support tickets so fast? ;)

Now, there are always blockers.  When I've worked on the task and the  
task is blocked in some way, it gets a tag that it's blocked in a  
particular way:

Waiting on additional communication from task stakeholder or outside  
source
Waiting to discuss at next meeting with task stakeholder
Waiting for a package or documentation to physically arrive

and the task falls to the bottom of the list, since it's blocked and  
I can't work it.  Every day, I check these to see if there's been  
activity and triage them back up to the normal tasklist if there has  
been.  (In Chandler, E-mail communication from a task stakeholder or  
outside source, or the actual date of the meeting, could  
automatically bump those issues back to the main list, which would be  
awesome).

I realize much of this is idiosyncratic, but a bit of restructuring  
-- more priority levels, customizable tags, time-based "triggers" for  
things in the tasklist -- would allow me to approximate what I do  
above.  If there are easy enough ways to accomplish the above in  
Chandler currently, let me know.

Okay, that's it -- sorry for the ridiculous length.  Again,  
congratulations on preview.  I may have brought up a number of issues  
here, but I've been genuinely enjoying using Chandler.

Dave


More information about the chandler-users mailing list