techno.blog("Dion")

Web developers have to walk around dragging a ball and chain. It is fantastic that we have a ridiculous install base (browsers, the Web runtimes) and a dynamic language in JavaScript.

The ball and chain though is the fact that we have to care so much about the payload of the application that we write. Less code means less bytes to download, and less for the JS runtime to load up.

This has bad consequences:

• You are tempted to write hard to understand code
• You have to balance functionality and code size much more than other environments
• You end up getting tricky and come up with ways to dynamically load modules on demand
• All of this time is time not spent on the app logic.

When you run into a problem like this in computer science what do you do? Build an abstraction!

GWT has done a great job here. It’s very nature requires a compilation step, and once you have to deal with that step…. you can do a lot at build time to change the above dynamics.

For example:

• You can write nice explicit source code, and trust that the compiler will output optimized JS (which can look as ugly as sin for all anyone cares)
• Your application can get faster with a new release of GWT, as the compiler gets better
• A lot of advanced techniques such as code splitting, and deferred binding can be applied to allow logic to apply at build time as well as runtime.

Ignoring GWT, when you write a pure JS application for the Web, you are writing a cross platform application. Unlike clean portable C, you don’t have that compilation step to do clean up work for you on each platform, so you end up with a lot of runtime conditional logic.

You try to do object detection rather than user agent conditional, but still, you end up both downloading the code necessary to run in all environments, and you have the overhead of loading and executing that code.

Chances are you are smart and don’t do if() checks all the time, but maybe do so once when loading up. For large chunks of big differences, maybe you do something like:

var Foo = (sometest) ? function() {
    // do it like this
} : function() {
    // do it like that
};

If you take a look at some parts of popular JavaScript frameworks, you see that they are abstractions or fixes for various browsers. As browsers have stepped up to the plate recently, they have fixed a lot, and suddenly you take a step back. A lot of frameworks have a chunk of code to give us the ability to do smart things with CSS querying. Modern browsers support querySelectorAll (even with some bugs) and getElementsByClassName so a lot of the code is un-needed…. unless you care about the old browsers.

We shouldn’t have to download all of that cruft on the other side of the if() statement when we don’t use it!

The GWT compiler can output versions of your application targeted to a given browser. Only the fastest, minimal code, will get sent down. Deferred binding goes far beyond just browser type (can deal w/ locales and much more) too.

GWT isn’t the only horse in this race though.

Alex Russell started to sprinkle in some directives to Dojo that would enable you to do a build that is WebKit targeted. A major use case for all of this is making sure that you are sending down lean code in the mobile space. It can matter everywhere, but when you are dealing with grown up walkie talkies…. you want to really optimize.

And this brings us to YUI. I was really excited to see some of the features in the YUI 3.2.0 preview release. Great stuff for touch/gesture support, but what stood out for me was “YUI’s intrinsic Loader now supports capability-based loading”. A-ha!

I poked around the source to see how it was used. Here is one fake example that shows how it works. When you boot up YUI you can add in “conditions” which are in charge of working out whether to load something. You can currently tie on to user agent, or write a test function:

YUI({
    modules: {
        lib2: {
            requires: ['yui'],
            fullpath: 'js/lib2.js',
            condition: {
                trigger: 'node-base',
                ua: 'gecko'
            }
        },
 
        lib3: {
            requires: ['yui'],
            fullpath: 'js/lib3.js',
            condition: {
                trigger: 'event-base',
                test: function(Y, req) {
                    return Y.UA.gecko;
                }
            }
        }
    }
 
}).use('node', function (Y) { .... });

The YUI team uses this themselves to only load certain ugly DOM stuff for IE6 when needed:

"dom-style-ie": {
    "condition": {
        "trigger": "dom-style", 
        "ua": "ie"
    }, 
    "requires": [
        "dom-style"
    ]
},
 
YUI.add('dom-style-ie', function(Y) {
    // ....
});

This makes a ton of sense, especially for the libraries themselves to do this work. They are the ones that do the heavy lifting of cross browser ugliness, all to allow us to write to an API that works.

Beyond that, we can then ourselves split out code if it becomes a performance issue.

Of course, the value of the test() function is that you can do capability based testing (not just user agent testing…. hence the name!). This means that you can do a test say for Canvas support (as Zach mentions in the comments) document.createElement(’canvas’).getContext, and load up excanvas or another shim library if it doesn’t exist.

Using modernizr and ilk, we could build out “plugins” for YUI that auto load based on common capabilities. You can imagine running a YUI build, having it detect that you are using a capability, and then automatically load up a plugin that has the condition all loaded up. What a great user experience as a developer!

Maybe it makes sense to come up with a common pattern and conventions for dealing with this issue. How do you name your CSS/JS? Do we setup server side hooks so we don’t even need loaders necessarily?

I can certainly see a day where you may be asking the Google Ajax Library service for jquery.js, but it is returning jquery.ie.js to you.

I consider myself a developer who happens to love community, evangelism, and advocacy.

When I put on the developer relations hat, I am constantly asking myself what value these roles have, and how to add more value to the process.

When I was working at Google, a certain engineering manager made it very clear that he felt advocacy and evangelism added close to zero value. His position was that you if you build a great product, developers will come. Rather than lash out, I keep that in the back of my mind, and think about how to make that view incorrect.

I keep coming back to Ohm’s law which explains the relationship between current, potential difference, and resistance and the laws of electricity.

I still remember the crazy physics teacher that I had that would scream:

“It’s the volts that jolt but the amps will kill ya!”

He would then kindly put kids through an experiment to get close to showing the truth behind that statement.

If you think of this law as a pipe and water flowing through it, there is the radius of said pipe, how fast the water is being pushed through it, and the resistance of the pipe.

How does this relate to developers and developer advocacy?

To reference the afore mentioned engineering manager, he has some truth. I feel like developer evangelism can help with the “push” (the volts). However, if you take the best developer relations crew… a crew that can push hard… they won’t be able to reach any potential if the pipe is tiny small, and the friction of the tools, APIs, platform, or economics provide.

Thus, the most important thing that you can do for a developer oriented initiative is first create a fantastic pipe. The pipe should have as little friction as possible, and should be as large as possible. Probably the most important way to achieve those goals is to provide developers with:

• A fantastic economic opportunity. Let’s face it, if Apple restricted developers so they had to use punch cards to build iOS apps, we would still have a lot of apps :) Same goes for Facebook etc. Even though when you look at the numbers on even those platforms, success is a “hit based” economy, the hits do so well that many developers get in the water for their change
• A chance to do something different. Create a platform with unique capabilities and the opportunity for developers to create something very different, and that itself will be a draw. New companies and products can be created where they didn’t exist. Nokia had (and has) a boatload of phones. At JavaOne for years a Sun exec would get up and say “developer a J2ME app and you can reach BILLLLLLLIONS of devices!” Few did in the scale that we see with so called “smartphones”. You just couldn’t create anything interesting or compelling (oh, and there are the carrier gateway issues of that time too)
• Make your platform fun and generative. This is a sub-bullet of the last one in many ways. But, if you a developer can have a great time creating on top of your building blocks, great things will happen, and the network effect can flow.

Now, evangelism comes in as a way to:

• Let developers KNOW about your fantastic economic opportunity, their chance to do something different, and how productive and fun it is to develop on.
• With tools, samples, articles, conferences, and community in general…. help lower the friction for these things. Give developers a leg up.

This push can have a huge effect. Good evangelism will also create external evangelists who share your excitement and vision ending up with a nice network effect.

Only half the story

But evangelism is only a piece of the story. The reason that I like the term “developer advocate” so much (and why I posted on this topic) is because it shows the other side of the coin. You are the third party developers representative back at your platform company. You are letting the internal teams understand their needs. And, you get to be part of that community:

“I can advocate something, and part of that will hopefully be heavily listening, and participating in the open community. Of course, these are just words, and you have to make this happen. We could call ourselves evangelists and do a lot of listening, or become advocates and do none. The word choice though does make you think about what you should be doing.
More importantly, in my opinion, is the word developer. Rather than talking just about technology, we are talking about humans who use it. This again makes you feel like you need to be more part of the community, working with developers on their level.”

Every now and then I reflect on Ohm’s law (it helps to watch the current of a stream in the mountains as I have been able to do in Colorado this week!), and think about how me and my team can both relieve friction and push harder for developers on the platform.

I have been at HP for a week or so now, and thus it was a great opportunity to think about how we can come together as a team to do just this. I think that I will be personally changing what I do, and I can’t wait to work with the community, the internal engineers, and the product chaps as we take webOS to the next level.

Steve Souders told me about Diffable, when I saw him after his awesome Velocity conference.

Diffable is an open source project that allows you to only send down the deltas in your application versions, versus full new downloads (which may have a large amount of duplicate data).

In their presentation, Josh Harrison and James deBoer, talk about the details after the start with the core issues:

Problem:

Frequently modified web resources must be downloaded in their entirety with every modification.
Even a small change invalidates the cache.
Rich internet applications often have large amounts of static content.

Idea:

Initial application resources kept in cache.
Changes to cached versions transmitted as deltas.
Deltas merged client-side to generate latest JS version.

Benefits:

Faster page load times for users with cached resources.
Small changes to large resources incur only small costs.

Steve summarizes things well in his post:

Diffable uses differential compression to reduce the size of JavaScript downloads. It makes a lot of sense. Suppose your web site has a large external script. When a new release comes out, it’s often the case that a bulk of that large script is unchanged. And yet, users have to download the entire new script even if the old script is still cached.

Josh and James work on Google Maps which has a main script that is ~300K. A typical revision for this 300K script produces patches that are less than 20K. It’s wasteful to download that other 280K if the user has the old revision in their cache. That’s the inspiration for Diffable.

Diffable is implemented on the server and the client. The server component records revision deltas so it can return a patch to bring older versions up to date. The client component (written in JavaScript) detects if an older version is cached and if necessary requests the patch to the current version. The client component knows how to merge the patch with the cached version and evals the result.

With this technique in action, you end up sending down JS arrays as deltas that looks like:

[0,10,"red",40,3," leaps",25,15,16,3,"."]

The data that these guys share is impressive. The results seem to add up for applications as large as Google Maps. Do they measure up for smaller apps? If large apps have a lot of static content, couldn’t that content be put into another download and even app cached away?

Also, it is a lot of work to implement this for a developer. Work on both client side and server side. It would be great if we can experiment with Diffable and then move things lower into the stack. Why can’t HTTP itself be smart enough to deal with diffs?

It did make me think of my favourite chaps @github. I know that GitHub is about development rather than deployment…. but what if they supported this natively (since they kinda grok diffin’ etc already) and offered a client side loader so you could github.load("project", ...).

It all just makes me realise that GitHub is poised to pounce in many directions. Good on ‘em.

I have been talking in analogy for the last few days. The common meme is relating the computing usage trends to that of the car industry. As I watch continue to watch my family use their devices, it does feel like things are changing. My mum continues to thrive on her iPad / Palm Pixi combo. She feels empowered to try the different corners of the experience. To download new experiences. She is having fun.

One friend suggested that it is like the shift (pun intended) that we saw when automatic transmissions were introduced. At first they were expensive and had some issues, but being able to have simple controls changed the way that people drove. It became so simple. There were people who cried that it would never take off. “People want the control of a manual stick shift system!” However, although we continue to see some die-hards, the vaste majority of the US population drive automatics (this isn’t true everywhere in the world). That battle is over. We will never go back.

The iPad experience is like driving the computing experience without the manual hassle. You don’t have to know how to install the engine to start out (install an OS), nor deal with (and worry endlessly about) the workings. In general, you just don’t need to worry about all of the abstractions any more. The notion of files. And, don’t get me started on viruses.

As my mother thrives on her iPad, I use it sparingly, mainly as an entertainment consumption device. Wait a minute: Am I am the guy who loves the stick shift and never wants to jump to an automatic? I am a little different from the religious chaps who claimed they couldn’t understand why anyone would want an automatic. Or looked down on those people. I understand why my Mum prefers the iPad experience.

I do find the iPad experience often frustrating however. My “why did the car shift then? it wasn’t time!” moments occur mainly around the restricted access to customization, and the inherent and enforced immersion.

First a small thing, which will unfortunately show off an how anal I can be:

I want to rename this to “BBC News”. I am the guy who winces when someone bookmarks a page and doesn’t rename it, thus having “Foo.com – a barish company that deals in widgets, gadgets, monkeys, and flubbers”. I want to jump in and rename it to “Foo” on the bookmark bar. More space. More room. Petty for sure.

Where it gets more real for me is in the lack of integration between applications. Being immersed with one application at a time can be a fantastic thing, I will give you that… even if I often would love to give a bit of screen real estate to me Twitter stream while working on another app right next to it. However, if you live in an immersive environment, you need great integration between experiences. I should be able to Tweet/Share from any application, and not have to close down the app, go to a Twitter client, and get back to the app that had content I was tweeting. A lot of this comes down to multitasking, but more comes from integration….. and putting intents on a stack. On the iPad I feel like I am jumping through doors without an easy way to go back.

The browser has some of these notions baked in. States have URLs that I can bookmark. I can go forward and back. I can search. I can fork off (new tab). Turns out, I really like those abstractions, and miss them when they are not there, and every single app tries to reproduce some of them. They are often cross cutting concerns. I don’t want the app developer to have to write code and choose where to put a “Share” button. I want the system to know that I have an account on Twitter and let me share with a simple gesture.

Back to the Web. I was a little stunned when a friend showed me the Speed Test.net experience on an iPad:

Yup, if you go to speedtest.net, you are automatically redirected to the App Store. There is no way to trick it (again: would be nice to have customizability and tweak user agents etc).

To the credit of the speed test developers, the website is driven by Flash, which won’t work…. so they are trying to do something good for a user. I get that.

However, I am scared to death to think of the Web going this way. You go to websites and get sent to apps directly. I *do* want user agents to tell me if apps are available (hence the App Discover experiment), but don’t force me into the world of apps. I also think that doing what YouTube does and take over a URL in a certain way can be a good thing. I would love to install handlers for mime types…. so a certain link always opens up my favourite Twitter client say.

I personally prefer many of the Web experiences to the “new” app experiences. (I talked earlier about the abstractions that I find useful). This could break the Web. Data that was shared at the ReadWriteWeb Mobile Summit showed that the same users often hit a site using: mobile website, full website, and application. We are context switching in real-time already. Different views are best for different use cases.

It definitely feels like there is a shift in the force. We need to get the balance spot on as we move to automatic transmissions. What should be customizable. What should be locked down. As developers as well as consumers, we need to make our voices heard. What do you think?

I am sure that we are going to see an explosion of people learning how you can create Chrome apps simply by creating a manifest and building a .crx as they rush to get their web apps into the Chrome Web Store.

This is a huge advantage of adding an “app” model on top of Web technology. We have been creating Web apps all along, and now we are getting to the packaging layer of the stack as we turn the Web inside out. Instead of hosting our apps on our own URLs, we are now packaging them up and putting them in external app catalogs for extra distribution. Kinda weird in many ways huh? ;)

Moving past simply wrapping up your Website so throw it in a store, I think we have an opportunity to do much more here.

With Greasemonkey user scripts, I am able to both personalize my experience across the Web, and pull in experiences.

I was just chatting with Phil Windley about Kynetx, his company that is doing interesting things in the “professional Greasemonkey” / enterprise client side mashup space. He showed me some of this in action. What if you are a member of AAA. By installing an app/add-on you get to carry that information around the Web with you. AAA has a ton of discounts that you never really know about. What if when you went to purchase something at coolwidgets.com it told you that you can get 10% off with a given AAA code? coolwidgets.com could choose to display all of the affiliates that it has, but that doesn’t scale. Instead, show me the affiliates that I have a relationship with!

Here Phil walks through a Twitter mashup example:

I want to break out of the app silo. I was drawn to webOS synergy because it allowed me to do just that. Our Facebook app is only part of the Facebook story. A bulk of the Facebook functionality is spread across the entire device. If a user enters their Facebook account, that follows them. Want to share a photo? Now you have a Facebook option. If users choose another social network, that can follow them instead. I don’t want to have to open an app to do everything.

This is where the trojan opportunity of the Chrome Web Store comes into play. Being able to package the Web application with extension like ability is key. Like Gmail? Download the app and:

• Works offline
• Nice big icon to click on
• Permissions problem “solved”
• Takes the Gmail experience throughout your browsing (mailto: goes to gmail, input type="email" auto completes on Gmail)

One great advantage of the Web is the mashup potential. There are a huge number of Web experiences that are vertical (go to a Web page to experience) as well as horizontal (having a favourite mapping service). The browser itself can add hooks (e.g. map: hooks into GMaps or Ovi Maps or MapQuest or …), but the browser is always behind the times. We can allow extensions to do this work. We can install a local library “web app” that means that wherever you see book information (e.g. Amazon, BN) you also get info about whether the book is available at the library. Right in the page.

I hope that the Chrome Web App store doesn’t become just wrapped Web pages, but we move the state of the art and break out of the silo.

NOTE: These are my random thoughts on Web App Stores and do not necessarily reflect the thoughts of Palm. Don’t read anything into this :)

App Stores. Catalogs. Markets. Gardens. They have been an incredibly hot topic ever since the success of the iPhone App Store. Everyone has wanted to own and control an app store ever since, for many different reasons. Not all of them are good. Not all of them can extract from the App Store experience.

With that, today Google unveiled a Chrome Web Store. Many folks have talked about how the Web, and the Open Web, could benefit from an app store. At a high level, the Web should give developers great options to distribute and monetize (if they so wish) their products, projects, and abilities.

There was a phase where people assumed that Internet meant “everything would be driven to be ‘free’”, and the model to make money is ads. Ads can potentially be a great avenue depending on your product, but people have always been willing to part with money to get value (or perceived value) back… and it shouldn’t be too shocking to have see that play out again via app stores. Deliver great experiences and they may come. There is a lot to be said about “expectations” though, and I feel for some of the business models that are in trouble (media etc).

So, it would be nice if a developer could build something useful, stick a price tag on it, and sell it… using great distribution channels. One model for this is to package the application in a way that works in the distribution channels (e.g. PhoneGap, Titanium, or for us on webOS…. natively) but surely we can do better?

When you look at what an app store is, it consists of many pieces indeed.

For example,

Application Platform

This is the set of APIs and technology that you can use to build your applications. We feel strongly that having many fragmented devices with their own set of APIs, and thus their own platform, is a path to madness. To fix that, we need a unifying platform. We could unify on a proprietary platform (e.g. Flash, Cocoa, Silverlight/.NET, or what have you) or we could learn from history and honour the very lucky place that are in as an industry, and choose Open standards… and in concrete, the Web.

The Chrome Web Store very much honours this. Their apps are just Web apps. This is fantastic and a big step forward. The fact that you could take the same codebase and ship it in a store that runs in Chrome and other browsers (and web OS’s :) is great news.

But this is only one level of the stack.

Application Packaging

How do you package up your application to place in a store? Chrome has a prelim crack at this with their crx format that we have seen via Chrome Extensions. There are also others:

W3C widgets, Android, webOS, Nokia WRT, and more. Libraries like PhoneGap already have to deal with this world. We need scripts and tools to navigate this world. In the short term lets create and use those tools, but how about all getting together and making a format that we can all live with and extend in the right ways?

Distribution

How do you distribute your apps? Right now you either: a) put up a website and folks find you (via search {and thus SEO}, the social web, and links), b) put an application into a store itself.

The Web won on distribution. AOL couldn’t hold back the tide. Everything was Out There. Do we really want one or two companies in charge of what gets Out There? There is certainly value to curation, and finding applications via places you trust, but I personally want to see us solve the problem is a distributed open way. No entity should own the pipe. There should be no “right way” to censor or review applications. Different systems can choose values. Ideally they are transparent, and consumers can then choose where they want to look for the app content.

Discoverability

If we had a standard format for “installable web apps” a lot of good can happen. If we had a standard format, we could annotate the Web with it. Browsers could consume it (e.g. App Discover and the talk on just this.) and search engines could index it.

If I am on a Web site that has an application available, the browser should let me know. If I do a Google search, a one box should tell me about the matching apps for the platforms that I care about.

Anyone could create a merchandising experience and have access to apps to search for. We can go beyond that too of course. We can have web hooks that ping services with information about applications that have been created. A meta service would crop up that looks for the data and then pings the various Web app stores, just like we saw with trackbacks and the like.

There is still a ton of room to innovate in discoverability. Smarter searching that ties deeper than matching on the content will kick in.

Merchandising

Having access to the application data is important. The Palm ecosystem shares full feeds of the data from the catalog and this allows anyone to merchandize the content. They can be creative and present the right content to the user. There is a lot of innovation to be done here. Ideally, someone could create a great new social algorithm and have it run against all of the web apps out there. Right now, the stack is monolithic and we only have basic merchandising needs in most of the ecosystems. What about affiliate systems and the like which could enable innovation here?

Fulfillment

How do you pay for a good. How does the developer get paid for the good. This is an obviously crucial layer. Apple has done very well because people already had iTunes accounts coming into the world of the iPhone. In a distributed model, users could choose to fulfill via Amazon, or Paypal, or Checkout, or SimpleBank (one day right al3x? :)

And more….

We haven’t even gotten into identity, single sign-on, reputation systems, and how reviews can be shared on the same applications in different stores. There is so much to be done here.

Looking forward, where does this next step take us? Is there a path where web applications themselves are back to just being websites that can live in various stores, and a pay gate can be setup in an easy way?

I can’t wait to see how this plays out. We could all go off and build ivory towered app stores, or we could come together and work out a better way. Are you in?

Ben and I gave a keynote at the Palm Developer Day where we set up the event, and also shared some of the technology that we are working on for developers. There are a lot of fun APIs, such as:

• Accelerated CSS transforms and animations
• JavaScript Services: You have always been able to publish messages to the Palm service bus (e.g. launch an application) but how about being able to subscribe and run code on the flip side? You will be able to do just that with JavaScript Services. You will get access to a slew of libraries in that world (your own process too!):
  • Background asynchronous services
  • File I/O
  • Binary JavaScript types
  • Low-level network I/O
  • “Medium-level” HTTP via CURL
  • Fast XML streaming parser
• db8: what if you had access to a fantastic performant native JSON store? That is where db8 comes in, our new open source JSON datastore that includes:
  • Native JSON storage with query mechanism
  • Built-in primitives for easy cloud syncing (Easily query changed / deleted data, Designed to sync with CouchDB in the cloud)
  • Fine-grained access control for apps
  • Mobile-optimized and fast (especially for updates)
  • Pluggable back-end
• Audio / Video Recording
• Media Indexer Access
• Secure Key Manager + Crypto Libs
• Bluetooth SPP
• Bonjour / Zeroconf

We just had fun doing a podcast on this and more. Join us as we go through the tech, and we also hope you enjoy the sales pitch at the 41 minute mark (not what you may think ;)

I got my Mum an iPad. I wanted to get one for her more than me (even though I got one too of cos ;) as it seemed like a perfect tool for her to consume content. Finally, I get to hand her something that won’t just break. She doesn’t need to be scared to use the device. One button. So much simpler for her than a normal computer.

She has loved it. My Dad has told me that she is always on it. This week she flew in and stayed with us, and I got to watch her use it first hand, and it was fascinating.

I had my brother setup the device for her first time around. He installed a bunch of apps, and must have shown her how to add a bookmark to the home screen. I say this, because when I asked her whether she had the Foo app, and she said “Yup, here it is.” However, it wasn’t that app at all, but rather foo.com saved onto the home screen. She had no idea that there was a difference! Now, I personally believe that the world of URLs on the device vs. apps should entirely blur…. but it already had to her! I then had to show her the “App Store” and how to install apps.

This is when I learned how poor the UX is for downloading and installing apps. I have thought this before, but didn’t realise how bad it truly is until I watched my Mum.

She had NO idea how to install an app. She could find them, but couldn’t install them. It turns out that the UI for doing an install is incredibly poor. You have to know to tap on a small [FREE] or [$1.99] button which then turns into the [INSTALL] button. It is small, and not obvious at all. I wonder why Apple hasn’t noticed this and made a more obvious [TAP HERE TO INSTALL THE APP] flashing green button?

This is bad on the iPhone:

But with large real estate on the iPad, it is really hard to find:

It is also hilarious when you see someone struggling on what to do with a device that has ONE button. I love you Mum. Thanks for letting me see a UI through different eyes this week. I hope you continue to enjoy the iPad!

As webOS grows up, developers learn more about the platform, and together we build commonality into our apps. I have talked about various gestures and practices that are both built in, and have emerged.

I have seen some very interesting advanced uses of our notification system recently and wanted to share.

First up is birdwatch a “background app” that polls your Twitter account and when new tweets come along, they are shown in a dashboard component at the bottom of the screen. You can simply tap that area to move through your tweets. Very nice indeed, and something I would love to see in our email client, and in the Facebook app. The feature has been added to our list.

It is a great and simple example of how you don’t need a full app for every use case, and remember: those areas are DOM windows too so you can make them do a lot! We have seen other core examples such as the media player controls, and I also look forward to seeing the Facebook app be able to accept/deny friend requests right there. What would your users want to do rather than be sent into the main app indeed? That is the question.

Then we have Jot It, a note taking application. What makes it different is again in the dashboard area. When the dashboard is activated you see a bottom UI bar that gives you quick access to your documents. A creative way to add the UI.

It does have issues, in that you only really want this if you REALLY care about notes :)

Back to Twitter. I have really been enjoying Tweet Me a new application that just got released into the catalog today.

One feature that fits into the notifications meme is the banner notification UX flow. If you type in a tweet and back gesture away instead of a dialog “are you SURE you want to leave that info?” the app does something very nice indeed. It saves a draft AND gives you the option to delete that draft right in the banner. It’s a small thing… but one of those touches that shows that the developer really sweats the small stuff.

I am really excited about this application in general. It is beautiful and really showcases how webOS apps can be gorgeous. The technology is there, and this app raises the bar for all webOS applications.

Check out the splash screen, the favorite tweet star animation, picture thumbnails and more. Take a quick look at the flow below:

Man, we have an amazing set of Twitter apps now. They each have their own feel and niche too. Bad Kitty is fantastic. And then there are Tweed and Twee and Spaz (fully open source) ….. the list keeps growing. A strong bench.

What other mobile apps are inspiring to you? Other practices?

In my feeling touch-y post on some of the fun usability issues and opportunities, I touched on shortcut keys.

As I have continued to learn more about the webOS platform, one of the biggest changes for me has been knowing that a physical keyboard is available.

This is why we put in shortcut keys for the Facebook app. I can now very easily jump to an area of the application by touching the gesture area and pushing a key. I would love to see shortcuts available in many other webOS apps, and a “GreaseyPalm” (greasemonkey type system on webOS) would be awesome… enabling me to easily tie my own in… but that is another story :)

Other than shortcut keys though, I have found more and more applications using the “Just Type” metaphor. It turns out that many apps can be smart about what a user would want to do if they just type.

We implemented this on the Facebook app. If you are on the news feed and you start to type, assume that this is a status update, pull up that UI and put the content in there.

Bad Kitty and other Twitter clients do a similar thing for assuming that you want to Tweet something.

My favourite example is in the core launcher itself. I remember being incredibly frustrated with home screen layout on the iPhone, and on webOS at first. Having to move icons around on the phone is a pain. I was excited when they added the ability to manage apps in iTunes, but the UI manages to be just about as frustrating in there.

It took me awhile to realise that I don’t need to use the launcher in this way at all. I can just type, and it will find the app I want. Hmm, where have I seen this before? Quicksilver! Ubiquity! Those examples go even further and offer actions that are even pluggable and scriptable… which would be awesome on a mobile device too.

This is yet another item on my checklist when I build an app. If the user started to type right now, could I do something smart that just works?

Just Type. Check!

Implementing Keyboard Shortcuts

A few folks asked about keyboard shortcuts. To implement them a la Facebook, you simply use the shortcut attribute for actions in the

        var appMenuModel = {
            items: [Mojo.Menu.editItem, {
                label: $L("Preferences & Accounts"),
                command: Mojo.Menu.prefsCmd
            },
            {
                label: $L("Navigate to..."),
                items: [
                {
                    label: $L("News Feed"),
                    command: "gotoNewsFeed",
                    shortcut: 'h' // H = home
                },
                // ...
                ]
            }
         }