techno.blog("Dion")

“HP is excited to announce that developers will be able to purchase an unlocked UMTS version of the new Palm Pre 2”

The words above are a long time coming. It has been a mission since joining Palm to get developers a great dev phone. It is one of those things from the outside that seems like an obvious thing, and surely it should be easy to do right? Well, I have been schooled in the world of carriers, and it took some real world to get all of the i’s dotted and t’s crossed.

If you have wanted a nice fast webOS 2.0 enabled device to test on, please get on the list and ready. There is still work to do (make available in more places around the world etc), but the ball is now rolling.

Kevin Decker has also put together a great new Facebook release for the various channels. When folks get webOS 2.0 they will be happy to see some great functionality there too.

Engineers put a ton of time into making webOS 2.0 shine. There is a lot of work under the hood and the org is setup to build nicely on the foundation of that work. Congrats to the engineers who made the release happen.

I mentioned Vapour, the Mozilla Open Web App Store. I didn’t know that it wasn’t released yet (even though the code was out there).

Well, now it has been released with the post on an Open Web App Ecosystem that has a prototype and technical documentation with it.

This is a huge deal, and I am jazzed that Mozilla is getting into the game here. The Web needs to give developers as many opportunities to monetize as possible, and needs to help consumers find the best possible content.

First we have the philosophy on what an Open Web App even is:

• Are built using HTML, CSS and JavaScript.
• Can be “installed” to a dashboard within your mobile or desktop Web browser, or to your native OS desktop or mobile home screen.
• Work in all modern Web browsers, while enabling each browser to compete on app presentation, organization and management user interfaces.
• Support paid apps by means of an authorization model that uses existing identity systems like OpenID.
• Support portable purchases: An app purchased for one browser works in other browsers, and across multiple desktop and mobile platforms without repurchase.
• Can request access to one or more advanced and/or privacy-sensitive capabilities that they would like access to (like geolocation) which the system will mediate, giving the user the ability to opt-in to them if desired.
• Can be distributed by developers directly to users without any gatekeeper, and distributed through multiple stores, allowing stores to compete on customer service, price, policies, app discoverability, ratings, reviews and other attributes.
• Can receive notifications from the cloud.
• Support deep search across apps: Apps can implement an interface that enables the app container (generally the Web browser) to provide the user with a cross-app search experience that links deeply into any app that can satisfy the search.

There are some interesting elements in there, such as calling out notification support as a first class required feature.

Then we get to the brass tacks. The tech behind this. I quickly peaked at the manifest and was happy to see that it looks very similar to Chrome (and the webOS appinfo.json). I would love to see us all get in a room and try to come up with some subset of JSON that we can agree on.

I also enjoyed seeing:

• Permissions: The thought around permissions and what it means to be an app.
• Verification: How do we actually make things like “buy on Chrome, use on Firefox” working? How do we allow distributed systems for payment and all of the services that tend to be silo’d right no?
• Cross app integration: The Web is great at mashups, and we should lose that in apps

Great to see the word now fully out, and now we have the concept we can join Mozilla in helping to define how this all works, and how it can be useful. It is so very hard to compete with a unified system, and to make it happen takes real work and collaboration. What do you think?

I love the Twitter for iPad application and how Loren et al have built an experience that feels right in your hands. There is one bug though that can drive me crazy, and that is the fact that the unread state of direct messages is broken. It feels like 99% of the time I will open up the application and the last 20 messages will have unread:true, even though I know I have read those messages. The bug is particularly irksome because it is so in your face. The messages tab is highlighted as though there are no items even though I know there is nothing new for me (and I just need to go through again and mark them all as read? ugh).

It made me wonder how Twitter was handling the state of direct messages. In creating Facebook for webOS we built out FB messaging, and the state was handled for us. The Facebook design has the notion of threading baked in (as apposed to email for example) and is as follows:

• A user has multiple mailbox folders (default messages, sent, updates)
• A folder has multiple threads
• A thread has multiple messages.

So, where is the unread flag kept? You may think that it is at the message level… after all, it is a message that is either read or not. However, the thread actually controls the flag for Facebook. This means that in a conversation there is basically an int count that shows you how many messages are unread. If zero, then all messages in the thread are read. There are trade offs on having the unread flag be a count and not a flag on the message layer, but the high level point is the core platform is keeping track of what a user has done. Whether you go through the website, or any application that speaks the Facebook API, as long as your application doesn’t cache too aggressively, you will have a good result. The key becomes: as the platform developer you very much understand that the service is the master, and you need to be smart about caching data to give your users a responsive interface, but make sure to sync on the data to make sure it is accurate.

The Twitter API on the other hand doesn’t appear to keep any unread state for messages. Echofon is a cross platform client that showcases its support for syncing this kind of data. It is a nice feature for them to be able to differentiate on, but man….. it sucks that they have to write it!

I hope that Twitter starts to own the state so we aren’t in the current situation of no one really knowing my state, and it has been interesting to see the different state of affairs, and have you thinking about what the platform should be doing, and what should be left to the clients of said platform.

I just wrote about the “don’t deploy HTML5″ comment that sparked a lot of conversation around HTML5 and its readiness (again).

I wasn’t sure if Philippe’s words were taken out of context from the reporter. There are some valid points that can be made around the comment, and thus I was curious to see if Philippe would take the opportunity to put his thoughts into his own words, and he has done in his post on HTML5: The jewel in the Open Web Platform.

It felt like a bit of a bizarre “response” since it doesn’t really acknowledge the discussion and instead reads to me, as a piece on how we are in the early stages, need to test, fun for browsers to be playing, but again….. early stages.

There are some points I very much agree with here. I like the notion of the “Open Web Platform” as the stack that brings together HTML5, CSS, JavaScript, etc…. although the server side and protocol side of the Open Web community may not agree and would prefer “Open Web Client Platform” or something. We have been using the term “HTML5″ as the big umbrella of the client side revolution, post-Ajax.

Ben and I have recently given a talk on HTML5 and the role the Web plays with respect to the application ecosystem explosion we are seeing right now. To put it in perspective, the iOS market by itself is growing faster than the Web 1.0 revolution. The Web is a massive ecosystem, and so is the app ecosystem, so it is obvious that there will be some impact from these two worlds colliding.

As Web fans, we are at war. We are passed the browser wars…. that is now in fighting. We need the Web to be a competitive platform, and this is where I do agree with Philippe. What does it mean to be an “HTML5″ platform right now? Just when I feel like we are getting aligned (e.g. using CSS3 transforms/transitions/animations for high performance graphics) one of the important browser runtimes leaves them out. Developers need a solid platform that they know they can build on. With HTML5 we have our first opportunity to deliver an app platform rather than a documentation hypertext system that happens to have enough hack-ability that we could add in Ajax. We can’t sit and complain to the W3C or browsers about the lack of platform features though. We as a community need to get together and show everyone what we as web app developers require from a platform. We want capability. We want ergonomics. We want uniformity. Great things are happening in browser runtime land right now…. so it is time to push.

So, I think Philippe has some of the right idea after all, but I do hope he realizes that we can’t wait for the full HTML5 to bear out. We need to weaponize *today* against the app ecosystems in the fight for the Web.

And, the Web is so very much worth fighting for. When in history has a major platform NOT been owned by a single vendor? Mainframes. personal computing. consoles. All the world of the proprietary. We are in absolute danger of losing the true gem of the Web…. its true open-ness. Being open itself isn’t a weapon though, and in fact it can be a drag and a hinderance which means we need to be even smarter to make sure that the open system that we have is able to deliver better experiences for developers and users.

Philipe of the W3C has been quoted telling the world that HTML5 isn’t ready yet and that you shouldn’t “deploy HTML5″. This is sparked the old debate around when HTML5 is ready, and the haters can come out and talk about how long it takes etc etc etc. Here are his words:

“The problem we’re facing right now is there is already a lot of excitement for HTML5, but it’s a little too early to deploy it because we’re running into interoperability issues. The real problem is can we make HTML5 work across browsers and at the moment, that is not the case.”

In the meantime, great developers are delivering next generation experiences on top of new modern features that many browsers have implemented TODAY.

The Web platform makes it very possible to progressively enhance (or regressively!) your application for the fast growing segment of the population that has a fantastic modern browser.

Thus, I utterly disagree with Philipe, and instead emplore you to think about what your site or app can be in 2010 with the new capabilities. The Ajax revolution was a hack, and with modern “HTML5″ browsers we finally have a fantastic runtime with great graphics performance (hardware accelerated up the wazoo [both CSS3 transitions/transforms/animations and Canvas]), amazing JavaScript runtimes, the ability to get off of the main UI thread (Web Workers), much better offline and caching support (Local Storage, Web Databases, App Cache) and much much more.

Take a look at the demos from the IE9 beta event, Chrome Experiments, and Mozilla Hacks for a glimpse at what is coming. Users expectations of the Web are just about to be changed again. The day that you used Google Maps for the first time was the day that MapQuest seemed AWFUL. As soon as the bar is raised, you can’t go back. What side of the bar do you want to be on?

Disclaimer: There are real tradeoffs with the Web platform being an open standard with multiple implementations. The platform is diverse and not always uniform. It is our job to rally browser vendors to fix things. For example, Microsoft is doing great things with IE9, but they need to add CSS3 transitions/transforms/animations as soon as physically possible. I would like to think that Philipe meant more to highlight the tradeoffs and not discourage developers. But man, the W3C can really drive me nuts.

Remy Sharp has some nice ranty thoughts on the topic, too.

Paul Irish gave a fantastic updated State of HTML5 talk at JSConf.EU. It is packed full of demos, including sharks with freaking lazer beams!

At one point he showed off the WebKit support for <input speech> implementation that allows you to talk into an input area. You click on the microphone, speak in, and it will get translated for you with the results. I am not sure if you can tweak how the translation is done (choose a Nuance vs. Google vs. …. solution for example), but it definitely works well out of the box.

I was surprised to see this already landed in my developer-channel Chrome, so I was incented to do something with it on the plane trip back from Berlin to New York City. Something simple would be to give the user the ability to enable speech on any input. I whipped up a Chrome extension using the context menu API, but was quickly surprised to see that there isn’t support in the API to get the DOM node that you are working on. Huh. Kinda crazy in fact.

Then the whizzkid antimatter came to the rescue with his cheeky little hack around the system. Here is how it plays out in the world of this extension:

The background page

First we enable the context menu on any “editable” element (vs. anywhere on the page, on any text, etc), and when clicked we fire off an event to the content script in the given tab:

<script>
chrome.contextMenus.create({
    title: "Turn on speech input",
    contexts: ["editable"],
    onclick: function(info, tab) {
        chrome.tabs.sendRequest(tab.id, 'letmespeak')
    }
});
</script>

Catching in a content script

A content script then does two things:

• Listens for mousedown events to keep resetting the last element in focus
• Catches the event, and turns on the speech attribute on the target DOM node

var last_target = null;
document.addEventListener('mousedown', function(event) {
    last_target = event.target;
}, true);
 
chrome.extension.onRequest.addListener(function(event) {
    last_target.setAttribute("speech", "on");
    last_target = null;
})

Wire-y wire-y

Of course, it all gets wired up in the manifest:

{
    "name": "Turn on Speech Input",
    "description": "Turns on the speech attribute, allows you to speak into an input",
    "version": "0.1",
    "permissions": ["contextMenus"],
    "minimum_chrome_version": "6",
    "background_page": "background.html",
    "content_scripts": [{
        "matches": ["<all_urls>"],
        "js": ["input-speech.js"]
    }]
}

This trivial extension is of course on GitHub (I want git-achivements after all! :).

A couple of things trouble me though:

• The microphone icon should sit on the right of the input, however when dynamically tweaked like this it shows up on the left by mistake [BUG]
• I have also played with extensions such as Google Scribe. Adding icons like this doesn’t scale. Having them show up all the time gets in my way. I think I want one ability to popup special powers like scribe completion, or speech-to-text, without it getting in my way
• When services are built into standard elements like this, it feels like I want to have the ability to tweak how they work (with great defaults of course, as 99.9999% of the time they won’t be changed.

You?

Do a search for JavaScript and you find a painful set of returns. The worst offender is having Java results show up. Ouch. (Remember: Java is to JavaScript as Ham is to Hamster!).

Compare to a search for Java, or C#, or Ruby, (or ….).

Ouch. We need better. To begin with the pirates of JSConf (lead by the awesome Mr. Chris Williams!) have started a grass roots Operation SEO at Promote JS. Go there, and help the cause by doing embeds like the following:

If we can do half of the work to promote this as we have with the awesome VaporJS library, then we should be in a better place.

Step 2: Come up with a fantastic landing area for JavaScript.

There has been a bit of chatter regarding how IE9 implements pinned sites, namely that this isn’t the way to go:

<meta name="application-name" content="Ars Technica"/>
<meta name="msapplication-starturl" content="http://arstechnica.com/"/>
<meta name="msapplication-tooltip" content="Ars Technica: Serving the technologist for 1.2 decades"/>
<meta name="msapplication-task" content="name=News;action-uri=http://arstechnica.com/;icon-uri=http://arstechnica.com/favicon.ico"/>
<meta name="msapplication-task" content="name=Features;action-uri=http://arstechnica.com/features/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-features.ico"/>
<meta name="msapplication-task" content="name=OpenForum;action-uri=http://arstechnica.com/civis/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-forum.ico"/>
<meta name="msapplication-task" content="name=One Microsoft Way;action-uri=http://arstechnica.com/microsoft/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-omw.ico"/>
<meta name="msapplication-task" content="name=Subscribe;action-uri=http://arstechnica.com/subscriptions/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-subscribe.ico"/>

Some are calling for using the menu tag, others for
a link tag that points to an external resource that defines the menus.

There are pros and cons to the different approaches (reusing menus across the site instead of embedding inline, [or just using <a> as Sam Pullara mentions!]). For me, the details on the implementation aren’t what is important here.

What matters to me is how Microsoft goes about adding these features. It is their browser, and they can do whatever they want. However, if they really want to work with developers, they could have worked with us (and other browser vendors) on the feature. I am all for trying things out and not standardizing anything prematurely, and I am frustrated when browser vendors don’t experiment more sometimes, but man.

This is a “beta” of IE9, so I hope that there is time to work on this together. If other browsers are interested in doing something similar in the future, it would be nice to abstract the task at hand, which is denoting what actions are available in the given page (or on the given site as a whole). If the msapplication prefix is used in a “before we work this out” way, that is probably OK, but I really don’t want to go down the path of multiple ways of defining this. I personally don’t enjoy seeing -webkit-*, -moz-*, -o-* in CSS. So much repetition that never goes away. I would much rather have someone grab foo and let people -vendor-foo if they disagree until things work out.

Microsoft, if you have worked with other browser vendors and developers on this, I forgive you; but if you haven’t and aren’t willing to listen to the community, I fear for the history repeating itself.

Am I off base?

The Web lives in a sandbox. An important one. It means that you can click around on links and “feel” safe (that is, until you go to a talk by Jeremiah Grossman).

On your desktop however, you have a binary situation. You either run some code that can do pretty much anything (ignoring file permissions and virtualization etc) or you don’t run that code.

One of the dialogs that I dislike is from OS X when you “download something from the Internet”:

I would love to see the stats that Apple may have on how people react to this. I can imagine a scenario where something has mistakenly been downloaded and run, but I would guess that 99% of the time a user goes through the following:

• Click on something to download an app
• Run the app, because I wanted to, hence me clicking on it
• I have no information here…. so I think I will just click yes!

Some will yell, “think of the children!” and that if this popup has stopped ONE virus or malware through, it is worth the pain for the other millions of up pops.

Surely we can do better. Of all of the features in the IE9 beta, one that may not shout out as you as much as fancy fast chess or goldfish bowls, is how they manage this situation.

In Dean’s whirlwind keynote presentation (very nicely produced!) he showed a feature where clicking on a particular .exe wouldn’t alert the user based on crowd data. Basically, if enough people have used foo.exe and it is trusted, it can Just Get Through.

The virus scanning world is doing a lot of this on the backend. Places with scale can monitor the crowd and do a lot more than we have done now, and I can’t wait to see what comes of this.

We have talked about social permissions before. It will be great when I can see that Jeremiah Grossman is using a particular application for example ;) I look forward to a way out of app permissions hell.

Yesterday’s announcement of what was immediately dubbed #newtwitter has crept up on me in its significance.

While Twitter has been growing in mainstream significance and popularity, it hasn’t managed to adopt a strategy that clearly aims the company towards mass market success. I think #newtwitter changes that, turning the site into a rich information discovery platform, if you’ll excuse the buzzword bingo. The new design is a pleasure to use, and encourages a kind of deep exploration of the data within Twitter that has previously only been exposed in bits and pieces by third-party applications. Browsing Twitter is now as rewarding as communicating with it.

This comes from Alex Payne, former Twitter API architect and all around top notch bloke. The new Twitter interface came at an interesting time for me. You see, Ben and I are working on upcoming presentations for Web Directions, JSConf.EU, NY JS, and Web 2.0 Expo. We have been spending some time analyzing the interesting worlds of apps vs. mobile Web, and how the worlds are converging in interesting ways. After the Twitter for iPad came out:

it was a stark contrast with Twitter.com:

On the iPad, the team had done a great job thinking about the feel of the application and how people sit back with their tablet devices and interact with them via touch. The stacking system is fun to use, and although some times it feels a little rough, it feels that way in the way that things in the physical world can feel rough. I like it. Of all the features, the only feature that truly matters to me is the inline preview of URLs. As soon as I experienced it, I knew it would change how I use Twitter. Flipboard is great, but is a fun sit back experience that I actually tend not to use. Twitter for iPad however gives me a more practical experience that goes beyond 140 characters. The Web joins me in the application rather than shooting me out to other tabs in the browser, or apps in the silo space.

After using the iPad version I started to ponder how different it was both from twitter.com and desktop clients (Tweetie for Mac, echofon, etc). I am not a TweetDeck “let me view lots of lists!” type of user. My desktop client sits in the corner, an appendix. I like how echofon uses draws to extend the space, but I now want to be able to change the size of the window and when large enough, flip to a tablet view. There is no reason that the desktop application couldn’t morph nicely and let me use the same application for my different use cases (small area of the screen to view tweets going by, extended version to immerse in the experience). When looking at twitter.com, the boring list of Tweets seemed poor compared to FriendFeed and Facebook’s expansion of that area. Those sites did smart things based on the type of content in the status update, they show comments right there, etc. Twitter has been notoriously awful for tracking the conversations being had in @replies. Changing this dynamic will change the conversations.

Just as I was looking at the touch iPad experience side by side with twitter.com and wanted to shout “the Web can do that too!” Twitter came along and implemented a fantastic rewrite of the site. The new Twitter brings an experience into the site that makes it so much more usable than 140 characters with a link.

Steve Souders just posted about his movement from blogging to Twitter. Twitter has very much changed the way I view blogging too. On Ajaxian.com I wanted to bring the community together to discuss the Ajax revolution. One of my goals was “if a developer only has a few minutes to see ‘what is important today?’” they could come to Ajaxian and feel like they are keeping up. There were other goals too (e.g. run The Ajax Experience as an excuse to get the top Ajax talent together to further the Web). The site had some exclusive content, but it was very much an aggregator, a curator. In that vein, my twitter feed started to become just as good as the website for the goal of people keeping up to date. With the new Twitter interface, that is even more true. That isn’t to say there isn’t room for more however. We have had visions of doing much more on the social community side, and hopefully one day we will get a chance to implement those visions. Whatever the case though, Twitter will be a real part of the solution.

Our users are expecting fantastic experiences. Once expectations are changed, the previous world is unusable. The day you played with Google Maps was the day you couldn’t deal with MapQuest. It felt archaic in comparison, but a day before hand you were fine with it!

The apps revolution has pushed fantastic experiences on us. With webOS we are showing that the Web can be a fantastic native runtime for these experiences. Today, we got to see Microsoft get behind the Web in a huge way.

“With HTML5, you can make as rich an experience as an app.”

At one point, Microsoft came along and pushed the Web forward with IE4, 5 and even poor old 6. However, once they had the market-share they gutted the team and moved on to WPF and Silverlight. The Web was the ghetto but to do beautiful, rich experiences…. use Silverlight and WPF! This is why it is amazing to see them pimp the beauty of the Web. You kinda have to rub your eyes in this turn around! Next, I hope that the Windows Phone 7 folks get the memo ;)

Now all of the top browsers have fantastic runtimes that are competing heavily. Fantastic news for us all. The Web is going to change in a huge way, and as developers we need to step up to the opportunity to deliver these experiences across various form factors. Right on.