I watched the tutorials on the site, and it appears to have a well thought out interface. If you’ve used timeline-based animations in Flash, this won’t look like it’s from another planet. Beyond that, since I haven’t actually used the software, it’s hard to say, but my first impression on that front is positive.

Leaving aside the question of whether a plague of gratiuitous CSS animation is really an improvement on the long-standing plague of gratuitous Flash animations, how does the code the tool generates stand up?

Not well.

Looking at the examples on the product’s web site, we find that the typical source code of a Hype-generated site looks something like this:

There is almost no HTML5 in your HTML5 document. All of the content you’ve so laboriously animated? That lives in a Javascript created by the tool. When Teh Googlebot comes to visit, it will see the following on a Hype-generated web site:

In other words, you won’t show up in Google at all. Further, if you need to update your site and you’re not near the computer where you created your Hype site, you’re not going to be able to edit the code by hand to fix that glaring typo that one of your customers called out to you on the trade show floor. Not that you would want to; the HTML that they’re generating inside that Javascript is a mess, a mix of divs, spans, and (OMG!) font tags, with nary a header tag in sight. So even if they were generating actual HTML, you probably wouldn’t want to use it, because Google would still find it a mess to parse. Years of research into search engine optimization are completely ignored here.

All that CSS that’s making it easier to update your site comprehensively? It’s all inline, totally defeating the purpose of CSS. If you want to incorporate some of the effects generated by Hype into your existing site, good luck. Hype appears to want to own your whole site.

But hey, you’ll get some whizzy effects, particularly in modern browsers.

I’m not averse to whizzy effects. And I figure any technological advance like this is going to be abused initially, just as early desktop publishers used way too many fonts at first, and as Flash developers made long, large, pointless splash screen animations and then tried to put a band-aid on their creations with the addition of the Skip Intro link. It’s part of figuring out what works, and that’s fine. Go wild. Make art. But not with Hype. Not if you’re trying to actually accomplish something with your web site.

Color me unimpressed.

Tags: hype

No comments (yet)

The biggest problem is that the HTML/CSS/JavaScript technology stack on these devices is slower than natively-executed code. It’s a lot slower. This is the case whether you’re targeting Mobile Safari or using an app shell like PhoneGap, which Faruk mentions but says he hasn’t had a chance to play with yet. I have played with it for personal projects. The app I worked on at work was a custom hybrid app, with a crunchy Objective-C based shell surrounding chewy HTML, CSS and JavaScript. The idea was to have the shell simply provide a UIWebView window, and all the interaction would be performed within that by the JavaScript. It was incredibly difficult to get those interactions to act the way they would if they were executed by natively compiled code. There are a number of tricks you can use, taking advantage of the fact that 3D CSS transforms and opacity are hardware accelerated, but that introduced other complications, particularly around the limited memory available on the first generation iPad.

The tools available to debug your JavaScript are primitive at best. In Mobile Safari, there’s the debug console, but you can’t set breakpoints and step through the code and examine the variables to determine why things are breaking. In a hybrid app using UIWebView, you don’t even have that. We wound up hacking something together where a JavaScript library would URL encode anything you wanted to log, then use it to create and call a URL with a custom URI scheme, which the app shell would then interpret, understand that it was a log message, and output it into the XCode debugging window. My partner on the project, who wrote the Objective-C shell, had difficulty with the memory barriers we kept running into, as XCode doesn’t provide much information about what’s happening inside the UIWebView.

Another problem we ran into is that UIWebView didn’t provide support for accessing orientation in JavaScript. The window.orientation object existed, but wasn’t updated when the screen changed; it always reported that the screen was at 0 degrees, if I recall correctly. My colleague had to provide a way for us to access that information as part of the Objective-C shell that he wrote. I found that a really puzzling omission on Apple’s part. Note that Mobile Safari does update window.orientation properly. I think PhoneGap might also have implemented support for this to make up for Apple’s omission.

The worst thing was that implementing the entire interface in HTML/CSS/Javascript wound up creating an experience where items flickered when you moved them. Drop shadows and backgrounds proved particularly problematic. Matteo Spinelli, the author of the incredibly useful but sometimes flaky iScroll, has a post about how to avoid flickering by applying hardware accelerated transforms to items that flicker, but we found that then you exacerbate the memory limitations of UIWebView.

My colleague and I discussed this extensively. I’ve come to believe that there’s a place for UIWebView in App Store apps like this, but that implementing the entire interface within one is a bad idea. The user experience just isn’t up to the standard of a native app. And if you’re distributing your app through the App Store, then the expectation is that your app will behave just like a native app. The user doesn’t know how you implemented the app they just downloaded. They just expect it to work like every other app they’ve downloaded. Unless you have a barebones interface, your hybrid app is unlikely to provide that experience.

I’ve looked at a lot of apps on the iPad that distribute periodic content (like magazines and other news organizations) where the ability to use the HTML/CSS/JavaScript tech stack for periodic production tasks is a huge benefit. Very few of them seem to be implementing the entire interface with UIWebViews. The BBC News iPad app looks likely to be implementing some part of the app with UIWebView, specifically the display of articles. My colleague and I discussed how it’s much easier to display content on the screen using a UIWebView rather than from native code. But I don’t think the entire interface is done that way, or specifically, not all at once. It may be true that everything on the screen is drawn by a UIWebView, but it looks to me like the screen is carved up into several of them. I think the same could be said about the NPR News iPad app. Other apps seem to get around problems with rendering pages by prerendering them, which is to say, they’re showing you pictures of words. Any app that’s built around the Adobe Digital Publishing Platform is using this approach (I’m not sure if they're using UIWebView or native calls to display the graphics, though). This bloats file sizes hugely, as can be seen by downloading an issue of Wired magazine from the App Store. And I think it’s probably inaccessible; VoiceOver doesn’t do text recognition in pictures.

There’s definitely a place for the hybrid workflow, but you’re not going to be able to create an identical experience with web technologies that you can with native code. Integrating a web technology-based workflow into an app requires a lot of thought, and particularly careful design that takes the limitations of the targeted device(s) into account. Throughout the development process, I kept noting that the iPad was definitely a 1.0 device, despite its iOS 3.2 pedigree.

User expectations are different for a web-based app. The experience of using a browser is one where network latency is common and users are not surprised to find that pages take a while to fully compose themselves on the screen. This is even more the case when you’re using an iPad over a 3G connection, combining the relatively slow processor with the relatively slow network connection. So the kind of interface anomalies you might see because of the relative slowness of UIWebView (as opposed to native apps) are more acceptable. You can, and should, make sure you optimize the experience by taking advantage of hardware acceleration where you can, but if things take a half second to redraw, users are more likely to find that acceptable in the context of using a mobile browser. They see that all the time. There are apps where that kind of interaction is acceptable, and that would be a good case for creating a mobile-enhanced web site/app rather than a native app. But that kind of app is terribly limited.

Apple initially tried to tell developers that this would be the way that all “apps” for the iPhone would be created. Very little happened; some people tried to follow Apple’s direction, others went down the jailbreaking path. Neither resulted in a flood of applications. Once Apple delivered an SDK that enabled developers to take full advantage of the power of the device, we saw an explosion of apps that changed the way people use their phones.

One of the things that interested me most about the recent iPad 2/iOS 4.3 announcements was that Apple had ported its new-generation Nitro JavaScript engine to Mobile Safari (and presumably to UIWebView). Honestly, I was surprised that it hadn’t been there from the start, although its absence explains a lot of what I saw. It’s possible that these limitations will disappear as the hardware gets more powerful. But it’s also possible that as the hardware gets more powerful, native apps will blaze the trail due to their inherent relative speed when it comes to creating new and amazing apps that just wouldn’t be possible with the HTML/CSS/JS tech stack until a couple more hardware and/or software revisions down the road.

So by all means, if you have an idea that would make a good app and you think it could be implemented either as a web application or as a hybrid application, jump right in, but make sure you’re aware of the limitations of the approach. You’re very unlikely to replicate the native app experience from a web application, and in the hybrid approach, it’s going to be a lot harder than you thought.

Tags: faruk ateş iPad mobile safari UIWebView

No comments (yet)

Sadly, that led us to this video by the Jacob Sisters:

Truly irritaining. And number 1 in Canada!

Tags: jacob sisters

1 comment

The Clean seemed a little off last night. I've seen them probably four times over the years, and this was easily the worst. That said, much like sex, bad Clean is better than good anything else. I don't know what the problem was. It might have been a bad mix; The Clean is a sturdy platform put up by Robert Scott (bass) and Hamish Kilgour (drums) for David Kilgour (guitars and organ) to build mountains of sound on. But there were a lot of points at which you could hardly hear David's guitar, at least where I was standing. Even when you could, it often lacked the bite of Kilgour's best guitar work. Borrowed guitar and amp, maybe? Or maybe the band's just Getting Older. I never expect them to be tight; the ramshackle nature of their performances is expected given that one member lives in New York and the other two in New Zealand, and usually it's charming. It didn't bother me that songs kind of fell apart at the end rather than coming to a full stop all at once. But something was just off last night. Even the encore closer, "Point That Thing Somewhere Else", wasn't the usual rouser that it is. I know the band likes to mess with their songs; I even have a copy of "Point That Thing" where the main melody is done on piano, and the bite of the song survives that. Even with all that, it was a solid B perfomance.

Vermillion Sands, who opened, were a band I'd never heard of. I thought they did a good job winning over the crowd with their catchy songs. I bought their CD from their singer after the show, so I must have thought they were pretty good. They'd fit right in on Little Steven's Underground Garage. B+/A-.

I was dragging this morning, but made it through the day without falling asleep, so I guess I'm not as old as I felt at 6:53 this morning when I woke up (53 minutes late and I still made the last express train into the city and got to work at my usual time).

Tags: maxwells the clean vermillion sands dump hoboken

No comments (yet)

The monument took the form of a stylized rendition of the original, which you can see in both of the links in the first paragraph.

Sadly, Bell Labs moved out of the building in Holmdel a few years ago. There have been attempts to sell the building and redevelop the huge tract of land in the middle of a very wealthy community, but they've come to naught, and the property is blocked off and basically inaccessible at this point. Back in 2007, shortly before the barriers were erected, I visited the site and took some pictures. Lucent, the corporate father of Bell Labs, had fallen on hard times, and the maintenance of a monument to their glorious corporate and scientific past at a location they didn't even want to own any more took a pretty low priority.

The text of the monument reads:

At this location in 1931, Karl Jansky, a Bell Laboratories physicist and radio researcher, recorded for the first time radio signals from beyond the Earth. The source of these signals -- radio noise at a wavelength of 14.6 meters -- was the center of our Milky Way galaxy.

This sculpture commemorates Jansky's discovery, first announced in 1933, which gave birth to the science of radio astronomy. The sculpture is oriented as Jansky’s antenna was at 7:10 p.m. on September 16, 1932, at a moment of maximum signal. As his directional antenna rotated, the center of our galaxy came into view in the direction of the constellation Sagittarius, low on the southern horizon.

Radio Astronomy pioneer Karl Jansky died in 1950, years before the scientific community realized the significance of his discovery. In 1973, the International Astronomical Union gave his name to the international unit of radio flux density. Jansky’s work led to a number of breakthroughs in astronomy: the discovery of quasars, pulsars, radio galaxies, and near this site in 1964, the Nobel Prize-winning discovery by Bell Laboratories scientists of the cosmic microwave background which has revolutionized our understanding of the origin of the universe.

It’s sad that the monument was left to the elements and blocked by barricades. I hope that someday it will be accessible again.

Tags: jansky

3 comments

...always makes me think of the video Chris Knox and Alec Bathgate did for the Tall Dwarfs song Turning Brown and Torn in Two

That’s only fitting, because Little Girls kind of sound like they could have been a Flying Nun band.

Tags: tall dwarfs little girls

No comments (yet)

Uh-uh.

Think more along the lines of classic NZ noisemeisters Bailter Space, shimmering waves of melodic noise. Great stuff. In this video from KEXP, they take Big Black's classic “Racer X” and make it their own.

They’re currently touring the world and releasing a single every two months that includes an interesting cover on the B-side. The first one, which had Racer X on it, is sold out, but you can get their new Younger Us single b/w a cover of X’s “Sex and Dying in High Society”. While you’re there, feel free to buy their two albums as well. Great stuff.

Tags: japandroids bigblack racerx

3 comments

Tags: music ponies laurabarrett

2 comments

Tags: pinhole communism kiev polaroid photography

No comments (yet)

No comments (yet)