Katie suggested that we look at the different ways in which the Mozilla community have customized and added to the Firefox browser and Scott pointed me to Mozilla Add-ons
as a good starting point.
A lot of the thinking below is simply echoing ideas and sentiments about extensibility that have been floating around OSAF from the very beginning. I'm simply struggling to come up with the right UI structure to help realize the original spirit of Chandler as a Platform.
Perusing the list of extensions, most can be categorized in one or more of the following ways:
- Enhancements to existing features (ie. Auto Copy, FlashGot, Tabbrowser Preferences, Virtual Joint, What is a cookie?, Filer Extension, Linky)
- New tool-sized features (ie. Auto Copy, ConQuery, DictionarySearch
- New client-sized features or Applets: Features that could exist as standalone apps (ie. Chatzilla
- Utilities: an extensions that doesn't really have a UI and is more a preference setting (ie. Disable Targets for Downloads, FlashGot, Tabbrowser Preferences, Bandwidth Tester, Virtual Joint, What is a cookie?, Gmail Notifier, Filer Extension, Slashy, Linky)
So the first issue is scale
. Can we identify discrete levels of scale? A brainstorm of likely extensions would help answer this question. If we're able to come up with a reasonable structure for scale, that will helps us structure the GUI so that it's easy for developers to understand how they should integrate their extensions into the interface. (ie. Preferences panel, app bar, toolbar, sidebar, summary view, detail view, status bar, take over the entire UI)
A second issue that is perhaps unique to Chandler is to figure out how to best structure the content model so that it is extended in a comprehensible way. I am currently writing up a StampingRevisited
page which puts Stamping in the context of extensibility by distinguishing between 2 types of Kinds: Stamping Kinds and Object Kinds...both of which could be extensible.
I think this second issue is crucial and in some ways more important than first. Getting the content model right is important for both users and developers and is the key challenge to the success of any general information manager.
Picturing the right
content model. How do we know if we have the right content model? It scales. Which means that as Chandler extends, the user experience remains fluid and integrated.
This won't always be possible. Sometimes it won't make sense for an extension to be integrated and we can't and don't want to control what the community does lest we lose the benfits of independent thinking and diversity. However, we don't want to forsake opportunities where it does make sense to integrate and the community actively wants to take advantage of the existing Chandler UI structure. As a general information manager, the Chandler UI has a lot of room to grow in terms of taking on more Kinds (ie. RSS feeds, Documents, Media files, Directories, etc) before it's exhausted the genre.
An even stronger statement would be to say that Chandler wouldn't really be an innovative general information manager (at least from the user experience standpoint) if we allowed it to balkanize into discrete applets (ie. Photo manager, Document manager, Contacts directory). All of our efforts to break down silos within the PIM domain would fail to extend to the general information management world and Chandler would be left with the single fatal flaw that is the downfall of most information management systems: Segregation. Segregation between data and what you can do with the data (ie. OS file systems v. Applications). Segregation between different kinds of data (ie. Word v. Outlook v. Photo organizers). Segregation between data types as a result of differences in taxonomy structures and meta-data. The list goes on.
That being said we can't predict the future, but some rigorous brainstorming should help us figure out how Chandler might grow. (Which shouldn't be hard given that there has already been a lot of thought and excitement around Chandler as a GIM.)
- Extensibility brainstorm
- Review StampingRevisited