There are many features that are missing from Helium. The list below briefly describes some features that are desired in future versions. If you are interested in helping to bring these features to the light of day, visit the developer documentation. Each of the features described will not be hard to do, in part because of the flexible nature of the KnownSpace environment.
Additional information about missing features and bugs can be found in the Helium roundup database.
In the current release only email messages that are either plain text or HTML can be displayed. Other formats are stored but cannot be viewed.
Future releases of Helium should add support for additional MIME types. At this time the format that are most missed are multipart/mixed and multipart/alternative MIME messages. Supporting these implies support for many other MIME formats as well.
The ability to access and manipulate groups of messages based on message threads would be very helpful. The mail header information required to determine threads (the In-Reply-To and References headers) is already stored by Helium, but it is not yet used.
To get new mail a user must manually press a button as they remember it. This is exactly the sort of tedious task computers are good at. In the future, new mail should be retrieved every few minutes, with a configurable interval.
Helium was originally envisioned as an email navigation tool. Something that could reveal connections in a large body of email. To make that large body of email, large numbers ofemail messages need to be gathered from many different locations. To make that easier it should be possible to configure Helium to download all the mail that exists for a particular user on a particular server.
There are times when Helium is engaged in some activity, such as retrieving new mail or recalculating layouts, that makes the system busy. It is not always that work is in progress. In an ideal setting there would be visual indicators that show that the system is busy.
For example, when email is being downloaded, a graphic should engage indicating mail is being transfered.
These sorts of visual feedback providers go a very long way to making an interface more usable.
When a message or group of messages is selected in one view, such as the list view, the corresponding messages in other views, such as the visualization, should be highlighted. This will allow a combination of visual and textual ways of interacting with messages.
In the long term, in order for Helium to be a valid tool for communication, it must be able to support reading and composing messages that are signed or encrypted with PGP.
Annotations are a system whereby a user may add a note to a single message or group of messages as an indicator of their meaning or as a reminder. Later the annotations can be used as a retrieval mechanism.
For example, a group of messages could be annotated with the word "friends" to indicate these messages have something to do with friends. Later all "friends" messages could be retrieved.
This may sound a lot like folders. It does provide some of the same functionality, but it does not have the same restrictions. In traditional folder storage a message may only be stored in one place. With annotations, any message may have multiple annotations and thus be in multiple categories at once.
Work is under way to use latent semantic analysis to create semantic clusters of messages. The same methods used for that process may also be used as an index for search queries that are more flexible than the simple text queries currently available.
A search of a collection of messages returns a list of messages which is a view of the messages through a filter. Some searches are common. A desirable feature is the ability to access and reuse previous searches as needed, with a simple gesture of the mouse or a keypress. These searches should be saved between sessions just like mail and configuration information.
It is common for people to retrieve their mail from multiple servers using multiple identities. Helium should support multiple identities easily by providing a mechanism for creating identities and for reusing them between sessions. When switching between identities no new configuration information should be necessary, just the selection of an identity.
The number of messages that Helium can work with is currently constrained by memory. Code is in progress that will allow messages (or more generally, Entities, see the developer docs) to be stored on disk as needed. Only those messages that are actively in use will be kept in memory.
This feature is almost done but is not quite stable enough to include in the current release.