[Chandler-dev] Some use cases and opinions

[Sam Halliday]

Hi all,

Both Mimi and Travis suggested I join the dev list and post my  
comments and use cases... and lurk until I can see something I can  
help out with on the dev side. I can code Java, but never written any  
JSP. I have J2SE, GWT and J2ME experience though. I guess my interest  
at the moment is in enabling server-side functionality and understand  
the Cosmo protocol. I'm very busy in work hours, but I do have some  
spare time coming up in the evenings so I may be available to do  
something.

# Project/Calendar Management Use Cases

The best way to explain what I would like to use Chandler for  
(especially the web app) is through some use cases... I'll describe  
them in the 1st person. I've been told some of these are already  
supported on the desktop app, but I haven't been able to check that  
out as SSL support on OS X is broken for me. I also have some  
opinionated comments at the bottom.

## Use Case: Set up a meeting

Task: I want to schedule a meeting with a client (and some members of  
my team) and enter it into our calendars.

Steps to accomplish:

- I need to arrange the meeting with the client in person/phone/e- 
mail, independent of Chandler. Although I will use Chandler to see my  
availability and the general availability of my team. I might get back  
a list of possible dates from the client, rather than a specific date.
- I need to create an event (which may have multiple unconfirmed dates  
and locations) and request members of my team to attend. I might need  
one person to join me, but I will invite several of them and let them  
decide who comes.
- I await their responses... some people may not be able to attend on  
certain days, so this needs to be captured.
- I want (and my team also want) to be able to add internal notes to  
the event, and possibly an agenda.
- I can then get back to the client with a more solid date (or set of  
dates).
- When we have agreed a specific date (independent of Chandler), I  
would like to be able to send an e-mail to the client, containing  
information on how to get to our offices and possibly an agenda for  
the meeting... but excluding any internal notes my team may have added  
to the event. An Outlook-compatible attachment would be nice, but by  
no means a priority... I don't want to assume anything about their  
calendar solution. Most people use pen and paper anyway!

There is a *lot* in that use case... but the core functionality is

- being able to create an event that I can invite other users to
- being able to see if they are attending or not (like Facebook events)
- being able to collaboratively edit the event details

and no e-mails exchanged between my team at any point... the only e- 
mails are with our client and only the very final one (and possibly  
the penultimate one) is generated from Chandler.

## Use Case: Delegate a task

Task: I want to be able to create a task (with a deadline) and assign  
it to somebody in my team.

Steps to accomplish:

- I need to create a task explaining what needs to be done and for  
when. (examples are "get your report to me by Friday", "write that  
test case" or "fill out your expenses form and put it on my desk").
- I delegate/assign it to somebody on my team (or multiple people)
- They get a notification of the task and it appears in their task list.
- I get a notification when they have finished, or if they have not  
finished the task before the specified date.

It seems a fairly simple use case... the important thing is that once  
I delegate it, I don't want to know about it until it either happens  
or the deadline is missed. Again, no e-mail involved. If they reject  
the task, I want to know about it.

## Use Case: Jotting down lots of ideas

This is much less important than the previous use cases... but would  
be good to have and is a part of the "Getting Things Done" philosophy.

Task: I want to be able to write lots of little micro-tasks (or TODOs)

- I want to capture lots of ideas, but they aren't quite solid enough  
to be tasks yet and certainly don't have any start/end date at this  
stage.
- I don't want to be distracted by them when I look at my current list  
of tasks and events... they shouldn't appear in either view.
- I want to be able to revisit them when I have time and elevate them  
to tasks or events.

I realise that this can be mostly accomplished by creating an event  
and not adding it to the task list or calendar. But it would be good  
to be able to distinguish these from tasks, events and ideas that need  
more thought... it would also be very good to be able to prioritise  
items in the same way iCal does.

# Some general comments

The following comments are much more opinionated than the use cases.  
They are how I would like the UI experience to be and some technical  
details :-) So feel free to rebuke them with all your might.

## On e-mail and communication in Chandler

I really hate the concept of using e-mail as the messaging system in  
Chandler. Some people might want to receive all their notifications  
over e-mail (like some people do in facebook)... but for me, that's  
too much in my (already overflowing!) inbox. I would prefer all  
Chandler communication to remain within Chandler (i.e. the web/desktop/ 
mobile app).

For example, perhaps there is a user who likes to receive everything  
in e-mail form, and never logs onto the server... but instead does all  
their task and event management from iCal/Outlook. When I invite them  
to an event or send them a task, they will get an e-mail about it  
because it is in their preferences to receive notifications that  
way... they can even accept/reject/complete tasks over e-mail  
(clicking links or replying with subject headings or similar). But I  
never have to see it... that's just their preferred UI.

Is the messaging codebase abstract enough to allow multiple input/ 
outputs? I can imagine some people in my team wanting notifications on  
SMS or twitter. In fact... I'd love to get SMS notifications if an  
event is cancelled and it was within 24 hours of now! (I'm not  
suggesting that you host an SMS gateway! Just asking could that sort  
of exchange be supported via the Cosmo protocol if somebody wrote a  
server to act as the middleman?)

## On Desktop vs WebApp vs Plugins

If you're thinking about desktop at all, then I'd suggest that Outlook/ 
Sunbird integration should be a priority (with no plugins allowed on  
Outlook)... not a Python app. The reason for this is because most  
people in management will feel much more at home in Outlook. Outlook  
can speak to servers, right? How well documented are those protocols?  
Could Cosmo pretend to be an Outlook server?

Python is great for prototyping code but is it really helping  
functionality to be ported back to the webapp? There is a lot of code  
re-implementation since the server is all Java. If I had my evil way,  
I'd have made the desktop app all Java (or Groovy, which is a lot like  
Python/Ruby) so that server code could be reused on the client side  
and so that the desktop app could be a way to quickly implement new  
features that can be easily ported back to the webapp. It would also  
mean more eyeballs on core code and provide a set of libraries that  
would make porting to other platforms (e.g. J2ME or Android) so much  
easier.

I would be interested in helping out with a Java-based desktop client  
as a quick way to prototype functionality for the webapp (and to pave  
a way for a mobile app). If there is no messaging system yet, then  
server-side I might be interested in helping out there instead. Where  
would be the best place to start to understand the protocol used when  
speaking to the server? (please say xml!)

Should I add all of these points as RFEs or is it more appropriate to  
discuss them here?

-- 
Sam

http://fommil.me.uk
http://javablog.co.uk