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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
