In the meantime, update your address books:

Redub LLC
151 W.19th St, 5th Fl
New York, NY 10011
O: 212.255.6290
F: 888.531.8858


View Larger Map

Tweet This Post

Suggestions and ideas are welcome.

Tweet This Post

If you’re a web or Flash developer (or a concerned publisher), you’re probably wondering “Why is Apple shutting out Adobe? Why isn’t it allowing Flash on the iPad?” Some publishers have already gambled and hitched their horses to Adobe AIR in the hopes that it will allow them to transition to app-building without making a dramatic shift to hiring Objective C and Cocoa developers. With their recent release of the iPhone OS 4.0 SDK beta, in section 3.3.1 of the iPhone Developer Program License Agreement, they explicitly state “that applications must be written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine” (see @gruber’s excellent redux). This strikes directly at the heart of Adobe’s CS5 release which promised the ability to author in an environment many designer/developers were familiar and comfortable with (Flash/Flex) and export to iPhone or iPad applications, something many people (myself included) were very excited about.

What happened? Why did Apple shut this route to app-ification down?

My take on it is that now that Apple’s gotten deep into the mobile computing business, it’s started to care a lot more about how applications are written, because how they’re written seriously affects how well and efficiently they run. And mobile computing is all about ruthless efficiency, like engineering for space travel. If your application (and then your phone) grinds to a halt because of some unidentifiable memory leak (I’m using “memory leak” here as a euphemism for “poorly written code that makes a program run sub-optimally”), and you need to make an emergency phone call, you’re ditching your iPhone right then and there.

The same “memory leak” might be happening right now on an application you’re running on your desktop (either a Flash SWF in your browser or some other desktop application) but because of the huge RAM and memory sizes of most desktop computers, these leaks take a lot longer to become noticeable. (I’m talking out of my ass here but correct me if I’m wrong.)

Another way to look at it is that when you use a “meta-framework” to author in Flash/Flex and export to iPhone, you’re depending on Adobe to create the proper hooks to tie into Apple’s Touch APIs, and the assumption with these meta-frameworks is that you don’t really care what’s going on under the Apple hood; you just want to “drive the car” so to speak. What Apple is saying, to put it bluntly, is “You need to care about what’s going on under the hood if you want to make apps for the iPhone/iPad.”

As @gruber points out, “We’re still in the early days of the transition from the PC era to the mobile era,” and it looks like Apple is taking this opportunity to enforce standards and best practices on their mobile devices by a) making app developers use their tools and APIs and b) strict gatekeeping during the app submission process before releasing them to the App store. It’s tough love, and some people are going to get hurt. Some people will have their feelings hurt (Flash developers), and others are going to have their businesses hurt (MonoTouch, Adobe, and it’s also looking like Flurry/PinchMedia and other analytics companies are going to get shut out).

Big Questions: What about Google/Android? Will Apple’s benevolent dictatorship win out over a messy but open democracy?

For more reading on this subject, check these excellent articles:

• Apple’s prohibition of Flash-built apps in iPhone 4.0 related to multitasking from AppleInsider
• Daring Fireball on Why Apple changed Section 331
• Steven Johnson’s column on How Apple has rethought a gospel of the web

Tweet This Post

The demos are getting more and more realistic (first Mag+, now this). My initial reax:

1. It took a whole team from Adobe partnering with the staff of Wired Magazine to do this demo. The tools aren’t there yet, but publishers, your newsrooms and staff need to look and work like this. Right now, I don’t think they’re geared for this type of production. Yet.
2. The question is what hardware is it running on? Can it run on any old tablet that supports multi-touch (not an iPad)? Who makes such a device?
3. Does the video have to play full-screen or can it play inline?
4. Can you resize the text? I don’t think you can. To me, it looks like they’re taking the assets from the InDesign layout and converting to Flash/Flex/AIR.
5. HTML5 and CSS3+ Javascript can’t necessarily pull this off yet. Another big “YET”. jQTouch, I’m waiting…
6. I foresee an app per publication, not per issue, which means for books, you’ll buy the Penguin app, and the Knopf app, and pay a subscription fee to get particular chapters of books. In terms of magazines, you’ll buy the Wired app and the GOOD app, e.g., and pay a subscription fee to get particular issues. The question is sharing…

UPDATE: from Wired itself:

The content was created in Adobe InDesign, as is the case for the print magazine, with the same designers adding interactive elements, from photo galleries and video to animations, along with adapting the designs so it looks great in both portrait and landscape orientation. This is a departure from the usual web model, where a different team repurposes magazine content into HTML, unavoidably losing much of the visual context in the process. Wired.com is not a re-purposed version of the magazine, but rather an separately-produced news service.

Read More http://www.wired.com/epicenter/2010/02/the-wired-ipad-app-a-video-demonstration/#ixzz0fjhurJU8

(Putting nose back to grindstone…)

Tweet This Post

• It’s about the mobile, stupid! Try using Buzz on m.google.com/app/buzz and you’ll see exactly what I’m talking about. On the plus side, you’ll notice, because it has your location, it recommends places around you, shows them to you on the “Buzz map”, nibbling on Yelp and Foursquare’s lunches. On the minus side, it does the same thing with people, ie, it shows you “public” conversations of people right around the corner in your neighborhood. This is one of those times where engineering making interaction design decisions turns out not to be such a great idea.
  

  Engineer: Wouldn’t it be awesome to be able to see what “buzz” is being generated in your vicinity? We can do that since we know all the Gmail users in the area! Sweet! We are SO smart!!!

  Unfortunately, what this “buzz” amounts to is some seriously embarassing (and unwitting) privacy violation:

  

  I have no idea who Brent is, except now I gather he is somewhere in my zip code and I probably brush by him at the grocery store, and now I know he’s going to have a HOT date night with his friend, Kate, who will be wearing her black stilettos and swilling Hennessy! Gross.

• Asymmetrical following: yes this is Twitter’s lunch. The difference is it’s a less relevant given that a) the following isn’t voluntary per se since Google takes the liberty of adding people you supposedly send lots of Gmail to and then b) shows you the conversations they are having with other people (most of whom are perfect strangers). This is weird and creepy, far from the interestingness you get from Twitter’s opt-in asymmetrical following model. (I’ve seen some inane, offensive, childish, and incomprehensible bickering that I really didn’t need to see.)

They know where you live, they know where you are right now, they know what you’re talking about, they know what you’re thinking, they know your all dirty little secrets. And if you’re not careful, you’re publishing everything for the world to see, all in the name of “sharing”! Happy Buzzing!

Tweet This Post