I agree, totally. Alongside that, I see a gamut of problems that arise from people’s preconceptions of what systems can and should do.

I have followed the OSAF/Chandler caboodle, albeit from a distance, from the outset. I recall Mac magazine interviews with Mitch Kapor, in which he expressed a long term vision for Chandler. AFAIR this was pre-establishment of the Foundation.

A critical point, a very positive observation: whilst I often wished for things to be realised sooner, at no time during the years of development (including the slippage) have I been disappointed with delivery.

(I set aside my preconceptions of what Chandler 1.0 might be.)

http://slides.diigo.com/list/grahamperrin/osaf-chandler was prepared in another context but I’ll throw it in here for good measure.

http://www.diigo.com/annotated/83ed6c0b930c4a1bc5072ed4edfde9c7 for an annotated view of this page.

Best regards
Graham

Thanks for the feedback. You have a good point about the distinction between getting started and sticking with Chandler.

Your point about “what user specifically wants to do what specifically with Chandler” is interesting. I’m not familiar with Mike Cohn but will look that up. I’m working on a post about the updated plan — will be interested in your take on the plan with that point in mind. I’ll link to the work queues — they are actually very specific lists of bugs.

The two goals in your Feb 15th posting seem the most clear and focused of all to me on this blog entry, comments included. Thanks for boiling it down to those.

I would like to suggest being a bit more specific with the first goal. For example, by breaking it into two similar goals that I think have different work queues.

-Fix problems for Beginner users who get blocked when they first try and use Chandler.

-Fix problems for Advanced Beginner users who get blocked when they first try and use Chandler.

I’m defining Beginners as those having problems starting up at all with Chandler, and Advanced Beginners as those who get blocked from sticking with Chandler, and recommending it to and involving others in their usage. However, the exact boundaries are not so important as getting even more specific, in my opinion.

What user specifically wants to do what specifically with Chandler, so that specifically something they value happens…(along the lines of Mike Cohn’s user stories, themes, and epics). If work queue items are less than very specific, I think the many competing forces will make it hard for the project not to drift again.

My two cents.

We really have two goals:

1. Fix problems for people who get blocked when they first try and use Chandler
2. Add functionality that makes Chandler more viral

The first one requires changes to desktop, server, web ui, project website, etc. etc. With the second one we’re trying a series of small experiments to see what will take. Are there too many experiments given the number of developers? Possibly — we’re adjusting that as we get down to the specific work queue.

Perhaps it will make more sense to you as we execute on the plan, or perhaps not, or perhaps you won’t choose to continue following the project because we’ve ruled out the goal you were interested in. I’m confident that we’re going to have a really great offering for a group of folks — but we’re not going to please everyone. I’m happy that the team feels focused and is making good progress, and am excited to see the emerging widgets and desktop changes.

We made a decision *not* to try to recreate the desktop experience on the web, at least not in the next year. For one, we *have* a working desktop application that people use. I know that you and a some other folks have a strong preference for a web app to a desktop app — and that there are others who feel equally passionately about their preference for desktop apps.

The web widgets projects is a modular approach to build simpler web functionality that is still useful. It bears some resemblance to your suggestion to start over — we want each step to be useful and polished, rather than doing a big bang rewrite. The work on the web widgets will pull working logic from the existing code where that makes sense. It may also be a foundation for a more substantial improvement to the web app.

That said, we *do* need to make some improvements to the web app to make sure that basic functionality works correctly for the various types of users using the Hub service — as we’ve been detailing out the work queue we’ve decided to make that a priority.

I’m glad you appreciate the server code — I agree that it is a strong offering. You are correct that we could change the bundling — so far we haven’t had a good reason to do so, but could consider that in the future.

This sounds like a lot of double-speak. Wasn’t there an announcement that OSAF laid off staff? Now it seems like they’ve expanded their projects from 2 (desktop, server) to 5 or 6 or 7, depending on how you look at it, with a fraction of the people? I don’t get it. It’s as though 2 products were actually too clear of a vision, so you’ve fragmented whatever that vision is into many, confusing products.

Oh no! We have too many users who know what we’re doing! Everyone scatter!

Neither comments from Katie or Mimi above really explain anything except that OSAF acknowledges its own failures to communicate it’s vision.

It sounds like you’re saying “We’re not building anything specific, so if you come to us with a specific expectation, we probably won’t meet it” which pretty much guarantees disappointment for all.

I wish you all the best of luck, but I sure don’t get it.

Our focus for the next year is to continue to build our user base around the core value of the Chandler ecosystem (Desktop and Server). Our best articulation of our core value to date is:

Chandler is a way to manage and collaborate on ideas using:

1. A List View built around the idea of the Triage Workflow
2. A Calendar View
3. Chandler Hub Sharing Service

We believe the user problem we are serving is an emerging market. That is one of the reasons why we’ve had such difficulty articulating our direction, there isn’t a shared, public vocabulary to describe what we’re doing. Probably the product that best matches our efforts in terms of ‘problem-space’ is Microsoft One Note.

Sometimes it helps to explicitly state what we’re *not* doing.

+ We’re not looking to be a cheaper alternative to Outlook/Exchange. This means we’re not investing in support for free/busy-style scheduling.
+ We’re not looking to be the ‘everyman’s’ version of Microsoft Project or Bug and Ticket-Tracking systems. This means we’re not investing in support for complex task and project management, e.g. task dependencies, tracking percent done, time estimates, robust support for assigning tasks, etc.
+ We’re also not going to be implementing the GTD methodology.

Instead, Chandler is meant to replace some of things people use text files, paper notebooks and email for. It is a separate space outside of the hub-bub of email where you can track, develop and collaborate with others on ideas, thoughts and questions for the projects and tasks you need to do.

This includes:

1. Better product messaging so that people understand what ‘user problem’ we’re trying to solve and how we’re trying to solve it.
2. Re-shaping the user experience to better express our value proposition and help users get started.
3. Lowering the barrier to entry to using Chandler by providing more ways to get data in and out of Chandler via the Chandler Hub Sharing Service with a Thunderbird plugin and web widgets (in the browser, on mobile devices and on the desktop).

I also don’t understand why your web client and desktop client wouldn’t have the same features, but I didn’t really understand any of the rest of this either.

Like many people I once had such high hopes for this project.

I’ve also started communications with Jared and Randy to persuade them to implement an abstract communication layer between users on the same server. I don’t think e-mail should be the core communication media between users. If it were made abstract (i.e. the server itself handles it), then multiple communication media are possible such as SMS, Twitter, e-mail, Facebook, widgets, IM, J2ME, webapp, desktop.