techno.blog("Dion")

Today was a big day for us, moving into the new pad on University Avenue, Palo Alto. Not a bad place to be! Major kudos to Spencer Tall of Allegis Capital who are letting us hang with them as we incubate our ideas. It is majorly appreciated, and exciting.

Once we finally settled into our offices (after a trip to the Apple Store, just a block away!) we sat down to look at the view, and we giggled to see that it was this:

We are staring at the front door of Sencha! It feels like we are on a stakeout to see when Abe comes and goes. We took this shot and sent it to Abe just to let him know that we are “in position” ;)

We said “hi” to our Sencha neighbours and man did they seem in good spirits. The very recent SenchaCon was a huge success. It was there that they announced their 1.0 of Sencha Touch, and that it was to be free. This is great news for the mobile Web community at large. The segment is buzzing with jQuery Mobile, Enyo, Sencha Touch, and more.

Congrats to all, and Abe….. looking forward to being your neighbour mate.

The Palm Developer Day in New York City was a ton of fun last weekend. Greg and the events team did a bang up job, and it was a pleasure to continue to hang out with the webOS community. Seeing old friends was great, and finally being able to put a face to a name or a nick was great too (highlighted by meeting Rod Whitby of webOS internals, all the way from down under!) This community sure is passionate.

A strong thread throughout the show was the importance of cross platform solutions for developers. There was great content such as a cross platform framework landscape review, and PhoneGap, and a panel including the likes of Charles Jolly of Strobe/SproutCore.

The icing on the cake though was the coming out party for Enyo (greek goddess of War), a next-generation touch UI framework from HP.

It is important to understand where Enyo came from. A chap called Matt McNulty was one of the reasons why Ben and I joined Palm way-back-when. We had been working with him on a webOS-bespin hybrid which later became the fantastic Ares Web based IDE. The layout system is still best in breed, and being able to deploy from the Web to your phone is just awesome.

Those in the Ajax community, especially Dojo old-timers wouldn’t have been surprised to see this level of polish and innovation. Scott and Steve created the grid that was donated to Dojo.

The team behind Ares were not using the Mojo framework, but rather another one (Opus) that would morph into what we see with Enyo today. Going between an Ares application and a Mojo one has always had friction, but that will all be changed with The Unification happens. You will be able to go between the UI builder tool (Ares) and hand coding, no sweet.

There are a bunch of modern touch UI frameworks these days: Sencha Touch, Sproutcore Touch, iAd JS (really!), jQuery Mobile, and more. I am excited about Enyo being added to this mix. Here is why:

Performance

This has been the number one goal, and I have seen the massive difference that it makes on webOS. Enyo based apps start incredibly quickly and stay smooth. This is an area that webOS needed to improve (performance) and Enyo makes huge strides (especially when you also add the work that the entire platform and apps teams have done). Fortunately a lot of the top frameworks are starting to do a really good job here. They are using similar tricks around: keeping a virtual tree and only going across the DOM boundary as little as possible, trying hard to keep animations and rendering on the GPU and without triggering re-renders whenever possible via CSS3 tricks.

Developer productivity

Ares developers have told us time and again how fun it is to write apps. It is very easy to get going, and this goes beyond the great tools. The Enyo framework itself has some fantastic developer ergonomics, especially around layout and the event design, which also helps make sure that you don’t leak memory (obviously a huge thing on mobile).

Cross device

Another major goal with Enyo is the fact that it has to deal with the number of devices coming out of HP running webOS in the future. This is huge, because a massive pain points for developers right now, and in the coming years even more so, will be the need to handle many resolutions, dimensions, and capabilities for the touch world. By solving this problem in a unique way, Enyo makes this a strength. Scott Miles (or as I call him, The Architect) showed off an email client that is in “phone” mode (list of emails) when in a narrow window, but as soon as it got big enough (say, a tablet size resolution) the layout changed in real-time to offer a different view. Being able to share views, and have magic components that can even do a lot of the work for you, is fantastic when you think of building applications that span mobile and tablet (and others). Beyond this though, what about Web apps? I have often said that I wish that I could run a Twitter app in an IM-like configuration (long thin view) looking like echofon/Tweetie/etc, but as soon as I maximise it or stretch it out, it uses that real-estate to become more like Twitter for iPad or TweetDeck. Enyo makes this very possible indeed.

ASIDE: I had a bit of fun with doing this manually with the “hello world” style site setdirection.com which changes between browser, mobile (including landscape and portrait).

Cross platform

Enyo is too good to be stuck on any one platform. I think that the folks behind webOS know this. Having a set of tools and framework like this available for the Web as a whole is going to add to the growing list of quality frameworks that are available for true touch applications (not just DOM sprinkling libraries).

Having this discipline is also added by the fact that you can then spend most of your time developing in a browser rather than an emulator, and thus use all of the browser debugging tools that are available.

Conclusion

Firstly, congrats to Matt, Scott, Steve, and the entire team for showing us a glimpse of Enyo. I can’t wait to have developers play with it. Go Web.

It is great to see not only PreCentral grok its importance, but also Engadget and others.

My last post discussed how special URLs are. They are loosely coupled strings of candyfloss and should be loved and respected.

Thus, a trend that I always makes me squirm is “sharecropping” (as Tantek would say) and not giving people your real address. You have all seen it:

• A TV ad that ends showing facebook.com/toyota instead of toyota.com
• A newpaper ad that just asks you to “follow” them with their Twitter URL
• “Check in” on Foursquare
• I was in a European airport that had billboards showing how to get info via their application that is “Available in the App Store”
• Remember AOL keywords?

On many of these services you are only renting space. You are sending traffic to the host of the system and helping them with their Google juice. I understand how you think that the hip kids just want to go to your Facebook page, but why not send them to your own URL that can deliver an experience that makes sense for them?

You get a lot of benefit:

• You are building your own SEO juice
• You inviting the user to your own house, and can thus own the relationship
• As a good host, you can choose the experience that you want to offer. For example, you can deliver an experience that makes sense for the given device AND what you have to offer.

This isn’t to say that you should tell the user where you are on the various services where they hang out.

I prototyped App Discover as a way to do the marriage between the users devices and what you have to offer. Hopefully sites will grow intelligence to give you an easy way to not keep telling you “download the app!” when you visit the site through your mobile device. The Delta mobile site throughs the above in your face, and since they have no way to query the system to check “hey, if the user has already installed the app, don’t bug him”, it bugs you. I always find it strange to open up the App Store itself and see it tell me about apps that I have already installed. Really? A lot of work to be done on discovery.

I think it is time to take some ownership of your URL, and treat it like a garden. Keep working on it.

A lot of time and effort has been spent by people discussing how the native platforms are superior to the Web recently. What is interesting to me is that many of these have always been the case.

“Wow, iOS applications are so much richer graphically, and you have much better access to the native environment”

Ben and I often talk about how the Web has changed over the years, and how the era of Ajax brought more focus to design in the Open Web platform (because you could [albeit via hackery] do more on the client without having to ask the server for every darn thing).

We compare how sites have changed, for example:

A core Web company such as Yahoo!

A design heavy company such as Disney:

And also Apple:

And, finally, we tease Google a little:

When you look back at many of the earlier designs of the top website brands, they are comical by todays standards. However, at this same time, technology such as WPF was being touted on the desktop. Why would people visit Web sites when they could experience amazing native Windows and Macintosh experiences?

The Web is always behind (in some ways), almost by definition due to the fact that it is based on Open standards. When you look at what you can do with the Web today, it actually compares a lot more favorably to the native desktop experiences that it did back then!

It turns out that the Web has some nice features and function. This isn’t about a ra-ra Web moment, but native folk should also use this as a way to make their platforms and applications better.

URLs are amazing

The Web offers a shared platform. The glue that binds the Web together is hyperlinks. My Mum can put up a website and join the shared fabric instantly. Her work can be found on Google, shared on Facebook, and quickly forgotten about on Twitter. All without having to talk to ANYONE. No deals. No vendors. Silent. That is pretty amazing.

Her work can join the shared stack as folks browse around the constantly changing event based Web. Not only can it be linked too, it can be embedded in various ways. The collective can all work on top of each others work in simple and interesting ways.

This is very different to the app silos of iOS for example. webOS and Android are better in different ways, and have some hooks that allow you to mimic the behaviour. In webOS you can cross scene push actions between applications and Android has a rich system of intents. Once you use these systems you wish you had them on the iOS…. e.g. being in an email, tapping on a link to go into a browser windows, and then going back to the email in a humane manner.

The mobile Web can really shine here if we can get that experience up to snuff. This clicked for me after talking to Charles Jolley sometime about a SproutCore application and differences between serving the mobile app on http vs. via PhoneGap/native app method.

Let’s say I have two native experiences installed on my iPad. Twitter for iPad, and the New York Times app. I am reading my Twitter feed and tap on a link to a nytimes URL. Ideally I may enjoy having the native experience take over, but it doesn’t as we are in silos. It would be nice if the native system would allow me to register a URL handler so the New York Times app could say “hey, if you see a nytimes URL, hand it to me and I can take care of it” (of course there are issues of preferences and choosing which app to launch etc).

Now imagine that the Twitter and New York Times solutions were done using Web technology, and could run via http and natively. Now, when you share a nytimes URL with me, I get the FULL experience passed over to me.

The Hackable Web

The fact that the Web is so hackable is a true gift too. I talked about the fact that you can embed and compose cleanly. “Mashups” are really powerful. The Facebook platform is a mashup. I feel very empowered on the Web as I know that I can change things…. and small things can frustrate me. I want to see the name of someone on Twitter instead of their handle (”Frank Davis” means more to me than “fatgopher” for all but friends that I know well or who tweet so much that I learn quickly). Echofon drives me nuts in that I can’t change this setting as I can in Tweetie (although Tweetie is so behind that I suffer through on Echofon :/).

If this was a Web application I could greasemonkey / extension my way out. There is always a power tool in reach. The core developer doesn’t have to build out a “plugin API” for me, but if they care about not breaking me they CAN expose a nice API as the Gmail team did back in the day. You can trick out twitter.com in so many ways thanks to the userscripts that are out there, and whatever you want to write yourself.

Now, this is far from mainstream. Sure, the good stuff can be wrapped up as a browser extension (and packaged together a la Better Gmail), but I still feel like we have a ways to go to make it easier for people to trick out their experiences. If my Mum goes to Twitter she will never realise there are hundred of ways to change that experience.

The Web has reach. You own your nodes (and can change what runs there at your convenience). It is still simple to get hacking on compared to most platforms (even if advanced things are hard) and remember: Distribution, distribution, distribution.

As we all push the Web forward, I look to see how we close the gap even more so with the proprietary platforms, and how we continue to surpass them in ways too.