Beckism.com

When I was first starting to program TapNote I did a lot of reading through Palm’s documentation and other WebOS developer help sites, but I never was able to find any good information on how to set up a data model.

Turns out that there aren’t any official recommendations. Palm mentions the app/models folder mainly just to get you thinking about using an MVC design for your app, I suspect.

While I designed the architecture of my app, however, I thought a fair amount about how to break down the logic, and I ended up coming up with some guidelines that may help other developers with their app design. Of course, this is probably pretty obvious stuff for people who design with MVC regularly, but I would have found it useful when I was starting out with WebOS programming (particularly because it was complicated by WebOS’s persistently asynchronous nature).

Knowledge and responsibilities

The controller (or assistant, in WebOS parlance) knows these things:

• The interface for the model
• The expected Javascript object schema for the data
• Details about the view elements (views being the HTML files for the scene)

The controller’s responsibilities are:

• Querying the model for new data when needed
• Updating view items with data once the model sends it over

The model (which should be either a Prototype class or a unique object stored in your app/models directory) knows these things:

• Exactly what storage system is being used for the data
• How to interact with the storage system (SQL queries or whatever else)
• The Javascript object schema for the data

The model’s responsibilities are:

• Gathering data when it is requested
• Transforming the data from its raw format into the proper Javascript object
• Returning the data using the provided callback

A decent metaphor is that of two coworkers in neighboring cubicles. The controller asks for something from the model, and tells it where to send the results. The model does what it needs to do to gather those results, then sends them where the controller requested. Neither can see into the other’s cubicle to know what exactly what their coworker is doing, but neither one needs to. Either model or controller can change what they’re doing with the data (how it’s stored or how it’s displayed), but this won’t affect their relationship to one another.

If you ever have something in the controller that depends on knowing what type of storage system is used for the data, you are doing it wrong. Similarly, if you ever have anything in the model that references or needs to know about specifically what view items are being populated with data, you need to rethink your architecture.

Basic layout

Unlike assistants which are automatically loaded by Mojo when their scene is pushed, you will need to add your model class to your app’s sources.json file by hand:

[
    {"source": "app/models/myDataModel.js"},
    {
        "scenes": "Myscene",
        "source": "app/assistants/myscene-assistant.js"
    },
]

What this does is expose the contents of myDataModel.js globally to your app (so be careful with your globally scoped variable names!).

Typical round trips

Based on TapNote’s design (in which I tried to follow the above guidelines), this is a typical function layout for the controller:

• Request function: this is typically triggered by an event in the view, and all it does is request something from the model (passing along any relevant info from the event, along with the callback function reference)
• Callback function: this accepts data from the model, and does whatever needs to be done with it in the view.

A typical controller would thus look like this:

var MysceneAssistant = Class.create({
    /* Standard function for Prototype classes */
    initialize: function() {
        this.model = new MyDataModel();
        // Always save static bound references to member functions
        this.bound = {
            populateData = this.populateData.bind(this)
        };
    },

    /* ... Setting up events etc. happens here ... */

    /* This function is triggered by an event */
    refreshData: function(event) {
        // Any necessary logic prior to requesting data
        this.model.refreshData(this.bound.populateData);
    },

    populateData: function(dataObject) {
        // Handle populating the view with the data object here
    }
});

My model ended up being very similar, since it too had an asynchronous call (although if you were accessing data in a depot or cookie you might not need two functions):

• Request function: receives requests from the controller, builds the necessary SQL (or whatever) and executes it, binding the callback into the success function of the datastore
• Return function: processes the successful results from the query, and sends the results of processing to the callback

Using the previous example code for the controller, here’s how our model class would look:

var MyDataModel = Class.create({
    /* ... Set up the model here ... */

    refreshData: function(callback) {
        // Set up the SQL, etc. here
        // Query the database here binding in our unique callback
        this.db.query(query, {
            onSuccess: this.returnData.bind(this, callback)
        });
    },

    /* Because of the on-the-fly bind, the callback is the first arg */
    returnData: function(callback, results) {
        // Transform results into Javascript object; simple example:
        var resultObject = results[0];
        // Send the object to the controller
        callback(resultObject);
    }
});

Unlike the controller, in the model we have to do the binding on the fly because otherwise we can’t pass the callback through. If you can guarantee that there will only ever be one controller requesting data at any given time, you could instead use a this.bound object like the controller and save the callback to a class variable (for instance, this.callback).

Brief side note: you may notice the unexplained this.db.query() call above. When I was writing TapNote, one of the first things I did was write a generic Database class to abstract away from the heinous syntax of the HTML 5 database connection. This is a generically useful class that I’ve released for free.

Implementing in your own app

The above examples certainly are not the only way to do things (I actually deviated from that design a bit for some data responses when TapNote became a multi-stage app partway through development), and you will likely find yourself changing things up based on the needs of your own app. However, if you start with this design as a basis and keep in mind the roles and responsibilities of model and controller, then you will hopefully create an app whose code is easy to debug and expand on down the road.

My girlfriend and I went to see The Princess and the Frog last night, and it was fun. Not great, but fun. Unfortunately Disney has managed to capture the spectacle but little of the soul of past great Disney movies (which is mildly ironic, given the movie’s setting). The Princess and the Frog was exquisitely executed (beautiful animation, great voice acting and characters, high-energy music) but something was missing, a core component that left the movie feeling ever so slightly flat.

My first inclination, comparing the film with my Disney favorites Little Mermaid, Beauty and the Beast, and Aladdin was that Princess and the Frog had used those prior movies as a formula and that was what was jarring. Upon further thought, though, I realized that the use of a formula wasn’t the problem; I’d never noticed before Princess and the Frog made me think about it, but Little Mermaid, Beauty and the Beast, and Aladdin follow strict formulas themselves. Heck, they’re practically the same movie:

• The movie opens, and shortly after introducing the main characters our heroine (or hero, but most of them are female for this particular sampling so for simplicity I’ll stick with the feminine) is brought to the villain’s attention. The villain reveals that the heroine has something that makes them uniquely important to the villain’s personal goals (Ariel is the key to Triton’s power, Belle is the only girl worthy of conquest, Aladdin is the only one who can gain the power of the lamp)
• Early on, our heroine reveals their core motivation via song (Part of Your World, Belle’s opening song, One Jump Ahead)
• A spectacular musical number reawakens our interest (Under the Sea, Be Our Guest, Friend Like Me)
• At some point, the villain has a lone musical number, partially spoken or otherwise not as melodic and memorable (Gaston’s song being something of an exception, likely because he’s more of a passive antagonist otherwise so they had to compensate somewhere to make him interesting)
• Various filler songs occur here and there, typically to advance the plot
• A love song occurs at the primary moment one (or both) of the love interests realize their feelings (or otherwise reach a turning point in their relationship)
• A showdown occurs with the villain, the heroine triumphs, and the culmination of their triumph is the marriage to the love interest and achievement of their dreams

You can break the formula down even further past the musical numbers to specific characters (villain’s humorous sidekick, heroine’s non-human helpers, etc.), but you get the idea.

It wasn’t that The Princess and the Frog followed a formula, then, that impaired the movie. In point of fact, the way it nails almost every aspect of the Little Mermaid/etc. formula may well be its greatest strength. Disney obviously brought a lot of budget and creativity to bear to bring the movie to life in the same vein as their old hits (even making the comparison explicitly in their previews, which is what cued me into comparing the two as I was watching it). Yet unlike Little Mermaid or Aladdin I didn’t walk out of the theater wanting to see it again, or utterly captivated by the characters, or excited and eager to tell my friends about the movie. I came out of the theater and thought, “Well, that was fun. Don’t really need to see it again.”

I’ve been pondering, and come to the conclusion that what the Disney movies of the early 90’s that I remember so fondly had that Princess and the Frog lacks is the spark, the soul, the story that needs desperately to be told. Without that inspiration, the formula falters, the pieces pull slightly apart, and the viewer is left with the realization that there is a formula and that it isn’t quite working.

Great movies happen because creative people get excited, and if they’re lucky they have the budget and direction they’ll need to create something fantastic. I think that people got excited about Princess and the Frog, but I don’t think that it was because of the story that drives the entire project forward. I think they got excited about the spectacle, the fun characters, and the setting. And in the end, that made the difference between a film destined to be a classic and one that is merely diverting.

The more near misses I see in the theater the more I’ve come to believe that story is the driving creative force that must exist for any narrative work to succeed, be it cinema, literature, or otherwise. Certainly, great characters are a part of the puzzle. A well-tested formula can help clarify and ease the story’s delivery. Talented people well directed can breathe a lot of life into any tale. But unless these things are born out of a story that needs to be told the pieces won’t quite snap into place.

The Princess and the Frog is not a story that needed to be told. It’s a decent story, an amusing story, a story that pleasantly reinforces our own delusions about ourself and our culture; but it isn’t a story that needs its telling so badly that it grabs the imaginations of its makers and viewers alike and refuses to let go even once the curtain has closed.

I don’t know where stories come from, or even how crafted and calculated the Disney movies of yore that I loved might have been behind the scenes. All I know is that in Princess and the Frog Disney has produced a film that sparkles, amuses, and tweaks gently at the heartstrings yet fails to achieve the vivid life bequeathed by story.

I’m a long-time user of StoryMill (starting when it was originally called Avenir), but I’m also something of a software junkie, so when Scrivener came out I tried using it for a few projects. Particularly now that StoryMill has a timeline view (as of this writing the only Mac creative writing software to implement the feature) and Mariner Software is distributing it, it seems like a more and more people are wondering whether they should use StoryMill or Scrivener.

Well, here it is: my definitive StoryMill vs. Scrivener review. Although StoryMill is my personal application of choice, there’s a lot to love (and some things to dislike) about both programs.

Quick and dirty

Not everyone wants to wade through my periphrastic meanderings (just discovered that word, and it’s making me really happy; sorry for sounding like a total vocab snob), so here’s the quick and dirty:

• If you primarily write fiction and want a program that will provide you with an easy framework for organizing your writing, you’ll probably prefer StoryMill.
• If you primarily write non-fiction or screenplays or write fiction and want a program that will let you do pretty much whatever the hell you want workflow-wise (with a correspondingly higher level of confusion), you’ll probably prefer Scrivener.

A broader picture

As is often the case, the fast and dirty comparison is a bit misleading: either program can help you write fiction or non-fiction. The reason the fiction/non-fiction comparison is common is because StoryMill is explicitly focused on fiction (and doesn’t support screenplays at all, since that would steal sales from its companion software Montage) while Scrivener provides a general writing metaphor that can apply to either genre equally well (with limited support for screenplay formatting and footnotes).

The truth is that regardless of your genre the deciding factor for which software to use will be a matter of style. StoryMill’s approach is to provide you with a specific framework for writing and organizing, complemented with a focused group of powerful features. In contrast, Scrivener is much more flexible and offers a larger number of features that you can pick and choose from to form your workflow. You can do most of the things in Scrivener that you can in StoryMill (with a few key exceptions), but it will be slightly more effort.

If StoryMill’s framework makes sense to you and you don’t have an urgent need for any of the features that are Scrivener-only, then StoryMill will be the easiest environment to write in. However, for some people the time necessary to set up their own framework in Scrivener is well worth the effort because the program’s flexibility allows them to write most effectively.

To figure out which style, and thus program, is the best choice for you, you’ll need to consider two big questions: what metaphors do you use for writing, and what specific features are most important for you?

StoryMill: a novel framework

The foundation of StoryMill’s approach to writing and organizing is the scene. Scenes in StoryMill are the building blocks which create chapters and ultimately the story itself (it’s worth noting that you can think of scenes and chapters as whatever content blocks make sense for your story; the names don’t really limit the function). Though you’ll track your characters, locations, and so forth elsewhere, the scenes are where you’ll tie them together.

StoryMill offers several other types of items like characters, locations, research, and even submission tracking for when you complete the novel, but the scenes are the core of the program. If working with scenes makes sense to you, and you like the ability to directly relate characters to scenes and organize both in plot order and chronological order (the latter via the timeline feature), then StoryMill will likely appeal.

This scene-centric framework has actually taken a page from Scrivener’s book in recent updates, as well. You can use scenes either as an outline (in the Scenes view) or as the actual text of the story (in the Chapters view). Storing text in scenes can be a little bit confusing (particularly since you can still store text in chapters and use scenes purely for organization if you choose), but this allows you to take advantage of the outline-as-text feature that Scrivener executes with such panache.

StoryMill also has some specific stand-out features that influenced my decision to use it. For me, annotations are one of the biggest. In StoryMill, you annotate text by selecting it and choosing “Annotate”. The text turns the standard link blue with underline, and a little window opens up in which you can type the annotation’s title (defaults to the selected text) and add your annotation. This is great for a number of reasons:

1. Annotated text is clearly marked, yet the annotations themselves are completely invisible unless you want to see them.
2. Annotations are rich text, so they can contain just about anything. This includes images, formatted text, etc.
3. StoryMill handles annotations intelligently: if you open up the annotations window and start moving through the text with your cursor, the displayed annotation will update based on which linked text the cursor is in. You can also open the annotations window for a given annotation with a hotkey (no clicking the link required).

Some people prefer the margin-notes approach to annotations in Pages, Word, etc., but I find those extremely limiting because if you type more than a sentence or two they become unwieldy, it’s not always easy to tell what text the annotation applies to, and you can’t have very many on a page before they get out of control. The only thing they have over StoryMill’s annotations is that you can view all of them at once, but in practice I’ve never found this to matter.

Another big draw for StoryMill is its timeline functionality. Timelines allow you to view and organize scenes in chronological time, even if the flow of the novel is completely different. This can be fantastically helpful for preventing plot holes and other inconsistencies, and getting a general overview of the flow of time through your novel can be useful in its own right. The downside to timeline is that it’s still a young feature; the interface could use a little refinement and it had a bit of a rocky start thanks to some bugs, but there’s still nothing comparable out there (aside from dedicated timeline software).

StoryMill has numerous other small features that I can’t live without, as well: the progress meter is a one that I’ve surprisingly grown to rely on. It visually tracks how far along you are for both your session and project word goals. It also can emit a sound when you hit your session goal, which is really nice feedback if you’re working in full screen. Full screen is of course another great feature, although one that’s available in most writing software these days. The reason I like StoryMill’s better than Scrivener’s is that it’s truly nothing but you and your writing; no annotations, no floating windows, nothing but the text. Tags and smart views, export templates, and the project-wide find and replace dialog are other reasons to love StoryMill.

Scrivener: your digital corkboard

Scrivener takes a slightly different approach to the writing process. Where StoryMill provides a framework with carefully designed parts, Scrivener offers the user a beautifully executed corkboard metaphor and then hangs potentially useful features around it.

Scrivener’s corkboard is where it really shines. The connection between outline, visual organization of “index cards”, and your actual text is simple, sensible, and flexible enough to handle virtually any kind of writing. Want to break things down into beats, then scenes, then chapters, then acts? Go for it. Your only real limit is your creativity. Scrivener’s central metaphor additionally captures in a digital format a way of working that instantly makes sense to most people who have written by hand. This is a definite strength over StoryMill, which takes a more relational database-driven approach to organization and writing that may not be as easy to initially access for some people.

Aside from its elegant central metaphor, Scrivener also offers a slew of useful features. I encourage you to check out the Scrivener website and free trial to figure out which ones you’ll care about, but the primary things of interest to me are snapshots (saving multiple versions of a single piece of text), wiki-style links to internal documents, the vastly flexible exporting system, and the simple script-writing formatting tools.

It’s worth taking a moment to dwell on snapshots. Although StoryMill is planning to implement similar functionality for their next version, this is a key area where Scrivener is clearly the better choice. Organizing multiple revisions of the same text in StoryMill is extremely kludgy at the current time, while Scrivener handles it with ease.

Additionally, you can (with a little bit of work) mimic some of StoryMill’s strengths in Scrivener. For instance, the Document References could be used to associate characters with scenes. You can also mimic StoryMill’s annotations to some extent using wiki-links that open in split views (Scrivener’s built-in annotations are inline with the text, making them only useful for very short notes to yourself that you don’t mind reading every time you go back over things). They’re not as easy to use as StoryMill annotations, sure, but this kind of flexibility is another of Scrivener’s strengths. The menus may be confusing and (to my eye) bloated, but all those disparate features mean that with a little work you can achieve numerous different workflows.

Beyond the software

Of course, there’s more to writing than just the software itself. Both Scrivener and StoryMill have healthy communities and refreshingly responsive developers. Scrivener has a larger community (and one more inclined to chat about whatever the heck is on their minds), but you may get a faster response in StoryMill’s forums simply because there aren’t as many threads. Your mileage will doubtless vary, but I highly suggest dropping by the forums for whichever software you’re leaning toward and asking any questions you have.

An additional concern is interoperability between your writing software and other software on your computer. Both Scrivener and StoryMill store data in proprietary formats but both also offer flexible ways to export that data. Which export system you like better will probably depend a lot on what you need to export, but both allow you to get all of your data out of the program without much fuss. If you’re trying either software’s free trial, definitely play with the export system before purchasing it.

Scrivener additionally allows easy editing of text in external programs, which can be nice if you like editing text in WriteRoom, BBEdit, or similar.

Time to write

Both StoryMill and Scrivener were created because the developers couldn’t find a tool that fit their respective needs as authors, and the bottom line for any potential user is you should use whichever program makes it easiest for you to write.

For myself, that program is StoryMill. Its framework makes sense to me and I’ve become addicted to its overall slimmed-down focus on the features that matter most (not to mention some specific niceties like rich annotations and timelines).

I can certainly appreciate the draw of Scrivener, however. Every time I open it I’m amazed anew at how simple and relevant a metaphor for writing it provides. StoryMill’s niggling issues with the separation between outline and text are nonexistent in Scrivener thanks to its solid basis in the idea of a corkboard. Sure, to get the kind of interconnectivity that StoryMill encourages you have to do a bit more work, but with Scrivener’s large and helpful community figuring out a document layout and workflow shouldn’t be too painful.

Ironically, in a few short years we’ve gone from having no great alternative writing environments to Word and the other word processors to having a difficult choice between two strong contenders (and that’s discounting the scads of similar but less popular software like CopyWrite, Jer’s Novel Writer, Storyist, or Ulysses, the program that started it all); no choice has exploded into too much choice. Hopefully by focusing on which general approach and specific features are most helpful for your workflow you’ll be able to select the best software for you and get on to what’s really important: your writing.

Although I find my current work as a web designer interesting and occasionally fulfilling, it is not what I want to do the rest of my life. Since I was a snot-nosed kid in fifth grade, I have instead set my sites on being a novelist. I know that I’m capable of writing a novel (learned that thanks to my senior thesis), but up until now my writing has been very haphazard. I’ll write on vacations (sometimes) or when the mood strikes, but anyone who has tried to write a novel knows that you’ll never get anything done doing that. To write a longer work, writing has to be a habit, and I’ve been finding it a difficult habit to form.

So this year, I’ve decided to finally jump on the National Novel Writing Month (NaNoWriMo) bandwagon in the hopes that the experience will help me settle into some good writing habits, like writing every morning instead of poking around listlessly online. I will, of course, be writing in StoryMill because I can’t fathom writing in any other software (and yes, I’ve tried pretty much all of the ones available for Mac).

But upon opening StoryMill and prepping a new document for the fast upcoming November 1st, I realized that my typical approach to writing in StoryMill simply isn’t going to work for NaNoWriMo. In order to finish 50,000 words in 30 days, on top of a full time job and other distractions, I’m going to need to write, write, write. Outlining, character backstory, notes on locations, research—all of these will be distractions that could well prevent me from reaching the goal, and yet all of these things are tasks that I regularly undertake in StoryMill. In fact, the program encourages it; take a look at its default novel document:

This is no good at all. Keeping track of characters, scenes, etc. is certainly useful, but I’m going for pure word output, and if the option to procrastinate by expanding on my backstory is available, I’ll probably take it. So to start, I decided to axe absolutely everything except the generic Tasks view, which I renamed to Notes (to delete and rename these items right click a view in the sidebar and choose Manage Views; then when you’re done, right click the smart view and choose Remove View):

I can add those views back in when it comes time to clean things up, and in the meantime I can drop any notes on backstory or whatever into the Notes view as I think of them without feeling any pressure to expand on the ideas. Will my story have more plot holes and inconsistencies than if I’d left those views in? Doubtless. But darn it, I want to win NaNoWriMo! I cannot afford distractions.

Next up, I took a look at the chapters view. I definitely am going to want to write my text in Chapters (the chapters editing window, which you can get to by double clicking a chapter title in the list area, offers numerous incentives like highlighting and annotations that aren’t as easy to use in other views). However, worrying about where my chapter breaks fall is going to slow me down and distract me yet again. I suppose I could just write in a single long chapter, but it would get difficult to manage quickly. Instead, I think I’ll add a new chapter every day. That way I can not only see how many words I was able to write in retrospect (which could be useful info), but I’ll have the story broken up into easily skimmable chunks if I need to go back over it to remember someone’s name or whatever.

Just to prevent any temptation, I also right-clicked on the Timeline button in the toolbar and chose “Remove Item”. Sure, it would never have been activated because I don’t have a scenes view, but the temptation to add a scenes view would be there.

Last, but certainly not least, I double clicked the Progress Meter and set my goals appropriately:

And with that, I’m ready to start writing, as distraction-free as I’m likely to get. I’m sure this system won’t work for everyone (heck, it might not even work for me; I’ve yet to test it out), but my hope is that by slimming down StoryMill to the bare essentials I’ll be able to get my first draft in there as part of reaching the NaNoWriMo goal of 50,000 words, and then I’ll be able to add features like the scenes view, characters, and locations back when I get ready to revise so that I can start cleaning up plot holes and putting a little more thought into the novel. Plus, needing to copy and paste all of my text into scenes will be an excellent excuse to read over it all as part of my revision efforts, anyway.

For other NaNoWriMo participants planning to use StoryMill, here’s a few generic tips to help you out:

• Full screen will likely be your best friend. You can enter full screen quickly from just about any part of the program by hitting command-option-F. Exit full screen by hitting escape.
• As I mentioned above, the Chapters window is probably the best editing experience in StoryMill (aside from full screen). Double click a chapter in the list or sidebar to see what I mean.
• If you’re using a slimmed-down project like I will, you’ll probably also want to avoid spending much time adding tags to things. However, if you drop something in the Notes view it would be a good idea to toss a couple quick tags on it to make sorting through things later easier. For instance, a note about a character could get a “character” tag. Then when it comes time to add the characters view back in you can make a smart view based on notes to filter for all character items and hit the ground running.

Good luck to the other NaNoWriMo participants!

I have never found a Mac OS X RSS feed reader that, after extended use, I was completely happy with, and this makes me sad because my feed reader is right up there with my email client for regular usage. Every time a new feed reader comes out, I eagerly try it, am often very happy with it initially, and then inevitably become dissatisfied with its shortcomings after a week or two of use.

I’ve tried and discarded NewsFire, Vienna, NetNewsWire, NewsLife, Times, and many others which were on my computer such a short time they don’t deserve a mention. None of them fully satisfied my needs.

Most recently, I decided to give Fever a try. Though I highly dislike web apps (I’ve never found a web app that was remotely as good as its desktop counterparts, mainly thanks to speed and usability issues), I love Mint and figured that maybe, just maybe, Shaun Inman would be the one who could write a web app that was actually useable day to day.

Sadly, my hopes were dashed. Fever is too slow to handle the speed that I can skim through feeds, and has some of the same problems that drove me from NewsFire (like refreshing automatically and losing your place in whatever you’re viewing after an update). I find that I never use the “Hot” functionality because it is so useless at actually predicting what I’ll find interesting (partially thanks to my lack of Spark link blogs, but others have had similar issues), and as a result Fever for me has turned out to just be a rather unresponsive generic feed reader.

(Side note: I haven’t been happy with Fever, but I’d still hesitantly recommend it for some people. Simply the fact that its capable of standing up with options like NewsFire and NetNewsWire is a big point in its favor if you don’t mind the Ajaxy slowness.)

Despite my rampant discontent, I still do not want to code a feed reader myself, so on the off chance that someone is trying to make the perfect feed reader, here’s what it needs.

Make sure keyboard navigation is easy to use. This is the part of Fever that I enjoy most. Hit space bar to jump to the next item. Right arrow opens the item in the browser. Enter swaps between excerpt and full text. Left arrow jumps back to the source list to select a different group. Brilliant.

Allow grouping items by source feed. NewsFire does this beautifully, but for some reason none of the other feed readers have even attempted it. I typically want to read or skim items based on which feed they’re in, and grouping items visually by feed makes it very easy for me to do so. Sticking the source website in a column, or under the title, or over the title, or next to the title does not work as well.

Don’t use a three-pane interface. Mail is a brilliant application for reading email. Feeds are not email. Go use Fever, NewsFire, or Times and find out why designing a great, feed reader-specific workflow is a better plan than rehashing the tired old three-pane news reader.

Settings should be possible to apply per feed, per group, or as application defaults. I love that NetNewsWire and Fever both allow me to granularly set behavior preferences for feeds. Setting refresh rates on a per-feed basis is rarely necessary, but when you need it you’ve got to have it. When I was hunting up freelance work, I subscribed to a few Craig’s List feeds. I eventually had enough work that the feeds were just noise, so (thanks to NetNewsWire), I stuck them in a group and turned off refreshing for that group. They were ready for when I needed them in the future, but out of my way for now.

Don’t sacrifice performance for aesthetics. Times, I’m looking at you. Times is a beautiful feed reader, with an innovative approach to feed reading, and a great set of features. I’d be using it right now if it weren’t buggier than an anthill. The somewhat recent 1.1 update fixed a lot of the really annoying bugs, but the program still isn’t usable. Maybe in another few point updates.

Don’t sacrifice aesthetics for performance. Hi, NetNewsWire! To be fair NetNewsWire mitigates this problem somewhat by offering some really top-notch themes, but although the application is certainly solid and obviously has been given a lot of attention to detail, it could still use a bit of the flair of NewsFire, Times, or Fever. I think there’s a middle road here, and on that middle road a talented designer and talented developer are collaborating. Sadly, feed readers appear to be primarily one-man-in-his-basement affairs.

Remember that users will subscribe both to feeds they want to read every word and those they merely want to skim. Times and Fever are both best for feeds that you want to focus on every headline. NewsFire is great for skimming through lots of headlines thanks to its group-by-feed feature. NetNewsWire is actually pretty good at both, as long as you’re careful about how you sort feeds into groups. The problem here is that the needs (and thus best interface) for feeds with lots of signal versus feeds with lots of noise are quite different, yet feed readers invariably only offer a single interface for browsing and accessing feeds (or offer multiple possible interfaces, but you have to switch between them globally for the whole program). I don’t know what the perfect solution is here, but I do know that it can only exist if the program recognizes that I have two very different approaches to feed reading and provides options accordingly.

Perhaps I’ll never see my perfect feed reader, and instead be destined to keep bouncing between substandard options as they release new upgrades and rekindle my hope that maybe this time they’ll have gotten it right. Perhaps Mac OS X feed readers simply aren’t profitable enough to attract the time and care necessary to craft something that does everything I want without being bloated and terrible, and I’ll eventually just have to suck it up and go with a web app.

But I hope that isn’t the case.

Shortly after it came out, I beat Braid, a puzzle platformer initially released for the Xbox 360 as an arcade title and incidentally the single best game I’ve played in years (it is now also available for Mac and PC). Braid was a short game (I finished it in one Saturday with lots of play, and a couple hours the following Monday; probably around 6 hours total) but it was one of the most satisfying gaming experiences I’ve had in a long time. Braid’s puzzles all revolve around your ability to affect time, and each one is unique. No puzzle requires you to travel until you find an appropriate item or hint that makes everything clear. You could, with patience and a willingness to think outside the box, solve each puzzle sequentially the first time you played the game. In a world where puzzle and adventure games have mostly devolved into mindless color matching or poking around until you find the hidden lever, Braid is a breath of fresh air.

If you’d like to get a great feeling for Braid take a moment to read through the Official Braid Walkthrough. I promise, it won’t spoil anything. Quite the contrary.

Early on when I was playing the game, I got frustrated at one of the puzzles and resorted to the internet to find a walkthrough with some pointers. I stumbled across the official one, read it, and rather sheepishly returned to the game without looking further (incidentally solving the puzzles that I’d had trouble with after leaving them alone for a while and coming back).

But the day that I beat the game, I cheated for real. In my defense, one of the puzzles that I sought help-via-walkthrough on was something I probably wouldn’t have figured out without some sort of hint, dumb luck, or an outside opinion.

For the second puzzle whose solution I looked up, though, I was just being lazy. I had one puzzle left, as far as I could tell it was impossible, and I wanted to beat the damn game and go to bed. After reading the solution, I realized that it was far from impossible, that if I had slept on it one more night and come back with a fresh perspective I would doubtless have figured it out for myself, and that I had just cheated myself out of the pleasure of discovering a solution on my own.

Which makes me wonder; when did beating the game become so important to me?

I don’t really know for sure, but I suspect I have beat maybe only 25% of the video games I’ve ever played, and most of those I completed before I entered junior high. This is in part thanks to the fact that my prime game-playing time (high school and college) I spent working for Inside Mac Games where it was more important to play lots of games than to play games to completion. Even for games that I loved and had a compelling reason to finish (like a few of Spiderweb Software’s games) I inevitably got interrupted by something new that needed to be played and written up; a few interrupted games I went back to and finished, but many more I simply let fall to the wayside. The rest of the reason that I have such a rotten record for games that I’ve beaten compared to when I was young is that I can now afford to just buy a new game if something ends up frustrating or annoying me. When I was in elementary school, Riven pissed me off more times than I can count. I constantly came up against impassable obstacles, and there were weeks or more when I would leave the game alone in disgust and frustration. I couldn’t afford to buy any other games, though, thanks to my all but non-existant allowance, so I kept coming back to Riven until I finally beat it.

Given my record, beating a game isn’t high on my list of priorities. Hell, just looking at my Xbox arcade collection proves that; of the twenty-two I own, I’ve only beaten two (one of which was Braid).

Which brings me back to the question: why was beating Braid important enough to cheat myself out of further time with it? I know, both from experience and from the official Braid walkthrough, that the journey is the reward and sometimes all you need is a good night’s sleep for a puzzle to open up to you. And I still ruined it.

My temptation is to blame the internet. The games I remember most fondly are the old LucasArts adventure games (Indiana Jones and the Fate of Atlantis, Sam & Max, Day of the Tentacle, The Dig), and I played them through either before my family had internet, or when walkthroughs were harder to find. In a way, I couldn’t find spoilers, so I couldn’t spoil myself.

That argument, however, is unfair. The problem isn’t that walkthroughs exist and are easy to find. I actually prefer information to be readily available; there’s nothing worse than having something in a game you can’t solve that you’ve been working at for days with no luck, and then being unable to find any information online to help you. The fault lies somewhere else.

I think the real reason that I became so focused on beating Braid, despite knowing better, was because I have become accustomed to games having some worthwhile content that is then expanded with mountains of filler. A game of Braid’s caliber, where every puzzle is lovingly crafted and unique, took me completely by surprise.

And that makes me sad, both because the game industry as a whole is so focused on quantity rather than quality and because I as a gamer have reached a point where I’m so immured to games without redeemable qualities past the bullet points on their boxes that I unintentionally spoil the few gems that I do come across.

If you have not yet come across Braid, I urge you to learn from my mistakes: don’t just beat the game; play it.

Espresso 1.0 has officially been released for general consumption, and I’m extremely proud to announce that TEA for Espresso (coded by yours truly) is bundled with the application! Espresso is a text editor aimed firmly (for the moment) at the web editing crowd, and offers code folding, a powerful code navigator, FTP synching, Textmate-style text snippets (with tab stops and all that jazz), and an extensible underbelly for extending the program. It’s pretty sweet.

That said, I have to admit that my feelings about this release are mixed, and I don’t think that most people who live in their text editor (including myself) will be able to switch to Espresso full time just yet. I’m beginning to think that this may just be how text editors work. I was completely underwhelmed by Coda when it first came out, too, but after Coda 1.5 I tried it again and started migrating projects to it, and as of 1.6 I’m using Coda full time. While some people will find Espresso 1.0’s friendly and simple editing just what the doctor ordered, I suspect that its wider appeal will not be truly realized for another few point releases.

None of which, of course, answers the question, “Is Espresso for me?” Obviously, you won’t know until you try it out for yourself, but for those of you who like to have other people do the initial dirty work, here’s what Espresso is, what it is not, and where it’s probably headed in the near future. (Please note that I don’t have any insider info; I have been participating in the betas since slightly before they went public, however, and would like to think that my guesses are fairly educated.)

In many ways, to understand Espresso you first need to understand what it is not.

Espresso is not CSSEdit

Before you so much as think about downloading Espresso, you need to be clear on one thing: Espresso is not CSSEdit. Yes, you can edit CSS files with Espresso, but it does not offer visual CSS editing, and X-ray and the inspector are nowhere to be seen. You can override stylesheets, CSSEdit groups are supported in the code navigator, and the CSS text editing is very similar, but if you are expecting CSSEdit plus the ability to edit HTML you will be sorely disappointed.

I’m going to make a prediction here (and yes, it’s just a prediction; I have no insider knowledge): I think that Espresso will get X-Ray in a point release. I think it will probably get the inspector and the ability to jump straight from the Inspector to a style in the CSS. But I don’t think it will ever get CSSEdit’s visual editors. Why?

Because competing with yourself is stupid.

CSSEdit is the best way to edit CSS (right now, anyway). Espresso is shooting to be the best way to edit code, no matter what the language.

Perhaps someday MacRabbit might want to merge CSSEdit into Espresso and retire their original flagship product, but don’t hold your breath.

All that said, I’m as baffled as the next guy why you can’t right click a CSS file in Espresso and choose “Edit in CSSEdit”.

Espresso is not Coda

Particularly when MacRabbit announced Espresso and showed off screenshots of an integrated FTP editor I think a lot of people assumed that Espresso was setting out to be an all-in-one editor to challenge Coda (albeit much more slimmed-down). “Hooray!” cried the masses. “Perhaps at last we’ll have an all-in-one solution with a decent text editor at its core!”

The masses were a ways off the mark. Coda attempts to give you every tool you’re likely to need to edit code. Espresso tries to give you a fantastic environment for editing web pages with an extensible Sugar architecture to allow you to expand the editor to other languages. Notice how different those two sentences are.

If you love Coda because of the diverse tools that it gives you, you’ll probably be underwhelmed by Espresso. However, if the shortcomings of Coda’s text editor rub you the wrong way and you don’t very often find yourself using SVN, books, the terminal, etc., then Espresso might be a wonderful solution to your needs.

Espresso 1.0 is a foundation

In many ways, Espresso is building off the legacy of Textmate, if you can say that a piece of software that’s still nominally developed and actively used has a legacy. Text snippets with tab stops and mirrored segments directly mimic Textmate’s snippets and the Sugar syntax system is fairly Textmate-y, as well. Where Textmate provides extreme flexibility with a correspondingly steep learning curve, Espresso attempts to provide some of the core aspects of that flexibility but focus on providing users with a more polished, CSSEdit-ish application.

Espresso 1.0 is a foundation, a solid feature-set that shows the core capabilities of the program and through its scope and design may give you a good idea of what directions the application is likely to grow. When I first read MacRabbit’s descriptions of Espresso I immediately began imagining the possibilities, and every time I launch it I find myself imagining possibilities again. It has the potential to grow into an application almost as flexible as Textmate, but easier to extend and with a friendlier interface that also happens to offer the core features needed for web development.

Aside from its potential, Espresso 1.0 is a powerful text editor that’s overly focused on web design with a few rough edges tucked away beneath the overall gleam of its interface. It’s better than most of the web-centric offerings, but may not be quite good enough to lure you away from heavy hitters like Textmate, Coda, or the venerable BBEdit.

If you’re looking for a simple yet powerful web-oriented text editor with a lot of flexibility and promise for growth, I highly recommend giving Espresso a download. As long as you don’t go in expecting CSSEdit, Coda, or something that will turn into a magical unicorn and solve all your problems you should be pretty pleased with what you find, even if, like myself, you’re unlikely to be able to switch to using it full time for your day job until the application is a bit more mature.

That’s nice; what about TEA?

I haven’t been talking about TEA for Espresso much because although I’m ecstatic that it was one of the few Sugars chosen to be included in the application, it frankly wasn’t ready. I still consider it in beta even if Espresso is out, and because I didn’t know that it was going to be bundled in the application until the morning the app was released, some of its better features are broken. Once I’ve got it in a more mature place, I’ll definitely brag about it a bit more and offer some examples of how to use it; for now, please give me a shout in the Espresso forums if you have any feedback, requests, or bug reports.

We always think what we want is the end of the story. We wait anxiously for the next installment, biting our nails and plaguing storytellers to let us know what happens next.

Sometimes we are given the end of the story. Maybe the budget is cut. Maybe the storyteller recognizes the end and has the discipline to finish it. Perhaps the ending was planned from the start. Whatever the reason, we find ourselves sliding through the denouement and gently deposited at the final page, the last paragraph, the happily (or not so) ever after.

There is a satisfaction in knowing the end of the story. All the truly great stories end.

When it comes to those great stories, the ones that capture our imaginations and hearts, there are two types of storytellers: the artists, and the merely talented. Where you discover what type you are dealing with is at the story’s end.

The talented storyteller ends the story in a timely fashion, draws all the threads together, and knots them. We smile as we leave the theater or close the book; at last, the final battle has been fought, the lovers united, the epilogue complete.

The artist, however, cheats. We reach the final page and discover that although the storyteller is finished, the story has not ended. Instead it lives on in our imaginations. The world or the characters – often both – haunt us. We take the story and play out possible futures in our heads; we make our own stories.

This is the difference between good and great, talented and true artist. Whatever we think we want, it isn’t for the story to end. It is for the storyteller to finish telling their part of the story in a way that encourages us to take up the story for ourselves and make it a part of our lives.

Harry Potter was an excellent story. It captured the imaginations of millions of people and led them on a journey spanning books and years. Yet at the end of the seventh book, J.K. Rowling revealed that while she is extremely talented, she is not an artist. All the threads were tied up. We were given a world in which the relationships have played out as we expected them to, and the future (the children) is merely a repetition of the story we just completed. The epilogue shuts down our imagination, closes off the imaginative space that existed while the ending was still in doubt, and leaves us with a really good story that is, unfortunately, not our story. Perhaps with time J.K. Rowling will become an artist (I hope so; with her talent and reach she could be great in ways most storytellers can’t even fantasize about), but the ending of her first story revealed her as merely talented.

In contrast, The Graveyard Book by Neil Gaiman (available on Amazon or Kindle) is the work of an artist. Like Harry Potter, The Graveyard Book is about a special boy who lives in a fantasy world hidden within our own, but where Rowling’s ending revealed that she had not reached her potential, Gaiman’s shows the artistry of a practiced master. When I finished The Graveyard Book I was delighted to find that it hadn’t actually ended; Gaiman had instead passed the story on to me and for several minutes I savored the feeling of Nobody Owens’ tale continuing to unfold in my imagination.

I wish that more storytellers aspired to tell stories like The Graveyard Book, that fewer people gave in to the temptation to extend their story indefinitely or end them so finally that the reader’s imaginative space is locked away. In my perfect world, all storytellers would both understand that the true magic of a story occurs when they let it free for their audience to take up and consciously strive to achieve such that level of artistry.

We don’t live in a perfect world. But fortunately, we do have Neil Gaiman and The Graveyard Book.

I recently discovered that, utterly without fanfare, a new version of iShowU had been released: iShowU HD Pro (and iShowU HD, a less feature-rich version of the software). Looking at the screenshots it looked like it was a clone/competitor to ScreenFlow. However, aside from some obvious mimicry in the interface, iShowU HD Pro approaches screencasting from a completely different angle than ScreenFlow and will appeal to a different set of users.

ScreenFlow, for those who aren’t aware, is an all-in-one screencasting solution. The general idea is that ScreenFlow captures positively everything that happens on-screen (while simultaneously recording audio, of course) and after you’ve recorded everything you can go in and highlight certain mouse interactions, add iSight video clips, change what part of the screen has focus, etc. If you are using ScreenFlow, then you are almost certainly intending to do a fair amount of post-production work on your screencast from within ScreenFlow before you share it with the world.

iShowU HD Pro, on the other hand, has no post-production capabilities whatsoever but enables you to post a finished screencast in the shortest amount of time possible. Unlike ScreenFlow, once you finish capturing a screencast iShowU HD Pro compresses it down (very quickly, using your graphics card to accelerate the process), and then provides you one-click access to post the video on YouTube (presumably more upload options will be provided in the future). Depending on the length of your video and amount of compression you can have it online and shared with the world literally seconds after you finish recording.

Unlike the original iShowU, iShowU HD Pro also allows you to visually highlight mouse clicks and keyboard events, or record from your iSight simultaneously while recording your desktop. Aside from the iSight recording, however, these features are all or nothing. When you start the program (and before you start recording) you can toggle mouse and/or keyboard capture on or off, and then for the duration of your video you’ll either have highlighted mouse and keyboard events or you won’t. You can also position an image over some or all of your recording area if you want to, say, have your website address displayed along the bottom of the screen. Sadly, this too will last throughout the entire movie.

iShowU HD Pro and ScreenFlow are doing very similar things from a technological standpoint (allowing you to capture high definition video or your entire screen), but the programs are obviously catering to very different crowds. iShowU HD Pro will be perfect if you need to record screencasts as quickly and easily as possible. It is one of those wonderful programs where you can be completely comfortable with the program within three minutes of launching it just by playing with the interface. If you need to record screencasts to share with your friends, or are a software developer who just wants to show users how to use a small feature without spending hours producing a video, then iShowU HD Pro will be an excellent choice. (It’s worth noting that iShowU HD Pro also supports drag and drop export to Final Cut Pro, so it likely has an audience with those people who like ScreenFlow’s capture capabilities but who feel limited by its post-production features.)

ScreenFlow will be much more appealing to the crowd who want to disseminate their screencasts a bit more widely and don’t mind putting in the effort to first learn the program and then do post-production on their recordings.

I’m pretty surprised that iShowU HD Pro hasn’t made more of a splash on Mac news sites and so forth; the program has a few issues and feels very much like a 1.0 release, but is still obviously a good contender in the screencasting software arena. Sure, it isn’t as flexible as ScreenFlow, but for some people who just want to get a good-looking screencast up as fast as possible, iShowU HD Pro at its cheaper price point will likely be the perfect solution.

Ah, StuffIt. The most perplexing rip-off in the recent history of software. I predicted we’d see version 13.0 before 12.0.4. Turns out I was bit conservative; the last 12.0.x update was 12.0.2.

For those who missed my previous hating on StuffIt, I’ll recap: do not buy it, and you probably shouldn’t update if you already own it. It is redundant, outdated, buggy, and a sad excuse for professional software whose company makes money by bumping the version number for every minor update. Back in the day, StuffIt was a must-have tool. Now it is an example of why giving complete control over a product to a marketing team is a terrible idea.

If you need a file compression and archiving solution, do yourself a favor and try something like Springy or BetterZip instead.