PragProg’s take on the iPad…

An article in the latest magazine from the Pragmatic Bookshelf says pretty much everything I want to say about the iPad and what it is about to unleash.

I find the most compelling point about this to be the “bling arms race”. Looking good is the critical element in an app, the only important feature. (Notable exceptions such as Doodle Jump ? acknowledged, but go with it for now…)? Maybe that’s not so bad in some cases, especially on an iPhone where I expect to use most of the apps a few times and be done with them.

The use case on the iPad is going to be far different though. Fart apps aren’t going to cut it. I don’t buy apps for my computer without a demo to try first, and I don’t see myself doing anything different for a device like the iPad. Sadly the only pre-purchase info you’ll get for you apps are the usual review (highly suspect and probably fake) and screenshots. This is a high quality device, and we’re going to want high-quality apps to run on it. The apps store ecosystem isn’t set up for this. It’ll be interesting to see what happens.

The parable of the boat builder…

Once upon a time there was a man who loved to build boats. Building boats takes a lot of space, and his apartment just wasn’t big enough. He went to a local warehouse and asked if he could rent some space to build a boat. They worked out an agreement. He would build boats and sell them to the burgeoning local sailing industry, and in exchange for 30% of the profit from the sales the warehouse would let him use the space for free during construction.

“One small caveat” said the warehouse owner, “we have final say on the distribution of your boats. We may suggest certain changes we think will help their marketability.”

The man agreed. Surely allowing some oversight would be no problem whatsover. He knew the local market, and he knew his boats would sell! He began drawing the designs that very day.

The man worked 12 hours a day for two weeks! Over 150 hours of work later he had the plans for the first boat. He went to the warehouse and began to lay the forms for the keel. As he was laying the forms one of the warehouse managers came by and looked at his plans.

“Looks great!” said the manager, “However I thought we were getting a sailboat, and this appears to be a small yacht! Our company has recently decided that we want to be ecologically sound, so we can’t really support powered boats. Redesign it as a sailboat and then you can start building it.”

The boat builder agreed, but he began to think that perhaps this oversight agreement may not be as simple as he thought. Throwing away his last two weeks of effort he began again, this time designing an eco-friendly sailboat.

Two weeks later, plans for the sailboat in hand, the boat builder once again began construction. He worked uninterrupted for 2 months, day in and day out, until after over 700 hours of hard labor he finally had his boat completed. It was a beautiful solid wood boat in natural hardwood color, with natural white cloth sails. After admiring his handiwork he went to tell the warehouse managers to have them begin looking for a buyer.

The warehouse managers looked at his boat and seemed suitably impressed. After a few moments though one of them spoke up. “It’s quite a beautiful boat, no doubt about it. In the last month however, we’ve decided to try to sell carbon-fiber racing boats, and we want people to think of these boats when they think of sailing! So before we try selling this boat you need to paint it bright red and change the sail for blue nylon. That should make it acceptable to the current market!”

The boat builder was astounded! A classic wooden boat with natural cloth sails and they wanted to make it look like plastic! He would have none of it, and he told this to the owners in no uncertain terms! The warehouse owners were firm though. Carbon-fiber racing boats were what people should be using, they said, and if he didn’t comply then they were not going to be able to sell his boat. The boat builder said that he was fine with that, and he would just take his boat and leave.

“Not so fast”, one of the owners responded, “you’ve been using our space without paying rent, and we’re due a portion of the value with the boat. If you don’t change it the way we want and sell it, then you can’t take it anywhere. There is no third option, this is our warehouse, and partly our boat.”

The boat builder agreed, there was nothing he could do. The owners went away and the boat builder sat and looked at his boat for a time. Then he went to his boat, puled out his lighter, lit the corner of sail, and walked from the building and never returned.

Where do you draw the line? ? Where should you? And what about the boating consumers and their ability to choose when the market is this controlled?

If you haven’t guessed, I’m not really for walled gardens, no matter how well decorated they are.

On data ownership…

Something I’ve been working on in my programming projects recently is ways to allow users to use their data from outside my service, and to take the data they have in services I create elsewhere.
In the new era portability is king. If you don’t allow users to use their data how they want, your service is utterly useless and doomed to failure.

Whoa there, you say, them’s some big bold words! If it sounds like I’m including the large portion of current generation products people are familiar with as the target of my wrath, you’re right on the money. Let’s take a look at a recent real life example, MobileMe.

MobileMe offers some excellent syncing tools for those of us with Macs and iPhones. Over-the-air (push!) syncing of contacts and calendars is a great tool, especially for those of us with a desktop, a laptop, an iPhone, and an iPod Touch all trying to stay perfectly in sync. However that’s exactly where the scope of the tool ends. Want to share contacts/calendars with someone else as “joint ownership”? Screwed! Can’t do it. So MobileMe loses one user/evangelist to Google, where I can choose to allow another user to collaboratively edit my calendar. MobileMe ends up in the trash heap because the data I give it can only be used in the ways that MobileMe wants me to use it, and I have different ideas.
Google also frustrates me though because I would very much like to set up a group of shared contacts between Bev and my accounts so we could maintain contact synchronization, but that’s not supported through them either. I have a huge store of data, and I can’t even grant another user ACCESS to it. This is full of fail.

Obviously one of the core problem with this is common language. There has to be a standard protocol that is used for each type of data in order for sharing to really work. For inter-service data (like sharing contacts with another user of the same system) there really is no excuse however.

There is another form of data usage to consider beyond just sharing. A good example of the type of thing I’m thinking of is WebHooks, but I’m not completely convinced on their implementation.
A current example of the concept would be posting? to an online forum that lets you “follow” the thread. When you post you can check the box for “email me when someone replies”. Now whenever someone posts something you get a notification. WebHooks is like that, except instead of providing a simple email notification it allows you to provide a URL and a notification is posted to that URL. The notification contains whetever data the application designer wants it to. This may seem like a power-user feature, but once the concept is widely accepted it allows you to let websites (and the datasets they contain) to interact with each other in fabulous new ways.

This starts with us, the application designers. And this is why I’m so hot and bothered about the idea. If I don’t design my own applications to allow the sort of data interactions that I want from other websites I use. Once again though, the problem is standards. How do you output the data? Do you create your own refspec for the specific website/application? Where do you draw the lines?

Once again, the problem is standards. There’s no reason why any user should have both MobileMe contacts and google contacts. Ideally either service should allow the user to use, not just “import”, contacts from the other.

We’re not there yet, and I understand how people scoff at this idea, but I’ll say it again. Data portability and access is king. If you don’t let your users get to the data they’ve entrusted to you and use it in the ways that they want to use it, they’re going to abandon you.

Delicious? How about “somewhat tasty”?

Delicious Library (Hah, you thought this was about food!) is a cool app. It’s pretty much the only game in town, and has also long been considered one of the premier mac apps in terms of visual style and workflow.

Where are the basic features though? Like secondary sorting characteristics? I really want to go through all my books and tag the “series” they belong to, but as delicious doesn’t sort “Series within author”, it’s kind of useless. This is especially annoying because the way core-data predicate searching works should make this decently easy to accomplish. iTunes has it (Album by Artist), and it’s really kind of an intuitive thing now that people are going to expect. (I’m actually really annoyed at Delicious Library right now, just because of this sorting issue!)

Here’s one of the downsides in working on cutting-edge platforms like Mac OS-X, iPhone App-Store, or the edge of webapp development. It’s a reaaaaally fast moving target. A feature that even a year ago would have been amazing, is now a major defect in your software if you don’t have it. You’re going to have to spend a lot of time chasing the target, and using whatever is left of your day to get ahead and innovate on your own.

This makes me wonder about doing development on any of these cutting-edge areas. I don’t know if I have that much time!

Why no observer patterns? (Pt. 2)

Immediately after posting the last article I started thinking about how this could work. Let’s assume a RESTful Rails based project.

Things we want to observe: Resources.
Done! That was easy!

So: would show you a list of things you could “subscribe” to, and indicate which of them you were already subscribed to. This would require you to be logged-in (openID) and have your own site’s URL tied to your login. (Thought: OpenID metadata?) Then you could simply say “I am interested in blogposts, microblog posts, and any new images you post.”

Then I, as, would have an option when I went to submit a blogpost: “Notify Observers?”. (Maybe it would only appear if this resource had people actually observing it?)

I should speak briefly on the core principle of this system and the reason I started thinking about it. People often think I am against “social networking”. In reality, what I am really against is personality fragmentation. I refuse to have a twitter AND a myspace AND a facebook AND a linkedin AND a flickr AND a AND twitpic AND youtube AND…. I AM, and everything about me should be in this single place. (Subject to needing additional hosting/bandwidth, but that can still all be linked to and found here.)

I’ve just discovered something called WebHooks.? I think I’ll go read about that for a while. Looks interesting.

Why no observer patterns?

The observer pattern is really quite handy:
“Hey, you, the dude responsible for managing Josh’s twitter posts! Let me know when he posts something new! My address is…”

That’s basically it. It works in Cocoa, it works in SproutCore (Javascript), it works in Rails.. Why has it never been taken to a wider scale?? I understand that pushing to users is difficult due to the “statelessness” of HTTP, but “push”ing between servers with static IP/Hostnames should be decently trivial.

REST, JSON, SSL, toss out any number of acronyms you want. It’s doable in a number of different ways. So why isn’t it common? Why can’t I subscribe to your blog and have it notify me when you make a new post? Forcing me to poll your RSS feed periodically to see if you’ve made a new post is, shall we say, fucking backwards and wrong!!

So what are the real challenges here?

  1. Callback address. What if a registered observer changes their callback URL? How do we address them?
  2. How do we authorize changes? Must research OpenID/OAuth and see if there are systems that might work for this.
  3. Sufficiently extensible and user-definable. No locking the user profile into ONLY having fields like “favorite pet” and “smoker y/n”. No limiting the language used.

What might this look like?? If I ( want to obsevre events at I could send this:

And then when makes a change to the blogposts it would know to send this:

I’m having trouble visualizing both exactly how this would work, and why it might not. I think it may be time to start diagramming some things out.

Continue reading in Part 2