OSAF’s Next Steps
February 6th, 2008 by Katie Capps ParlanteLast 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).
free viagra
buy viagra online
generic viagra
how does viagra work
cheap viagra
buy viagra
buy viagra online inurl
viagra 6 free samples
viagra online
viagra for women
viagra side effects
female viagra
natural viagra
online viagra
cheapest viagra prices
herbal viagra
alternative to viagra
buy generic viagra
purchase viagra online
free viagra without prescription
viagra attorneys
free viagra samples before buying
buy generic viagra cheap
viagra uk
generic viagra online
try viagra for free
generic viagra from india
fda approves viagra
free viagra sample
what is better viagra or levitra
discount generic viagra online
viagra cialis levitra
viagra dosage
viagra cheap
viagra on line
best price for viagra
free sample pack of viagra
viagra generic
viagra without prescription
discount viagra
gay viagra
mail order viagra
viagra inurl
generic viagra online paypal
generic viagra overnight
generic viagra online pharmacy
generic viagra uk
buy cheap viagra online uk
suppliers of viagra
how long does viagra last
viagra sex
generic viagra soft tabs
generic viagra 100mg
buy viagra onli
generic viagra online without prescription
viagra energy drink
cheapest uk supplier viagra
viagra cialis
generic viagra safe
viagra professional
viagra sales
viagra free trial pack
viagra lawyers
over the counter viagra
best price for generic viagra
viagra jokes
buying viagra
viagra samples
viagra sample
cialis
generic cialis
cheapest cialis
buy cialis online
buying generic cialis
cialis for order
what are the side effects of cialis
buy generic cialis
what is the generic name for cialis
cheap cialis
cialis online
buy cialis
cialis side effects
how long does cialis last
cialis forum
cialis lawyer ohio
cialis attorneys
cialis attorney columbus
cialis injury lawyer ohio
cialis injury attorney ohio
cialis injury lawyer columbus
prices cialis
cialis lawyers
viagra cialis levitra
cialis lawyer columbus
online generic cialis
daily cialis
cialis injury attorney columbus
cialis attorney ohio
cialis cost
cialis professional
cialis super active
how does cialis work
what does cialis look like
cialis drug
viagra cialis
cialis to buy new zealand
cialis without prescription
free cialis
cialis soft tabs
discount cialis
cialis generic
generic cialis from india
cheap cialis sale online
cialis daily
cialis reviews
cialis generico
how can i take cialis
cheap cialis si
cialis vs viagra
levitra
generic levitra
levitra attorneys
what is better viagra or levitra
viagra cialis levitra
levitra side effects
buy levitra
levitra online
levitra dangers
how does levitra work
levitra lawyers
what is the difference between levitra and viagra
levitra versus viagra
which works better viagra or levitra
buy levitra and overnight shipping
levitra vs viagra
canidan pharmacies levitra
how long does levitra last
viagra cialis levitra
levitra acheter
comprare levitra
levitra ohne rezept
levitra 20mg
levitra senza ricetta
cheapest generic levitra
levitra compra
cheap levitra
levitra overnight
levitra generika
levitra kaufen
February 7th, 2008 at 3:42 am
Widgets? If you’d said this in January 2007 I’d have been excited, but do you not think getting the functionality of the webapp up to speed with the desktop client is a priority? What’s the point of creating widgets if you need to download the desktop client *anyway* to do basic stuff like share calendars.
My 2 cents is to move *all* development resource over to the webapp… the Java-based webapp is really primitive at the moment so you shouldn’t feel too bad about starting from scratch. I’d suggest scrapping it and doing something in Java/GWT to speed up development (or Python if the larger part of your team feel at home in that language). There is no reason why the webapp has to be bundled with the server.
The server itself looks like good code, and I believe the Java/Servlet framework is the correct one… but really, that webapp sucks, and not in a good way.
February 7th, 2008 at 3:49 am
Incidentally… I’d be totally up for helping out with a GWT based webapp.
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.
February 7th, 2008 at 7:09 am
Wow, this really has to be one of the most confusing things I’ve ever read. It doesn’t do much on explaining clearly what’s going on. One place you talk about not doing X, and then later you talk about how you want to do X. I wish the project all the best, but it sure seems like you’re floundering trying to go too many things. With a desktop client, a plugin for Thunderbird and widgets, this seems to lack a clear direction.
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.
February 7th, 2008 at 1:46 pm
Katie Parlante’s blog post was meant to be a summary of what we’re focusing *and* how we got to that focus, so I understand if the ‘clear’ direction that emerged from last week isn’t crystal clear. Here is an attempt to extract just the ‘direction’ piece from her post.
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).
February 7th, 2008 at 8:58 pm
I agree with “w” above – you say you’re a calendar product, but you’re not going to focus on calendar features, but one of your three core strengths is calendar. Which is it? But that’s just the tip of the iceberg.
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.
February 15th, 2008 at 2:49 pm
Sam,
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.
February 15th, 2008 at 3:25 pm
w and v,
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.
March 2nd, 2008 at 5:21 pm
Hi Katie,
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.
March 6th, 2008 at 12:48 pm
Hi Andre,
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.
November 24th, 2008 at 1:03 am
> the user problem we are serving is an emerging market.
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