I know I’ve been fairly quiet lately, though for good reasons. One is that I did some of my more recent blogging on the PGXN Blog, though even there it has been a while. The main reason for my silence has been my focus on coding DesignScene, a new app for the iPad that I developed with my friend and partner Roger Wong.

Some history. Early last year I started learning Objective-C to implement an iPhone application. I’d had a great idea for a simple app to replace SMS, and so set about learning the ropes, and got relatively far in the development of the UI. (Fortunately, borange and atebits released Textie and I was able to kill that project.) As I worked, I started tweeting things about working with Objective-C and cocoa (both completely new experiences for me), and Roger, whom I’ve known since he and Strongrrl were in art school together in the early 90s, and who’d had an idea of his own, took notice and DMed me about a partnership.

Roger envisioned an application in which he could absorb himself in all the images and feeds he normally explored as part of his everyday work of gathering inspiration as a graphic designer. His initial mockup looked great, and I was immediately drawn to the idea of an app with carefully curated content in a beautiful interface to serve a specific (and design-savvy) niche. We agreed to meet at iPad Dev Camp in April to see if the idea had any legs, and whether we could work well together.

iPad Dev Camp was a great success for us. Jayant Sai was especially helpful, hanging out in the “newbie room” and pointing out that Roger could work on stuff in Interface Builder while I hacked code. It made it much easier to figure out how we could collaborate (though in fairness Roger has had to wait for me to learn and code a lot of stuff). Bill Dudney was there too, and helped us work out some of the details of animating the browser view. Good stuff. By the time it was over, we had a prototype of the UI nicely working, and even won an honorable mention at the hackathon.

Since then, we’ve had times when I’ve been able to give development more or less time. I spent six weeks over the summer developing the back end in my spare time from my day jobs. The code there regularly harvests from all the feeds we’ve selected, finds good images, extracts summaries, and provides a single, clean feed for DesignScene to consume. This allows the app to sync very quickly, which we felt was important for optimizing the user experience.

And as I worked on the iPad app itself, I’ve learned a lot about real MVC design patterns and development, which is quite different from the stuff we web app developers tend to call MVC. And in the last few months the app really came together, as we started pulling in actual content and applying the fit and finish. And now it’s here, in the App Store. I’m so thrilled with how it turned out, so happy to be using it. Hell, it’s one of the few apps I’ve ever developed that I actually enjoy using on a day-to-day basis. You will too; go get it!

Oh, and just dig the awesome trailer Roger put together. It’s such a joy to work with someone who knows Photoshop and After Effects like I know Perl and SQL.

Since we launched on Tuesday, we’ve been fortunate to receive some really terrific coverage:

• Gizzmodo (includes a video of the UI in action)
• macstories
• Padvance
• Shawn Blanc
• MacMagazine (Portuguese)

And we’re not sitting still. I’m working through a short list of burrs and spurs that need to be polished off, and then moving on to some other great features we have planned. Stay tuned!

Looking for the comments? Try the old layout.

Well, this is entertaining. It seems that the Gartner Group has decided that iPods are a significant security threat. I think it’s great that a company like that makes its money by telling people that, yes, you can copy files between your PC and your iPod, and that poses a serious security threat. Please.

The problem, of course, is not the iPod. Or digital cameras. Or floppies. Or CD burners. No, the problem is people. I prefer to build a company that trusts its employees. Novel concept, I know. So here’s the mantra: iPods aren’t security threats; employees are security threats.

Now, I had to think carefully about posting this, because it reminded me, suddenly, of the old gun nut statement that guns don’t kill people, people kill people. The reason why I’m willing to use it for the iPod and not guns, however, has to do with design. Guns are designed to kill. It kind of makes the statement moot. I mean, what would you expect people to do with them? iPods, however, are not designed to breach security. They’re designed to listen to music, to store files, to copy your calendar, etc. Now, whether an individual person decides to use the iPod in breach of a company’s security protocols is a matter independent of the iPod’s design and intended use.

So the mantra holds: iPods aren’t security threats; employees are security threats. But guns, yeah, they’re pretty much designed for killing.

Looking for the comments? Try the old layout.

I’ve just finished updating the UML diagram for the design of Bricolage 2.0. It’s not completely comprehensive, mainly because the lines would start criss-crossing all over the place and no one would never be able to make any sense of it, including me! Notably, I’ve left out the links to Bricolage::Biz::Site, Bricolage::Biz::Class, Bricolage::Party::Person::User, and Bricolage::Party::Person::Contributor. But it’s pretty clear how they hook up if you study the classes, since they contain the appropriate *_guid attributes. And that’s all those of us who will be writing Bricolage will need.

I’m happy to get this largely done. The technical specification is also largely complete. I’m going to fill in a bit on Bricolage::Client::CLI right now, but otherwise, it will probably be stable for a while. It will change of course, because it’s not completely comprehensive, and there will be things that I haven’t thought about as I’m starting to code. But that’s probably a ways off, as there is quite a lot to get going with right now.

I’m not sure if I’ll update the functional specification anytime soon. It’s really out of date, but would take up quite a lot of time to rewrite, and for what benefit I’m not really sure at this point. The technical spec contains most of the information I need. Perhaps it will be time to update the functional spec once the API is nearing completeness and I start really working on the UI.

In the meantime, it’s time to get back to hacking!

Looking for the comments? Try the old layout.

I’ve been working on the design for what are called distribution jobs and alerts in Bricolage 1.x. There were some good ideas there. Distribution jobs enable users to set up a list of tasks to execute against the files being distributed, such as validating them against a DTD or distributing them via email. It also allowed developers to create fairly simple plugin modules that could be added as new jobs. Alerts are great ways of letting users know that some even has happened, and their rules-based evaluation of event attributes is a powerful way of configuring alerts to be sent only for certain events logged for certain objects.

The problem is that they’re specific solutions to general problems. Distribution job s are an example of scheduling arbitrary tasks to be executed, while alerts are an example of triggering the execution of arbitrary tasks upon the logging of an event. So what I’ve been working on is trying to generalize these ideas into a simpler yet more powerful and flexible architecture. What I’ve come with is this:

Tasks

Very simply, a task is an object of a class designed to perform a simple, um task. Examples include publishing a document, expiring a document, sending an alert, or validating a file against a DTD. An abstract base class, Bricolage::Biz::Task, will establish the the interface for tasks, although its subclasses may add their own attributes (such as the subject and message of an alert). Each will implement an execute() method that will simply carry out the task on the object passed to it. Some task classes may operate on only one type of object (such as Task::Publish), while others may operate on many or even all Bricolage business classes (such as Task::SendAlert). There is no connection between task classes and events or jobs, except that the object that called the task object’s execute() method will be passed to execute() as a second argument.

Actions

An action is an event-triggered series of tasks. New action types can be created that have rules set to be evaluated against the event, just as is currently the case for alert types in Bricolage 1.x. The difference is that rather than being limited to sending alerts, actions types will be associated with one or more task objects, and each of those tasks will be executed in sequence when an action of that type is triggered. This will enable users to, for example, configure an action to republish an index document whenever a story document is published.

Jobs

A job is a scheduled series of tasks. Users will be able to create new jobs for any single object in Bricolage, associate any number of task objects, and then schedule the job to be run at some specific date and time in the future. This approach will enable users to, for example, schedule a job to send an alert about a given document one year in the future, as a reminder to update the document.

Destinations

Destinations will be similar to what’s currently in Bricolage 1.x. However, rather than having “job” classes specific to distribution, they’ll be able to specify a list of any tasks that are designed to be executed against an output file. This keeps the interface for tasks identical across all three uses.

Alerts

Alerts are no longer closely tied to events, since they can sent as part of a scheduled job or as part of a distribution to a destination in addition to when an event is logged. Rather, they will only be created by Bricolage::Biz::Task::SendAlert. So a Bricolage business object can have any number of associated alerts, just as it can have any number of associated events.

Upshot

The upshot of this redesign, which took me several days of thinking to tease out to be general enough to satisfy me, is that more users will have more of what they need from Bricolage, and developers can more easily add new functionality that’s immediately available to event actions, scheduled jobs, and distribution destinations.

Looking for the comments? Try the old layout.