A month ago, I wrote about next steps for the Chandler project after our reformulation as a smaller, more agile team. Since then we’ve made the plan concrete — here is a summary of the goals and a few pointers to specific work queues.

Mimi described the goals nicely in a post to the chandler-dev list…

1. Get Chandler in front of more users, aka: Make it more viral.

Product changes:

• Item sharing: a new workflow to use the web to collaborate on just one item. We’ll “widgetize” this functionality, making it available in other contexts like iGoogle or on an iPhone.
• Improve web UI “ticket views” so subscribers can more easily subscribe to collections in applications they already use
• Improve existing use cases for iCal and Lightning users (sharing with Chandler users, using Chandler Hub)

Marketing and Evangelism:

• Improve our pitch, improve our web presence
• Better demos, user testimonials
• Reach out and talk to people about Chandler in other spaces

2. Make Chandler more appealing to new users, aka: Reduce barriers to getting started.

Reduce the number of new concepts users need to understand in order to get started:

• Pare down UI, de-emphasizing email UI
• De-emphasize notion of “Item” and replace with “Note”
• Remove explicit “Task” and introduce “Star”

Improve the web UI experience for people not using Chandler desktop (iCal/Lightning or Hub only users):

• smooth out sharing workflows
• auto-triaging CalDAV events
• make Notes field in detail view more usable

3. Make it easier for new users to ramp up to using Chandler every day.

Add two additional “widgets” with features that allow people to use Chandler in other contexts:

• Notifications: Users can send themselves or others notifications about changes to shared collections. This also counts towards the first goal, as it allows current users to share some Chandler functionality with other people. Notifications will be available first as an iGoogle widget (and potentially other similar contexts), and eventually also as email, SMS, or IM messages.
• Quick Entry: this widget will allow users to enter items into Chandler Hub from other contexts: iGoogle, iPhone, OSX and Vista widgets. Eventually we’d like to allow similar functionality through forwarding email to a particular address.

Work Queues and Releases

The work described above has been broken down into tasks and bugs and is prioritized into two work queues, one for the desktop and one for all of the web related work. Grant is marching down the desktop queue while everyone else tackles the web queue. We meet daily to cover progress, adjusting the work queues if priorities change. (Mockups and specs for the new widgets and web UI changes are also linked from the web queue.)

• Web Work Queue
• Desktop Work Queue

The plan is to do a desktop release and a server release once a month. Usually these won’t need to be coordinated — though in this next round we have a security bug that involves both.

Phillip’s work on the desktop rearchitecture is the exception. He’s posting about his work over on the PEAK list. We may move Chandler desktop over to this architecture after the 1.0 — we’re waiting to see how this plays out to make the call on that.

Milestones

We plan on hitting a few major milestones by early summer — these are the big goals we are shooting for:

• Web Widgets: Quick Entry, Notifications, Item Sharing — we’d like to have these deployed in a few contexts.
• Desktop 1.0: We’re pretty close to releasing a 1.0 desktop. Prior to launching this we want to make sure some web UI improvements go up on the Hub, and make some changes to the website.
• Server 1.0: With some security fixes, authentication work, and a few other items (e.g. the ability to disable account signups), we should be able to release a 1.0 for people who want to run their own server.

We don’t need to coordinate all of these milestones — we may hit some more quickly than others.

Changes to the Plan

We were thinking we’d put minimal investment into the existing web ui, figuring that we’d do a better job on the web use cases we want to hit with the web widgets. Once started thinking through both the web and desktop use cases, we realized we really do need to make some investment in the existing web ui. We’ve added web ui bugs to the web queue.

We decided to put off working on a Thunderbird plugin, for two reasons: (1) after doing a bit of research it was starting to look like a more sizable investment than we initially thought and (2) we worried about having too many projects.