My Dream App

Time for some Atmosphere love!

Here is a description of Atmosphere’s drawing stack. And here is a description of what can go into an Atmosphere theme.

This is some seriously dry reading, as these are development specifications, not marketing materials. So unless you’re really interested in minutia, skip ‘em and just read the rest of this post instead.

Design Goals

There are a couple of design goals that dictated both of these documents:
- It should be very, very easy to create an Atmosphere theme that accomplishes the basics.
- The theme designer should be able to customize things very very deeply if desired.
- The Atmosphere desktop should be variable enough that the user will never be positive if she has seen everything that there is to see.

The first goal is easy - you can create a basic Atmosphere theme by just taking an image and masking things in Photoshop. Reasonable defaults will do the rest of the magic.

The second goal is met by the design docs - an Atmosphere theme is crazily customizable if the theme designer feels like going beyond the basics. And I do mean crazily customizable.

The last goal follows from the second goal - the more interesting possibilities the theme designer puts in the theme, the more there will be to discover. But even with a basic Atmosphere theme, the combination of reasonable defaults, season, time of day, and weather makes for a lot of variability in what the user will see on her desktop.

Animal Crossing

My wife and ex-girlfriend are both heavily addicted to the game Animal Crossing, which means I’ve spent countless hours watching them slap-fight over who gets to play. And as a result of me being forced to watch that boring game, Atmosphere has already been heavily influenced by the idea of the changing environment in Animal Crossing. I especially like the idea of special events, so the above specification includes the possibility for stuff like Santa flying across the screen on Christmas Eve, or pumpkins appearing around Halloween. It’s all up to the theme designer - I made it very easy to add stuff like that.

Anyway, as I said, these are initial specifications, and it’s quite possible that I screwed something up, missed something important, did something inconsistent, or just generally did something dumb. If you catch something like this, please post here and let me know!

And finally, these specs are most definitely subject to change once I’m actually in the code. I still don’t know whether the animation stuff can be implemented with a low enough resource hit to remain feasible, so those are first on the chopping block. Everything else is pretty straight-forward, but time pressures might cause things to get cut.

Enjoy, and please leave feedback!

I wanted to drop in with a better-late-than-never congratulations to our MDA winners Farzad, Michael, and Cameron! Great job, gents! Hopefully, you guys have stopped with the cardiovasculatory arrhythmia and your stress hernias have subsided by now… That was an intense competition and you guys braved your way from start to finish. Congratulations is not a strong enough word for you.

Our finalists also deserve gigantic congrats - they put in a hell of an effort, and I hope to see their ideas get picked up by someone else. They’re too compelling (and monetary!!!) not to be.

Which brings me to my point: Suggestions and publicity for the finalists!

Richard, Whistler desperately needs to be made. The guys who made Tangerine seem like an obvious bet, as does Rogue Amoeba. I think even Ambrosia does some audio stuff. I’d love to see you pitch Whistler to these guys. And if not, there’s been some pretty cool action in the forums from Dennis Cox.

Hijack looks like it’s a go no matter what. A lot of interest sprung up around it, both open and closed source. There’s enough interest there that I’m not too worried about this one.

Dan has been making noises as though there’s interest in Blossom, but I don’t know what’s happening behind the scenes. I can’t think of a company offhand that fits Blossom perfectly, so I’m afraid I don’t have any suggestions here. I should mention, though, that a version 1.0 of Blossom isn’t too tough to achieve: Take one part Accessibility API, one part Launch Services, and one part published plant growth algorithms and shake vigorously with MiracleGro^™ until sprouts form.

Ground Control looks like it may be sorted, with the inimitable and perennially non-PC Steve Streza pretending to develop once he’s gotten Spewbular sorted out. :)

Finally, it looks as though Bubble Fish might see the light of day. Which would be very cool!

Maybe you’ve heard of that Atmosphere program, too? Expect to see lots more about in in the next few days as I’ll be soliciting feedback from you guys a lot. There’s also a bit of upcoming press regarding it, check out Switzerland National Public Radio next Saturday 11/11/06. Be sure that you can parlur frann-kaise if you tune in! I’m told that Cameron, Phill, John, and I will also be showing up in next month’s MacWorld.

So stay tuned!

So you may recall My Dream Slapper from the heady days of yore, 5000 years ago, before My Dream App voting had begun.

And you also may recall me mentioning that I might open-source it when we were finished with it.

Well, guess what? We’re finished with it (have been for two months, actually, but I forgot about it). And I’m pleased to announce that My Dream Slapper is now open source!

I don’t know how useful it will be to people since I created it for a very specific purpose, but if nothing else, it might serve as a good example of a real-world, MySQL-eating, Core Data-using bit of Cocoa quick’n'dirty code. People must be getting the impression that I don’t write any other kind…

Oh, and it’s also released under the BSD license, so you can pretty much go hog-wild with it.

Enjoy Your Slapper!

Okay, as promised, here’s my quick’n'dirty Hijack Proof of Concept.

You almost certainly want to download the app to find out how it doesn’t really work well and then complain to me about it. Well, click that link. I’ve tested it on this site, forums.macnn.com, and the forums on the phpBB homepage. It only works on pages of posts, not listings of threads. There’s no way to post. If the site admin even considers changing the HTML, if they even think about it, this build will break.

In other words, it’s not in any way, shape, or form “useful”. You don’t really want to download it is what I’m saying. I know you will anyway.

You can add support for other sites by playing around in the Windows menu if you can understand my incredibly arcane string crap I elaborate on below.

—-

Codegeeks: Here’s what you want.

Basically, it loads your request into a hidden WebView so that it can get WebKit to generate a DOM for us. It hands that DOM off to something that creates a “tagSoup” our of it. Tag Soup is sort of like a giant Xpath of the entire document, but it shows sibling and parent relationships. The idea behind tagSoup was to give a really quick way of finding matches for a page that Hijack has never seen before, to identify what scraping scheme to use. More on tagSoup in a bit (hint, tagSoup sux).

Along the way, it looks to see if it can figure out through keywords what forum package the page belongs to. If it can, it’ll try to use those to figure out how to do the scraping.

Then, it tries to match a ScrapeScheme to the DOM that got loaded. ScrapeSchemes are stored in a CoreData database (binary format because the SQLLite ones don’t support beginsWith, which I needed for some reason I have forgotten). This happens inside of ScrapeSchemeManager. It tries to do this as lazily as it can, but if lazy doesn’t work, it comes down to doing string matching against the tagSoup. More on tagSoup in a bit (hint, tagSoup sux).

If it can find a match, it sucks the data out of the DOM and builds a new generic html/css page out of it in DOMRenderer. This is then rendered in a visible webview by way of what appears to be a generic NSEnumerator but is actually 85000 lines of code pain, making you say “ooh” and “ahh” and “wow, this program totally fucking blows goats.”

A scrape consists of an (optional) prefix, an identifier or regular expression, and an (optional) suffix. The scrape is used to find something in the DOM that matches the scrape. The found item is then matched to a “significance”, which indicates what the matched thing actually is. Your avatar, for example.

The syntax, as I said, is similar to Xpath, but not the same, as it’s a bit more fuzzy. A child is denoted by “{”, a sibling is denoted by “-”, and a parent is denoted by “}”. So, if you want to find the second “tr” of a table with 2 data cells (and no tags inside the data cells), you would use “table{tbody{tr{td-td}tr}}”.

ClassNames are prefixed with “$” (I’d love to have used a period, but it’s a legal part of a className according to the XML spec, which I find baffling). idNames are prefixed with “#”. So, if that second “tr” was actually <tr id=”uniqueRow” class=”firstClass secondClass”>, the match string would be “table{tbody{tr{td-td}tr$firstClass secondClass#uniqueRow}}”.

If the match portion has an innerHTML, it is what is scraped, otherwise, the outerHTML gets scraped. Unless, of course, you specified a regex, in which case the match is scraped, unless the regex has at least one parenthesized portion, in which case the first parenthesized match is scraped.

Fun, huh? :)

—-

But you can pretty much ignore everything I just said because it’s all waaaay too brittle to be useful.

The tagSoup was a nice first attempt, but it’s no good for actual matching, as I discovered when adding this forum to the mix. This forum uses multiple class tags for a given tagName, which might be in any arbitrary order, so naive string matching is useless. tagSoup needs to go away.

Here is a Core Data schema that makes more sense. I began implementing this and got bogged down in writing an editor for it. I’ve since discovered XQuery, which supports regular expressions, which are completely vital (you’ll know why when you look at nassssty phpBB). That’s probably a better route to take.

Reskinning this is easy, just change the html/css in the “HTML” folder.

Finally, this code is the result of under 20 hours of work, done in a rush because I was annoyed at people telling me Hijack wasn’t feasible. So the code is pretty gross. Apologies for that, c’est la vie, yo!

And enjoy!

Okay, so now that we’re into the Finals, it’s time for me to come out and say which contestants I want to win! I really dig all of them, so this is a toughie to do.

First, a note: This is completely subjective, and it’s my opinion, not the opinion of the My Dream App Team in general. My opinion is based on two factors - selfishness and altruisism, with selfishness strongly in the lead! I’m picking the apps that I think will make me the most amount of scratch with the least amount of work, and if they change the world in the process, that’s a great bonus.

For the mathematically inclined, you can think about it like this:

appeal = w1 * easeOfProgramming + w2 * potentialEarnings + w3 * socialGood


where the w’s are weighting factors. w1 and w2 are pretty much equal, and greater than w3.

As Colbert says, moooving on:

Hijack

It’s probably no surprise that I want this one to get made, since I’ve been pimping it for the whole competition. One more time, all together now: “IT IS FEASIBLE!!!”

Hijack was impossible five years ago, but two things have made it possible today: the rise of semantic web programming (read, CSS) and WebKit, which can do the heavy lifting for us. Put ‘em together and DOM scraping becomes eminently feasible. Identification is the tough part, but it’s not insurmountable.

Hijack’s hard to code, granted. But its potential earnings are huge. Seriously, take a look at this Internet of ours. Every big site has a forum. Why? People use ‘em, people like ‘em. The number of Mac users on the Internet is but a fraction, and the number of Mac users who use forums is but a fraction, and the number of Mac forum users who’d buy Hijack is but a fraction. But the initial pool of people is so huge that even a fraction works out to a huge potential audience. And the idea is compelling enough to change the industry and raise all of those percentages.

Finally, Kevin looks like he’ll be absolutely stellar to work with during development! His design skills are amazing, and he’s been receptive, friendly and funny. A++, would vote again.

Ease Of Programming: low
Potential Earnings: huge
Social Good: high

It’s the creation of a new genre. Vote for Hijack!

Cookbook

This one is an easy winner. The potential market is large, and if executed well (functional, beautiful and EASY), Cookbook should enjoy good, steady sales. It’s not going to be gigantic, but it’ll sell well unless we really screw things up. And if we can create a community around RecipeCasting or RecipeSS, it’ll grow, and grow well. And it’ll make people happy along the way.

More importantly, there are no large technical challenges to writing it. There’s a lot of work there, certainly - it’s a large program. But it’s all completely conventional code and techniques. Lots of the development time can, and should, be spent on design and workflow analysis.

Ease Of Programming: high
Potential Earnings: high
Social Good: moderate

Finally, Michael looks like he’ll be absolutely stellar to work with during development! His ability to simplify a complex idea into a UI that seems simple yet is still powerful is absolutely first rate, and he’s been completely receptive and friendly all the way through.

Easy to code, easy to sell. Vote for Cookbook!

Atmosphere

The third choice was a toughie. It was Atmosphere, Whistler or Portal - I’ve been oscillating between all three for weeks. Basically, my formula saved me - Atmosphere is fairly simple to code and it will sell fairly well. But it ain’t gonna change the world… If the wind had blown slighly harder over New Zealand yesterday, Whistler would be in this spot.

That said, Atmosphere’s a pretty cool idea. And some of the algorithmic stuff would be pretty fun to code - fractal clouds, algorithmic snowflakes, sporadic OpenGL leaf surfaces randomly shifted and overlayed to build up fallen leaves.

And, I foresee a ton of creativity coming from graphics designers creating new desktop packages - we’ll have to make sure that we make the system really open and really easy to use, while remaining powerful. Unfortunately, Atmosphere won’t foster any creativity from users - it’s a passive experience for them.

Ease Of Programming: moderate
Potential Earnings: moderate
Social Good: low

Finally, Cameron seems only fairly good to work with. He’s enthusiastic, which is good, but he seems a bit less engaged than some of the other contestants. I get the impression he’s more interested in the cash than in making a great app.

Vote for Atmosphere!

Whistler

Damn it, I really wanted to put this in my list of “vote fors”. I would absolutely love to code this. At the same time, I’m completely terrified of coding this. It’s hard, and it’s right at the edge of my abilities. It would really be work. At the same time, I’m completely confident that I could pull it off, and the result would be amazing.

The reason this one stayed out of my list of winners is the potential market - I just don’t think it’s big enough. MDA is all about creating consumer-level apps, so we’d be priced fairly low, which helps a bit to broaden the market, but not that much. I just can’t see Whistler having amazing sales, and the sales would need to be amazing to offset the amount of work necessary to create it.

Which sucks, because the amount of social good that could come from Whistler is gigantic. Huge. Whistler could change people’s lives, for the better, launch new careers, bring happiness to people. Damn it.

Ease Of Programming: miniscule
Potential Earnings: moderate
Social Good: huge

Finally, Richard seems like he’d be very good to work with. His design skills are phenomenal. My only complaint is that he still seems somewhat nebulous on Whistler’s feature list, but I suspect he’s done that on purpose and that once it came time to begin development, it would sort itself out.

Don’t vote for Whistler. But I secretly hope that you do anyway. I want it, and I want to code it.

Portal

I also had a really hard time not putting this one into my list of “vote fors”. At the beginning of the competition, I was completely unenthusiastic about it. But since then, Farzad has put a ton of effort into it and has been amazingly polite, enthusiastic, and receptive along the way, and I’ve really warmed up to it as a result.

Is Portal needed? Absolutely! Do I want to write it? Nope. The concept just doesn’t excite me. Moving files back and forth ain’t sexy. The UI has promise, lots of it, but it ain’t there yet and the enthusiasm I have is mainly of the “could be” variety. The syncing animations (the wormholes) have never appealed to me, and I’m someone who likes gratuitous eye candy!

Coding Portal is moderately complicated as it involves lots of low-level file system notification stuff and lots of high level networking stuff. I think Portal would sell fairly well, but not hugely. And, unfortunately, nobody is going to wet their pants over how Portal has changed their lives.

I’d hit it, but I don’t have a crush on it.

Ease Of Programming: low
Potential Earnings: moderate
Social Good: low

Finally, Farzad seems like he’d be phenomenal to work with! As I said, his enthusiasm, receptiveness and amenability have all been first rate.

Don’t vote for Portal…

Blossom

I’m kind of sad about Blossom, as I’m the one who pushed for it to become a finalist. I still love the idea - using positive feedback to increase productivity by way of an emotional attachment. Psychologically, it’s brilliant, and looking at historically similar ideas, I think it would sell like a mofo.

That said, it’s really hard to code and it’s got to be just right or it won’t sell at all. The plant algorithms are hard, obviously. They’ve got to be compelling and interesting, and continually so. Getting it right would take a lot of work.

Collecting the performance metrics (is an app/window good or bad) is hard too, as it involves lots of weirdness with the Accessibility APIs and lots of special case code. More hard coding.

Moreover, Blossom would need a gadjillion special case things to keep the user interested. Cutesy things like a bee occasionally coming to investigate a flower, or a snail slowly making its way up the tree, stuff like that. Each of those is coding time, and it would need a ton of surprises like that to keep the user engaged over a long time span.

But my big problem with Blossom is that I just don’t like how it’s been fleshed out over the course of this contest. It’s become less compelling to me than it was at the beginning. I’m just not enthusiastic about it anymore.

Ease Of Programming: low
Potential Earnings: high
Social Good: high

Finally, I didn’t really ever get a sense of how Dan would be to work with. I’m not sure why - he’s been active during the course of the contest. Maybe it’s because I don’t feel as though I have personally interacted with him much.

Don’t vote for Blossom…