Here’s an annotated peek at some Actiontastic and Actionatr source code for the 1.0 releases. I don’t like Photoshop hype nor do I like showing a raw un-styled UI, so this is my attempt to show real working code and highlight some of the new features that it enables.

1. All Actions View

Sometimes you just want to see everything on your list, regardless of what project or context contains the items.

2. Project List View

The new project list view shows all projects with their actions listed underneath in a tree-like view. Projects can also be marked as complete.

3. Tags Instead of Contexts

Tags are a great way to build a scalable user interface. By scalable, I mean an interface that grows with the user. Contexts are canonical to GTD but tags are more universally understood, not to mention expendable. If you don’t do full-on GTD, tags are easier to ignore than the imposing “Contexts” button in the toolbar of Actiontastic today. (As an aside, the toolbar is going away in favor of an iTunes-like source list.)

So, you can still have tags for contexts like “calls” or “errands” but you can also use them in a more free form manner as your personal system grows. Beyond this, there is no more “one context per action” rule; you can apply as many tags to an item as you desire. Tag collections are in the works too, for things like “important” and “calls” in a single click.

4. Time Travel

Go back in time to see what was completed on each day.

5. Trash

Just in case you delete something that you didn’t mean to delete, these apps now have a Trash Can, just like your desktop.

Not knowing if I cover enough technical subjects here on the blog, I thought I should throw in even more nerdery detailing the path from Actiontastic 0.9.3 to Actiontastic 1.0 with its web sidekick, Actionatr. This was inspired by Wolf Rentzsch as well as a post from Ivan Moscoso on the Pathfinder blog, where he asks about alternatives to GWT-RPC (which we’ll get to in a moment). This post could also be titled “Why I Should Blog More Frequently, In Smaller Chunks.” My apologies.

Background

Actiontastic has remained stubbornly at 0.9.3 for months now while I have refused to release a 1.0 that isn’t a 1.0. Sure, it could have been released anyway as a commercial app before so many others joined the Mac/Getting Things Done niche, riding the wave of cash to a beach front house on some island in the tropics. (A second scenario would be selling just enough copies to require keeping a full time job while relegating all evenings and weekends to email support, but let’s favor optimism when daydreaming, shall we?)

Instead, I have stuck with the original vision of building something I believe is a requirement for productivity applications — ubiquity. It’s not okay to not have my lists with me when I’m running errands. It’s also not okay to not have my lists with me when I’m away from the Mac and need to make some calls. Paper printouts don’t sync and thus don’t solve the problem. Web apps don’t cut it on the BART (yet). iCal/PDA syncing also doesn’t hit the 100% mark for two-dimensional lists that are central to canonical GTD. That’s where the hybrid desktop/mobile/web app comes into play.

“Just ship it” is good advice, but that very idea hinges on defining the minimum requirement(s) for “it,” a 1.0 release. Setting the bar at “ubiquitous” has increased the challenge for this project while focusing it in many other areas. For example, there won’t be lots of widgets and configuration options inside of dozens of popups, sheets, and panels. Instead, Actiontastic will remain focused on the Next Action idea with its filter bars catering to this sort of work flow.

Exploration

As I’ve mentioned before, there have been lots of technology prototypes assembled behind the scenes. These include:

1. A basic Java web app, started more than a year before Actiontastic was first released.
2. Hard wiring communication between blocks of code in Actiontastic to a web service built in Rails. (Not really a serious solution but good for exploration of the idea.)
3. Building an app that ran in the browser as well as the desktop using Flex and AIR (using Cairngorm which was pretty nice).
4. Building an app that ran in the browser as well as the destkop using JavaScript/CSS/HTML with AIR.
5. Building an app that ran in my own Mac app container (a variant of WebKit Apps) that used a WebKit plugin to allow local SQLite storage via JavaScript/Objective-C bindings. This option used only JavaScript/CSS/HTML for the interface so would have also worked online as well as on other platforms. ExtJS with Jester and a RESTful Rails back end were helpful with this approach.
6. Building method #5 above without the plugin, tying it more closely to the Mac platform with WebKit hooks.

All of the above failed. Here’s why, using the same numbering as above:

1. This was during the age of Struts, Spring, and Hibernate. XML configuration pain and mapping the same things in every layer of the app wore thin and led to picking up my first Mac programming book, Cocoa Programming for Mac OS X, if only for a change of pace. This also led to Rails.
2. As mentioned before, hard wiring interactions isn’t an elegant design and would have been a nightmare to maintain as the application progressed.
3. Although a Flex app can be themed to look like a native Mac app, I found that basic text support was not built into Flex in a way that current Actiontastic users would expect. This also required implementing my own widgets for things like sheets. Further, integrating with native services on the Mac required lots of hackery including an Actionscript-to-Java bridge to a Java-to-Objective-C bridge that has been deprecated. I’ll pass.
4. Scrollbars, plus some of the problems with option #3 above.
5. The plugin seemed like the wrong way to go as Google Gears, once it regains its Safari compatibility, will solve this same problem. More on that later.
6. Sadly, this is the one I hoped would work the most. I love the idea of using Web Standards to build interfaces that work on the desktop and in a browser. This one made it very far including a complete theming of ExtJS to mimic Leopard source lists, sortable tables, fluid layouts with dragable dividers, animation, and even HUD windows. This may still be the platform for Actiontastic 2.0, given enough compatibility progress in the browser world. In the end, juggling incompatibilities between browser versions, even the same browser (Safari 2 vs. Safari 3 Beta vs. Safari on Leopard before it shipped) made things grow ugly. If you see your app as “managing documents” or targeting a more web-native look and feel, this could still work, but when trying to mimic precise UI behavior from the desktop world, things are not so good. For the record, WebKit is my favorite JavaScript and CSS environment, but building a desktop-like web app that meets multi-browser expectations would require a team and a very robust architecture. This might include basic objects that could be extended for browser-specific quirks (rather than wedging in the ugly but common “if Gecko then…” kinds of hacks throughout the app). An architecture like this simply wouldn’t fit in the time line for 1.0. More on this browser-specific targeting in a moment, though.

This leads us to today, where the failures aren’t really failures. They have been excellent learning experiences and perfect excuses to explore some new technologies. Getting back to the title of the post, this is where GWT and REST come in.

Automagic REST

Months ago, I blogged about the possibility of a fast, compiled REST app that could be generated from a data model. Rails sort of hits in this direction minus the “fast, compiled” and “generated from a data model” part. This isn’t to be snarky either. The scaffold_resource generator in Rails (soon to be the default in 2.x) can do an impressive job of generating a REST service, but it lacks a few things out of the box that are offered more easily on the Java platform today.

For starters, Java-land seems to be heading in a better direction, thanks in part to competition from Rails. These days, if you want a REST service in a green field environment, you can just generate it from a data model. The anti-patterns encountered during failure #1 above are largely gone. This is due to a mix of technologies: Netbeans 6.0, Jersey/JSR-311, and JPA. Check out this tutorial, and there you have it, automagic REST that produces and consumes XML and/or JSON.

KloudKit

In the same blog post referenced above, I joked that REST was the new SQL. This is the tie-in to the Mac platform. If your Mac app uses Core Data, then it is following common ORM patterns. It retrieves, saves, updates, and deletes records, most likely from a SQLite database. These operations map exactly to those in a REST architecture — GET, PUT, POST, and DELETE. Naturally, this mapping means that a Mac app should be able to easily talk to a REST web service. This is where KloudKit comes in.

KloudKit is being assembled on top of OAuthConsumer so that it can do transparent authentication from a Mac app to its web companion. If you’ve ever published something from iMovie to YouTube or used a Flickr uploader, it’s sort of like that in the eyes of a user. With authentication out of the way, KloudKit can replicate actions taken on the Mac to the web. Right now, this implementation is forming as a framework that uses Core Data’s objectsDidChange notification, but I could see it also working as an extension to Wolf Rentzsch’s MOGenerator.

The MOGenerator option would have less invisible “magic” and could generate a rich data model to act as the seed for the generation of the REST app. All hooks would be exposed in the generated code, favoring a sort of “annotation over confusion” approach (with apologies to Michael Easter who seems to have been the first to coin this phrase).

Given a clear path for interface development on the Mac (Cocoa), storage (Core Data), authentication (OAuth), and communication with a RESTful web app (KloudKit), the browser interface to this RESTful hub is all that remains. This is where GWT shines.

The Google Web Toolkit brings these advantages to a browser interface:

1. Java is compiled down to JavaScript, reducing the amount of context switching needed during development. I’m not bad at switching from HTML to JavaScript, to CSS, to Ruby, to SQL, to Objective-C, to graphic design, but it could be easier. A mostly Java and Objective-C mix would go a long way to delivering desktop, mobile, and web apps for most operating systems.
2. Easy internationalization support.
3. Optimized browser-specific versions of the same app delivered according to each client’s needs.
4. Reduction of HTTP requests by merging all graphics into a single file. This file is delivered to the browser in one request. CSS tricks are used to display the pieces in the right spots.
5. Debugging of JavaScript using an IDE while running in “hosted mode.”
6. A large set of widgets, allowing appearance to be styled with CSS. There is even an add-on to integrate GWT with Ext.
7. Unit test support.
8. Google.

GWT’s native method of communicating with the server is called GWT-RPC and this is its weak link, in my opinion. Not that GWT-RPC isn’t fast or well integrated into the client-side JavaScript. It is. However, the current 1.4 version doesn’t handle Java 1.5+ code, meaning it doesn’t work with annotations, which rules out JPA. This can lead to EJB 2 flashbacks for those who have been there, as it requires an extra layer of Data Transfer Objects, mapping those DTOs to and from annotated objects using pseudo-annotations as GWT compiler hints, two interfaces for each service endpoint, etc.

Fortunately, GWT also includes a JSONParser and a RequestBuilder that can be crafted to work with a REST service. It may be even easier than this, however. GWT includes JSNI, a JavaScript Native Interface which allows it to interact with third party JavaScript libraries. Jester, mentioned above, supports asynchronous JSON to REST services and can be configured to use mappings outside of the default ActiveResource conventions. Tying these things together seems like a nice approach.

Conclusion and the 1.0 Architecture

To wrap this up, we have a desktop app (even mobile apps using JME, Android, or the iPhone SDK), transparently talking to a REST web service. A browser app, compiled down to a single page AJAX app talks to this same service. Given that GWT now supports Google Gears and Safari support is planned, it won’t be long before the pure HTML/CSS/JavaScript vision is possible on all platforms.

My Oblique Strategies widget just suggested that I “change ambiguities to specifics.” While this certainly applies to getting things done, it can also apply to communicating software plans and progress. And, speaking of news scoops, I was recently interviewed by Ed Arnold regarding Actiontastic, GTD, the open source announcement, etc. and would like to link the article and say thank you for taking it easy on me.

The Scoop: Actiontastic

Actiontastic is going to continue on its announced open source path. If you’ve been wondering about the source code release, it is still on the way but involves more than the simple mechanics of publishing some code. The goal is to make it GPL and that involves rewriting GPL-incompatible third party code prior to release.

It occurred to me today that instead of targeting a source release that matches the existing free version, I might do better to remove some of the third party code in question and replace it with something that could be used by interested developers sooner rather than later. Then, when everything is up to par, the source code base and the binary releases could move in sync with one another. I still have some thinking and experimenting to do in this regard so I will keep you posted on the progress as it happens.

The Scoop: Actionatr

The real news is that Actionatr will not only be running in your browser as planned, but also on the desktop and not just on the Mac. It will also run on Windows and Linux. This is all thanks to the previously blogged REST architecture on the server plus Adobe’s Flex and Apollo technologies. One way (Flash Lite) or another (J2ME a la the Gmail app for the BlackBerry) or another (in the browser), Actionatr will also be running on mobile phones.

I believe strongly that a ToDo list that isn’t available anytime, anywhere, online or offline, is a step backward from a folded sheet of paper in your pocket. Conversely, a ubiquitous set of checkboxes and idea capturing tools will be a welcome step forward…at least in my little world.

The important pieces of this are already running on my trusty laptop and communicating with each other. Screenshots will be posted as soon as the UI gets a little more love.

Download Actiontastic 0.9.2
(Mac OS X 10.4 Required)

The new Actiontastic release is out, and with it comes a serious set of upgrades. Over the last few days, I have blogged about the new Quicksilver and Inbox bling, plus the new Mail and Anti-Drawer upgrades. On top of this, there is another feature that is just for the productivity black belts out there.

What’s the Next Action?

If you’re seriously into GTD or even just focused on moving your projects forward using your own personal system, you probably ask yourself “What’s the next action?” several times a day. This near-magic question keeps projects from growing stale and ambiguous. With this new release, I am happy to say that Actiontastic is way smarter about answering this question.

A short while ago, new filters were introduced that hid projects and contexts with start dates beyond the current day as well as those that were “paused.” Several of you remarked that it would be great if those filters went all the way down to the action level. My response has always been that it was just a matter of time and code. The time has come and these filters go all the way down. And, they also interact intuitively with the other filters above the action lists. Give them a shot and let me know what you think.

Speaking of the Next Action, What About 1.0?

I recently promised in The Hub to give the rest of the plan for 1.0 here on the blog, so here it is. The next major Actiontastic release will be 1.0. It will include web syncing with Actionatr. Today’s release is nearly feature complete, but 1.0 will also include printing support, automatic updates, integrated Apple Help and a few other items.

As always, our interactions make these releases what they are. A sincere thank you goes out to each of you who shared your thoughts on Twitter, in The Hub, over email or on this blog.

Here is one last preview post before tomorrow’s release, which will likely occur during the evening hours on Tuesday.

First, a warning to anyone using rich text (colors, graphics, etc.) in the Notes field for any items — tomorrow’s update will transform this text into plain text automatically (in the same way that syncing notes to iCal does right now). This was mentioned as a possibility in the iCal sync release announcement and it is now a sure thing. There weren’t any real controls to allow rich text in those fields, but a right-click allowed it as did copy/paste operations. This technique was even highlighted by my MailTags post a while back as an easy way to link to mail messages. If you are concerned about losing anything of value by changing the format, please let me know and I will post an extended version of the previous release for you to use while you convert your notes.

Having said that, let’s get on to the good stuff.

The Anti-Drawer

Just yesterday, the idea mashup was discussed and this is yet another case. There are very few applications with drawers that don’t make me cringe. TextMate is one of them. Feeder is another. I know many of you feel the same way. Without getting into any drawer holy wars, I can say that I wasn’t happy with the design of the current drawer but had some reservation about using panels or a standard three-paned window.

As a result of a few different feature requests and an odd bit of inspiration from an animation app, I started wondering about a drawer that slid in instead of out. That would solve the window resizing issues of the standard drawer while still allowing the information in the so-called anti-drawer to stay optional and out of the way during a mad box-checking-in-the-context-view binge.

So here it is in the Inbox view:

Cmd-I slides open this new third pane and closes it just as easily. The URL field shown above brings us to the next topic.

Mail Integration

The new integration with Mail works in two ways. If you use MailTags, you can pop open the new ToDo box and assign your message to the @inbox calendar in iCal (created by Actiontastic).

This latest version of MailTags cleverly sends a URL to iCal that will open the individual message from anywhere on your Mac. Actiontastic picks up this URL during its sync so that the link can now stick with your new action or project.

With or without MailTags, you can use AppleScript (inspired by a post in The Hub) to take messages with a prefix like “todo:”, place them in a folder and send them to the @inbox calendar in iCal. Upon syncing, Actiontastic will see this prefix and strip it for you so that your mail subject shows up as the inbox item name and the message content is stored in the notes. Using this method, you will be able to email actions to yourself from just about anywhere.

This use of notes syncing from iCal to Actiontastic (instead of being one way as it is now) was the prompt for the Notes/text change mentioned at the beginning of this post. This will allow two-way note syncing from iCal, which has been requested by quite a few people, plus all of these other goodies. It will also integrate much more smoothly with Actionatr when it is ready.

That’s it for today. I’m going duck into a St. Louis-style Bat Cave and finish tidying up your new release.