Currently in the planning stages, Avocado is the web UI, intended to replace Dragonfly. Crystal makes up the server backend, and the Javascript message transport API.
Contents |
[edit] Status
Code is currently under development. We're hoping to put this in the next major release. Basic read-only mail support is working. Some key features underway:
- Pagination
- Mail composition
- Setting properties on mail (eg read/unread, staring).
[edit] Installation
For the brave, you can try out Avocado installing Crystal and then moving on to installing Avocado on top of it.
[edit] Features
This section won't be complete until we finish a prelim release. :)
[edit] Core plugins
As Avocado is modular in design, the core of Avocado would only contain the interfaces and API, as well as a GUI skeleton. The following plugins would be available together with the core Avocado release to provide some sort of functionality to the end user:
- Mail (in progress)
- Calendar
- Summary
- Contacts
- Instant Messaging
[edit] Some planning stuff that needs cleanup
[edit] Target userbase
- Personal computers?
- Mobile devices?
- Non-Bongo users?
[edit] Project aim
To provide a clean, well thoughtout, accessible web interface for <target userbase>, solving some portion of the issues presented in the 'Problems' section below.
[edit] Problems
There are several problems associated with current email and calendaring clients. Design for these clients has not changed over the past few years, to keep up to user's changing demands. This section describes several of these issues.
[edit] Information overload
We need to provide a way to cut down the information displayed to the user to only the things he/she needs or wants.
[edit] Keeping track
Many users get lots of email everyday, and a majority of the time, they are not responded to immediately. This could be because the user is awaiting on something or somebody else, or need to attend to more important issues. It is common for the user to become 'lost' under the volume of mail they recieve and forget about the other emails they need to respond to. Other people have lots of calendar appointments, and it often becomes hard to manage all their appointments, especially when you need to co-ordinate things with others.
[edit] Locating information
It often becomes hard to track down information quickly. Email search is generally quite limited and slow, subjects aren't always useful, and email does not contain all that much context. Some users sort their mail into 'folders' as to make it easier to find some information in the future. However, this adds a management overhead to their day-to-day mail - some people spend an inordinate amount of time cleaning up their inbox into folders.
[edit] Disjointed workflow
Relationships between objects are almost non-existant in some email clients. Calendar items, emails and chats are seen as seperate objects, when they could quite easily relate to the same thing. Creating an appointment after discussing times and a location with your contacts via email and IM requires you to manually collate the information about possible times, decide what would be best for everyone, setup a calendar event, email everyone about the final date/time, and get them to confirm. This honestly requires a lot of work on the part of the user; possibly a reason eletronic calendaring is not utilised by many.
[edit] Staying in sync
Many people use mobile devices, as well as many new Web 2.0 websites. These all use slightly different sets of data. We should be able to share all this information, and collate this into something useful. For example, it takes a while for you to manually import all your contact information from your mobile phone; you might be able to gather data you don't currently have about your contact(s) - for example, if you only know the name of a representative from Yoyodyne Corp., you could sync with her contact information, and automatically fill in her work phone number, address etc.
[edit] Overloading email
Although email was originally designed as a asynchronus communication tool, it is now being used for other tasks, including information management, task management, contact management, record keeping and file transfer.
[edit] Observations
- Flags are useless.
- Users don't like automatic filing systems.
- Users can be classified as "No-filers", "spring cleaners" or "frequent filers".
- Users are often control freaks when it comes to displaying information.
- Programs should not force users into a particular way of organising emails, however, it can be allowed to nudge them in a particular direction (this should be editable as a setting if it could be coming annoying, however).
- Users often mistrust filters.
- If a message is out of sight, then the user is very likely to forget the message ever existed.
- Todos are very important, and should be linked to mail; with or without a due date.
- Almost all email in users' inboxes that are not classified as "frequent filers" can be deleted if it has been read.
[edit] Ideas
Feel free to jot down your ideas here!
| Component | Name | Description | Helps solve |
|---|---|---|---|
| Thread Arcs | Thread arcs are a compact overview of the other messages in a thread and their relationships to each other. One can navigate to these other messages via the visualisation without having to go back to the Inbox list. | Locating information | |
| All | Relation-based suggestive actions | Allow objects (emails, calendar items, contacts) to have other, similar items linked together. Items created by automatic actions (eg clicking on a date in an email to make an appointment) should generally be automatically linked, so that the email and appointment are related. Provide a way to see other likely related objects by performing a search in the background and display related results. | Locating information, keeping track, disjointed workflow |
| All | Context-based suggestive actions | Provide links to start actions based on the context of the link/sentence/object. Dates in emails and chats (eg "tomorrow", "at 7PM") should be clickable to make appointments (with the email referenced, see above); names of contacts should provide 'contact cards' with the ability to initiate chat, etc. | Disjointed workflow |
| Mail, Calendar | Object Sources | Many applications use email as a notification mechanism. For example, changes in a collaborative web site (eg a wiki), or transaction confirmations (like an Amazon book purchase) trigger automatic email messages. It could be possible to integrate each of these sources into the message view, so that you could have your RSS feeds or purchase progess alongside your email, while still being to toggle these sources on and off without affecting mail. You can also search and sort through these seperately. | Information overload, locating information, overloading email |
| Weighted messages | Emails could be weighted in three categories: contacts with/without a star; factor of whether or not the user has replied to the conversation (making it more important if he/she has); and weighting conversations in reverse proportion to the number of recipients the original email received (however, this shouldn't not change a message's weighting as much as the other two categories) - this enables removal of low content high noise conversations such as mailing list flames. This could be also be weighed contually on all new messages to the conversation? We could discuss the exact algorithm when the time comes to implement it. | Information overload, keeping track | |
| Search | Instant filtered search | Instant 'type-and-refine' search is quite often fast and useful to the end user, as it enables them to quickly navigate to whatever they need using the least amount of effort. They can instantly see whether a keyword is returning the right results, and if it is, it allows the user to not type more than is required to get the search results they need. Search should be provided by filtering both the current view, and searching the entire system; the option provided via a dropdown or radio button. The view should not change if filtering, merely removing non-matching items. | Information overload, locating information |
| Dual-mail view | As many users primarily 'live' in their inbox, it makes sense to keep this the most relevant to the user. Only unread messages would ever live in the Inbox, read messages marked as done or archived live in Archived. Messages can be in other states, such as Postponed, etc. See the Inbox Zero idea below for more information. | Information overload, keeping track | |
| Inbox Zero | Basically, provide mail to be in all the states (actions) he described. Marking as done makes it read (archived), deleted etc. I should probably fill this in and be more descriptive, but it's getting late. | Information overload, keeping track |