This last week included an unexpected high, and a pretty dismal low.

On Thursday, HP released a free promo code for TapNote. In a matter of hours, my userbase had increased roughly 600%. This was a completely unexpected windfall (the first I heard of the promo was a user emailing me to ask about it), and if all those people enjoy TapNote and tell their friends, could provide some nice long-term benefits to the app. It was also a nice bit of validation for the time that I’ve been continuing to dedicate to the platform.

And then on Saturday, my partner’s grandfather unexpectedly died. It was quite a shocker, because in the flurry of the moment everyone forgot to mention that he had passed away (last we heard before heading down to the hospital was that he was in the ER and being transferred to a room), so we showed up at the hospital, were told, “He’s in the room down the hall if you would like to see him”, and walked in to find little but an earthly shell.

Although I didn’t know my partner’s grandfather very well, her family’s grief and shock resonated strongly thanks to the recent death of my own grandfather, who died suddenly in mid-July.

My partner’s family is sure to be telling lots of stories as they work through their own loss, and for that I can but listen. However, there is a story I have been meaning to tell about my own grandfather that I wasn’t able to adequately formulate when I first lost him, and the events of yesterday once more brought it to mind.

Love is a little red playhouse

People claim that grandparents don’t have favorite grandchildren, but what do they know? I was this close to being my grandfather’s favorite when I was young. But then I totally blew it.

My grandfather spent most of his working life as a Boeing engineer, and although he never said it out loud it was pretty clear that he hoped his grandchildren would discover the joys of science and engineering.

So when I took a class on technical drawing in junior high in order to fulfill one of my art requirements, Grandpa immediately sent me a T-square, a miniature draft table, and come Christmas several years worth of subscription to a magazine called Invention & Technology, whose topic matter was about what you’d expect.

But I hated drafting. Drawing precise diagrams of simplistic machines was fantastically boring and I didn’t care to develop the spatial reasoning necessary to get absorbed in considering an object from all sides at once. And even though I had never heard of CAD software at that point, I still had the sneaking suspicion that the whole exercise was outdated.

As a result, the T-square and drafting table went in my closet to gather dust at the end of the class, and I forfeited the standing of favorite grandchild before I realized it could be mine.

I don’t mind. Because although I never found much to engage me in the lackluster science courses offered by the local public schools, Grandpa ended up teaching me something more important.

For me, childhood and my grandfather are inextricably intertwined. One of my earliest memories is of jumping in rain puddles wearing one of the bright red Gore-Tex jackets that Grandpa would make yearly for his ever-growing grandchildren. If you are not familiar with Gore-Tex, it is the only fabric I know of that is truly waterproof. Unlike the “water resistant” junk that stores sell that bleeds through in a matter of minutes under any decent downpour, Grandpa’s jackets would keep use completely dry for as long as we cared to stay out in the rain, snow, or whatever other inclement weather the Pacific Northwest cared to throw at us.

Other early memories: playing with my sisters in the little red playhouse that Grandpa constructed in our back yard (complete with a shuttered bell-tower), rocking on the hand-made wooden rocking horse he made for us, exploring the intricate dollhouse (including room-by-room electric lighting) that he constructed for my sisters, climbing around in the treehouse he built in his backyard, swinging on the attached swingset, and at the end of just about all of those activities taking a trip with him down to the local German bakery where they served maple bars that were literally as long as my forearm.

The playhouse, under construction

Grandpa was not a verbally demonstrative man. I don’t think I can ever remember hearing him tell someone he loved them.

For Grandpa, love was a little red playhouse. It was careful design, hours of labor, and the reward was years of laughter and fun.

Which is why I find such joy in creating things, be they websites or apps or other. Which is why I bake things. Which is why I always find time to help the people I love in areas I have expertise even if, like my grandfather, I sometimes find it hard to tell them outright that I love them.

I miss you, Grandpa.

Yesterday HP dropped a bombshell on the webOS community when they announced that they are discontinuing all of their webOS hardware (phones and TouchPad), and have no plans in place to take the operating system forward.

Honestly, I am still a little bit in shock over this. The timing of the announcement bewilders me (the TouchPad has been out less than two months, and the Pre3 was right around the corner), and I completely failed to see it coming. I knew that the TouchPad was not selling vast quantities, but my sales have been constantly rising since the TouchPad came out and my outlook for the platform was hopeful. I have been re-investing my profits from TapNote development back into TapNote—my secondary TouchPad for development arrived the day before yesterday—and my goals and plans for the app all revolved around incremental improvements leading to long-term growth.

Now my investments both of time and money are looking like very poor choices indeed. Best case scenario, I will likely continue to make diminishing profits in the short term as people who just adopted HP hardware continue to use it (those who do not return it to the store outright, that is). However, without hardware there is virtually no possibility for growth (the aftermarket for super-cheap TouchPads that will doubtless flourish short-term is unlikely to be a market of people interested in buying $5 apps), and judging by HP’s scattered and doublespeak-laden announcements yesterday it does not seem likely that they have anything concrete lined up as far as licensing deals. Their whole philosophy with webOS seems to have been “if we build it, they will come” (both for developers and users), and now they seem to have switched to “if we kill it, they will come” (for licensors). Needless to say, outside the cinema this strategy is typically not a good one.

This means months without hardware on the market as webOS becomes increasingly irrelevant. Assuming HP is successful in licensing webOS fairly quickly, we will still have to wait for that hardware to be released and any of us third party devs remaining loyal to the platform will doubtless have to revise our apps yet again to get them to run properly on a new aspect ratio, screen size, etc.

All of which offers very little in the way of incentive for a third party developer on the platform. My justifications for TapNote’s historical lack of profitability were that I was a) scratching my own itch, and b) investing in a platform that I foresaw growing. I’d thought this was paying off; being one of the few quality note-taking apps on the platform on launch day has certainly helped TapNote on the TouchPad. HP evidently saw things differently; Jon Rubinstein’s “marathon not a sprint” memo was evidently sent to the wrong people.

Looking forward

Where do I go from here? Honestly, I am still not completely sure. The webOS developer relations folks basically went dark yesterday as soon as the announcement hit, and I am still waiting to hear what their spin on the issue is. Richard Kerris (head of that department) has been posting ridiculously rose-colored-glass tweets, presumably trying to limit the damage caused by his superiors, but other than that no official statement or recommendation for third party devs has yet to arrive. So I am not going to make any final strategic decisions just yet.

What I do know is that I will personally continue to use and love my existing webOS hardware. Nothing has changed from my original glowing TouchPad review except that I am now extremely disillusioned with HP’s upper management and a bit more pessimistic about the long-term chances of the platform.

Development-wise, there will not be any significant updates to TapNote in the short term, but I will continue to support it. If you find bugs, I want to hear about them and I will help you find workaroudns or fix them myself. If you have feature requests, I’d love to hear those, too, although I can’t make any promises about if or when I’ll be able to act on them.

If any Pre3’s make it out into the wild, I will submit the update that I’ve been working on with full compatibility for its new size. I was originally planning to include a new theme for the TouchPad version in that update (and possibly filtering by document titles, to bring it up to feature parity with the phone version), and I will likely still release those improvements although on a much less urgent release cycle.

As with the fiasco of publishing a single package with support for multiple devices, my priorities are firmly on doing right by my existing userbase, even if HP upper management has once again shown utter contempt for that value.

Further down the road than that, I am not yet sure. I’ve poured most of my free time for over a year into TapNote, and if webOS does indeed fade into obscurity I would hate to see that just die. I am currently thinking of ways to keep TapNote relevant without needing to rely anymore on HP. However, this is also an excellent opportunity to refocus my priorities and get back into writing novels. I’d dearly love to be published (in some form) before I’m thirty, and app development has badly distracted me from that goal.

I hope webOS doesn’t die because I dearly love using and developing for it, but with such a bungled, rushed announcement on the part of HP I am not optimistic about its long-term chances. I have lost a lot of trust in HP’s decision-making process. Both Palm and HP have had fantastic developer relations and engineering/design departments whose efforts are routinely sabotaged by mismanagement and poor decisions from higher up the chain of command.

We shall see how things play out; I will certainly keep you updated about my plans as I continue to try and make sense of the mess that HP has left its third party developers and developer relations team to deal with.

(Fair warning: this is only going to be interesting if you are a TapNote user who is interested in Box.net synching.)

I’ve had a fair number of people recently suggesting that I implement Box.net synching for TapNote. This has come up because Box.net is offering 50 free GB of space for anyone opening an account on a TouchPad (which is a good deal; normally would cost $20/month for that storage upgrade).

Despite popular demand, I will not be adding Box.net synching to TapNote. I have considered Box.net integration twice (once when I was initially researching sync options, and more closely when I heard about the 50 GB free deal), but it remains a less attractive option than Dropbox for several reasons.

First and foremost, although Box.net is superficially a Dropbox competitor, if you look closer its free plan does not offer feature parity. In particular, all “personal” plans fail to automatically sync files to your computer. This is a non-negotiable feature for me, both as a user and a developer. Dropbox is nowhere near perfect (topic for another time), but their desktop sync is instant, a true sync (so if you lose network connectivity, you still have normal access to all your documents), and so easy that when I told a non-tech-savvy relative that my app leverages Dropbox they said, “Oh, yeah, Dropbox. I love Dropbox.” This officially makes Dropbox the first web service that I didn’t need to explain in detail before they would be even willing to try it.

Which leads us to point the second: Dropbox is ubiquitous. You can access Dropbox from just about any computer or device, and a lot of people already have a Dropbox account (to the tune of 25 million plus, if memory serves). You don’t need Dropbox to enjoy TapNote, but for a lot of people hooking the two up is a no-brainer because they do not need to register; Dropbox is already part of their day-to-day life.

Third, in my trial runs Box.net was overall less easy to use than Dropbox. Dropbox is setup to be dead simple for everyday folks, because they are the service’s bread and butter. Box.net, on the other hand, is targeted primarily toward businesses. There is nothing wrong with business-centric apps, of course. But that focus does not jibe well with TapNote, where I am courting everyday individuals rather than corporate sales.

Fourth, I have limited time to spend on TapNote. WebOS app development does not generate nearly enough money for me to do it full time, so app development is relegated to my time outside of my day job. Implementing Dropbox sync took me over nine months, and even then I had to compromise on my ideal vision. Replacing the sync would likely dominate development time for a half year or more. This is personally abhorrent to me, and the happiness I would gain from some users for Box.net support would not remotely outweight the unhappiness all my users would feel if months go by without an update.

Fifth…but at this point your eyes have glazed over, haven’t they?

But wait! What about [XYZ]?

To hopefully nip some further arguments and rebuttals for Box.net integration in the bud:

Mounting Box.net as a WebDAV server in Windows or Mac is certainly possible (here’s how). However, this is not remotely acceptable as an alternate way to access TapNote files easily on your computer because:

• It is not easy. Most users are not going to be willing to go through the rigamarole of connecting manually to a WebDAV server
• It is not sync. You can only access files on a WebDAV server if you have a network connection. With Dropbox, once your files are pulled down, you can take your computer offline and continue to work
• Using mounted WebDAV servers sucks. A lot. Trust me, I’ve been trying to use them on and off for years with Apple’s iDisk. (Fun trivia fact: you know what feature is not being included in the new iCloud service? Yeah, that’s right. iDisk. I leave it to you to wonder why.) Mounted WebDAV servers look like normal folders on your operating system, but feel like high-latency wastes of your time.

Adding Box.net sync as an optional alternative to Dropbox sounds really great, but–lack of development time aside–in practice it increases the complexity and mental cost of using the app far more than justifies the benefit. Consider:

• With two sync services, the sync interface has to offer a way for users to swap between the two. This adds yet another choice the user has to make when enabling sync, which in turn makes it far less likely they will turn sync on at all. Which in turn means if something catastrophic happens to their device, their documents are lost forever. I call it “sync”, but Dropbox integration also serves as a fantastic, multi-location backup.
• Two sync services with two different APIs more than doubles the complexity of maintaining and developing the app, and I become limited by the lowest common denominator between both services. Given that web service APIs tend to change with little warning, it is entirely conceivable that one or both of them could break something and it would take me significantly longer to fix it because I would have to debug any changes across both services. This is a development nightmare, and would very quickly leech all the fun out of app development.

Looking forward

I may reconsider my decision for what sync service to use in TapNote longer term; as I mentioned, Dropbox is certainly not perfect. Short-term, though, Box.net simply is not as compelling an option for TapNote, despite their generosity towards TouchPad owners.

All that said, I would love to continue hearing from users about how well Dropbox sync works for them, and if they have any suggestions for alternatives! Yes, I believe that I know better when it comes to Box.net, but that doesn’t change the fact that I love feedback and have been known to change my mind.

I love my TouchPad. That is the most important thing you should know. It is not without its imperfections, of course. I love it anyway.

Unless you are remarkably similar to me, however, my love of the device will not accurately predict your own. The real story lies in why I love it as much as I do after so short a span of time with it, despite the fact that I typically am unhappy with early adopter technology.

When the iPad came crashing onto the scene and created a new computing market practically overnight, there were two types of reviews: in the first, reviewers dissected, often at great length, the hardware and software ups and downs of the device. In the second, reviewers tried to understand and communicate the emotional ties that they found themselves building with the iPad. The TouchPad takes a lot of cues from the iPad, with its ability to emotionally resonate with users not least. This review, therefore, is of the second type.

Inevitable bias

Everyone is biased, from the professional reviewers who oh-so-dispassionately cover every new gizmo coming down the pipe to gentle readers like yourself. This fact is uninteresting to me. What is interesting is knowing the source of a given person’s bias. Here’s mine:

I develop apps for WebOS (currently TapNote is monopolizing my focus, though I hope to add to my lineup eventually), and have invested quite a lot of time over the past year in learning, supporting, and developing for the platform. Disavowing the TouchPad would be the same as stating that I wasted a lot of my free time for a year (as well as negatively impacting me financially by potentially depressing TapNote sales), so I am primed to like it.

For the source of your own bias, I leave it to you to explore.

On gorillas

You cannot discuss any tablet without mentioning the iPad, so let’s get it over with. Yes, the TouchPad is indebted to the iPad and very similar in many respects (particularly hardware). Every tablet is, even the ones that look very little like the iPad.

This is because the iPad created a new industry and way of thinking about mobile computing. Yes, it was also built on previous creations and ideas, but like Sigmund Freud for psychology, the iPad brought tablet computing to the masses. Love or hate Freud, it is impossible to study psychology without learning about him, because just about every school of psychological thought afterward was either building on his ideas or reacting against them. The iPad is the same.

Unlike most Android tablets, the TouchPad is heavily and explicitly inspired by the iPad. (If you liked the Freud metaphor, one might say that the TouchPad is Carl Jung to the iPad’s Freud.)

In particular, the hardware for the TouchPad is very reminiscent of the iPad, with differences that I leave to you to discover in other reviews. Personally, I think this is a good thing. The iPad nailed a particular size and shape that is very pleasing to use and hold.

The items that are most often cited by other reviewers as detracting from the TouchPad compared to the iPad seem trivial to me. In particular, the extra thickness and weight is very difficult to discern day-to-day. Both devices feel overly heavy to me (I can’t wait for the engineers to figure out ways to miniaturize the components and get the weight down), but unless I were holding both an iPad and a TouchPad at once, I wouldn’t notice the weight difference.

The slight extra width of the TouchPad is also not noticeable unless you are looking at the devices side-by-side, and given that Stephen DeWitt has said that the extra size of the TouchPad is thanks to the hardware that enables inductive charging with a Touchstone dock (if you are a user of Apple devices, you cannot understand how fantastically liberating inductive charging is without trying it for yourself), I am exceedingly happy to love my slightly fatter TouchPad’s form factor regardless of professional reviewer’s iPad comparisons.

Based on my experience, the hardware differences that many people are chatting up as the main reason to avoid the TouchPad seem like things few would notice in the course of everyday use.

It’s worth noting, however, that I am keeping my first tablet, the iPad 1, around. I rarely have the desire to pick up the iPad since getting the TouchPad, but particularly when it comes to games the iOS App Store still trounces the competition. I’ve got to get my occasional Small World or Avadon fix, and the iPad is the only place I can do that (well, I could play Avadon on my computer, but it’s so much better on a tablet).

The distinguishing factor: WebOS

WebOS is the main reason I love the TouchPad as much as I do, because it lets me focus completely on a single task at a time.

If you have read any of HP’s promotional materials (or other reviews mentioning WebOS), you are likely scratching your head right now because multitasking is the word that most often gets bandied around when talking about WebOS. It is the wrong word.

The word everyone is looking for is “multi-apping”.

WebOS does not let you multitask any more than the iPad lets you multitask (frankly, if you want to dilute your focus and work on multiple tasks at once, a computer is the best option). Instead, it lets you very effectively work at a single task because it understands that tasks do not equal apps.

Take, for instance, the simple act of posting a tweet that is inspired by something I read in Instapaper.

1. While in an Instapaper app, I read something that triggers a short thought I would like to share
2. I open a Twitter app, and write my thought down
3. While revising my thought, I realize that it would benefit by a link to an old blog post of mine
4. I open a browser app, navigate to my blog post, and copy the link
5. Back in the Twitter app, I paste the link, post the tweet, and switch back to my Instapaper app to resume reading

Over the course of that task, I needed three apps. The more time and thought I have to spend on the mechanics of switching between those apps, the more distracted I get. By the time I get back to the Instapaper app, I might have completely lost the flow of the article and need to reread back a few paragraphs.

Both iOS (from which I defected in favor of WebOS) and WebOS allow switching between apps during the course of a task, of course, but WebOS requires far less explicit thought (and time spent) on the mechanics of the switch. Swipe up or single tap the home button in WebOS and I have the card view where I can see all of my apps as small, live snapshots. Another swipe and tap, and I am in the app I need. Because WebOS is designed from the ground up to gracefully run multiple apps side-by-side, my thoughts can remain on my task at hand, making me both happier and more productive.

In iOS, by contrast, I have to double tap the home button, search for the app icon that I need in a long list of apps organized based on when I last launched them instead of by task (which, being icons, offer no indication of the state of that app), and rinse and repeat for every switch. This entire system makes it much more difficult to work on any task on iOS that requires multiple apps. Which, for me, is most tasks that I do on a tablet aside from gaming.

Like the multi-apping, there are numerous other features in WebOS that delight me, such as notifications, over-the-air updates, and Synergy. Were the TouchPad running any other operating system, my feelings for it would likely be little more than ambivalent. With WebOS, however, it truly shines.

A life without wires

When I first brought home a WebOS device, turning it on and having all my data (contacts, calendars, etc.) available at my fingertips within minutes was life-altering. I had not realized prior how much effort maintaining Apple device’s dependency on iTunes was requiring of me. I had to remember to sync and charge my device regularly or risk losing data. In order to do this, I had to keep track of cables, remember to plug it into my computer when iTunes was running (or have my workflow badly interrupted when iTunes launched automatically), and wait for it to sync before I could unplug it. With WebOS devices I never have to think about it. My data is automatically synched and backed up to the cloud, and even if I need to charge it I just drop it on the Touchstone inductive charging dock and grab it when I am ready to go.

Thanks to its lack of reliance on wires, the TouchPad is the first truly mobile tablet I have had the pleasure to use. Once you have tasted true wireless computing, there simply is no going back.

Creativity, empowered

It is uniquely human to spend a lot of time thinking about tools. Other animals use tools, of course, but we spend an inordinate amount of our lives imagining, creating, and using them. Even the people I know who are completely uninterested in engineering or programming do this. It seems like everyone has an idea for that one gadget that would make life easier, even if most of us never act on those ideas.

I am no different, except that when it comes to websites (and to a lesser extent software) I am better equipped than many to make my ideas a reality. Prior to WebOS, however, I did not have anywhere I felt I could happily make native apps. Websites are great, but I have never been particularly interested in creating a web app simply because I myself do not like interacting with applications through the frame of a browser. Mac OS, iOS, Android, and Windows are all running on core technologies that I do not particularly enjoy using, have significant learning curves, and would be far more difficult to get noticed on.

WebOS (and particularly the TouchPad) changed all that for me. Here is a full-size computing platform where I can finally make my ideas reality, thanks to so much of the knowledge and so many of the skills that I gained doing web development being directly applicable.

There is something incredibly fulfilling about using something you have created and seeing other people use and enjoy it, as well. Thanks to this, TapNote is a huge contributor to my positive feelings for the TouchPad, both because the app itself is perfectly suited to my needs and because it represents my capability to make my dreams reality.

Of course, this aspect of the TouchPad is not likely to appeal to many casual users, but if you are a web developer who has been dreaming up app ideas, then you need to give some serious thought to WebOS. HP is creating and nurturing something truly great here.

My device is my own

Although I do not make nearly as heavy use of it as some, the WebOS homebrew community is another reason that I love the TouchPad. Using homebrew is similar to jailbreaking an iPhone or rooting an Android device except:

• you can use homebrew and paid apps side by side
• the homebrew community is 100% blessed by HP

When I first got my TouchPad, one of the first apps I downloaded was Paper Mache because I love using tablets for Instapaper. However, the WebOS Browser app does not provide support for Javascript bookmarklets, making it difficult to add URLs from the browser to Instapaper for reading in Paper Mache.

Not a problem with homebrew; the Paper Mache developer released a patch there recently that creates an “Add to Paper Mache” item in the browser’s built-in share menu. Homebrew and the paid App Catalog are often synergistically related.

For those a little more adventurous than I, homebrew also offers overclocking capabilities, extra launcher tabs, themes, and much more. WebOS devices are devices that you can truly make your own, without needing to worry about breaking warranties and so forth.

Apps make or break the experience

If you have read any review of a tablet to date, you know that apps make or break the experience. Everyone has different needs when it comes to apps. I have discussed the TouchPad App Catalog at launch in detail before, but suffice it to say that while the app selection is a lot smaller than other platforms, my core needs are very well covered (the one exception being that I still have not found an RSS reader that makes me happy).

Your mileage will vary, of course, but if you anticipate using a tablet mostly to interact with the web, consume various types of media (audio, video, the written word), and supplant casual computer use, the TouchPad will be an excellent fit (it certainly has been for me). The catalog is still evolving, but the core competencies are there and pretty solid.

I am also highly optimistic about HP’s ability to attract developers. I have been developing for WebOS for over a year now (including back when it was Palm running the show rather than HP), and the developer relations team has always been outstanding. No other mobile platform offers such a great experience for third party developers, HP has been aggressively working to attract even more, and despite some frustrating missteps along the way they are very good about owning their mistakes and making things right. (An excellent recent example was that the sales reporting for many apps was showing up to three times as many sales as their most recent payout. HP very quickly investigated the issue, and although they discovered that the checks they sent were correct they still decided to pay developers the difference in the reported numbers.)

Flash and other miscellany

When it comes to specific features, like Beats audio or support for Flash, I am personally ambivalent. However, the other day my partner complained about needing go plug in her computer halfway through a TV episode on Hulu, and I mentioned she could try using the TouchPad. She said she didn’t want to pay for Hulu Plus, and continued plugging in her computer. I told her there wasn’t a Hulu app; she could watch it normally in the browser using Flash. She got quiet for a second, then said, “But why would I need a computer then?”

Which seems telling.

Of course, when I visited Hulu the other day and tried to watch a TV show, nothing but the advertisements worked (which is also telling). The promise of access to the full web via Flash is still premature. However, the few times that I have stumbled across a Flash video embedded on a website while using the TouchPad it has been extremely refreshing to be able to immediately watch it.

The TouchPad is for me

Both as a user and a developer, I love my TouchPad. It is likely not the right device for everyone, of course, but it is a great piece of hardware running a fantastic piece of software with a decent catalog of apps that is actively growing and maturing.

If you are in the market for a tablet, you will likely love the TouchPad (or not) for different reasons than me, of course. I encourage you to visit a store with display models and try it for yourself (I’ve heard places like Best Buy, Staples, and so forth often have units on display).

Enough of these consumer-oriented blog posts about TapNote! It is finally time for a look at WebOS and the TouchPad from a developer’s standpoint.

If like myself you developed an app in Mojo, you are likely now considering whether to port it to Enyo (or are in the process of porting already). I wanted to post this a month or two ago, but thanks to the NDA was out of luck. Now, however, here are some pointers about the differences between the two frameworks, and specific suggestions for how to more quickly migrate your application. I am assuming that you have already worked through the basic Enyo documentation and tutorials and are at least somewhat comfortable with the basic ideas (like kinds); if not, you will likely find the discussion to follow confusing.

As you first start getting into Enyo, it will seem very weird compared to Mojo. However, there is a method to this madness, and if your experience is anything like my own you will find that you are able to do the same things as you did in Mojo, except with less code that is better organized. I was skeptical of the benefits of Enyo when I first got into it (and particularly skeptical about not being able to code HTML by hand) but I have since come to believe that HP has made the right choice in switching frameworks. I was particularly heartened as, through the course of the Enyo beta, HP consistently made iterative improvements to the most egregious parts of the Enyo framework and very actively listened to developer feedback.

But you probably don’t care about that; after all, you’re here because you want to migrate your code and take advanage of the new hotness that is the TouchPad.

File layout and appinfo

Unlike Mojo, Enyo is pretty flexible about how you organize and name your files. There are only four required files for an Enyo project, three of them shared with Mojo:

• appinfo.json
• framework_config.json
• index.html
• depends.js

You will basically need to rewrite your index.html file to include a reference to the Enyo framework and to initialize your base application kind, but appinfo.json and framework_config.json are effectively unchanged. The only thing to note here is that you absolutely must not forget to add this to your appinfo.json:

"uiRevision": 2

The uiRevision key tells WebOS that your app is capable of running full-screen on a TouchPad, avoiding the annoying phone emulator. (Side note: you can actually convert a Mojo application to run on TouchPad without the emulator simply by including this line in your appinfo.json, but I would not recommend it. Theoretically, Mojo should stretch to fill the space just fine, but you will find that the Mojo widgets and default styling do not work effectively on a large screen.)

As for depends.js, this is where you include the various Javascript files that you need for your project. It effectively replaces the Mojo sources.json file that was previously required.

When it comes to your application’s Javascript files, you will be able to keep some virtually intact and completely rewrite others:

• Models and helper classes can be ported very easily simply by replacing Mojo references with the appropriate Enyo references, and converting them to kinds. Compare, for instance, my own Database class in Mojo vs. its Enyo equivalent. The core logic is unchanged; merely the Prototype and Mojo-specific code had to be converted.
• View assistants will basically need to be rewritten, but you can typically keep your logic code intact. For instance, I used Prototype classes throughout my app, and although I had to replace the widget setup code with Enyo components most of my event handlers and so forth I was able to port simply by tweaking the arguments they received (see below).

Mojo methods: initialize, setup, cleanup

The basic methods you used for setting up your Mojo assistants map over to Enyo reasonably well.

initialize from Mojo was something you only used if you were writing Prototype classes. Otherwise, this would be the basic function that you used to initialize your object. In Enyo, initialization is done in the constructor method of your kinds.

However, you have to make at least one more change besides renaming the method: you must add this.inherited(arguments) to either the top or the bottom of the method. this.inherited() is a special function that invokes the parent kind’s method, and any time you override an existing kind method you will probably need to call it. Particularly if you forget to put it in your constructor, you will get some very strange errors from the Enyo framework.

For setup and cleanup in Mojo, you can switch to using create and destroy in Enyo, with the same caveat as above to include a call to the parent kind’s definition of those methods.

If you were using Prototype classes, your old code might look like this:

var MySceneAssistant = Class.create({
    initialize: function() {
        // Initialization tasks here
    },
    setup: function() {
        // Setup widgets here
    },
    cleanup: function() {
        // Cleanup for garbage collection
    }
});

And you will transition to code that looks something like this:

enyo.kind({
    name: "MyKind",
    constructor: function() {
        this.inherited(arguments);
        // Initialization tasks here
    },
    create: function() {
        this.inherited(arguments);
        // New Enyo code to initialize items in this.$ hash
    },
    destroy: function() {
        // Cleanup for garbage collection
        this.inherited(arguments);
    }
});

As shown, I typically call this.inherited(arguments) at the beginning of constructor and create and at the end of destroy. The reason for this is that in constructor it triggers the basic setup for the kind (so after that I will have access to my getters and setters, events, and so forth) and in create it sets up the all-important this.$ hash of the kind’s components. In destroy, though, it cleans up the this.$ hash, and I typically need to do my own cleanup before that hash is emptied.

Some things to note:

• Not all kinds handle create the same way. In particular, if you are working with a Popup or other LazyControl, you will need to use componentsReady or similar, instead.
• Unlike in Mojo, destroy is not always called in Enyo. In particular, it is not triggered when the user tosses your card off screen, so putting last-minute saving instructions in here is not a good idea. Instead, use ApplicationEvents and onUnload.

Event handling

Event handling in Enyo is completely different from Mojo. Where before you needed to explicitly subscribe to events in activate and deactivate, you now assign event listeners directly in your components array. So where before you had this:

initialize: function() {
    // Save our bindings for later
    this.bound = { editItem: this.editItem.bind(this) };
},

setup: function() {
    // Setup the document list
    this.controller.setupWidget('documents-list', docListAttr, null);
},

activate: function() {
    // Setup the listTap event
    this.controller.listen('documents-list', Mojo.Event.listTap, this.bound.editItem);
},

deactivate: function() {
    // Disable the listTap event
    this.controller.listen('documents-list', Mojo.Event.listTap, this.bound.editItem);
}

In Enyo you will convert it to something like this:

components: [
    {
        name: "list",
        kind: "VirtualList",
        onclick: "editItem",
        // ...
    }
]

Some events handlers will transfer over very easily, but one thing to remember is that Enyo events always have the control that triggered the event as their first argument (unlike Mojo events, which typically have the Event object first, a la vanilla Javascript). So in the example above, this is our old handler:

editItem: function(event) {
    // work with our event object
}

And this is its Enyo equivalent:

editItem: function(sender, event) {
    // work with our event object
}

Not all Enyo events will pass an event object as the second argument; refer to the docs for more information. In general, if you are typing into a DOM event (like onclick in the above example) you will get a standard Event object as your second argument. If you are tying into a custom Enyo kind event, however, you will probably receive something else (you can tell a custom Enyo event because it will be in camelCaps: onCustomEvent vs. onmousedown).

There are other interesting complexities to Enyo event handling, as well (like using *Handler methods to automatically capture DOM events), but most of them are things you will be adding to your project new rather than things you will be using to replace Mojo elements.

Activate, deactivate, and the Enyo ApplicationEvents kind

For events that are not attached to a particular control on screen, Enyo provides a generic ApplicationEvents kind that you can include in the components for any kind that needs access to universal events.

Typically this is most useful because you need to replace your Mojo activate and deactivate logic that triggers when the card is minimized or maximized. For instance:

components: [
    {kind: "ApplicationEvents", onWindowActivated: "activate", onWindowDeactivated: "deactivate"}
],

activate: function() {
    // Do window maximized logic
},

deactivate: function() {
    // Do window minimized logic
}

ApplicationEvents is also what you will use to tie into application relaunch events, the window onunload event (as referenced above), document-level handling of clicks, and more.

Binding

Binding behaves identically in Mojo and Enyo, but the syntax is different. In Mojo, you could use the Prototype bind method: myFunction.bind(this). In Enyo, you need to use the enyo.bind method: enyo.bind(this, myFunction). I used the following regular expressions to convert my bindings (syntax for replacements may vary depending on your editor, and if you are binding functions that are not attached to this you will need to handle those separately):

Find:
(this\.\w+?)\.bind\(this(, .+?)?\)

Replace:
enyo.bind(this, \1\2)

Cookies

Converting from Mojo to Enyo cookies is reasonably straight-forward, with the following caveats:

• You no longer need to create a Cookie object before you can assign or get a value from it
• Enyo will not automatically convert Javascript objects! You must stringify and parse objects with JSON to store or retrieve them

For instance, if this is your Mojo cookie code:

var myCookie = new Mojo.Menu.Cookie('DeliciousCookies');
if (!myCookie.get()) {
    var cookies = [
        "Chocolate Chip",
        "Snickerdoodle",
        "Ginger snaps"
    ];
    myCookie.put(cookies);
}

Then you will need to revise it like so:

if (!enyo.getCookie('DeliciousCookies')) {
    var cookies = [
        "Chocolate Chip",
        "Snickerdoodle",
        "Ginger snaps"
    ];
    enyo.setCookie('DeliciousCookies', enyo.json.stringify(cookies));
}
// And later when you fetch the cookie...
var cookies = enyo.json.parse(enyo.getCookie('DeliciousCookies'));

Reading appinfo and device details

In Mojo, if you needed to check a value in your appinfo.json file or lookup the type of device you were using you could use the Mojo.Controller.appInfo or the Mojo.Environment.DeviceInfo objects. In Enyo, this information is now accessible through functions:

• Mojo.Controller.appInfo → enyo.fetchAppInfo()
• Mojo.Environment.DeviceInfo → enyo.fetchDeviceInfo()
• Mojo.Environment.frameworkConfiguration → enyo.fetchFrameworkConfig()

Headless applications and noWindow: true

Setting "noWindow": true in your appinfo.json still works, but Enyo handles it differently than Mojo. Of particular note, in Mojo your assistants could access shared code easily using things like Mojo.Controller.getAppController(). However, in Enyo every window is effectively sandboxed, and has no access to other windows except for the special enyo.application object (to which you can attach whatever properties you need).

For instance, in my own app I used my ApplicationAssistant to handle all the shared behavior, route things through the model, manage synching, and so forth. Most of my assistants thus included this in their initialize function:

this.app = Mojo.Controller.getAppController().assistant;

In Enyo, while I still have a shared application kind, I have to explicitly make it discoverable by my other windows. In the shared application kind’s constructor I have this:

constructor: function() {
    this.inherited(arguments);
    // Other initialization code
    enyo.application.app = this;
}

And then I access it inside of kinds in other windows like so:

constructor: function() {
    this.inherited(arguments);
    this.app = enyo.application.app;
}

The benefit of the Enyo setup is that I can load the kinds that I need as I need them. For instance, the only items in my root-level depends.js file are the shared application kind, data models, and so forth. Then I place my actual windows in their own directories (with their own index.html and depends.js) and only load in the necessary view-related kinds for them.

You will find more information about the difference between Enyo and Mojo headless app handling in the Enyo documentation.

The dreaded switch from widgets to components

Converting your old Mojo-widget-reliant view files to Enyo is going to be the hardest part of the process, for here find and replace will avail you not.

In Mojo, your view files were typically split across several locations:

• First, you would have one or more HTML files where you would code stub divs representing Mojo widgets and any surrounding markup needed
• Second, you would have a Javascript Assistant that would initialize your widgets, populate them with data, and handle interaction logic and events
• Third, you would style your widgets and surrounding markup using CSS (typically all stored in a single central file)

In Enyo the Javascript and CSS is still there, but the HTML is completely absent. Instead, you create a tree of components, each of which typically represents a DOM node (usually a div, although the specific markup will not affect you much).

Most Mojo widgets have Enyo equivalent controls, so a large part of converting your view file is simply a matter of digging through the Enyo API reference in search of the right component.

However, you will need to make some adjustments to how you style your app. Before, you typically would know what the markup surrounding your widgets looked like because you coded it yourself (not necessarily a good thing, of course; digging through the Mojo source code so that I could use un-documented standard classes to achieve groups and so forth was no fun). In Enyo, you can set the className for any component, but if you need to figure out what the standard classes are you will need to use the WebKit Inspector by either running your app in a browser (best) or using a tool like weinre (see my weinre tutorial for more info).

I was skeptical about the Enyo Javascript-only approach at first, but I have since become a convert. Although I theoretically like the idea of having direct control over my markupt, the truth was tht Mojo did not provide direct control over the most important markup, anyway, and being able to run Enyo apps in a normal browser (without an emulator at all) means that it is very, very easy to quickly and accurately style things, even when I have not defined a single one of the classes that went into the markup.

Go forth and Enyo-ize

There are certainly many other differences between Mojo and Enyo, but hopefully this selection will help you to get through some of the nuts-and-bolts conversion tasks that can be so onerous. Good luck with your WebOS app!

As you are doubtless aware if you have either read a review or seen a TouchPad yourself, the hardware is heavily inspired by the iPad. This is a good thing: the iPad’s size and screen resolution are a sweet spot for tablets (as the many non-iPad-sized Android tablets seem to be discovering to their chagrin), and like the iPad before it, the TouchPad very quickly disappears as you are absorbed by whatever app you are using.

Of course, this means that you are not going to buy the TouchPad because of the hardware; you are going to buy it for WebOS and the apps. If you have ever used a WebOS device before, you probably already know how fantastic it is (and if not, don’t take my biased word for it; go read all the reviews from the Apple fans and tech blogs who are discovering the joys of WebOS).

So ultimately, people are going to be buying TouchPads in order to run awesome apps. This is the area where the iPad has an indisputable advantage. Numbers aren’t everything, but the iOS store also tends to have better-quality apps than competing app venues. Granted, HP does not need to compete directly with the iOS app store; they just need high enough quality offerings to make it viable for people to use the TouchPad instead of an iPad so that the lure of WebOS can tempt them over. A fair number of people I’ve talked to would prefer to use WebOS over iOS, but are leery to buy a TouchPad because they are worried the apps will not be there.

Which begs the question: how does the TouchPad’s app ecosystem stack up? Sure the TouchPad App Catalog is young, but if you are considering becoming an early adopter of the TouchPad the state of the App Catalog right now is what you care about.

Rather than reviewing TouchPad apps on an app-by-app basis, I will look at several popular uses for tablets and review how the TouchPad’s App Catalog stacks up against the iPad.

Core competencies: email, calendars, contacts

You can read specifics about the various default apps in many of the TouchPad reviews, but suffice it to say that HP paid a lot of attention to the basic apps, with the Email app in particular standing out as a quintessential example of WebOS apps at their best.

HP is not making the mistakes of companies like RIM with their Playbook/email fiasco. The core productivity apps are there, they’re solid, and they’re tied tightly together with WebOS Synergy. If the only thing you needed a tablet for was email and personal info management, the TouchPad would be a very strong contender.

Listening to music

If you like music on your tablet, the TouchPad is a compelling option. The much-advertised Beats Audio speakers were something I personally paid little attention to, but the quality of the speakers when I tried them out surprised me. The music app is also very nice. Like on WebOS phones, the music app keeps a notification in your dashboard, so you can play, pause, and skip songs without needing to switch cards.

Synching music to the TouchPad is slightly wonky at the moment, though; you have to put the device into USB mode connected to your computer, and while the beta HPPlay app works reasonably well it is extremely rough around the edges and moves sluggishly. I was able to synchronize several gigabytes of music on the first try (after HPPlay finally got rolling, transfer speeds were nice and fast), and the TouchPad Music app picked them up without a problem. (Do note that immediately after transferring music you may have a short period of time when it appears that the TouchPad has not noticed your music; this is because WebOS is indexing the new files in the background. If you check back in a few minutes, your music should be there.)

App-wise, there are a number of interesting music-related apps, including several online radio apps, Moodagent (which lets you construct automatic playlists based on a given song or your mood). I certainly have not tried them all, but the selection here seems decent. Additionally, the inclusion of Flash means that things like Amazon Cloud Storage and other Flash-based streaming players should work great (reports on Twitter seem positive in this regard; I have not experimented with them myself, being ambivalent about Flash).

When I searched, there did not seem to be any dedicated podcast apps, however. Apps for listening to audio seem to mainly be focusing on specific stations/podcasts, or serving broad audiences. The niches have not yet filled out, but the core apps appear to be available and are TouchPad-native.

Making music

If you want to make music with a tablet, you have two options:

1. Wait and hope
2. Buy an iPad

And honestly, I would recommend the second.

Multitouch Piano HD on the TouchPad notwithstanding, GarageBand and the many niche apps on the iPad make it hard to justify a TouchPad purchase for people who want to use it to make music.

Likely the options here will improve as the App Catalog matures (the App Catalog will be improving in leaps and bounds now that the SDK is public and developers start to get more comfortable with the framework), but this is definitely one of the areas where the iPad’s “long tail” of apps makes it much more compelling.

Watching videos

Unlike listening to music, the app landscape for consuming videos is barren on the TouchPad at the time of this writing. If you want to watch Flash videos in the browser, of course, you’re covered (at least as well as you can expect with Flash on tablets still being beta quality, and prone to slowdowns or other issues). And presumably the Photos and Video app would play videos fine if you manually moved them onto the device (and they are free of DRM). But if you want to just rent a video or whatever, you are out of luck.

The HP MovieStore app that HP is promoting is a “coming soon” splash screen (why it is in the App Catalog at all is a mystery to me, honestly). A search for “movies” yields a bunch of worthless soundboard apps…all of which are coded for phones, anyway.

I am sure that folks at HP are working their butts off to try and get better media options on the TouchPad, but the showing at launch is fantastically poor.

Creating video

As with creating audio, if this were important to me I would be buying an iPad 2 without looking back. At least for people into music you can plunk out a tune on the virtual piano on TouchPad. But there are no apps that I could find that make shooting, editing, or otherwise doing something creative and interesting with video remotely possible.

Given that the only camera is a 1.3 megapixel front-facer and there is no centralized way to get video on and off the device, I doubt this category will get much love in the near future. If you are interested in producing video on a tablet, you will need to wait for the next TouchPad device or beyond, or just get an iPad.

Reading

I was super stoked when I heard about Amazon Kindle on the TouchPad leading up to launch. It was thus a shock to tap the Kindle icon in my launcher and have the App Catalog open and prompt me to download the app.

It was an even worse shock when I discovered that the app I had downloaded was a “coming soon” splash screen.

There is no Kindle app on the TouchPad. There is an icon in your launcher that you cannot delete.

I am exceedingly disappointed by this. Sure, the Kindle app will eventually be finished and offered for download, but for now there are no decent ebook options on the TouchPad aside from the hordes of worthless one-offs (for phones, no less), and three Bert and Ernie picture books.

To add insult to injury, there are also no high-quality RSS readers (or Google Reader clients) that I could find for the TouchPad. Even worse, none of the WebOS phone options seem to have been approved for the TouchPad, so the feed reading niche is largely empty. I hope that time will rectify this, but right now your best bet will probably be using Google Reader in the browser.

Shortly after publishing this article, I was reminded via Twitter that I had overlooked the Mosaic RSS reader (which also syncs to Google Reader). Mosaic is basically unusable for the way that I read feeds (the “article in a box” approach just doesn’t work with a large number of feeds, or articles that tend not to have images attached to them) but it may be more interesting for other folks and certainly deserves kudos for being one of the first reasonably polished RSS apps in the catalog.

On a more positive note, Paper Mache is an excellent Instapaper app, and free to boot (although a paid subscription to Instapaper is required). WebOS phones never really got a decent Instapaper app, so it is highly gratifying to be able to access my Instapaper articles on the TouchPad from day one.

For reading more business-world related documents, the bundled Quickoffice and Adobe Reader seem to do passable jobs.

Writing

Aside from my own TapNote, there are not very many good options for writing on the TouchPad. The bundled Memos app is as laughably bad as it was on phones, and many of the third-party writing apps were evidently not ported to TouchPad.

There are two other decent options that I did find: pondNotes (a Simplenote client) and Typewriter Beta. The former is less polished than TapNote, but if you are already a Simplenote user (or prefer Simplenote to Dropbox for whatever reason) it may be a better fit. Typewriter is a snazzy Markdown-based editor with rudimentary support for saving documents to Dropbox, but is currently lacking in useful features (including standard features like spell-checking and auto-complete). It will doubtless be improving as time goes by, however, and its scrubber method of swapping between your actual text and an HTML preview is lots of fun.

If you are interested in editing rich text documents or things like PDFs, Microsoft Word, and so forth, however, you are out of luck. Quickoffice is apparently slated to be upgraded with editing capabilities, but there are no third party apps that I could find that support writing rich text in the current initial App Catalog.

Life is looking better for bloggers, though; the TouchPad offers excellent apps for WordPress, Tumblr, and Posterous (there are likely others, as well). I particularly like that the WordPress app keeps an eye on your WordPress comments in the background and notifies you when you have a new one (much more humane and direct than getting a notification via email).

Viewing images

Although the selection is still limited, there are some high quality options for viewing images available for the TouchPad. The built-in Photos app is decent, and third-party offerings like Flickr Mundo HD and InterfaceLIFT HD offer elegant access to images online.

Given the quality of the tools that Enyo provides for handling images in various ways, I fully expect that this type of app will be a popular niche for developers to fill, as well.

Creating images

As with the other categories, there are not nearly as many quality apps for creating images on TouchPad as there are for iPhone. There are a smattering of early drawing and sketching tools, but they tend to be phone apps not optimized for TouchPad or else appear to have been rushed to release and very rough around the edges.

Playing games

One of the primary reasons to get a tablet, in my opinion, is to play games. Not all games work particularly well with a touch interface, but for the ones that do (like most casual and puzzle games) you’ll wonder why you ever played them with a mouse.

The TouchPad has a pretty decent offering of cross-platform games at launch. In particular, Sparkle HD, Galcon Fusion, Paratrooper HD, and Angry Birds HD (which is completely free) provide the catalog with an excellent grounding in mobile gaming. At the moment you will not find any WebOS-only games, but that is likely to change as the platform matures. There are plenty of games that you can only get on an iPad (I will be missing Small World, in particular) but gaming on the TouchPad is still highly satisfying.

Social media

Perhaps thanks to Twitter’s recent aggressive anti-developer stance, there is only one Twitter client optimized for TouchPad (Spaz HD). However, I hear that the Facebook Tablet app is excellent (I do not have a Facebook account myself to test it), and there are a number of other social media apps available (like the previously-mentioned Flickr Mundo HD).

This is the app category that I expect will be the fastest growing in the catalog. WebOS has always had a focus on third party web services thanks to its developers mainly coming from web development backgrounds. The offerings now are decent, if not particularly varied, but if you are interested in social media a TouchPad is likely a sure bet.

Overall

For the TouchPad launch, the available apps are looking far better than some competing platforms (Android, RIM), but the App Catalog is still not competitive with the iPad App Store in several categories. Whether the TouchPad is a good fit for you thus depends a lot on how you plan to use the device.

For myself, the things I did most on my iPad 1 were read (particularly RSS and Instapaper), browse and post to Twitter, and play games. Switching to a TouchPad has thus been a mixed bag; there are still games I enjoy playing and the Paper Mache Instapaper app is great, but I cannot yet read RSS, am underwhelmed by the only TouchPad-optimized Twitter client, and extremely disappointed in the lack of core promised apps like Kindle and the Movie Store. Fortunately, none of these apps are particularly niche (or if they are, like RSS readers, they are niche for web developers who make up the bulk of WebOS developers), so with a little time I expect my app needs to be met admirably.

For others, whether a TouchPad is worth it depends a lot on whether using WebOS is important enough to you to ignore some of the deficiencies in the App Catalog, or if your needs are largely met by the existing app ecosystem.

What to expect

Because the TouchPad App Catalog is so young (days old at the time of this writing), the offerings are going to be in a great deal of flux in the near future.

Predicting how it will evolve is difficult, however. HP is working very hard to interest developers in the platform (if you are a web developer of any stripe who wants to create a tablet app, you will find no better platform; the developer relations team is fantastic, the community helpful and responsive, and the framework a joy to work with), but for some developers the choice to invest development time in a platform is based purely on whether they can make money and it is still too early to see if HP’s WebOS will attract enough users to make it economically viable.

Personally, I am optimistic: TapNote never sold particularly well on WebOS phones (in part because there were so few users, and in part because I was never successful in getting noticed), but I have loved both developing and using WebOS (when I have to use iOS now it feels extremely limiting and claustrophobic) and HP has aggressively ramped up their efforts to attract developers. Although I was deeply concerned after the February 9th event where HP announced the TouchPad and their new Enyo framework, since then I have watched HP as they iteratively improve their framework (which, after I got over the shock of needing to completely rewrite my app, was legitimately better than the old framework to start), treated me like royalty despite the fact that my app has never made them any money worth noticing, and has been aggressively offering discounts and fantastic deals to their existing WebOS users and early adopters.

I do not think this platform is going to take off overnight, because unlike the iPad it is not entering into a vacuum or defining a new category of product. However, I do think that we are going to see steady and increasing growth as users of both Android and iOS start to discover the beauty of WebOS, developers expand the App Catalog, and the Pre3 and Veer continue to make inroads in the smartphone market. WebOS is excellent and the App Catalog is starting from a decent grounding in the basic apps most users need, making this an excellent platform to invest in for both users and developers alike.

Whether it fits your personal needs enough to convince you to become an early adopter depends a lot more on what your needs are, but hopefully this look at the initial offerings in the App Catalog will help you determine that for yourself. If the TouchPad sounds good to you, I highly recommend you head to a Best Buy or similar store and try one for yourself.

The apps mentioned

For existing TouchPad users, here are links to the App Catalog for the third-party apps I mentioned above:

• Personal favorites
  • TapNote (or try it for free with TapNote Lite)
  • Paper Mache (Instapaper client)
• Radio and music
  • Moodagent
  • Multitouch Piano HD
  • iHeartRadio
  • rad.io
  • (and a bunch of more niche radio apps)
• Writing
  • pondNotes (Simplenote client)
  • Typewriter Beta
  • WordPress
  • Tumbly HD
  • Tumblbox 2 (haven’t played with the Tumblr clients yet, so I’m not sure which I prefer; listing both for completeness’ sake)
  • Postie (Posterous client)
• Games
  • Sparkle HD
  • Galcon Fusion
  • Paratrooper HD
  • Angry Birds HD
• Others
  • Spaz HD for Twitter and StatusNet
  • Mosaic Reader
  • Flickr Mundo HD
  • InterfaceLIFT HD

But wait, there’s more!

There are over 300 TouchPad-optimized apps in the HP App Catalog at launch, and although that is not very many compared to the other app venues, it is still far more than I can browse through or use over the course of a few days. If you feel like I have missed a gem in my overview of the App Catalog at TouchPad launch, or if I’ve ignored a category of common tablet use, let me know in the comments! I love hearing what apps other users love, or discovering new apps for myself.

I am very pleased to announce that TapNote is available on the HP TouchPad from launch day! Not only that, but it features a gorgeous new interface (and one awesome new feature) to take advantage of the TouchPad’s expansive screen size:

This is the best version of TapNote yet, and if you are the proud new owner of a TouchPad I highly recommend you check out TapNote in the App Catalog.

TapNote Lite has also been converted to work natively on the TouchPad; try TapNote Lite for free.

New to TapNote? You want TapNote because is a joy to use, it avoids clutter and complexity, and it enables you to focus on what matters: your writing. It also is a great WebOS citizen, with automatic cloud synching via Dropbox, Just Type support for adding or appending to your documents without launching the app, and a bevy of thoughtful features that make it easier to edit text. And last but not least, I am fanatical about offering high-quality support.

Universally useful

One of my favorite features of the new version of TapNote is that it is universally compatible: that’s right, TapNote runs on every WebOS device available, be it an original Pre from 2009, the indomitable Pixi, the overlooked Pre2, that tiny Veer, and right on up to the TouchPad. TapNote is purchase once, run anywhere: your notes and documents are always at your fingertips regardless of device.

Unfortunately, in these early days of TouchPad sales the App Catalog has still not been fully tweaked to support universal applications; although TapNote for TouchPad is universal, it is not yet possible to download it to a WebOS phone. I am working with HP, and will have it enabled in all app catalogs within a week or so.

Existing TapNote users

If you are an existing WebOS phone user of TapNote you will find that the TouchPad version for TapNote is a new app (you cannot download it for free). Limitations in the App Catalog leading up to launch coupled with a desire to get rid of the last vestiges of the old “TouchNote” name prompted me to submit the TouchPad edition of TapNote separately. However, fear not! An update to the original version of TapNote is awaiting approval from HP, and includes a way to request a free upgrade to the new TapNote version (via promo codes). If you have purchased TapNote in the past, you will be getting a free upgrade to the TouchPad version (which, as mentioned above, will continue to run on your phone as soon as I am able to get it into legacy app catalogs).

TouchPad-specific changes

The most obvious change to TapNote for TouchPad is the switch to a light-based theme instead of the default dark theme. I made this change because while a dark theme makes it much easier to focus on text on phones, the greater screen real estate and line lengths of the TouchPad made a light-on-dark interface distracting and phrenetic to use (particularly with the additional buttons and other interface). A darker theme for the light-averse among us is coming soon.

Another big change is that the functionality that used to live in the application menu has now moved into the footer as distinct buttons. Thank goodness for screen real estate; everyone can now discover the joys of Quick Text and other previously hidden features.

Most of this functionality is standard between TapNote on phones and TapNote on TouchPad, but there are a couple of new items worth noting:

In addition to being able to open your documents in new cards and email them, you can now also print documents on most HP wireless printers (has to be a printer that the TouchPad supports).

Also, as PreCentral and others have noted in their reviews, placing your cursor on the TouchPad can be exceedingly frustrating. Not so in TapNote; simply tap or hold on the cursor placement icons to get your cursor exactly where you want it.

I hope you enjoy TapNote! For those without access to a TouchPad just yet, in closing I’ll give you a few more screenshots to ogle:

Focus on a single document by dragging or tapping the grab bars

Just Type allows access to TapNote without launching it first

Choose your preferred font, font size, and more

Multiple cards make working across apps ridiculously easy