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.

Mimi and I were checking out Things the other day, which appears to be a thoughtfully designed task manager for OSX (similar space to Chandler). One of the developers had a recent post that I thought captured something important about good design:

Of course both Jobs and Schiller know that there are times when you listen to users and times you better not. And the interesting thing is, even when developers don’t listen, they might do it for the best of their users. But how is that?

By all means developers need to follow their vision without asking anybody. They need to think out of the box and innovate. How else could they surprise and ultimately delight?

One of the main responsibilities of a developer is to keep guard over the gestalt of a program. It is all too easy to let your application burst into a universe of hardly connected little features. We have all seen it happen. But it is equally easy to ignore your customers’ needs and to embark on a journey where nobody is following you.

It is not about listening or not, it is about what to do with all the things you have learned from listening. And that is integration. The best feature is worth nothing when not integrated properly. When we read a feature request, we don’t think about doing it or not doing it. After all, if software development is not about satisfying users, then what is it? We are thinking about how we could nicely integrate it with the rest of the application without diluting its identity.

Of course, as an open project, we’ve sort of given up the element of surprise.

One of the project goals has been to experiment with involving users, developers, and other interested parties throughout the design process, making design decisions in conversations on public mailing lists. During that process it can be tempting to use “what the user has asked for” as an objective criteria for making decisions. The quote above does a nice job articulating that doing so can be dangerous for the integrity of a design, without writing off the importance of paying attention to what users are saying.

Mimi did a writeup on OSAF’s open design process last summer in preparation for a presentation she did with Ted Leung at OSCON. She goes into some detail describing how we manage conversations and make design decisions in a way that tries to preserve both the “gestalt” of the design as well as the continued interest of developers who might be pursing individual passions and concerns. Getting this process right continues to be one of the more interesting challenges of the project.

Last week the staff got together in person and took a critical look at where the project is now and what we want to achieve in the next year.

We asked ourselves a series of questions, including: “We have some successful, enthusiastic users who rely on Chandler daily: how are they using it? What are their success stories? How can we build on that and grow the user base?” and “Why do we only have 100s of unique desktop users syncing to the Hub daily when many 1000s of users have downloaded the desktop?”

Looking at users who are successful and potential users who run into difficulties, we had this insight: Chandler succeeds at meeting the needs of users who are tracking ‘knowledge work’. What do we mean by this? We’ve observed people tracking ideas and questions for tasks they need to do — the kind of things people otherwise might jot down in notebooks, on scraps of paper or in text files. They selectively add important email messages to Chandler (the ones they might have flagged if they were only using their email client). They share collections of these items with other people as they develop an idea, using Chandler to record the ‘knowledge’ about a shared project. Quick item entry, stamping items onto the calendar or a task list, and items in multiple collections are all signature features that help users evolve their ideas into tasks and projects. While the design includes tasks and a hard calendar landscape, Chandler is not oriented around calendaring per se or around a complicated task and project landscape with many dependencies. We don’t have enterprise scheduling features, for example, or task and project dependencies. Instead of adding more features for calendaring and task/project management over the next year, we’d like to build on Chandler’s more unique strengths, excelling at meeting the needs people who currently find Chandler compelling.

Of course, many users who do have similar needs to the successful users run into barriers when trying to use Chandler. The application is too slow for their hardware, they are overwhelmed by non essential functionality visible in the application, they don’t know how to get started, they run into a roadblock when creating an account, etc. We want to remove these barriers.

The flip side of this is that some people who have been drawn to the project are really not target users. Chandler doesn’t meet their needs because Chandler is not designed for them. We just don’t have the resources to make all of these people happy — we really do have to focus. More on this in the “what we are not doing” section below.

Another idea that came up in our discussions: we want Chandler to be more viral. We want Chandler to be easy to explain to others. We want Chandler to be found in contexts where people are already spending time. We want Chandler to be of great use to the individual using Chandler on their own, and to be even more useful as that user pulls in other people to collaborate. We want happy users be successful evangelists for Chandler.

What we are doing next

We made some important high level decisions about what we’re going to be focusing on in the next year, and in particular for the next 3-4 months. It was most concrete for us when we discussed exactly what each person would be working on (in particular what each developer would be working on), so I’ll use that to frame our strategy.

Grant Baillie: Incremental progress on the desktop. We decided that we can’t stop and take time out to rewrite the desktop or build a complete web based home for our target users, so that means continuing to maintain the current desktop code base. Grant will focus on bugs and small feature changes that remove barriers for users who otherwise would value Chandler’s feature set. We are not far from a 1.0 version of the desktop. One of the first projects that Grant is working on is a pass at simplifying the UI by removing rarely used email functionality — reducing the number of new concepts that users need to get started.

Travis Vachon and Jeffrey Harris: Web widgets. We’re turning our focus on the web away from replicating the desktop functionality, and toward making Chandler more viral and better at facilitating idea gathering and collaboration for our target users. Travis and Jeffrey are going to build web widgets that might be deployed in different contexts — iGoogle, Facebook, on an iPhone, etc. Widgets will give read/write access to a particular item (instead of a whole collection), allow users to search for a particular item, allow quick entry of items, etc. We’ve started the design work on the chandler-dev list. One requirement for the web strategy is that these widgets should be compelling to a new user who does not use the desktop, in addition to providing features that complement the desktop. Eventually, the widgets can be building blocks for developing out that web based home for our target users.

Brian Kirsch: Thunderbird plugin. Brian has already blogged about this idea; we’ve decided to proceed with it. We think it will be a great way to introduce Chandler ideas to a new audience.

Jared Rhine: Email related features on the Hub. Jared will explore adding email notifications/reports from the service, and email as a way of entering data into the service. Again, these features are a way of making the Hub more viral — data access from other contexts where people spend their time. This work is in addition to Jared’s many other responsibilities (managing the Hub service, build and release management, etc.).

Randy Letness: Chandler Server improvements and support for web widgets. Randy will continue with security work that has long been planned, as well as server support necessary for the new web widgets.

Phillip Eby: Desktop rearchitecture. We will continue to make a modest investment in the rearchitecture project that we embarked upon last year, as the rearchitecture is our path to really solving desktop performance problems. The rearchitecture will also provide a much better platform for other developers to contribute to the project.

Mimi Yin: Product design and strategy. Web strategy and web widget design, Thunderbird plugin design, desktop prioritization, project website improvements, etc.

Sheila Mooney: Evangelism strategy. Develop a pitch and a demo, meet with stakeholders, etc. One of the barriers for potential users and partners is really a marketing barrier — helping people understand what Chandler is intended for.

My job is to manage the project overall and give the project its best shot at thriving beyond the end of the year.

What we are not doing

We are not trying to be an open source Exchange/Outlook competitor. While this would be a worthy goal, it is not our passion and we don’t really have the right product or organization to pull this off. It has been a misperception in the press that this has ever been our goal — probably because so many people want an open source competitor to Exchange/Outlook. We have not designed Chandler for enterprise calendaring. Actually, the Microsoft product with the most overlap with our design objectives is probably OneNote.

Being a CalDAV reference implementation is not a priority. We believe that calendaring standards are important and hope that they are adopted in the world, and much of OSAF’s energy in previous years was directed at making that a reality. With our current need to focus, however, our strategic objective wrt calendaring standards is to be able to interoperate with popular clients (e.g. iCal and Lightning). For this reason and because we are not trying to do enterprise calendaring, we will not be implementing CalDAV scheduling.

We are not trying to be a GTD specific tool. Yes, we paid a lot of attention to GTD as we were designing Chandler and we were inspired by ideas from GTD. We also looked at how people who have never heard of GTD really use their inbox to manage their world, and taken inspiration from that as well. When getting into the specifics of Chandler’s design, we focused on user scenarios and workflows that would make our target users successful — not necessarily designing to GTD processes. We’ve recently taken a critical look at how well Chandler meets the needs of someone following the GTD process strictly. In doing so, we realized that we didn’t want to prioritize staff time to work on changes that would make Chandler a GTD specific tool, and that Chandler’s philosophy is different enough from GTD that it would be misleading to call Chandler a GTD tool. We’ll need to change our messaging — our landing page, blog and other places that refer to GTD. That said, we recognize that some developers are interested in features that would help people use Chandler for a GTD process, and we encourage anyone who wants to contribute code for such features.

We are not going to add full email functionality to Chandler desktop, or contacts (at least not in the next year, not on OSAF staff time). Yes, we know that many people want these features, and we’d love to design them and implement them if we had the resources, but we don’t have the resources in the next year. Again, we’d gladly accept code contributions that implemented these features, or additional funding to implement them. We are willing to spend time to help make people successful contributing code for these features (or other features that complement the current product).

Several folks have asked who is staying on for the next phase — who is remaining on the staff.

Mimi Yin continues on as our Product Designer, Sheila Mooney in Program and Product Management, and Jared Rhine running the Hub Service. Jared will add more IT responsibilities, as well as build and release responsibilities to his plate. Mimi, Jared and Sheila will also be helping me with a wide variety of tasks for the organization, as one might expect on a small team.

Grant Baillie, Jeffrey Harris, Brian Kirsch, Randy Letness and Travis Vachon are all developers on the new staff. Phillip Eby continues to have a contracting relationship with OSAF, and is actively participating in strategy discussions with the team. Grant, Jeffrey and Brian had recently been working on the desktop team, Randy and Travis on the server team. Travis was an intern on the desktop team a few summers back, and Brian worked on the server team a few years ago. Going forward, developers will move around and tackle code on either code base depending on what is needed.

For the time being we’ll have a flat organization, and think of ourselves as one team. (Previously we were organized in server, desktop, qa, product, build/release and management teams). We’ve ended all of our older recurring meetings, and now have one daily sync up with the 10 people noted above. We’re currently doing this on the phone while we get our footing, but may eventually transition to IRC.

You should start seeing more posts on this blog about strategy and overall direction. We’re also starting to getting back into the groove of working on the lists.

I’d also like to emphasize that Chandler Project is bigger than these 10 staff members. Several former staff members intend to remain involved in the project. Andi Vajda will continue to maintain PyLucene and PyICU. Heikki Toivonen and Philippe Bossut will continue with Finnish and French translations. Heikki will continue to maintain M2Crypto. I continue to appreciate the counsel of Phillipe and Ted Leung, and am looking to find ways for them to be involved in an advisory capacity. Others have mentioned wanting to remain involved as well — I’m sure new roles will unfold as the next phase shakes out. Chandler Project also includes contributors like Andre Mueninghoff and Davor Cubranic, who helped immensely in getting out our Preview release. We also really appreciate all the users who speak up on the chandler-users list. We look forward to the project growing, even with a smaller paid staff.

OSAF and the Chandler project are going through some big transitions. Yesterday, January 7, we restructured the organization. This is the biggest change since the inception of project six and a half years ago.

In September 2007 we delivered a Preview release of Chandler Desktop, Chandler Server and the Chandler Hub web application. Since then we’ve been gradually acquiring users and building a community of people interested in the project. We now have hundreds of people participating in our users mailing list and thousands of users downloading Chandler and creating accounts on Chandler Hub.

Chandler is an open source, standards-based calendar and task manager built around small group collaboration and a core set of information management workflows modeled on Inbox usage patterns. Users manage and share calendars, tasks, messages, and notes with the Chandler Desktop application and with the Chandler Hub web application.

The next phase of the project is about growing the user base, building the community, and diversifying our funding sources. OSAF has been primarily funded by one person up to this point, Mitch Kapor. Our goal going forward is to modify our organization and our funding model to grow into a publicly supported community project, not propelled by one individual.

I will be leading the next phase of the project, and Mitch will be winding down his role on the project. Mitch will provide transitional financial assistance to support the organization through 2008. Mitch will step down from the board, and I will replace him.

OSAF will maintain a smaller staff during the next phase of the project. While figuring out the new funding model, it is prudent for the organization to reduce expenses. OSAF’s paid staff will go from 27 people to 10 people. While I expect that most former staff members will move on to other endeavors, we certainly welcome them to remain involved with OSAF and Chandler in some capacity. Developers will retain commit privileges, for example.

Strategically, we find ourselves at a crossroads. The new Chandler team will continue to address the needs of informal groups sharing calendars and managing projects together. We’ve gotten a lot of great feedback from our current users, and intend to use that to fix usability problems and shape the next set of feature work. We have several options before us and will be ironing out a more focused plan for the next phase. We will keep everyone updated on this blog.

The Chandler team did a fantastic job shipping the Preview release. Building on this accomplishment, the project has many great possibilities ahead. While saddened to see such a great team come to an end, I’m excited about the project’s opportunities and looking forward to the next chapter.

I’m pleased to announce that the Chandler project has hit our Preview milestone! We now have public-beta quality releases of our products; we believe them to be full featured enough and stable enough for daily use. Check out a full overview of features (including screenshots and screencasts). Download Chandler Desktop, create an account on Chandler Hub. Check out the source. Get involved in the project, help us build a really great 1.0 release.

Chandler Desktop
We released 0.7.0.1 of the Chandler Desktop yesterday, September 10. (In the spirit of responding to user feedback quicky, we fixed a problem with the release found by a user before we made the announcement).

Chandler desktop adds a central dashboard for managing tasks, notes, events, and messages to the basic calendar functionality found in the 0.6 release. You can share calendars, task lists, messages and notes in collections that can hold whatever you choose to put in them, regardless of data type. The performance has improved greatly, the application has basic search functionality, and now there’s a way to to manage and resolve conflicts on shared data. You can collaborate on individual items via email with the ability to edit and update messages you’ve already received or sent. Although Chandler Preview is not meant to replace your email application, you can configure your IMAP account so that Chandler can see some messages from your regular mail client.

We’re currently planning a 0.7.1 release in about a month, to quickly iterate on the Preview release. We’ll make use of user feedback to identify problems and drive priorities.

Chandler Hub
We upgraded Chandler Hub to the 0.7.0 release of Chandler Server on August 27th.

The latest release of Chandler Hub also adds a dashboard for managing tasks (and other kinds of data) to basic web calendaring features. Friends and family can access shared collections from the web without having to create an account or log in. We’ve focused on workflows that let desktop users share data with others using the web; this release is a major step towards realizing the full Chandler vision on the web as well as the desktop.

We’ll be upgrading the service with small fixes on a weekly basis for the next month or so, fixing minor glitches and adding support for Safari.

Chandler Server
The Chandler Server 0.7.0 release is available for download as a ready-to-run bundle. We’ll be creating 0.7.x releases as we improve the Hub service. In parallel, we’re working on a 0.8 release that is focused on interoperability with other calendar applications and services such as iCal, Google Calendar and Evolution.

Try out Chandler
We believe you can now feel confident putting your data in Chandler. We have migration features to make upgrading easier, and will do our best to support people if they run into problems. (The chandler-users@osafoundation.org mailing list is a great forum for support). These releases do have some bugs and rough edges, so Chandler might not yet be appropriate for mission critical uses. We are using the desktop and hub internally day to day for our office calendar, personal calendars, personal project management, and several small group task lists. We hope you’ll join us using Chandler — let us know how you like it! We’ll use your feedback to make a better 1.0 release.

Get Involved
One of our goals for this Preview milestone is to grow outside involvement with the project. We want users to log bugs. We want designers to collaborate with us on ideas. We want developers to submit patches fixing bugs that annoy them, create desktop plugins with their favorite features, and write clients that take advantage of their data on the server. Check out how to get involved.

Mitchell Baker started a conversation about the future of email at Mozilla, looking for people to participate in “a new vision of mail”. OSAF should be engaging in this conversation, looking for ways to collaborate with Mozilla.

We’ve been looking at email as an important part of the Chandler project. Our approach has been to design applications around user problems and goals, in particular for informal groups working together. Our starting point was the observation that people use their Inbox as their task list. Another observation: calendaring is fundamental to task management; integration of messaging with calendaring makes a lot of sense with user workflows. We think that people will benefit from integrating email, tasks, calendar, contacts and other related information in one application, instead of having to do the work of patching together information across software tools, protocols and data formats. We’ve observed people collaborating on shared problems with email; we think there are huge gains to be made by converging personal communication and group collaboration. Email protocols are not the only route for communication; social networking and other messaging paradigms are other important areas to explore.

The Chandler team is currently working on a Preview release expected by the end of August: a usable version of the desktop application, rich web application, and server. We’ll also launch our free hosted service, Chandler Hub (an instance of Chandler Server).

Chandler Desktop will not be a full email client in the Preview release, but great email support is important to our full vision. Our research shows that many people sit in their email client all day as they try and manage their personal information and work on projects with others. Chandler uses email protocols for “sharing” items (calendar events, notes, tasks). It also has enough basic email functionality to allow users to get email into Chandler to manage a task list and calendar, but as a complement to an email client. Filling out Chandler to be a full email client is one of our options for a 1.0 release.

If you want more information about Chandler ideas, you can read the latest draft of our vision document or explore our wiki. A user guide and screencasts will be showing up as well. You can also experience Chandler in action by downloading the desktop, server, and/or creating a free account on Chandler Hub. Even though we haven’t released Preview yet, the recent desktop checkpoints are usable (modulo a few bugs) as is the previous release of the server (it doesn’t have the full Preview feature set). We use it internally to share group task lists and manage an office calendar.

The Chandler team is focused on getting our Preview release out, so we’re pretty busy through August. We anticipate getting interesting feedback from Preview and we’re going to let that guide our next steps.

I’m not yet sure where a collaboration with Mozilla would lead or what it would mean, but I think we’re looking at a similar problem space and it makes sense to see if we can forge a common path and combine resources. We offer a perspective on the problem, a server and a desktop application, and a team of people who are excited about doing creative things with personal information management (including email). Once we have Preview out, I intend for OSAF to participate actively in the conversation about email futures.

We’re closing in on our Preview release, currently on target for launch in late August.

Hub (hub.chandlerproject.org)
The service is running the 0.6.1.1 version of the server, and works well with desktop checkpoints. We maintain our OSAF office calendar on the hub; several OSAF’ers are now using desktop checkpoints with the service to manage shared task lists.

Desktop
The desktop team has hit the code complete deadline for 0.7, and is closing in on Zero Bug Release.

You can download the latest checkpoint now and and give it a spin. It is more stable than the last alpha release or than the 0.6 release, and contains data migration features for upgrades.

Server
The server team hit feature complete for its 0.7 release, and is busy testing and fixing bugs. Upgrading the hub to use the 0.7 version of the server will determine the launch date.

Website and Wiki
We’ve improved our web presence and cleaned up our wiki (though we still have a little work to do before launch). We’re also working on end user documentation.

• http://www.osafoundation.org/
• http://chandlerproject.org/
• http://chandlerproject.org/wikihome

The OSAF team has been busily focusing on our “Preview” releases — functional products that are interesting enough for people to try out and give us meaningful feedback. (”Preview” will not be 1.0 — more like a usable public beta). Our original goal was to have these releases ready this month — we’ve adjusted our schedule to June. The countdown to Preview is tracked on our wiki.

Help us!

If you are adventurous and want to help out the project, we’d love to have people trying out the desktop application and the web application even before we get to Preview. Find bugs and help us make it better! Join the users list, download the latest checkpoint of the desktop application, or check out the web application.

Branding

Chandler was originally a code name for the desktop application. After careful consideration, we decided to use the name for the whole group of products (the desktop application, the online service and the server that runs the service). We’ve chosen a domain name (chandlerproject.org), and we’re working on a new logo. We’re also cleaning up our wiki and our websites as we near Preview. We discuss this work on the general mailing list.

Chandler Desktop

The desktop project hit a feature complete milestone on April 9. New features include recurrence and auto-triage of items in the dashboard, editing and updating items via email, Chandler IMAP folders, context menus, a new sharing format, conflict management, and data migration features. The team is working on performance now, and will spend many weeks after that fixing bugs.

Chandler Server (Cosmo)

“Chandler Server” is our new name for Cosmo. The 0.6 release of Chandler server was described in an earlier post. The server team is currently wrapping up the 0.6.1 release, which implements a new sharing format for data exchange with the desktop application. The team has also started on the 0.7 release, which will allow users to view and edit shared tasks and events in a table.

Chandler Hub (osaf.us)

“Chandler Hub” is our new name for the online service hosted by OSAF, running Chandler server. The service is currently running the 0.6 version of the server. We plan on moving to 0.6.1 in a few weeks, and upgrading to 0.7 in June. Once we’re ready to “Launch” Preview, we’ll use our new domain name (chandlerproject.org).

Scott Rosenberg’s new book about OSAF’s first years comes out this month, titled Dreaming in Code. Scott is a friend of OSAF — he spent a lot of time in our office, hanging out in meetings as a sort of “embedded reporter”. I’m not going to comment on OSAF’s adventures during that time period — you can go read the book for yourself. Instead, I’ll give an update on what OSAF has been up to since Scott’s narrative leaves off, around the end of 2005. At that time, we had narrowed our focus to get a calendar working, cutting out many interesting features. Since then, we’ve made a lot of progress. We’ve added a Dashboard for managing other types of information (including tasks, notes, messages) and improved polish, performance and reliability. The Preview release around April 2007 (described below) should be a good release for people to try out Chandler and Cosmo for the first time.

Cosmo

The Cosmo project was just getting started at the end of Scott’s book. Cosmo is currently both a web calendar and a server for sharing data. The Chandler desktop application uses the Cosmo server to share data; shared calendars can also be viewed and edited in a browser using a Cosmo URL. Eventually Cosmo’s web client will be as full featured as Chandler, supporting tasks and other types of information. Cosmo’s server implements several standard protocols, so data can be accessed from other clients as well (including Apple iCal and Mozilla Sunbird). One of the big changes at OSAF in the last year has been the increasing importance of the Cosmo project. We’ve been designing Chandler and Cosmo so that they can be used in tandem.

Using Chandler and Cosmo at OSAF

With the release of Chandler 0.6 in late 2005, we started using Chandler and Cosmo at OSAF. Chandler at 0.6 was pretty rough — but we got good feedback and made significant improvements. The most recent milestone, Chandler 0.7alpha4, runs much more quickly on the Intel Mac, has a more polished calendar, and has the first workable Dashboard for tasks and notes. Several of us at OSAF brave the rough edges and use Chandler for our calendaring on a daily basis. Mitch and his assistant Esther are currently using 0.7alpha4 to share a calendar.

Preview

We set a major goal for ourselves last year: GET USERS OUTSIDE OSAF! We’ve been focusing on a “Preview” release for Chandler and Cosmo that will be functional and interesting for end users. While Preview will not include everything we want to accomplish for a 1.0 release, it will provide a tangible, plausible promise of the fully-fledged application we’d like to build.

Setting this goal has been a key step in transitioning to a “ship it” mindset from a more chaotic big tent of interesting ideas. Once Preview is out we can start building a community, since we’ll have something real people can use to solve real problems.

It was important to us that the Preview release contain some of the features that we’ve been excited about from the beginning: “stamping” features to blend tasks, events and notes; and “triage” features to manage important information in one view. It was also important to coordinate Chandler and Cosmo designs. We set a goal of Q1 2007 — my current best guess is that we will hit Preview in early April. Feedback from users will shape the remaining work towards a 1.0 release.

Informal workgroup collaboration

Early in 2006, we did a gut check and reevaluated our priorities. From the beginning of the project we struggled with too many ambitious and sometimes competing goals. The end result of a prioritization exercise was a tighter focus around small workgroup collaboration. Note that we never aspired to be an “Outlook killer” — we’re more passionate about solving problems for informal groups than for enterprises.

To make decisions about the feature set for Preview, we used the technique of identifying target users and the workflows they would use to accomplish their goals. Our keystone user is a person who sits in Chandler every day, using the desktop app for projects and tasks, as well as calendaring. We refer to this type of user as a “Hub”. The Hub interacts with “Casual Collaborators” — people in the Hub’s workgroup who don’t run their life with a calendar and task list or people outside of the group. The Hub might send a URL to the Casual Collaborator, who can then use that URL to access a calendar or task list on Cosmo. An example scenario: individual contributors in a workgroup edit their PTO on a shared office calendar (via Cosmo), which is largely maintained by a project manager (using Chandler). More info on target users and the Preview feature set for Chandler and Cosmo can be found on our wiki.

osaf.us

We’re going to host Cosmo as a free service starting in March or April (when Preview is ready) . Small groups will be able to use the service to share calendars and task lists instead of running their own Cosmo server. Someday we’d like small workgroups to be able to run their own Cosmo server without much hassle, but that will require more work. Braver souls can download Cosmo and try it out, though.

CalDAV and interoperability

CalDAV is an emerging calendaring standard; Scott chronicles a bit of Lisa Dusseault’s involvement breathing life into CalDAV. Cosmo is a CalDAV server and Chandler is a CalDAV client. OSAF remains committed to supporting standards based interoperability — we test against other servers and clients at Calconnect events and fix bugs when we find them.

People

Several people mentioned in Scott’s book are no longer working with OSAF, including Andy Hertzfeld, Michael Toy, and Chao Lam. Lisa Dusseault moved on to focus on IETF work as an Area Director. Each of these people made significant positive contributions to the project. We have new talented developers and designers working on Cosmo and Chandler who don’t appear in the book, appear only briefly, or have taken on new roles. The current team deserves a lot credit for pulling Chandler and Cosmo together as healthy, productive projects. I’m pretty excited about both and am really looking forward to Preview.