Of course, you get what you pay for, and Perch is definitely worth paying for… for some projects. Perch is very unique in its approach. Consider it an emergent CMS. Perch doesn’t have a predefined site structure that it builds on. Rather, you insert tags into your pages that CMS picks out and pairs with templates used for data-entry. It took me a while to wrap my head around it, but once I did I found it to be very powerful.

Because it’s not free (~$55 per domain), I’ve not used it at every opportunity. So far, I’ve reserved it for sites where someone else is picking up the tab, which is where it shines because that usually means I’m building a site for a non-technical user, thus Perch’s emergent CMS provides the minimal UI for that user’s site. For example, I used Perch to build a real-estate site for a friend of mine, Williams & Associates.

Originally, I was going to build this site on top of WordPress: pages for fixed content, categorized posts for news and property listings. I found a plugin that would provide a custom set of form fields for editing a post that would’ve worked well for the property listings… if I could have gotten it working. In the end, I was fighting WP more than it was helping me, and even if everything worked as planned there would still be a hugely complicated admin UI presented to the client whenever they wanted to make changes. (Yes, there are plugins to address that as well…)

I then ran across Perch. I loved its minimalism. It allowed me to build the site exactly as I wanted — which if you look at the HTML, you’ll see is pretty minimal, way more than a normal WP site would be — and then generate the admin-side of things automatically from its structure. Perch 1.0 definitely lacked some major features, such as image uploads and list re-ordering, but these have largely been addressed in recent updates (though they were slower coming than I would have hoped).

In fact, I was quite happy to see that when I recently went in to make some updates to the site, I ended up spending far more time in the admin UI editing text than I did touching any HTML structure, much of this thanks to Perch’s native support of Textile and Markdown.

Just last week, Perch 1.5.5 was announced, and I’m looking forward to playing with its new features. They include the notion of “apps” that I’m very interested in checking out. I do wish Perch was free, or significantly cheaper (say, $5 for non-commercial sites), or offered a subscription license (unlimited domains for a year) as it’s a perfect fit for lots of throw-away sites where a full-blown CMS would simply be overkill.

1. The WHATWG and W3C revise the Canvas API to align with Flash’s Display List API.
2. Adobe donates the Flash Player to the WebKit project to serve as an initial implementation of the revised Canvas API.
3. Apple, Google and Microsoft adopt and implement the revised Canvas API in all of their desktop and mobile browsers.

I think this is an ideal compromise: everyone gives a little, everyone gains a lot. There are no losers.

I’ll address each point in more detail this week.

I suggest visiting CTW to get the full run-down of what’s offered, but a quick description: CTW is place for kids (and adults!) to build their own games and “chat worlds” to share with their friends. Everything is built from treasures that folks can purchase through micro-transactions or earn using the Nintendo DS game Treasure World which Aspyr shipped last year.

CTW was the first project I used Robotlegs on. Even though we didn’t use it extensively—the other developer on the project was not familiar with dependency injection—it provided a nice solid architecture to jump off of. And due to its minimal nature, even when we weren’t leveraging it, it was never in the way.

While we were working on this project I also started several other smaller projects leveraging Robotlegs (none yet released) and have gradually refined my own workflow with it. I’m still a fan, though I’m quite curious about Swiz because it appears to be even more minimal, if that can be believed. I am completely sold on the idea of dependency injection and have started applying it to my API designs.

My latest Robotlegs project is also my first project to leverage Rob Penner’s excellent AS3 Signals. These two together have significantly cleaned up my code and are definitely quashing many of the architectural issues I ran into when developing the original Mockingbird app. In fact, I’m itching to go back and rebuild the whole app and site—not to add features but to clean up the codebase in such a way that it’d be ready for some rapid feature addition in the future. Robotlegs definitely provides a very agile framework.

For CTW we also used SmartFoxServer for the first time. In the end, I was less enthused about this choice. While it got us up and running really fast with it’s simple API and built-in chat functionality, it was a pain to develop with and debug, and I wouldn’t choose to use it again. The API originates from AS1/AS2, so there’s very little type safety and none of the current AS3 conventions. The documentation leaves out a huge amount of caveats present in the API that don’t necessarily make sense, even though it’s clear from the support forums that developer after developer encounter the same issue. The next time around I plan on using a more robust option, like ElectroServer, or possibly the still-in-alpha Union Platform.

Nice metaphor they’ve taken advantage of is the notion of a “script” (i.e. typed dialogue and stage direction) as a fundamental component of movies. People get that, they can wrap their heads around it. I think we’re close to finding the same thing with games, but the metaphor is not quite as concrete yet.

Peter Williams – Hypermedia as the Engine of Application State.

Mockingbird’s REST API is pretty straightforward because documents are constructed on the client and the server API essentially just loads and saves whole documents. But it’s intriguing that it could be completely encapsulated on the server by simply doing what the server already does for humans…

The Sporepedia, which serves as a clearing house for the most popular creatures created by players, employs a very clever (and very user-friendly) means to upload/download creatures: they embed the data in the PNG thumbnail of the creature. Instead of having some custom data format that’s opaque to the user (and basically worthless after it hits their desktop except for importing straight into Spore), the user has a traditional PNG that they can trivially view on any modern browser/OS. Embedded in the alpha channel data of the PNG, though, is a bunch of data (about 1K according to some estimates).

Now, this is an old trick, and you can do it “officially” with PNGs in custom chunks or in JPEGs, etc. It’s possible in almost any well-structured format. But it’s a very clever, modern, web way of handling it. It allows for trivial sharing by the user through whatever means they’re accustomed to because sharing an image is an almost universal feature of any collaborative software. So, user’s can attach the thumbs to their e-mail, or post them to their Flickr account, or put them on Facebook or their MySpace page, or send them in an IM.

Consider this inspiration! I’m now officially on the look out for how I can apply this technique to Mockingbird. Embedding the game’s description in its screenshot? Encoding ActionScript into the action icons? I don’t know, but I’m going to find something. And you should, too! Incorporate this feature into your products today!

Of course, Valleywag calls it “bizarre”, “rambling” and “entertaining nonsense”, and a majority of the comments are no more flattering. I (and some of the comments) get it, though. It’s rather brilliant. Stewart reveals himself to be a well-rounded, liberally-educated guy who can actually write! Of course, I could feel that in all of the presentations I’ve seen from the Flickr founders who always come across as having a real grasp on the human nature intrinsic to a social website. I think we (designers of interactive content, whether it be the web or games) could learn a huge amount from Flickr and the views of its creators.

In fact, I wrote about this not too long ago (from the UI designer at Flickr). Read the essay. Get inspired to create something for people.

It wasn’t that long ago that I gushed about Cake. But after doing some development with it (beta sites for Mockingbird), and after recently working on our current site (which runs on top of Pligg, kinda), I’ve started to kinda think, “hey, what are these guys actually doing for me?”

First, I am still baffled that with all of the auto-sniffing-magic that these frameworks (Rails, et al) do I still have to describe by database schema in two places. I mean, come on, Microsoft solved this problem in .NET. Sure, they do it through code-generation (XML database schema creates the actual underlying database as well as generating all of the C# classes used to interact with it in a completely typed, validated way). But with Cake (and with Rails, AFAIK) I have to go off and do DB admin creating tables and indices and such, and then I have to come and create some parallel classes in the framework. Sure, I don’t have to specify the individual fields, it’ll automatically attempt to map unknown properties for me… unless I want to build-in validation, or relationships, or serialization… you know, trivial little things that only serious webapps would need… ahem. Sure.

Second, I’m just terrified by the amount of decision-making that is made each time “through” the framework when one of my pages is served up. Sure, op-code caching alleviates some of this, but really, should I be executing 10x the necessary amount of code to save me from having to write out a dozen lines of completely self-explanatory, easy-peasy lines of code?

Maybe I’m missing something… maybe these guys are doing a lot of stuff for me I’m not realizing. But I get the itch’n feeling that they’re really just providing a different syntax (with some defaults that make building a bare bones blog in 15 minutes a snap) on bits that are already there, at a lower level.

Routing — mod_rewrite/.htaccess is the only routing tool you need. I almost guarantee you’re not doing anything in your webapp that requires some kind of routing logic that can’t be handled elegantly with mod_rewrite/.htaccess.

Controller — this is the PHP file that your mod_rewrite directs queries to. All you need to do is practice some self-control and keep all of the aesthetic bits out of this PHP file. Just do the work, the logic of the user’s request. When you done all your work, just pass the results off to the view.

View — go download Smarty. Just use it. Flickr uses it and they get more traffic than you ever will. It’s a templating engine designed with the viewpoint that the template should *only* be the view and that the designer and programmer are at least independent tasks if not entirely different individuals.

Model — I was very frustrated with Cake when I tried to combine it with Pligg. Pligg had a particular table/field naming scheme, and Cake had a similar (but different enough) scheme. There was no combination of tweaking that would get one to be compatible with the other. Writing the necessary SQL queries to bridge the gap manually was trivial. And I knew them all along – in fact, I used them when debugging the naming scheme in an attempt to work backwards. :) Just grab ezSQL, that’s as simplified and automatic as your database interaction should be, because the database is critical (and powerful) if you don’t discount it as just a big property list.

Helpers, Components, Behaviors &mash; these frameworks all have a bunch of additional “utility” features that basically just make life easier as a webapp developer. These could be worth it, if they’re you’re particular flavor. But I bet for each one there’s a strong, healthier open-source version that does more.

Maybe I should put my money where my mouth is? Maybe so. How cleanly could I build a webapp without a framework (and without implicitly building one myself)? In other words, have we heaped one abstraction too many on the pile?

Treat your place like your home: welcome people, fix them a drink and make them feel comfortable. Before you know it, your guests will be chatting amongst themselves, the party will be pumping, and people will be making plans together.