Jan 02

The rise and fall of webOS is an epic tale; webOS != Web OS

webOS 12 Comments »

“WebKit remains not ready for prime time, because the Web cannot deliver yet.”

– Paul Mercer, creator of a non-Web OS

There has been a lot of chatter over the article on the HP Touchpad flop, which conflates success of the Touchpad with the success of webOS and even gets into anti-Web territory.

I do think that the HP Touchpad was doomed, mainly due to how it was released before ready, with the hardware of an iPad 1. It wasn’t fair.

The sad thing is that there is a great story behind the rise and fall of Palm (and webOS). I wasn’t there for all of it, but learned a lot from stories… and my time in the belly of the beast. Palm was a juxtaposition for me. On the one hand I met phenomenal engineers. They were hard working (working all hours of the day for my entire time there, and I know beyond), and cared a lot. Many of them came from Apple, and other great companies. Some folks are posting that Palm should have hired better caliber engineers, and that is just wrong….there were plenty there. The fact that they shipped webOS in the timeline that they did amazes me. The other side of the coin is one of dysfunction throughout the company. Going up against iOS (and later Android) was a tough proposition, but I really think that we coulda been a contender, and we shot ourselves in the foot time and time again.

The New York Times article quotes Paul Mercer heavily. It is important to know where those quotes are coming from. Paul is a technologist who left Apple to create the Pixo OS (which sold to Sun) and later created technology that Palm acquired. This was not webOS as you know it. It was a Java based operating system (hand written JVM!) with a proprietary XML dialect for layout. Does that sound familiar? (I have seen Paul and Andy Rubin together in Los Altos many a time :) Can you imagine if Palm came out with a new OS that was basically Android, but not Android? It would have flopped. Instead, imagine a brave engineer hacking WebKit as the head to the system…. and suddenly you have webOS. There was a reason that people were excited when Palm announced webOS. The user experience was superior to iOS of the time in many ways (cards, network sync, multi-tasking, etc). For developers, especially Web developers, in theory they could write web apps that would live in this beautiful UI.

In practice, I admit that there were real issues. webOS 1.0 was more like a beta. Timing required that it just had to ship, but the performance wasn’t there and it was buggy. The article also mentions the return issues on the hardware. If you think about it, this is beyond a bummer. Apple has their own stores that customers can’t wait to go to. When you walk in, the experience is all Apple, and you will walk out with some of their product. Contrast that to where webOS devices were. I don’t know about you, but I never enjoy walking into carrier stores, and even in retail venues such as a Best Buy…. you are surrounded by competitors product. If the sales force sees a large return rate, they will push people to buy something else. I remember going into Sprint stores asking for a Palm Pre and being told “hey, get a Blackberry instead!” That was an immediate “uh oh” moment for me. The sales channel was poisoned. Doom.

With the early webOS releases, there were scrambles to fix issues on software and hardware, and then a classic second system syndrome kicked in. Many shortcuts were in place, so people wanted to go in and fix those problems and “build it right”. There were some real core architectural issues to be fixed here too (no sandboxing of apps so any bad code could mess up any other bad code, a lesson not learned from Pixo) and “fixing” these in a performant way is far from trivial! Needless to say, webOS 2.0 came waaaay too late and didn’t fix the core performance problems. In hindsight it would have been much better to have had a performance tzar who had people sitting with profilers open and fixing the darn problems.

The structure of the teams was also wrong in my opinion. App teams ran all the way up and down the stack, and there was no real platform. At one point there was a VP of Developer Platform that didn’t have direct reports that mapped to the platform itself!

So, there were a ton of core issues, from market timing to executive decisions etc… but none of these meant that the Web wasn’t up to the task.

Brendan Eich mentioned that B2G already has 60Hz flicker/tear-free panning/zooming using HTML/JS/WebGL. and that isn’t on bleeding edge devices. It is hard work to pull this off. Apple has a core system that is optimized for this, and they have to work their arses off to keep it solid (I am sure), and Android still has a ton of issues here, even with dual-core systems. It is naive to think “all you need is GPU acceleration!” and that there are other silver bullets. Blood, sweat, and tears is still needed. When you have a GPU in the mix, you have to worry about moving data between CPU and GPU… and using both in an optimized way. iOS views map nicely to GPU textures which is great, and can help a lot at the architecture level. Another great example is Kinoma. This crew came from the Quicktime and Carbon teams of Apple. Check out their demos and then think to yourself…. this is all done in software. Videos playback beautifully and when you minimize them they keep playing as their shrink into the icon location. Amazing. Again…. blood, sweat, and tears… on low end devices.

Don’t get me wrong. A Web runtime is a tough proposition. The Web wasn’t built to be an app platform, but its evolution is fast. Core platforms such as WebKit, and V8…. with standards such as WebGL and hardware accelerated graphics, make it better than ever to pull this off. But those who poo-poo the Web as “just a document platform” miss the great things about the Web. This is where webOS missed out. It was a Mojo platform more than it was a Web platform. We tried to change that and get functionality into the Web platform layer rather that in the “user land” of Mojo.

If we brought a true, reliable, performant, Web platform with the great UI of Matias and friends…. webOS wouldn’t be in the hands of Meg right now.

Great engineers, such as the Enyo team, keep the torch alive. Being able to create an Enyo+PhoneGap application that can deploy to iOS and Android as well as webOS is key. I keep harping on PhoneGap Plugins as a way to get into the land of native when needed… and it *is* needed. Android WebKit and even iOS WebKit are not there yet. At Walmart we build native+Web hybrid applications for a reason, but in my heart I long for someone to come along with a true Web runtime that lets developers write to a standards-based multi-vendor platform that no one company owns. Democracy is messy, but the Open Web is worth it. Don’t read one article and think that it can’t be done.

We often love to focus on the mistakes. The things that “went wrong”, but there is a lot that went right too. To truly learn from the rise and fall, it is important to know both sides.

Aug 21

Facebook webOS; Playing to Win

Mobile, Palm, webOS 2 Comments »

I have been taking in the news and constant amazement as the “HP webOS” situation changes in front of my eyes. A month ago we had folks from HP saying that we are staying the course and great devices are coming soon, and now we have utter chaos. I don’t know what HP’s plan was, but man…. surely it wasn’t to be executed as badly as this.

I feel so bad for the webOS userbase, developer base, and employee base. They have been left in the lurch again. Shocking, really.

It has made me look back at my own career and think about the good times and the bad. As I reflect on my experiences, I definitely see a trend. I have felt the most frustrated when I know that we didn’t “play to win” and were too conservative. My successes have come from projects and products that had a strong vision and we went all out for it. The funny thing there is, even if the outcome wasn’t a home run, great things came out of it.

I don’t think that either Palm or HP were anywhere near aggressive enough, and I can look back at early meetings that Ben and I had with folks where big ideas were shot down for being too risky. Many of the folks at the top wanted to be another Apple, and you can’t fight that war. Android has been so successful through a) hard work by engineers and b) a disruptive and very different business model. Java is yesterdays technology though, and if we saw webOS at Google I think that Android would have been even more than it is today. The interaction model is vastly superior. This doesn’t mean that the user experience is superior. I can’t say that is the case because webOS hasn’t performed well enough. It has been too slow and buggy, and it pains me to say that. webOS 2.0 was a case of second system syndrome to the extreme, and if we had instead had folks sitting in a darn profiler, we would have ended up at a much better spot.

I think that the only real hope for webOS is not for an HTC to come along and make some hardware for it. It needs an owner that cares and will push the hell out of it. The only owner that I really see is Facebook of all people. They very much have a culture of playing to win, they are making large bets on the Web. They need to do so, as the last thing they want is for an iOS/Android duopoly surrounding them.

They could take webOS and do some very interesting things with it. Imagine an open source webOS that could run on top of Android (hint: I may have seen this before). This way, your system can be installed by the Android user base, and Android apps can even run on it. They may not run perfectly, but who cares…. you get access to that application base and you can kill the “number of apps” arguments.

Why stop there? You can run webOS a la iCloud, but even more so. The entire experience is in the cloud, and the synergy concept can now truly go where ever you want, even onto iOS and Android. The core WebKit platform could join the PhoneGap project. Now the Web gets a massive boost. Instead of waiting for the Web features to trickle into the Android and iOS WebKit implementations, we could rally behind a WebKit (or Gecko if they work with Moz!) platform that you can target on any platform. Chrome Frame for Mobile. We need it to compete.

There are some great engineers who (very kindly imo) stuck it out for love of the platform and their teams. However, many great ones have left too. So, whoever comes in needs to rebuild the team.

It is hard for HP to come in and recruit talent, especially now, but Facebook? If they step up to the plate with a killer vision and stock options to boot…. wow. I can see the team now. It is amazing. It has many WebKit engineers (which are much much needed). If I was a college for computer science I would be spending as much time with the WebKit code as possible :)

It would be a crazy big bet for Facebook, but they have the funds and cojones to pull it off. As great as the Web is, it needs a lot of help on mobile devices. iOS is fantastic and has a great mix of a high level language in Objective-C with a fast low level runtime (especially with ARC). The Web is a very forward looking solution. We need a lot of engineers to keep accelerating it, but that is happening. The JavaScript runtimes are on an amazing streak. We are getting better and better graphics and low level APIs made available.

Man, I would love to see someone really give it a shot, and go for broke. HP’s fire sale will get some users in the field, so someone can swoop in and take advantage of it.

Facebook actually has a fair few engineers and execs from Palm over there, and what about Amazon? They have made a big bet on Android, and are going gangbusters on being the company that makes money off of Android. However, if they went webOS on top of Android? Oh, and Jon Rubenstein is on the board of Amazon (which always seemed a bit weird to me!) Maybe Amazon and HP could at least be good partners.

Nov 21

Enyo shows us a some skin; Sneak peak at a fantastic new mobile Web Touch framework

Mobile, Tech, Web Frameworks, webOS 2 Comments »

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.

Oct 22

Setting our own Direction; Ben and I to move on from Palm

Palm, Tech, webOS 14 Comments »

set direction

When we joined Palm, we were excited to join the intersection of mobile and Web. It has been fascinating to see how that seam has grown over a very short period of time. The device landscape has exploded and developers have amazing new hardware to target. webOS embodies the spirit of joining Web and mobile and we have enjoyed growing the developer community but with its new home at HP we thought it was time for us to move on and allow their resources to take things to the next level. As Ben mentions on his own reflection, it is bittersweet to leave, and I really want to thank Palm, HP, and the webOS community that have embraced us and the platform. I also want to give a massive thanks to: a) the amazing engineers who developed webOS, b) the developer relations team that care so much about our developers, and of course c) the developers who created great experiences on webOS. I wish everyone the best, and as we mention on our post on the Palm Developer Blog, we look forward to continued involvement with the community in our new role as consultants.

What’s next? I have enjoyed time at large companies and small, and there are pros and cons to both environments, but it is time for me to swing back to “small”. I wrote about how the culture of joining companies after an interview is akin to marriage after the first date, so I am not looking to dance down the aisle just yet, no matter how pretty the bride is ;).

Instead, I am incredibly excited to start a new venture with my long time co-hort, and best mate, Ben Galbraith. We have learned a lot about the trials and tribulations of being a developer for the mobile Web, and have some ideas on how we can help people create compelling experiences using HTML5 and related technologies in a highly productive manner. We care passionately about developer community, and are interested in helping companies understand and do the right thing by developers. Finally, we are makers, and have some ideas of great products to build. We look forward, as is our DNA, to share the journey and experience as we strive to build great software.

Industry cross roads

Scott Rosenberg posted on the Web parenthesis and questions whether the Open Web is closing. We are so lucky to be in a position where a massive global platform is Open. If you look at our history with mainframes, PCs, and gaming consoles, they have all be closed proprietary systems. As developers we have been beholden to the vendors. When we are both aligned, things can work out, but as soon as the company has a change in strategy and we misalign, developers are often left by the wayside. This mirrors the world of dictatorships. If you could guarantee your dictator is fully aligned with you there is a good chance that the system will be far more efficient than a democracy. History has taught us though that 99.9% of the time this isn’t the case. The Open Web gives us an escape valve. It has its own problems and complexities (just as democracy), but that is all critically worth it.

Being “open” isn’t enough, and we need to have a platform that works for developers. We need to be able to make money. We need to be able to create amazing experiences for our users. The Web has a huge new challenge vis a vie the “app economies” out there, but it behooves us to all push the Web forward and make it work for us.

The Web has the opportunity to be THE unifying platform that can give us the best opportunities.

It is going to be an exciting and important few years. Now is the time to endeavor to help set some direction in the industry. I hope we can have an impact in our own small way.

Oct 19

The Palm Pre 2 Developer Phone

Tech, webOS No Comments »

Palm Pre 2

“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.

Aug 31

Node is our turtle shell; Node.js now powers services on webOS

JavaScript, Mobile, Open Source, Palm, Tech, webOS with tags: 3 Comments »

ryannode

At our last Palm Developer Day, Ben and I discussed future APIs for webOS including “JavaScript services” as a way to write code that runs on the other side of the device service bus using JavaScript.

If you think about it, node delivers a services platform for the cloud, so is there a way that we could work together? We got together with Ryan Dahl of Node to try this out, and it turns out that node works fantastically well on a mobile device! Major kudos should go to the V8 team for creating a great VM and to Ryan for writing efficient code that scaled down from the cloud to the device.

Today we announce that node is part of webOS 2.0:

The popular Node.js runtime environment is built into webOS 2.0, which means that you can now develop not just webOS apps but also services in JavaScript. The active Node ecosystem is on hand to provide community support and a rapidly growing library of modules that you can use in your webOS services.

Besides powering the new Synergy APIs, JavaScript services strengthen webOS’s support for background processing and add new capabilities—like low-level networking, file system access, and binary data processing—to the web technology stack.

I am really excited about this move for us. The node community is top class. I get to see this time and time again, most recently over the weekend and this week as I judge the node knockout. There is magic in the air with Node. It feels like the Rails days. I remember being so happy to jump to Rails and get away from the heavy world of Enterprise Java. It was a breath of fresh air to not have to argue with folks about every piece of the stack. “What about JSF with HiveMind and Commons-Logging and ….” Argh! Too. Much. Choice. And, a logging abstraction above Log4J was hilarious :)

Node is low level, yet simple. It is more like Sinatra than Rails. The event-based opinions keep you in good stead, and with cloud solutions such as Heroku and no.de you have great deployment stories, unlike Rails back in the day.

If you check out the modules that are growing daily, and the fun real-time hacks from the knockout you will get a good feel for node.

It feels great to have webOS as the first mobile device that embeds node. With db8 we offer a JSON store than can sync to the cloud (e.g. sync with CouchDB). This stack is starting to look pretty great.

Jun 02

Will we feel like stick shift drivers? The potential shift in the OS marketplace

Apple, Comic, Tech, Web Browsing, webOS 1 Comment »

stickinthemud

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.

stickshift

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:

bbcname

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:

speedtest

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?

May 15

Palm Developer Day: Walking through the announcements in our keynote

Palm, Tech, webOS 2 Comments »

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 ;)

Apr 30

More mobile UX; The power of dashboards, notifications and raw beauty

Mobile, Tech, webOS 3 Comments »

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.

birdwatch

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.

jotit

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 :)

tweetme

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?

Apr 28

Just Type. One of my favourite platform metaphors.

Mobile, Tech, UI / UX, webOS 7 Comments »

type

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.

gesture-facebook

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.

justtype-facebook

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.

justtype-badkitty

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

justtype-launch

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
                },
                // ...
                ]
            }
         }