My goal is to have shortcuts in one place, organized by project, as the ultimate launcher.

Here were some good initial attempts:

• Firefox bookmarks might be a nice way to go, but doesn’t make it easy to link to local files, so that solution was quickly dismissed.
• Butler did this well — a quick click in the menu bar pulls up a hierarchical list of projects and shortcuts to resources for each project.  You could easily drag and drop URLs as well as local file shortcuts to Butler as well.  This approach basically created a nice external bookmark manager not tied to any one browser and able to link to files of all types.
• Recently I noticed that Snow Leopard’s improved Grid (in the Dock) now allows for navigating down a hierarchy of folders quickly, so though about putting my shortcuts there.  The only problem is that the dock is “way down there” (irregardless of where you put the dock) and takes time to mouse around.

Each tool took their own approach, and I had to pick one since I couldn’t easily use multiple ones. Also, graphical solutions still take precious time to drag your mouse and navigate through the hierarchy.

Then a better idea.

Spotlight is quick and fast for searching so is ideal (just press apple-spacebar) though typing in search phrases still brings up lots of extra information I don’t want.

So how do I universally “tag” resources and bring them up quickly?

First, the cool 2006 (and still usable) metadata solution mentioned on LifeHacker: Apple-I on files you want to tag, then add a custom tag into the comment box. Prefix with & so it’s quick to find without bringing up a lot of other crap.  For my common Web Collective company shortcuts, I used &wc.  Now, when I jump to Spotlight and type &wc, I instantly see all my shortcuts.

This was great, but then I found tagging nirvana on OSX.

An ecosystem of tagging tools has popped up around a free and open source OpenMeta Tag standard.

OpenMeta means that you can now tag files, folders, emails, web pages, etc, with an assortment of tools, and then search for them with an assortment of tools. No need for custom tagging in the file “comment” field, and no need to use a proprietary tagging system that locks you into one tool. (Btw, for web pages, I drag a shortcut from the browser to my file system, then tag the resulting .webloc file)

The simplest workflow consists of tagging files by dragging/dropping them onto Tagger, then pulling them up quickly in Spotlight.  To pull up all my shortcuts tagged with “wc” you just type “tag:wc”.  This is a free solution and works well.

Next in the evolution are tools such as Tags or Punakea or Leap — which make it easy to tag, while also having nice integrated search features. Tags makes it easy to tag email (in addition to files and folders), Leap (the creator of OpenMeta) is interesting because it has a very fast and flexible searching mechanism and basically does all the work of the Finder with the powerful addition of tagging and rating.  These are all paid applications — well worth it if they help you to better organize.

I’m still playing around to find the right combination of tools for my own workflow.  See http://code.google.com/p/openmeta/wiki/OpenMetaApplications for a nice list.

Tagger and Spotlight are working well for quick shortcuts — Tags, Punakea and Leap start to show what a world would be like when relying less on hierarchy and more on tags.

Hmmm, TagFolders looks pretty interesting too…

I’m now using Remember the Milk as my primary GTD tool with the Firefox extension for Gmail. The extension lets you see all your action items on the right side of the Gmail page (grouped by day) and lets you add new ones and roll-over existing ones and make quick changes and reschedules.

Its most useful feature is that you can add action items automatically when you “star” (or tag) a Gmail message.  With many of my actionable items and reminders coming in through email, this is a killer feature for me.

For example…

…if a client sends me an email that I need to respond to later in the day, I just star it and it registers as an action item for today.  If I decide I really could answer it tomorrow, I can roll over the new action item, and click the “postpone” button or type in a due date of “tomorrow”.

Then, when tomorrow comes and it’s time to act on this, I roll over the action item and now see a little “envelope” icon which allows me to jump to the email, reply to it, unstar it, and the task disappears because it’s done.

There are some very nice OSX GTD apps (like OmniFocus, and Things) but after personally jumping from client to client, I decided I wanted to go with a web-based service that had an API in case I wanted to extend it with a new UI, or maybe integrate it with another web service.

I looked at many web-based tools, but liked Remember the Milk for its API, its web-based interface (not flashy, but useful), no syncing worries, the Gmail Firefox extension (my main interface for using it), and it even has a nice iPhone web interface (with a native iPhone app rumored).  For the iPhone interface, they ask you to join their Pro membership, but $25 for a year is well worth supporting this great service.

I also built CollectiveGTD for Plone, but have decided to take a different direction with this product.  Instead of it being a tool to manage all my general GTD needs, it will evolve into a set of tools for managing Plone content within a site.

This is a Plone product that implements an Open Source version of the Getting Things Done (GTD) methodology.

New in this release:
This version fixes all known unicode issues, so that non-ascii characters can now be used throughout interface for editing, viewing, and KSS inline editing.

For download, please visit http://plone.org/products/collectivegtd-thoughts/releases/1.0b2

Change log:

• NEW: Fixed all known unicode issues which were causing context/project tagging to break when editing and when viewing, and were preventing KSS from updating the UI. Language-to-date features are still only supported in English.  Templates have not been internationalized.
  • Future Plan is to replace home-grown language-to-date functionality with the parsedate python module, which also supports multiple languages.
• NEW: Added new getAllActiveActions(outputFormat=”xml) method to spit out all ActionItems, Context tags and Project tags for use by a desktop application.
• INCOMPLETE: Started to build an iPhone interface. Partially complete. Further work on this postponed.

This was challenging in that it was my first KSS project, plus most of the KSS editing examples I’ve found deal with editing just one piece of content (instead of multiple rows).

Here is a screencast to whet your appetite for inline editing. Basically, CollectiveGTD has many rows of Action Items (each with Name, Start Date, Due Date, etc) that needed to be edited.

Screencast: Example of Inline Editing in CollectiveGTD

Here were the issues that needed to be solved:

• How do we capture KSS events for a specific field in a specific row?
• How do we display inline editing forms?
• How do we handle the same row of content if it shows up in multiple places? e.g. CollectiveGTD also has a portlet which might display the same content in both the multi-row form

Here are highlights, issues and lesson’s learned:

Note: If you generally want to see all of the new KSS code in one place:
svn diff -r59525:60742 https://svn.plone.org/svn/collective/CollectiveGTD/trunk

1. Converting from a plain old HTML form to a nice KSS template

Prior to adding KSS, I started with a single HTML form that allowed users to check “Done” or “Starred” fields and click “Submit” to update all the pieces of content. The goal was to replace that with KSS, plus add inline editing. To do this, I had to remove the one HTML form since you can’t have mini-inline forms inside of a big form.

Issue: Not sure how to degrade this functionality nicely if someone doesn’t have JavaScript enabled.

I recommend creating macros for each field you’re editing, and a unique naming scheme for your inline fields.

I created 4 TAL macros (in collectivegtd_kss.pt) – one for each field to be edited with KSS. There is a lot of HTML to put in, so doing this simplifies the main page template which then just generates the page and repeats through multiple rows of data (actions_view.pt).

The first goal was to uniquely id each editable field, even if the same piece of content shows up in more than one place on the page.

To do this, each field’s CSS ID was based on the content’s short-name (to represent the specific piece of content, aka “row”) with a ‘prefix’ string (to represent the specific fieldname in case it appears in many places). For CollectiveGTD there are 4 prefixes for the main page (main_startdate, main_duedate, main_complete, main_flag) and 4 prefixes for the portlet (portlet_startdate, portlet_duedate, portlet_complete, portlet_flag).

Issue: A period in the field’s CSS ID breaks KSS. A period can appear because the short-name for a Plone piece of content can contain periods, and I’m using the short-name as the unique identifier. I haven’t fixed this one yet.

The macros require two pieces of information: ‘actionItem’ and ‘prefix’. ActionItem is a single piece of content that has all the fields a row needs. These prefix also allowed the KSS code to be able to update multiple fields if the same piece of content appears more than once. e.g. Changing Start date on the form, should also update the Start date for that items if it also appears in the portlet.

2. Inline Editing Issues

The initial tricky part of multi-row data (specifically with inline-editing) is that you can’t dynamically create KSS events for every row (nor would you want to!), so you need to structure your HTML and CSS a specific way so that when you trigger a KSS event it is smart enough to know which fields are connected with that row. My first version ended up showing and hiding all the rows forms instead of just the one I wanted.

How to hide and show the inline form:

Since inline text editing requires grouping several elements together, it’s important to group everything in one tag (e.g. <div>) and make sure all the KSS selectors for that inline form starts with that tag. The reason is that you want the parent of all the forms to be the same, so that when your KSS action fires, you can capture it within that form — and not all forms. You do all this magic via the “parentnode” function in your KSS selector.

I also set each form to have these two classes to start with (editform hiddenform) so that all the form default to being hidden.

Here’s the example of the “Due Date” field:

3. What happens after submitting an inline-edit form?

New ActionItemListKSS view for handling the server-side content updates

I created a new ActionItemListKSS (which subclasses PloneKSSView) to provide the server-side code to update content, and also reflect the changes back to the webpage (via those unique IDs we generated in the templates).

The unique IDs are used by our ActionItemListKSS.

The methods of my view are connected to the form via KSS (in collectivegtd.kss). The major methods include: update_dueDate(), update_startDate(), update_complete(), update_flag(). This is where a lot of code duplication happens (similar code in all 4 methods), but easy to understand.

They all basically are passed a ActionItem ID (content short-name) and the new value (via KSS magic). The method then updates the piece of content, reindexes the content to make sure the catalog is updated, then updates the webpage by doing an HTML replace for both prefixes (”main” and “portlet”). It the content only exists in one place, the other replace is ignored. Finally, a Portal Message is sent to the user to let them know what was changed. The two “inline edited” fields are naturally more complex.

Issue: This still seems like too much duplicate code is needed in ActionItemListKSS. Once I had one field working, I found myself refactoring common code as I learned KSS and discovered which code to reuse across fields. The refactoring is leading toward a view class useful for inline editing though!

Lesson Learned: I ended up adding helper functions in ActionItemListKSS to handle the individual field-level updates of content, because updating fields like Start Date and Due Date were complex because of the complex date conversion code — converting strings to dates, then converting dates back to strings. This was largely because I didn’t build individual field update code in CollectiveGTD. I started with formlib code which created new ActionItems all at once. In hindsight, it would be good to have a view that allows updating of each individual field — then it could be reused in both formlib and KSS without having to duplicate code. I still may do this refactoring at some point.

4. CSS file (collectivegtd.css)

The CSS was straight-forward. Minor note: The only reason some of the selectors have a lot of options is that I was playing with CSS rollovers (where one image has both rollover states) and found some boilerplate code that looks like it works for all browsers imaginable. I’m sure some of those could be removed.

5. Tests

I added tests for the ActionItemListKSS methods, but haven’t tried UI testing yet.

Conclusion

Therefore, thus…

* It’s worth learning KSS because of the power it brings you without having to write JavaScript code directly.

* The tricky piece was learning how the various pieces work together (KSS, PloneKSSView, and figuring out best-practices for structuring HTML and CSS), though once that is understood, it was easy to maintain the pieces separately by breaking the templates up into macros (to keep things simple and reusable), put all the server-side code in one Python class, with one KSS file that connects the two.

I hope this example provides you with what you need to avoid some of that initial learning curve.

I’m also interested in learning from KSS gurus if there is a way to simplify any of these pieces.

This beta release of CollectiveGTD for Plone 3.0 includes new features such as:

• AJAX Inline Editing using KSS
• Filtering of Actions by Context tag and Project tag
• An Import script that will import an iGTD CSV export and which is easy to modify for importing other formats.

The 8-minute screencast is available here: CollectiveGTD Beta 1 Screencast

The project page and link to the code is here: http://plone.org/products/collectivegtd-thoughts