Arc v' December 2002

It should come as no surprise that I'm still fiddling with project management solutions via "Zope". I've started down a new path, but before I explain it, I want to explain the current situation.

General Requirements

We're a very small organization (two people, with loose associations to other very small organizations). As such, we're constantly busy (thankfully) and don't have too much overhead to worry about in regards to project management. But having a to-do list of any sort is always helpful, and having a place to dump notes and flesh out ideas is always good too. Plus, we're decentralized - we work as much from home as we do from the office, and are often working from multiple machines in either location. Sometimes we need to communicate progress with each other, sometimes it's nice just to have a list for our own uses.

Ideally, content (which could be proposals, notes, software configuration requirements, etc) and issues should be managed by the same system - or at the very least be close to each other. And projects need to be easy to add in to the system by either main user, from wherever they may be. And most of all - it should offer only just-enough project content management features.

What we've used

Last year, we experimented with a couple of home-grown systems. One was a Zope based SQL backed project / task / contact tracking system. Data went derelict rather quickly. I was working on a much more thorough CMF based system with detailed workflows, nested tasks, role assignment, and more. There were a few key features that were difficult to do to meet our requirements, particularly in the non-containment object relation area, an area where Zope has typically struggled (but should be dealt with in Zope 3).

We gave the Roundup (0.4.2) issue tracker a try. While fast, it was still a young product. Too much command line work was involved to set up a Roundup instance, and while there is a Zope-Roundup Gateway available, it didn't integrate too well with Zope based content. I really like Roundup and think it has a lot of potential, but it didn't satisfy our requirements.

Ultimately, we landed in the ZWiki 0.7 + Tracker situation. Each project was their own folder or wiki, and usually had a tracker in it. This approach succeeded on the simplicity category and has been used for almost half a year. But it suffers from a couple of problems. The first is that Tracker is an aging old beast. It's generally pretty thorough, but has some rough edges. It's no longer supported, and I've heard claims that it doesn't work with the latest "Zope" release family (2.6.x).

The second problem is that I'm no big fan of Wiki's. I never have been. They've been useful, but we don't need whatever supposed collaborative effects Wikis are supposed to have. I don't like Wiki names - they either end up looking funny (with words like OneDotOh or ZoPe) or kick in when you don't want them to. Now that I've done some work with reStructuredText, I've come to loath working with Zope's normal StructuredText. It just doesn't work well with TextAreas. If you're used to Zope's StructuredText and have a good editor on your side, it's not too bad. But StructuredText and DTML (outside of SQL methods and occasional small non-HTML uses) are two Zope technologies I'm happy to leave to the past. Finally, we needed a stronger content management system than a pool of individual wiki's provided.

We did (briefly) try out ZWiki 0.12 with setting up the ZWiki based Issue Tracker, but it was a beast to set up and configure (loosing out on the 'easy-to-add-new-project' requirement) and too dependant on DTML for me to debug and make work for us on short notice. I liked the integration of Issue Tracking with the Wiki (gaining points on the keeping-issues-close-to-content) but there was too much pain involved, and too much inolvement with the technologies I wanted to leave behind.

And I know Wiki's really really work well for some, but I've never really been able to get comfortable with the Wiki way (ask anyone that I used to work with). I've been able to get by, but that's about it.

The new attempt

Facing the problem of trying to support the Trackers onto post-Zope 2.5.1 software, and facing other issues that stemmed from the basic folder/wiki layout of the site (no intra-project search abilities, poor navigation), it was time to look for something new. That new thing is Plone - a realized content management system built upon Zope's CMF (Content Management Framework). With my knowledge of the CMF (I used to be on the content management team at Zope Corp), I was able to start tweaking the system where I needed to - I made a Project Folder content type to distinguish Projects from other content types without putting too much expectations on the content type. It can contain anything, like documents, links, events, and a CMF Collector (a weaker but still fairly usable descendant of the Tracker). I later designed a quick workflow for Projects so that their status would be more meaningful to allow distinction between active, pending, suspended, completed, and cancelled projects. The workflow has a few simple rules, but nothing distracting.

CMFCollector is decent. It has some of its own rough edges, and is missing out on some of the nicer features of Tracker (mainly intra-issue explicit linking). But it has some nice new features, like the ability to automatically assign/accept a new issue. Its interface is a bit more streamlined, particularly in the Plone skin. It uses a very simple plain text markup language it calls WebText. It basically takes plain text, marks up URL's and citations/literal blocks (lines beginning with '>' or white space).

A downside to Plone is that it - for better or worse - just builds upon CMFDefault. And CMFDefault has very basic content objects, particularly the default Document, which is very monolithic. I partly blame myself for the design - I could have proposed a better solution back when I was on the team. In my vaporware compound document project, FDoc, not only are the parts of a document componentized, but so are the text handlers. A separate Handler Registry contains handler objects, which take a chunk of text and turn it into an HTML content body. This could be HTML (taking the content between the BODY tags), Structured Text, Plain Text, etc.

So today, wanting reStructuredText support, I tried to think of how to deal with this. I had a couple of options: either take the existing FDoc work, which is half baked (the most complete work is in a customer specific project and hasn't been backported yet due to time constraints) and add a reStructuredText handler (and also make a Plone friendly user interface), or make a subclass of CMFDefault's Document class, add in the ability to manage reStructuredText somehow and make it a new Content Type or replace the Document document type (this too would involve some Plone UI work, but it would only be a tweak of the Document's edit form).

Neither situation was quite what I wanted - there were too many existing dependencies on the default CMF Document behavior, and I haven't had the time to really learn how to make my own Plone UI pages work. So, I decided to do a hybrid of my original ideas. I made some new FDoc handlers that handled Zope's StructuredText and the reStructuredText formats. Then I made a subclass of the CMFDefault Document and started wiring in knowledge of the handlers and handler registry (based on the FDoc Text Part component, but made to match the default Document's interface). Then, out of some act of devilry, I decided to monkey-patch document by doing some good old fashioned Pythonic class __dict__ comparisons and substitutions. After a few tweaks to the document edit form to list the available text formats dynamically instead of statically, I had it working (aside from one infinite recursion bug my __dict__ tweaking introduced).

So now, it's mostly working. We have a decent looking project site that's navigation friendly. It's easy to add new content and to decide its form and format with very little restriction. And I'm finally away from StructuredText (although it still exists as an option). With other CMF and Plone options available from the likes of the CMF Collective, there's a lot of potential expansion if required.

This month is just dogging me down. And that's about all I have to say about that. I'm starting to feel like I'm getting back to the sunny side of the street / really-almost-finished side of the project / etc / etc, but this feeling has come along and deceived me before.

There's just too much going on, and at the same time - nothing.

All I want now is a guilt-free ski day.

The theme of today's conference was decentralization....
The theme of today's conference was decentralization. The first time the term appeared in DaveNet was in the first piece of 2001. That's another DaveNet tradition, like the Thanksgiving essays. I try to make the first essay of each year somehow express the most important idea of the year-ahead. It's always a guess. Some years I nailed it, desktop websites were the big idea of 2001, as we prepared Radio 8 for the market (it shipped in January 2002). And Werbach was right to pick it as the theme for the future in software-based technology. There's so much power on the desktops, both in the machine CPU and the human CPU, that isn't being well used in the centralized Internet architecture. [Scripting News]

Pfeh to the desktops. There's a lot of power in them, but I'm positive I'm not the only one using three machines throughout the day. There's nothing worse than realizing that the data you need is held hostage at home or at work - wherever you're not. There are plenty of times when I don't mind the separation - work's work, home's home. But there are certainly things that go in between.

I've been a fairly happy subscriber to Apple's .mac services, using my iDisk to ferry a few common documents and preferences (standardizing the subscriptions on all my instances of NetNewsWire Lite, Chimera bookmarks, etc). I'm using Apple's iSync Beta to keep two desktops, a laptop, and an iPod all synced up with the same address book and calendar data (I have a palm too, but I seldom use it any more).

Microsoft's "Active Desktop" vision wasn't entirely wrong. The implementation wasn't quite right, and definitely premature. But the lines between the desktop, the local network, and the global network, are fading away. Rendezvous makes local networking absolutely unbelievable in Mac OS X (well, it's believable to those who used the old AppleTalk, but it's remarkable in the internet age).

I don't know. The desktop web site idea isn't too bad (I'm using Radio right now), but I'll always prefer the "Zope" "Everything is done through the web" model. It's the comfort of knowing that fixes, updates, etc, can happen from anywhere, with pretty damn good security.

It's hard to believe that these recordings were done 3-3.5 years ago. There's nothing like a sunny day spent with friends crammed into cars driving out of the great city to a small airport on long island with power toys, recording equipment, pedals, and a full pack of lucky strikes. (idlewild mk1 and idlewild mk0).

Nor is there anything quite like spending a brilliant winter solstice night under the brightest full moon in decades in NYC's Murray Hill neighborhood with a beautiful friend, a minidisc recorder, a full pack of lucky strikes, and an urge to whistle. (tuscany court ih'ladriel). Garbage trucks and energy, followed by a night of drinking and a hyper day of shopping. I miss the East sometimes.

http://euc.cx/rive/022/

For as long as it's been possible, I've had my Mac OS X dock placed on the right side of the screen, pinned to the top (instead of the default middle). I even had Mac OS 8/9 doing this for as long as the Applications Menu could be torn off and manipulated to look like a dock. It's the NeXTStep place to put it. Generally, I like the Dock, and how it combines application launching and running application management into a single widget (as well as offering shortcuts to documents and access to minimized windows). It's especially nice in comparison to the plethora of taskbar/launchbar/dock options found in Windows (although Windows XP does take some nice steps to clean up cluttered taskbars) and the stuffed-full-of-applet bars often found in Gnome and KDE. Those bars all have their purposes and uses, but I prefer simplicity and the Mac OS X dock gives it generously. An especially nice feature (when it's actually used) is that applications can have their own Dock Menus. Certain applications take good advantage of it, others ignore it completely. Radio 8 uses it well, offering quick access to the page I'm currently using to write this post, as well as to some other quick actions. Apple's iTunes uses it well, offering quick access to track controls (next/previous/play/pause) and the title and artist of the current playing track. And Brent Simmons' excellent NetNewsWire Lite makes the dock a very useful headline scanner (see screenshot). Having access like this a click away in the Dock is very useful - I often run up the dock with my Mouse checking info from certain applications while keeping them in the background. So, Applications that use the Dock Menu well make me happy.

Some applications, however, do not use it at all, but they should! Apple's new (young) iCal calendering application doesn't use it at all, but wouldn't it be handy if it displayed events and todo items for the current day (or week or month, based on configuration)? Similarly, Mac OS X's built in chat program, iChat forgoes a dock menu in favor of a global menubar item. There's some good reason for this - you can be signed in on iChat without the program running - but it's annoying when doing my little dock information crawl to have to go somewhere else for timely information. My instincts (rightly) take me to the dock first, menu bar second, and as such I'd like to change my status and check my buddy list from the Dock where I generally do so many other little tasks (like pausing iTunes when stepping out of the office).

So, where do dashboards fit into this? It's interesting to see the progress in Microsoft's MSN 8 offering. MSN 8 has a dashboard which you can attach to one side (left or right) of the screen and configure with parts updated with information from various MSN Sources. Paul Thurrot gives a detailed review (with screen shots). Some interesting things are the flyout windows, like this one based on the MSN Calendar component. It shows current appointments with shortcuts to add new ones. This dashboard concept is a major part of Longhorn, the code name for the next major revision of Windows. The point of all this is rapid access to constantly changing information.

Generally, I like the concept. But, looking at the size of the dashboards for MSN 8 and Longhorn makes me like Mac OS X's dock all the more. All of the items on it are still normal items on the system, not specialized objects (the Docklings that existed briefly in Mac OS X's life were a bad idea, and I'm glad to see them gone). Notification of change is done on the icon itself (Apple's Mail and iChat programs, along with AOL for Mac OS X and NetNewsWire, add a number to their icon indicating the number of newly received items), and allows the dock to remain small and out of the way.

The Dock - quick launcher, control strip, task switcher, window holder, information center, easily usable with 32x32 icons. Nice.