To start, I spent some time on Open Source CMS playing with the various CMS tools out there. This was an a very valuable tool that made it possible to try out a number of content management systems without spending the time to install them. After playing with them, I decided to pursue installing Drupal. I installed it and played around with it for a while to get familiar with the administrative interface and more importantly, to get a feel for what the contributors would experience. I ended up frustrated with the lack of usability for contributors.

I moved on to wikis to see if one of them would fit the bill. I installed TWiki and MediaWiki to try them out. In past lives I had experienced Intranets that were not kept up to date because the editing process was poorly understood or too cumbersome (or both). From that perspective, a wiki seemed like it would be a match. Unfortunately, while very simple to keep the content up to date, none of the WYSIWYG tools provided a good enough interface for the contributors.

As one last effort to avoid using Adobe Contribute with static pages, I thought I would investigate using WordPress. A friend mentioned that he had used it for some simple sites. I really like the cleanliness of WordPress. Unfortunately, out of the box it wasn’t going to meet my needs. I did some research via Google, finding a number of people attempting to shoehorn WordPress into the role of a CMS. I found a number of blogs detailing some steps to get WordPress closer to a CMS:

• From Weblog to CMS with WordPress
• WordPress as CMS
• Feature: 5 Reasons to Use WordPress as CMS
• Five Wordpress "CMS Enabling" Plugins

From those entries I came up with the following plug-ins that seemed necessary to get what I wanted:

• Dagon Design Sitemap Generator
• Search Everything
• Role Manager
• Search_Hilite
• Xinha4WP

The final piece that made me think it would all be possible was the Xinha4WP plugin. The contributors wanted to be able to have rich editing capability and Xinha provided the support I needed. Role Manager also is a critical piece to allow each person to have the appropriate permissions for editing and adding content.

The final coup was finding a lead on the MaisonBisson blog that would allow contributors to use existing applications like ecto, MarsEdit, or Contribute to create and edit content. The post appears to focus on an older version of WordPress, but I was able to get it working with WordPress 2.1 with only the following change to the wp_get_recent_posts function in wp-includes/post.php:

Find:

$sql = "SELECT * FROM $wpdb->posts WHERE post_type = 'post' ORDER BY post_date DESC $limit";

Change to:

$sql = "SELECT * FROM $wpdb->posts WHERE post_type IN ('post', 'page') ORDER BY post_date DESC $limit";

Shazam. Now I have a solution that meets all of my requirements! Now to see if it isn’t already too late to reverse the Adobe Contribute + static pages decision that was already made.

[UPDATE] The Role Manager plugin mentioned above is not compatible with WordPress 2.1 and later. It has been updated and is now available here: http://www.im-web-gefunden.de/wordpress-plugins/role-manager/.
 

I decided to compile a list of the various projects that are using the APIs from 37signals to integrate various projects together. I haven’t actually used the Backpack APIs, but once I got going on the list, I figured I would finish the job and include all the products. These projects are not all using published APIs, but why not err on the side of a more interesting list of integrations rather than only look at official API use:

Basecamp (API Docs)

• Telescope
• Blinksale
• Scout
• BCTix
• Tick
• Basecamp mobile
• Mailroom (Blog entry)
• Subversion Post-Commit Hook
• Futuretrack5
• Sundial

Backpack (API Docs)

• PackRat
• O’Reilly Radar Books
• Backpack Dashboard Widget
• cellTell voiceNote

Campfire (no official API)

• Marshmallow
• Pyro

Ta-da List (no official API)

• Ta-da List Widget

I am sure there are more than this and I will make an attempt to keep this list up to date as new projects surface. If you are cooking something with an API or are aware of another project using on of these APIs, let’s hear about it.

HAPI integrating!

Digg this

Technorati Tags: 37signals, api, backpack, basecamp, campfire

At around the same time the Dashcode news was wandering around the Mac-centric blogs, 37signals released an API for Basecamp. I have been using Basecamp to keep track of our home remodeling project. I decided to take a crack at writing a Dashboard Widget that leveraged the Basecamp API and RSS feed. What follows is a summary of my experiences with Dashcode and with the Basecamp API while creating Telescope–a Dashboard Widget for Basecamp.

Having never written a widget before, I wasn’t quite sure what was in store. The first screen that appears when launching Dashcode gives an option to start a new project from a predefined template. The three that are included in the MacBook Pro version are Custom, Countdown, and Blog Viewer (really just an RSS reader). As I knew I would be leveraging the Basecamp RSS feed, I chose the Blog Viewer template. Having been through the process once now, I would probably choose to start from the Custom template. I ended up spending a fair amount of time understanding the generated code and ultimately stripped out a bunch of code that I didn’t need for Telescope. One annoying bug in the generated source was one that made me think the whole thing wasn’t working and almost pushed me to ditch the idea of using Dashcode for Telescope. It turned out to be a bug in the template code that was attempting to filter the RSS feed to the last n days, causing me to think that the RSS viewer was broken altogether. After fixing that, things looked good to go.

Working with the layout, I encountered my first few bugs with Dashcode. I found that working with the graphical layout tool was a sometimes unpredictable experience–crashing Dashcode four or five times. At first I thought it was going to be a fruitless exercise due to the bugs. However, after deciding to give it a second shot after a frustrating initial attempt, I was able to avoid the bugs and make some real progress. The bug that was the most annoying was one that crashed Dashcode when editing text label in the layout. Avoiding complete edits of the labels seemed to minimize the crashes.

With the initial layout complete, the crashing was much less frequent. The editor worked well, providing syntax highlighting for the CSS, Javascript, and HTML files, block indenting, keyword completion, line numbers, the ability to jump to functions, and set and clear breakpoints. It’s not as complete as TextMate, but the integration with the debug environment makes it very useful.

The debugging capability was probably the most useful part of Dashcode. The key features that helped here were breakpoints, quick start/stop of widgets, the stack frame, and the Javascript evaluator. Building Telescope was the first time I had worked with XMLHttpRequest so the stack frame and evaluator were especially helpful in understanding the results I was getting back from the Basecamp API. It was pretty handy to be able to type something like this into the evaluator and see the result:

milestones[0].getElementsByTagName("milestone")[i].getElementsByTagName("completed")[0].firstChild.nodeValue

Then you can drop the snippet into the code and quickly restart the widget and see it in action. Much faster and more flexible than putting in alert statements or using the stack frame.

After using the evaluator to become familiar with navigating the XML results, I will probably use Prototype next time. It was a good learning experience, but I think using Prototype would have been quicker and easier.

One area that took some trial and error was the handling of HTTP authentication. XMLHttpRequest.open supports two ways of doing this. One with the username and password passed as independent parameters to open:

url = "http://hostname.clientsection.com/project/list";
projectMilestones.open("GET", url, true, basecampUsername, basecampPassword);

and the other with the username and password encoded into the URL string as in

url = "http://" + basecampUsername + ":" + basecampPassword + "@hostname.clientsection.com/project/list";
projectMilestones.open("GET", url, true);

I was only successful with the version with the username and password encoded into the URL.

One thing I was grateful for was the simplicity of the Basecamp API. The basic function of Telescope is to give a quick snapshot of current project status. The Basecamp RSS feed give the last 25 changes made. Whether this is for a specific project or all projects, depends on whether you use the project specific feed or the general account feed. Generally, Telescope is more useful when using the general account feed because it allows you to filter the events based on project. The project list comes from the Basecamp API–giving the user the ability to see updates for any active project.

In addition to pulling the list of active projects through the API, Telescope also retrieves the milestones for the selected project and displays the next milestone (or the earliest overdue milestone).

With the milestone API you can either pull all milestones for a project or milestones in a specific state. Unfortunately, I wanted both upcoming and overdue. Not wanting to load the server unnecessarily, I asked Jamis (37signals’ Basecamp API wizard) whether more small requests or fewer larger requests were preferable. He indicated a preference for fewer requests so I retrieved all milestones and filtered out the completed ones within Telescope.

This leads me to another topic. I wanted to allow the server to distinguish Telescope from other API requests so 37signals could let me know if Telescope was causing undue load on the servers. I have read a number of threads from server administrators complaining about widgets that refresh too often or otherwise load the servers with no perceived benefit to the widget user. I highly encourage widget creators to be sensitive to those running the applications on which the widgets depend.

One solution I came up with for this still hasn’t worked. It seemed like the perfect approach would be to set the User-Agent header to Telescope so that it appeared as a unique application in the server logs. In theory this should work, but for some reason, the User-Agent string was not getting updated. Here is the snippet that I will eventually try from another environment to determine if this is an issue with the Dashboard Engine:

projectMilestones.open("GET", milestoneURL, true);
projectMilestones.setRequestHeader('User-Agent', userAgent);

I will leave the code in on the hope that in some Dashboard Engine update it starts working. In the mean time, I have added a custom header (X-User-Agent) to distinguish Telescope. Unfortunately, most analysis tools won’t be looking for that so it will require manual analysis to determine what sort of load Telescope is putting on the applications.

Overall, I have had a very positive experience on all fronts with these new toys: MacBook Pro, Basecamp API, and Dashcode. Hopefully folks will find my exercise useful; either through using Telescope or for the background on the Basecamp API or Dashcode. I hope to extend Telescope in the future. Let me know how you are using it and what you think it should do.

Happy Basecamping!

Digg this

Technorati Tags:
dashcode, basecamp, dashboard

There are some great songs, but one stood out to us as we were driving back one summer from a family vacation. It is called My Electronic Vacation. I haven’t been able to find it online, so just order the whole CD from his site. It is worth it. Anyway, the song makes fun of those of us who start to twitch when our Treo’s can’t get signal to download our email. The loggedoff.org comes from the epitaph of our tombstones, as we lie dead — unable to check our email.

As for what I will be writing about on this blog; well, I am not quite sure yet, but Dashboard Widgets, small business software, HOWTO’s for things I couldn’t already find written up, Mac-based media centers, and someday maybe some suggestions for how to get logged off and back to real life.