In any case, this evening I found myself in need of something to serve with dessert crêpes since we didn’t have any ice cream in the house (a batch of crêpes split in half makes almost exactly two savory and two dessert crêpes, which is perfect for my girlfriend and me). I figured I’d try tapioca pudding, but I wasn’t eager to have plain tapioca pudding inside of plain crêpes.

One thing led to another, and I ended up with orange-flavored tapioca pudding, which is ridiculously good for a shot in the dark (I searched the internet prior to making it, but aside from learning that this is something a small number of people do I didn’t find any good recipes. If you like tapioca pudding and oranges, I highly recommend you give it a try.

Orange tapioca pudding recipe

(This is a lightly-modified version of the recipe on the Minute tapioca box; you could likely adjust it for use with other types of tapioca without much effort; the trick is substituting orange juice for most, but not all, of the milk.)

• 1/3 cup sugar
• 3 tablespoons Minute tapioca
• 2 cups orange juice
• 3/4 cup milk (whole milk is best)
• 1 egg, beaten
• Pinch of orange zest (optional)

• 1 teaspoon vanilla extract
• Splash of orange flower water (optional)

Combine the sugar, tapioca, orange juice, milk, beaten egg, and orange zest (if you have a fresh orange on hand) in a medium pot and let it sit for five minutes.

Cook on medium heat, stirring constantly, until it comes to a full boil (boils while you are still stirring). Remove from heat. Stir in the vanilla and a little orange flower water (if you have any on hand).

Let the pudding cool for 20 minutes or so, then either eat it warm or refrigerate for later. I prefer it warm, my girlfriend prefers it cold.

I can say first-hand that this is absolutely divine served in dessert crêpes, garnished with orange zest, and drizzled with chocolate sauce. I fully expect the left-overs will be great on their own, too. If you’re really feeling fancy, slice up some fresh orange or other citrus-friendly fruit and serve it alongside or on top.

I was actually pretty happy with the previous design, so I stuck with the same main layout and color scheme. The main problem I had it was that the one pixel borders and arrows were simply not breaking things up enough well enough; it was really difficult to distinguish between posts on the homepage, and viewing the site on a mobile device was an effort in frustration (since the borders were virtually invisible and the headings were longer than the text, which made zooming in difficult).

Both of these issues should now be fixed, and I also introduced some fun little features here and there like threaded comments, a search button in the header to jump straight to the footer, and so forth. Additionally, the site should look beautiful on the iPhone 4 (I haven’t had a chance to test it on other mobile devices yet).

I’ve tested things on the major non-IE browsers, but please let me know if you run into any problems! I always love getting feedback.

It’s been a while, but I think it is long past time that I shared the love. Here are some authors that I have discovered recently who you should not miss, along with some old friends and standbys.

In general, my tastes run to fantasy and science fiction, so that’s what you will find here.

My standbys

Some of my standbys you already know about from elsewhere. Neil Gaiman (start with Neverwhere if you prefer action, StarDust if you like romance, or The Graveyard Book if you just like a ridiculously good novel). Terry Pratchett (start with Nation, or just about any Discworld book aside from Colour of Magic; Equal Rites or Guards! Guards! would be excellent entry points). J.R.R. Tolkien, J.K. Rowling, C.S. Lewis.

But there are at least four that you might not have heard of, and need to know about. (Note that all links below are unencumbered; I tried playing the affiliate linking game in the past, but it made me feel dirty and didn’t make any money, so screw that.)

First up, Diana Wynne Jones. If you like children’s fantasy, you’ve probably already run across her, but if not you should waste no time in picking up one of her novels. Sadly, Jones passed away this year but she has a large corpus of novels, virtually all of which are excellent. Start with Howl’s Moving Castle, The Lives of Christopher Chant, or (if you can find them) Cart and Cwidder or Archer’s Goon.

Diana Wynne Jones: Amazon, B&N

Second, C.J. Cherryh. Cherryh mostly writes science fiction, but she dabbles in fantasy from time to time, and she is fantastic. There are a few of her older books that I like less well, but in the last couple decades she has really hit her stride and at this point I buy whatever she publishes sight unseen. Great starting points for Cherryh are Foreigner (stick with it until you meet Bren Cameron; maybe the first quarter of the novel sets up the historical situation and is less interesting), Cyteen, or if you can find it Merchanter’s Luck. Also, don’t be scared by the number of Foreigner books out. Yes, it looks like another Robert Jordan-level commitment, but it’s not. Each book is self-contained, and they have broader story arcs that are organized into trilogies so if you only ever buy one to three books at a time you’ll have a very satisfying reading experience.

C.J. Cherryh: website, Amazon, B&N

Third, Jonathan Stroud. I, likely along with most of his readership, discovered Stroud in the surge of children’s fantasy that occurred thanks to the success of the early Harry Potter books. However, I like him far better than J.K. Rowling (particularly after reading Harry Potter and the Deathly Hallows and its awful ending/epilogue). Start with Amulet of Samarkind, and if you don’t hit it off with Bartimeus read Heroes of the Vally instead.

Jonathan Stroud: website, Amazon, B&N

Last, Megan Whalen Turner. There’s only one starting point for Turner (The Thief) since she has only published books in a single series/world so far. Aside from Cherryh (whose intense third-person style might not appeal to some folks), Turner is the most likely of these authors to not appeal to everyone. The Thief is very accessible and kid-friendly (it was a Newberry Honor book), but Queen of Attolia is much more stand-offish when it comes to characterization and is more of a YA or adult book thematically. Each of her novels so far has had a distinct flavor from the rest, making her a difficult author to pin down.

Megan Whalen Turner: website, Amazon, B&N

Indie authors

I’ve been reading a lot more self-published authors on Kindle lately, and wow is it ever a mixed bag. A small number of them have been horrible (but evidently spent a lot of time making the first part of the book that’s in the sample read great, unfortunately). Most of them have been mediocre to the point where I stop halfway through and move on. And at least two of them have quickly rocketed onto my favorite authors list.

First off, Michael J. Sullivan. At this point, he has achieved a level of legitimacy dreamed of by most other indies, and you can find his fantastic six Riryia Revelations in ebook or print format. Start with Theft of Swords (followed by Rise of Empire and finally Heir of Novron). Sullivan writes old-school adventure fantasy, and I can’t recommend him highly enough.

Michael J. Sullivan: website, Amazon, B&N

Next up is Lindsay Buroker. If Michael J. Sullivan was the best indie author I discovered in 2010, Buroker is hands-down my favorite for 2011. Her first book is The Emperor’s Edge, and it is a wonderful romp through a steam-powered fantasy city. Note that this is not steampunk (although she has a mini-series of novellas that apparently do fit that genre which I have not yet read). Instead, the Emperor’s Edge series are character-focused fantasy adventures. This is also one of the few series where I’ve discovered an “ultimate assassin” type character who actually seemed realistic (it’s really difficult to create a sympathetic cold killer, but over the course of the three books currently released Buroker manages it).

Lindsay Buroker: website, Amazon, B&N

And that’s about it for the independent authors. I’ve found others who were decent, but those are the only two who fall into my “must read everything they write and evangelize them afterward” category.

Newly discovered

I have run into a fair number of excellent authors since I last posted anything on this blog about reading, so these are in no particular order.

You need to read D.M. Cornish. His first book is The Foundling’s Tale (might also be called Monster Blood Tattoo, depending on where you live) and he is one of the authors on this list who is not optional. It is very, very rare in fantasy for people to create things that are truly unique. Typically fantasy relies on mythology, fairy tales, or Tolkien and the many stereotypes that arose out of his founding epic. D.M. Cornish, however, has created a world unto itself, including a new and wonderful vocabulary. He is also one of those rare authors who illustrates his own works, giving you some wonderful insight into how he sees the characters he is describing.

D.M. Cornish: website, Amazon, B&N

I discovered Catherine Fisher because of Incarceron, which is a fantastically interesting book about two worlds: one privileged, with their high technology hidden behind the scenes in order to enforce the illusion that they are living in the past; the other a prison-world where the prison is actively trying to kill its inmates. I highly recommend it. After finishing Incarceron I discovered Fisher is quite prolific. So far I have only read her Oracle trilogy, but it was excellent (a very odd blend of Egyptian and Greek mythology that somehow completely works). I’m looking forward to discovering more of Fisher’s work in the months to come.

Catherine Fisher: website, Amazon, B&N

A year or two ago, I tried Scott Westerfeld’s Leviathan (this one is legitimately steampunk), and since then I’ve read everything he’s written that I can find. Westerfeld is an intriguing one: his premises and characters are flawless and fascinating, but in almost every world he has written I have left it feeling like he fell short of his own potential. He tends to setup worlds where people are diametrically opposed to one another, but often they just shrug off their differences and move on with it. For instance, Leviathan focuses on World War I except that the two sides are divided into Clankers (people whose society is powered by mechanical constructs) and Darwinists (people whose society is powered by artificially fabricated animals). This is a socio-cultural divide that would be deep-seated, largely emotional, and difficult to overcome. Yet the one time the main characters address it boils down to an argument where one says “machines are better”, the other responds “no, animals are better!” and they leave it at that. The ethical, psychological, and cultural ramifications of Westerfeld’s creations are largely unexplored (or left to the imagination of the reader). I have to recommend him, though, because his books and characters are so much fun, and although he pulls back whenever it comes time to deal with deeper issues his premises on their own open up a lot of interesting supposition about our own world. Other than Leviathan, Uglies is an excellent starting point for Westerfeld. In all cases for Westerfeld, ignore the covers of his books. They are never indicative of the quality or style of the books themselves.

Scott Westerfeld: website, Amazon, B&N

Rachel Neumeier is another author whose entire corpus is worth reading (although her very first book is less excellent). In particular, The Floating Islands is a ridiculously good standalone, and her griffin mage trilogy (starting with Lord of the Changing Winds) is one of my recent favorite fantasy discoveries (and what introduced me to her). At this point, Neumeier is another one of the few authors whose books I will simply buy without looking at the description because I know they won’t disappoint.

Rachel Neumeier: website, Amazon, B&N

Lastly, Patricia Briggs. Although I have been getting bored recently with her Mercy Thompson series (stereotypical vampires+werewolves urban fantasy is not my thing), her writing is excellent, and I particularly enjoy her early “duologies” like Dragon Bones and its companion Dragon Blood. Mercy Thompson is worth reading, too, if you aren’t burnt out on all the terrible urban fantasy (this is one of the urban fantasy series of late that actually deserves to survive, although I hope Briggs brings it to a close sooner rather than later).

Patricia Briggs: website, Amazon, B&N

The search goes ever onward

There are of course loads of other great books that I’ve read in the recent past (I didn’t even touch the mountain of princess books that I worked my way through recently; I have no idea why I went on a princess kick, but once you start something like that you enter into a self-reinforcing cycle with Amazon’s “other users bought such and such” and “if you liked this, maybe you’ll like that” recommendations. I barely escaped alive). Perhaps I will remember to post about them here at some point.

In the meantime, the search for more wonderful authors and books continues! If you’ve read some ridiculously good fantasy or science fiction (particularly YA or kids stuff; I tend to enjoy adult novels less because of the graphic violence and escapist sex that often are their defining characteristic), I would love to hear!

A whole lot of things are new and improved in Espresso 2, but hands-down my favorite feature is the new Javascript API, which allows you to add custom text actions to the editor using web languages you already know: XML and Javascript. This is seriously awesome; back in the days of Espresso 1.x I created Spice.sugar to allow coding text actions in Javascript, but it was a hack that I was never completely happy with. The new Javascript API is something of a spiritual successor to Spice.sugar, except without the suckiness. It is simpler, better documented, and is true Javascript (rather than Objective-C methods contorted into Javascript).

Sadly, I don’t think people realize how awesome the new Javascript API is, so in the hopes of making people’s lives better and raising awareness for it, I present to you Handy.sugar:

https://github.com/onecrayon/Handy.sugar

Every so often someone writes in to MacRabbit with a feature request that I think is awesome, but which I doubt Jan will want to integrate in the core editor for whatever reason (or that I think he probably will implement, but is currently a low priority). Of course, this was exactly why Jan implemented the Sugar system in the first place: Espresso will never support a broad enough range of actions to make everyone happy out of the box, but it is ridiculously easy to extend.

And so was born Handy.sugar: a collection of some of my favorite feature requests I’ve read at MacRabbit recently, with a focus on actions that allow you to keep your hands on the keyboard.

I am still adding things to Handy.sugar, but here are my current two favorite features (all of the visible features that Handy.sugar adds will show up in the Actions→Handy menu, so you can explore others on your own).

Keyboard of coding +1

Handy.sugar’s actions for incrementing and decrementing numbers in your code are what prompted me to create the Sugar in the first place.

Using the actions is super easy: move your cursor next to a number, and hit command option ↑ to add 1 to the number. As you might expect, command option ↓ decreases it by 1. Add the shift key, and you’ll move up or down in increments of 10.

But wait, there’s more! The incrementing/decrementing actions are smart enough to also handle the following situations:

• If you select a swathe of text that has a number somewhere in it, the action will affect that number
• If you select a swathe of text with multiple numbers in it, the action will affect all of them
• If you have multiple selections, the action will affect any numbers in them (as long as the first selection contains a number; otherwise the action will not be enabled)

For the moment, you can only modify base 10 integers using these actions. I thought about implementing something similar for hex or octals, but thanks to formatting differences across languages could not come up with a good “one size fits all” approach. You can modify floats, but only the portion before the decimal point will be modified. Transitioning between positive and negative numbers should work exactly as you would expect.

Multiple selections for fun and profit

Creating multiple selections in Espresso is easy (it works just like it does elsewhere in Mac OS X):

• Hold down the option key, then click and drag to create a column of selections
• Hold down the command key, and select things with your mouse in multiple places (by double clicking words, triple clicking lines, clicking and dragging, etc.)

But once you have multiple selections, Espresso unfortunately only really supports deleting all of them at once. Until you install the Handy.sugar, that is:

• Hit control [ to prepend text to all selections
• Hit control ] to append text to all selections
• Hit control \ to replace all selections

(Incidentally, if you opt not to type anything after invoking that last shortcut, it will instead replace all selections with the contents of your first selection, which might be useful in its own right.)

If you have been missing column selections from Textmate or block editing from Coda, these actions will likely make you very happy since they perform basically the same functions.

Not just a useful tool

Handy.sugar offers a bunch of useful functionality, of course, but hopefully it will also serve as an example of the kinds of things you can accomplish with the JavaScript API. You can check out exactly how I am accomplishing any given action by right clicking on Handy.sugar in the Finder and choosing “Show Package Contents” or by browsing the source on GitHub. I tried to keep it pretty well commented.

If you decide you would like to try your hand at your own custom Sugar actions using the JavaScript API, check out the introduction to JavaScript actions and then take a gander at the JavaScript API reference.

And if you do undertake some Sugar development, you can always email MacRabbit for help or look for aid in our Sugar developer forums.

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.

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.

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.

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

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!

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.

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

You can read more about the kaboom over on the Espresso blog, or check the Espresso 2 FAQ about upgrades and how to download.

What you will not find just yet are release notes, but for current Espresso users there are some changes between Espresso 1 and Espresso 2 that I wanted to point out to help make the transition between the two versions easier.

General changes

Quick Publish is no longer a file-by-file setting, and does not live in the Tools section any longer. To enable Quick Publish for your project, select an item in your Workspace (or double click a project file to open it in your workspace first) and toggle Quick Publish on there. When Quick Publish is on, all files in your project that you save within Espresso will be pushed automatically to your server. You will still need to use right click and “publish to” if you need to push images or other files that Espresso cannot edit.

Snippets are currently living in the Actions menu (down at the very bottom).

Some third-party sugars are no longer necessary. In particular, Espresso 2.0 offers native support for Ruby, Ruby templates (ERB files), Python, Markdown, Apache config documents, and JSON. If you have third-party sugars for these languages installed, you should remove them before testing Espresso 2.0. (Incidentally, we would really appreciate feedback from Ruby users! No one at MacRabbit actually codes Ruby, so although we think we’ve got some pretty good support for Ruby syntax coloring, it is highly likely that there are problems we have overlooked simply because we are not fluent in the language. Send that feedback in!)

Espresso 1.x themes may not work as well in Espresso 2. Although the HTML and CSS syntaxes have not changed their zone names, Javascript and PHP are very different, and the new Ruby, Python, and Markdown syntaxes do not share many similarities with their third-party antecedents.

The Indent New Line action has a new shortcut: control-enter. When I originally wrote the “TEA for Espresso” actions, I based a lot of them on Textmate (simply because that was what I was used to). However, it makes no sense to have Indent New Line (a very common shortcut for anyone who likes to keep their code nicely indented) require more modifier keys than the action that inserts a <br/> tag. So I swapped them. If you use this command as much as I do, muscle memory is going to be a beast for a little while.

The Actions menu has been shuffled around a bit to hopefully make finding text actions easier and more logical. Aside from Indent New Line mentioned above, shortcuts should remain unchanged.

Noteworthy new and improved actions

On the topic of the Actions menu, a lot of the work that I contributed to this release has to do with the included sugar actions, and there are some tasty additions that you might enjoy knowing about.

Zen coding is now running the latest version (there may be some bleeding edge improvements in zen coding that have not made it in, but if memory serves Espresso 2.0 includes zen coding 0.7 out of the box).

BBEdit ex-pats will likely be happy to find a new Zap Gremlins action in the Convert / Strip sub-menu. For those unfamiliar with the venerable BBEdit, Zap Gremlins will check your document for invisible control characters and non-breaking spaces, and allow you to remove or replace them.

Wrap With… offers the ability to wrap your selected text in arbitrary characters (located in the Text sub-menu). Give it a try; I think you will enjoy how it handles things like square braces, curly quotes, and multiple wrapped characters.

Balance and Balance Inward now work inside of strings (this is incredibly useful; just hit control-B while your cursor is inside a string) and should also function within just about any language that supports code folding.

And if you are someone who works with the Terminal a lot, right click on any file to quickly cd to its parent directory in the Terminal or execute the file itself.

Go forth and test

The Espresso 2.0 kaboom is pretty stable (I’ve been using it and its predecessors instead of Espresso 1 myself for a while without any major incidents), but remember that this is pre-release software and there will be bugs! Drop MacRabbit a line if you find any problems, and I hope you enjoy Espresso 2.0!

But I was rather shocked when I heard about Apple’s release of Final Cut Pro X that didn’t even offer backwards compatibility with the previous versions of Final Cut Pro. “What the hell was Apple thinking?” I asked myself, perplexed. Judging by the backlash John Gruber documented recently, others are equally perplexed (and the ones who relied on Final Cut Pro are angry).

My shock wore off pretty quickly, though, because this is quintessential Apple; honestly, I’m a little embarrassed that I was surprised in the first place.

For years Apple has been working on applying the following philosophy to their entire product line:

It is preferable to sell a moderately priced but feature-limited product to a huge number of people than to sell a high-priced, feature-rich product to a small number of people.

Apple did not avoid its near-death experience in the 90′s by catering to an exclusive, tech-savvy group. They escaped death by selling the bubbly, fruit-colored iMac to people like my grandmother because Apple realized that although wooing over the tech-savvy power users can sometimes be rewarding, everybody has a grandmother.

Certainly, they have not applied this philosophy perfectly over time (and there are a bunch of other factors affecting their decisions), but more and more in the recent past they have been aggressively pursuing it for every one of their products. The iPod, iWork, iLife, iOS, the iTunes store, and most recently Mac OS X itself along with the majority of their other software offerings: all of these have been moving toward increasing mass appeal at the expense of the fringe of power-users.

Does this suck for the power-users? Undoubtedly. Apple always iterates and offers better and better products, but unfortunately the writing is on the wall: power-users would be nice to have, but they are not the customer that Apple cares most about.

Apple cares most about the people who would never in a million years have considered buying Final Cut before. Many posts I’ve read have mentioned that Final Cut feels a lot more like iMovie, and that’s no accident. iMovie is Final Cut’s gateway drug, and if Apple is right (which is a likely bet, given their past performance), they are going to make a quiet killing that far exceeds their previous Final Cut profits even if they lose massive amounts of market share within professional video editing studios.

And they might lose less market share than some doomsayers are predicting. I know nothing about the competing products, but I would not be surprised if Apple hit most of the core needs and manages to retain a decent segment of the professional market despite the negative fallout the initial release is causing. After all, the new product costs a third as much as the old one (or, presumably, its competitors). There will certainly be people who abandon the product, but because Apple is no longer trying internally to compete with those products and companies, Apple will not particularly care.

Final Cut Pro 7 sounds like it was a great professional video editor, but it was only one of multiple choices, which is an unacceptable position for Apple. Apple does not want to compete with other companies; they want to define their own rules, move into unexpected markets, and have other companies vainly try to copy them.

Which is why I should not be surprised by anything that Apple does. Taking their software in a new direction that pisses off the majority of their userbase? Only surprising if you forget that Apple has succeeded by consistently failing to think their target userbase is the same as outsiders think.

As for my personal reaction? Not being a user (or potential user), I am completely unaffected by Final Cut Pro X in the immediate future. However, while I can’t help but admire Apple’s brilliant and ruthless focus on moving into a broader consumer market than their competitors have previously dared to dream of, I am uncomfortable with their increasing trend of ignoring the needs of their power-users who are, in many cases, the most invested in any given platform or product.

But this is totally predictable, because I am typically affiliated with the power-users and every time that Apple says, “We are going to do this thing which will make power-users unhappy but will make a whole lot of other people more willing to give us money” it means that I have lost a little more power and the software and hardware has become, in a way, a little less mine.

(Honestly, I think this is why so much of the bleeding-edge tech blogging world is negative about Apple so much of the time: Apple is relying less and less on them and their ilk for designing products, and a tech pundit without any influence on the tech they are opining about is an alienated, angry pundit.)

Apple is unlikely to change their minds about this philosophy in the foreseeable future. It is making them billions of dollars and leaving them largely uncontested in the markets that they choose to focus on. Since power-users are the fringe for all of those markets (where they are part of the market at all), things are not going to get better for us in the short term.

Thanks to my personal bias, this seems bad to me; power-users and early adopters’ loyalty to a product or platform should not be disregarded out of hand. But for the millions of people for whom software and hardware are becoming less and less to be feared and more and more enjoyable and empowering (the way I have been enjoying and empowered by computers for years), the Apple-driven future is bright.

After much debating, I sensibly planned to finish TapNote 1.2 (which was in the early stages of beta testing at the time), and then start a new app with the Enyo framework to lay the groundwork for eventually porting TapNote to run natively on the TouchPad (the new app being vastly simpler, but using the same basic aspects of the framework as I would need for TapNote). My hope is that the TouchPad and Pre3 will breathe some life back into the platform, and it would be nice to have an app available on day one to increase my own visibility.

Instead of my carefully planned roadmap however, today I am excited to announce two new bits of awesomeness: TapNote version 1.3, and a new product called TapNote Lite. Both are brought to you by the power of user feature requests.

TapNote 1.3

TapNote 1.3 includes two main new features:

Quick Text allows you to instantly insert the current date and/or time to a document. I am pretty proud of this feature; so far as I know, it is a novel approach to a common problem for note-taking apps on the platform, and the implementation turned out to scale through multiple types of usage more elegantly than I originally expected.

If you are a run-of-the-mill user who needs Quick Text rarely, you will find it in the app menu (swipe down from the top left of your screen). Tap it, tap what you want to insert, and you’re done.

However, if you are more of a power user, then you can access Quick Text without ever taking your hands off the keyboard. Simply type something like @date or @d, hold a finger in the gesture area, type the @ key, and the abbreviation will be automatically replaced with the current date (in this instance; @time or @t and @datetime or @dt are also available). You can also use Quick Text abbreviations multiple places in your document, then select everything and run Quick Text to replace them all.

If you are one of the several users who emailed me asking for a way to easily insert date and time information, this will likely be a favorite feature. And if, like myself, it’s not something you would ever have thought to desire on your own, Quick Text will quietly stay out of your way in the app menu until you do need it.

The second new feature, Quick Note, is a Just Type action for the subset of TapNote users who are lucky enough to have a WebOS 2.0+ device. To use it, open your Just Type preferences (type anything where the Just Type bar is visible, scroll to the bottom, and tap Preferences) and add the Quick Note action under the Quick Actions sub-section.

Afterward, whenever you type something using Just Type, you will be able to use Quick Note to create a new note with your text, or append your text to an existing note. This on its own can be astonishingly useful, but it gets better:

• If you have a particular document you are appending a lot of text to in Quick Note, open it up as its own card and instead of an “Append to Document” button that takes you to a screen with a list of all your documents, you will have the option to choose your open document immediately.
• You can use the Quick Text abbreviations mentioned above in your Just Type text, and they will be automatically expanded with the current date and time.
• Quick Note has its own pair of abbreviations that you can use at the very beginning of your text to specify what you want to do (reducing the number of things you have to tap afterward). Simply type @new or @n to immediatley create a new document, and @append or @a to jump straight to the list of documents to choose where to append it.

I’ve been planning to add support for Just Type since HP announced the feature, but what prompted me to do so now instead of later was a feature request from a beta user who was lusting after Just Type support. Thanks to his feedback, I also implemented the dual new note/append to note functionality (because an app can only have a single Quick Action in Just Type at this time).

TapNote Lite

TapNote Lite is a free, feature-limited version of TapNote, and it is the riskiest thing I have ever released. I have played around with the idea of a free trial version since releasing TapNote 1.0, but have never done so because of several scary facts:

1. The app that a free version of TapNote competes most directly (and effectively) against is TapNote.
2. Although I am making next to nothing on TapNote, next to nothing is far better than nothing at all, which is what I will make if future users end up using only the free version.
3. A free version may create a lot more interest in TapNote, but a lot more interest might also mean a lot more support, and unless I am able to convert free users into paid users that support is basically offered pro bono out of the goodness of my heart. Which is soul-crushing and completely unsustainable.
4. In addition to more support needs, users of free apps tend to be more demanding, less comprehensible, and generally less pleasant to interact with (based on my observations of free App Catalog reviews, and experience with MacRabbit support).
5. From what I’ve read and observed, paid apps scale better than free apps. I have always intended to grow TapNote incrementally over time, and priced it accordingly. This has negatively impacted my early sales and user uptake, but has hopefully positively improved existing user loyalty and perception of my services and stability as an app developer.

Worst case scenario, releasing a free version of TapNote runs the risk of killing the app completely by pillaging the few sales that I do have, burning me out on support, and taking the fun out of app development.

So why the heck am I releasing TapNote Lite, you say? Two good reasons:

• If I am successfully able to convert a consistently decent percentage of free trial users into paid users, TapNote Lite has the potential to be the single best marketing tool for TapNote in my arsenal. And I could use a successful marketing tool.
• A WebOS user in Mexico emailed me recently to tell me that he had a chance to play with TapNote on a US friend’s Pre, and he found it perfect for his needs but was unable to purchase it because the paid App Catalog is not available in Mexico. This is unacceptable.

I hope that TapNote Lite will become a potent tool for driving sales, but the truth of the matter is that I am releasing it because I do not want to disappoint this awesome, polite dude from Mexico who dearly wants to use my app. I can’t sell him TapNote on the side thanks the exclusivity clauses in the Palm App Catalog distribution agreement, but for him and others like him I can at least provide the core TapNote functionality for free until HP/Palm hopefully gets their act together and expands the availability of paid apps.

Strategy be damned, it’s about the users

When HP/Palm announced that they were deprecating the Mojo framework in favor of Enyo, and then further admitted that they would not be releasing WebOS 2.0 on most of their existing phones what they were really revealing was that they have decided that the potential cost of alienating their existing userbase and third-party developers was outweighed by the benefits of an influx of all-new users and developers and the chance to start basically from scratch and do it better this time. Little as I like it, they are probably right.

I, however, am not so cavalier. My motivation for creating TapNote was to address my own need for an attractive and minimalist note taking app. I released it in hopes that other people shared that need and I would get a return on the investment of my time, and although the return-on-investment thing has not really panned out I have discovered a second big motivator: I like making users happy. I want people to be able to use my app, because the app makes me happy, and when other people share my excitement and interest in it I am reaffirmed in my estimation of the app (and my own design/development capabilities). I may not be making much of a profit, but I greatly enjoy hearing how other people use it and improving it to make their lives better, even if a feature might not be something I will use myself a lot (like Quick Text) or represents a risk to the overall business of app development (like TapNote Lite).

Of course I hope that some economic success will follow on the coat-tails of a happy user base, but regardless TapNote Lite is an experiment that needs to be made, if only so that the one guy in Mexico who wants to use my app can do so. Because when you come right down to it, marketing, viral word of mouth, third-party reviews, and all those other things that drive app sales are things I can influence but not control. The only two items that are firmly within my sphere of influence are making an awesome, high-quality app; and making users happy, one at a time.

As a result of this suckitude, HP deep-sixed the Palm Inspector, and it no longer works with emulators running WebOS 2.0+, leaving current WebOS developers with an interesting conundrum: how the heck do we debug WebOS 2.0 app styling problems?

Fortunately, there is a way, and its name is weinre (WEbkit REmote INspector, and pronounced “winery” or “wiener” depending on personal preference and maturity level). Weinre is basically what the Palm Inspector should have been all along: you can inspect any kind of app (headless or not), and some things (like highlighting the elements you hover over in the Inspector within the emulator) work surprisingly well. However, setting up weinre is a bit more complicated than the Palm Inspector. Here’s how to go about it on Mac OS X.

Initial setup

1. Download the Mac OS X version of weinre
2. Unzip weinre, and run it once (or you can create the hidden folder below by hand). Quit weinre; we don’t actually want it running yet.

3. Navigate to ~/.weinre/ in the Finder or Terminal.app (in the Finder, open a new window, click the Go→Go To Folder menu item, and enter that path). Using your favorite text editor (*ahem*), create a new file here called server.properties with this line as its only contents:

   boundHost:    -all-

   (If down the road you want to customize your weinre server settings further, this is the file that you will use; more detail here.)

You are now ready for weinre to work its magic!

Using weinre

When you need to use weinre to figure out why on earth your beautiful CSS isn’t behaving as you would expect, do the following:

1. Launch the Palm Emulator (obviously)

2. Open up Terminal.app, and enter this to create an SSH tunnel to the Emulator (hit enter when it queries for your password; no password needed):

   ssh -p 5522 -L 5581:localhost:8080 root@localhost
   

3. Launch weinre, and in the Debugger tab look for boundHosts under “Server Properties”. There should be something resembling either an I.P. address or using the format “computer-name.local”. This is the address that you can use from the Emulator to connect to weinre. So for instance, if your computer is named “epic-burrito”, then epic-burrito.local will be in the list.

4. In your app’s index.html file (and any other HTML files that you want to debug, like dashboard templates), add this script tag in the HEAD (assuming your computer is indeed located at epic-burrito.local):

   <script src="http://epic-burrito.local:8080/target/target-script-min.js"></script>
   

5. Install and run your app, and when you switch back to weinre you should find it in the list of targets. If you are perusing the Elements pane and notice that it isn’t up to date, try switching between different targets and back in the Debugger tab; this seemed to do the trick for me for refreshing widgets that hadn’t shown up in weinre, for instance.

Upsides and downsides

On the one hand, weinre’s WebKit Inspector is far superior to the Palm Inspector (hurray, the console is there!). On the other, the setup is a lot more onerous. Particularly nasty is the need to embed a local reference to the script tag that makes the magic happen. What I’ve done is create a folder with debugging versions of various files in my app (like sources.json), and I’ve added a copy of my index.html to that folder. Then when I need it, I copy it to the root of the project, and when I’m done testing revert the file in my Git repo.

There likely are other problems and gotchas, and I’ll update the post if I run into them; I haven’t tested weinre’s capabilities extensively by any means.

However, given that we literally have no other options (unless you count the bugtastic “Emulator host mode”, which I don’t), weinre is a pretty solid option for WebOS debugging at the moment.

Many thanks to unwiredben for the tip that led me to weinre!

Updates after further testing

You need to place the weinre <script> tag at the very top of your HEAD (before your Mojo framework include and custom CSS <link>).

One big gotcha I’m finding when working with weinre is that default Palm styles are not displayed in the “Matched CSS rules” section. The section properly shows properties in your local rules that have been overridden, and the Computed Styles section works great, but it does not display the Palm styles that are affecting your app. Best I can tell, this is because the Palm styles are included by Mojo writing out <link> tags on the fly, which doesn’t play well with weinre. This can make it difficult to debug specificity problems with your custom selectors.

And to help my readers maintain their sanity, that’s all I will say on that subject. Instead, I’d like to take a closer look at why this version—which from a user’s perspective has merely three visible changes (two buttons and a conflict resolution scene they will rarely, if ever, see)—took me nine months to complete.

An app is not a website

Although I have been writing code for years, most of the things that I have worked on to date have been websites. Typically these are projects with a fairly limited scope, or with a scope determined by a third party. Nothing that I have coded from scratch can properly be called a web app, and my contributions to other people’s web apps have mainly consisted of frontend work to refine or extend an existing design.

Developing TapNote has thus been an interesting experience for me. It is the first true application that I have created, and I am finding that applications (particularly applications that you are both designing and developing) are an entirely different beast from the types of web coding that I am familiar with. A lot of the basics are the same, of course (coding and debugging is pretty similar no matter where you do it), but the overall process is much different.

Because I am so new to application development I have as a matter of course been making mistakes. Looking back over my progress on TapNote since I started working on synchronization until now, one thing in particular stands out as the most prominent cause of my long development cycle.

The dream

Every software developer worth their salt has a dream, and it is a dream of the Perfect Solution. The Perfect Solution is elegant, fast, and does everything they need it to do without edging into feature bloat. The Perfect Solution’s code is well-organized, logical, handles every possible error scenario gracefully, and is easy to extend and maintain. The Perfect Solution is not limited by external factors; should an external dependency prevent the Perfect Solution from achieving perfection, an alternative solution will be developed to work with the Perfect Solution instead.

The dream of the Perfect Solution is a difficult dream from which to wake, and judging from my growing experience as a developer is one of the main culprits for brilliant software that is either never begun or never shipped. In our imperfect world, the Perfect Solution requires such a daunting amount of work to achieve that many people give up without even trying, or find themselves endlessly tweaking the same code over and over until they forget that they ever intended to release it for others to enjoy in the first place.

When I started work on synchronization for TapNote, I was dreaming of a perfect solution. Looking back at my commit logs, the consequences are clear: three months without any work early on as I remained overwhelmed by my own ambition; multiple database schema rewrites, each setting progress back as I had to rework my basic logic planning; code that I wrote, removed, rewrote, and removed again across multiple portions of the app. The list goes on.

Eventually, however, I realized that my dreaming was preventing me from actually accomplishing anything, and at that point I finally started to write some workable code, culminating in TapNote 1.2. Needless to say, the sync feature in 1.2 bears little resemblance to my original plans.

Dreaming piecemeal

I don’t believe the problem is my tendency to dream. My desire for perfection is a driving force influencing me to create and develop; odds are good I wouldn’t have started writing TapNote if not for the inadequacies I perceived in other note-taking apps on WebOS coupled with my vision of the perfect solution.

The problem is that the dream we developers perceive, whole and perfect, is ultimately a lie. Aside from possibly Athena, nothing leaps into this world fully-formed and perfect. Whether we are talking about people or programs, everything needs time to mature into its fullest potential.

What I am finding is that the key to using the dream without being overwhelmed is to break it into pieces.

I don’t remember specifically when this happened, but sometime after my three months of inactivity, I finally sat down and admitted to myself that I was never going to be able to include all the features I wanted in version 1.2 and still ship it. Instead, I wrote out a list of the things that were absolutely necessary for synching to be any use whatsoever. Then I implemented the most basic of those features, tested them, and crossed some of the other features off the list (having discovered that I could live without them, whatever I thought originally). As I continued to write code and test it, I found that even the bowdlerized version of the Perfect Solution I was developing was surprisingly useful, and the more I used it the more it felt like the right approach. Additionally, even though I knew they weren’t ultimately going to result in my Perfect Solution being unleashed upon the world, hitting small milestones (like the first successful push/pull sync) was extremely gratifying.

Grand dreams, simple pleasures

Though it is a lesson I continue to have trouble implementing consistently, ultimately coding applications—like many creative endeavors—is about grand dreams and simple pleasures. The dream is what prods you to undertake the project, while the simple pleasures are the small features that you implement day to day that keep you happy and productive. I’m sure this is self-evident for most experienced developers, but before now I didn’t truly understand how integral iteration is to successful application development. Perhaps this is one of those lessons that you have to experience to fully comprehend; I honestly don’t know.

In any case, with the basic groundwork for sync laid out in TapNote, I am now free to take things one feature at a time as piece by piece I work my way closer to perfection. Let’s just hope I don’t get too distracted by dreaming along the way.

Three weeks short of a year ago, I started work on the WebOS app that would eventually be called TapNote. I had a grand vision at the time: it would be an extremely simple text editor similar to classics like PlainText for iOS or WriteRoom for Mac (both from Hog Bay Software, and both highly recommended). It would synchronize my documents with an online service so that I could access and edit them on my Mac or elsewhere. It would take the WebOS world by storm with its classy design and minimalist approach to text editing. Along with sundry other minor goals and visions for a grand future.

Of those three main goals, I accomplished the first: I released a beautiful, minimalist text editor for WebOS. It turned out that in order to ship anything at all, I needed to slim down my expectations. Sadly, there was no way I could include sync and still release it during the Hot Apps promotion (a self-imposed deadline, since I thought I might have a chance to win some money, and I knew I’d need some external impetus because I had never released an app before), and after I released it in a haze of excitement and started hovering over my sales statistics it quickly became clear that TapNote was in no way taking anything by storm.

I am a stubborn bastard, however, and the happy result is that I am now one step closer to my original dream: TapNote at long last will sync your notes with Dropbox, allowing you to view and edit them from virtually anywhere! (If you’re new to Dropbox, sign up here to give both of us some free extra disk space.)

Even for me, who has written (and often rewritten) every single line of code necessary for Dropbox sync, it feels pretty magical. TapNote 1.2 is the version of TapNote that I wish I could have released originally, and I think the few remaining WebOS stalwarts out there are going to love it.

Dropbox, for the uninitiated

This section is probably unnecessary (after all, when I told my Dad—who is generally not that internet-savvy—that my app update used a popular cloud service to back up its files, he said, “Which one, Dropbox? I love Dropbox!”), but for those of you who are not in the know, Dropbox is a service that makes it ludicrously simple to transfer files from one computer to another. Simply move a file into your special Dropbox folder, and it is instantly whisked up into the cloud and onto whatever other computers are hooked up to your Dropbox account.

Dropbox also has some other nifty features (sharing folders with people, keeping revisions of your files for 30 days, and more), but they are extraneous to the TapNote experience. I leave it up to you to discover and enjoy them on your own.

TapNote in the cloud

TapNote is not a Dropbox client for WebOS; you can only access text files (with the .txt extension). In TapNote, the Dropbox connection is a simple two-part affair: an on/off button in the preferences, and a sync button at the bottom of the main documents list.

After you turn Dropbox sync on, the app will try to make sure that your documents are always both on your Palm device and on Dropbox’s servers. To do so, it syncs when you launch the app, and immediately pushes any changes you make to a document as you make them.

(Just a side note: yes, WebOS is vaunted for its ability to do background processing, but background processing without any interface shown at all is severely curtailed in WebOS 1.4.x, and given the variable amount of time it can take to complete a sync—not to mention the variable amount of CPU usage—it is safer to only attempt syncs when the app is running. I will likely revisit this problem in the future when dropping support for 1.4 is viable, since WebOS 2.0 has a number of workarounds for this issue.)

Once things are synched up, you will be able to access and edit your documents right on your computer from your Dropbox folder. Any changes you make on your device will show up almost instantly, and any changes you make on your computer will show up on the device after your next sync.

It’s dead-easy; just set it once and forget about it until you need it. So far as I know, there are no other highly polished note-taking apps in the App Catalog that make synching your data with the cloud so simple.

The road ahead

With TapNote 1.2 I finally have the basis upon which I can incrementally build some of the awesome features that I dreamed up in my early brainstorming (along with others that have been suggested by TapNote users along the way). Although the next several months will mainly be focused on figuring out how the heck to deal with the nasty curveball that HP threw WebOS developers on February 9th, I suspect you are going to very much enjoy some of the things I have planned.

In the meantime, though, I would love to hear from folks how TapNote 1.2 is treating you! If you have any questions, comments, or feedback don’t hesitate to email me!

As always, you can find information about TapNote at the TapNote website and download it from the Palm App Catalog.

Say I want to download StoryMill 4.0, released today. I visit the main StoryMill page, click the prominent Download link on the left side of the page and…am taken to a page listing all of their software. Okay, well that’s not terribly friendly, but whatever. I scroll down the page until I locate StoryMill, and click the download link, fully expecting to see the Safari download window pop up.

Instead I get a form, requiring that I enter my first name, last name, email address, and operating system. Naturally, I fill it out with fake information because—much as I love Mariner Software, have contracted for them in the past, and know several of the employees personally—they don’t need to know that information.

I arrive at a page that reads thusly (emphasis theirs):

Note: In an effort to reduce SPAM on our site, we ask you to verify your email address. An email has been sent to the email address you just entered with a link to our downloads page. You will not need to do this for future visits to this page.

If you use a spam filter and don’t receive a confirmation email back from us immediately, try checking to see if the email wasn’t routed to your spam folder.

Thank you for your understanding.

No, Mariner Software, I don’t understand. At all. Reduce spam on your site? How the hell does my downloading your trial software cause spam? I am not registering for an account. I am not attempting to post in a forum. I am trying to download a software trial, and you are making it as hard as humanly possible. You have placed six to nine steps in between me and your software:

1. Click the download link (the only step required by most software developers)
2. Find the product on a large page
3. Click the right download link once I have found the product (there are numerous downloads listed for most products)
4. Fill out personal information, with no indication if I am opting into communications that I may be completely uninterested in receiving; submit the form
5. Check my email (in an entirely different program); find the email from Mariner Software, which may well be marked as spam (accurately, in my opinion; hey, I didn’t really solicit this)
6. Click the link in the email

And although I haven’t completed this process, I am guessing from the horrifically poor design choices I’ve come across up to this point that clicking that link will probably take me back to the main list of downloads. Whereupon I will need to first remember what the hell I was trying to download, then find it in the page again, and finally click the damn download link a second time.

No. I refuse. This is not user unfriendly, this is actively user hostile. The entire interaction is pointlessly intrusive, and I bet that you’re storing the information about whether I’ve jumped through these ridiculous hoops as a cookie, aren’t you? So when I try to download StoryMill 4.0 on my iMac (or switch browsers on my MacBook), I’ll have to repeat the whole pointless process (at which time it will be pointless for you, as well, since you already have my information).

Unless you are selling the personal information you are gathering through this process on the side, your only business is selling me software, which means that this ridiculous download process is likely actively hurting your bottom line because it is a huge disincentive for users to actually try your software. Imagine I was a less web and software savvy user who didn’t know that I dearly wanted StoryMill 4.0. Would I even remember, once I checked my email who knows how much later, which product I was trying to download? Would I take time to try and figure it out? Or would I go purchase the vastly more well-known Scrivener, whose download link simply downloads the software?

Mariner Software, I sincerely hope you will reconsider your download flow. The current implementation is only hurting yourself.

If you, gentle reader, are not from Mariner Software and wish to send them some feedback along these same lines, you can do so through the Mariner Software contact form.

-- Script Name: hello
-- Version: 1.0
-- Description: Say "hello" in various interesting ways
-- Author: Ian Beck <http://beckism.com>

-- Usage: /hello folks!
-- Output: [Greeting] folks!
-- (can also use alone for just the greeting)

on linkinuscmd(name)
	-- Get a random item from the list of greetings
	set response to some item of {"Aloha", "Bonjour", "Ciào", "G'day", "Guten tag", "Hallo", "Hello", "Hey", "Hola", "Salaam", "Shalom"}

	-- Add the name, if we are using one
	if name is not equal to "" then
		set response to response & " " & name
	end if

	return response
end linkinuscmd

-- Changelog:
-- 1.0:
-- - Initial release

To install the command, pop open your favorite Applescript editor (like the free AppleScript Editor that comes with your computer, or Script Debugger if you’re all fancy-shmancy), paste in the code above, and save it as hello.scpt at this path:

~/Library/Application Support/Linkinus 2/Scripts/hello.scpt

The next time you launch Linkinus, you will be able to enter /hello with an optional name or similar, and it will output a random greeting followed by whatever you typed. So for instance, you type /hello folks! and what shows up in the chat room is “Aloha folks!” Or maybe “Hola folks!” Or possibly “Guten tag folks!” Or any number of other greetings.

If you want to use a different selection of greetings, you can modify the list on line 12 of the script.

Granted, figuring out a random greeting in Linkinus is probably not a problem most people have (“IRC? What on earth is that?”), but for those of you who are also annoyed by this repetitive task, enjoy!

This is an incredibly handy feature, and Jay Canuck and Doug Reeder both posted code snippets to help you integrate it into your own app. However, their code has some downsides: you have to implement it for every scene, it doesn’t animate, and extending prototypes is ugly.

Here, then, is a reasonably simple way for you to enable animated two-finger power scrolling in all scenes of your WebOS app.

To do so, we’ll use Prototype.js class inheritance to create a generic base class with two-finger scrolling support that can then be added to any of your scene assistant classes to toggle on power-scrolling.

The first step is to create a new file (location doesn’t matter, although mine is stored in /app/assistants) and add it to your sources.json file. In my instance, I called it power-scroll-base.js so the new line in sources.json looks like this:

{"source": "app/assistants/power-scroll-base.js"},

(Trailing comma is there because this is not the last item; if yours is last in your file, you won’t want that comma.)

After you have the file created and added to sources.json, add these contents to it:

/*
PowerScrollBase: a Prototype base class to quickly add power scrolling
to your existing scenes

Created by Ian Beck <http://beckism.com>
Released in the public domain

Many thanks to Jay Canuck and Doug Reeder for the basic idea and code:
- http://pastebin.com/6JqcQT4a
- https://gist.github.com/786358
*/
var PowerScrollBase = Class.create({
    // === $SUPER CALLS ===

    initialize: function() {
        this.twoFingerStartBound = this.twoFingerStart.bind(this);
        this.twoFingerEndBound = this.twoFingerEnd.bind(this);
    },

    activate: function() {
        // Add listeners for two-finger gesture events
        Mojo.Event.listen(this.controller.document, "gesturestart", this.twoFingerStartBound);
        Mojo.Event.listen(this.controller.document, "gestureend", this.twoFingerEndBound);
    },

    deactivate: function() {
        // Stop listening to two-finger gesture events
        Mojo.Event.stopListening(this.controller.document, "gesturestart", this.twoFingerStartBound);
        Mojo.Event.stopListening(this.controller.document, "gestureend", this.twoFingerEndBound);
    },

    // === EVENT METHODS ===

    twoFingerStart: function(event) {
        this.gestureStartY = event.centerY;
    },

    twoFingerEnd: function(event) {
        var gestureDistanceY = event.centerY - this.gestureStartY;
        var scroller = this.controller.getSceneScroller();
        var pos;
        if (gestureDistanceY > 0) {
            scroller.mojo.revealTop();
            pos = scroller.mojo.getScrollPosition();
            scroller.mojo.scrollTo(0, pos.top - 50, true);
        } else if (gestureDistanceY < 0) {
            scroller.mojo.revealBottom();
            pos = scroller.mojo.getScrollPosition();
            scroller.mojo.scrollTo(0, pos.top + 50, true);
        }
    }
});

This works by listening to the WebOS two-finger gesture events. When the gesture starts, it notes the Y position. Then when the two-finger gesture ends, if the Y position has changed it uses Mojo.Widget.Scroller.revealTop() or Mojo.Widget.Scroller.revealBottom() to immediately jump to the top or bottom of the scene scroller (Mojo.Widget.Scroller documentation here). However, this instantaneous jump is not very user-friendly because there’s no good visual indication what just happened, so the code then grabs the scroller position and bumps it 50 pixels beyond its bounds with Mojo.Widget.Scroller.scrollTo() (with animation enabled). This triggers the “you’ve reached the end of the scrollable area” bounce, which effectively communicates to the user that they have jumped to the top or bottom of the scene.

To use this code, you need to make a few changes to your existing scenes (assuming that they are already laid out as Prototype classes—if not you will need to first convert them). For instance, if you have an ExampleAssistant, you would modify it to look like this:

var ExampleAssistant = Class.create(PowerScrollBase, {
    initialize: function($super) {
        $super();
        // Do other initialization
    },

    activate: function($super, event) {
        $super(event);
        // Do other activation tasks
    },

    deactivate: function($super, event) {
        $super(event);
        // Do other deactivation tasks
    }
    // Presumably you will have other logic in this class, as well
});

This works by using Prototype.js’s class inheritance and special $super keyword. When the first argument in a class method in Prototype is $super, Prototype will internally modify the method so that external calls ignore the $super argument, but within the function you can call $super() to invoke the overridden copy of the method on the base class. By using PowerScrollBase for your base class and $super in your initialize, activate, and deactivate methods you can enable power scrolling very quickly in any scene within your app.

Here’s hoping that power scrolling catches on more broadly within the WebOS community; it’s one of those gestures that you will rarely discover on your own, but once you know it can make your life a whole heck of a lot easier.

I’m thinking of commissioning a dedicated site for teaching the basics of blogging. Unless somebody knows of a really good one already?

I’ve never come across a good site for beginning bloggers myself. Most of them are spammy content farms, one-off posts about blogging on otherwise unrelated blogs, or “how to blog” sites that are started with good intentions and abandoned a month or two later when the author runs out of steam.

It’s an intriguing idea, though. After all, blogging is an increasingly popular activity, and it’s one of those things that you never really master. Like any type of writing (or art, depending on what you’re posting), blogging is an on-going project, your style and approach subtly changing every time you put words to page (or, in this case, bits to screen).

As I thought about such a site, what I ended up wondering is what constitutes the basics of blogging? It’s an incredibly wide topic. At a magazine, an author may write an article, but other people are responsible for laying it out, designing the surrounding pages/cover/etc., marketing it, and handling revenue streams. Most bloggers, however, handle all of that and more.

Blogging is finding and choosing the software or platform to host your blog. Blogging is then finding or creating a design for your blog.

Blogging is HTML, CSS, Markdown, Textile, WYSIWYG, and countless other systems for formatting your text.

Blogging is basic writing skills; tone, narrative, grammar, punctuation, and all the rest.

Blogging is being author, copy editor, editor, and publisher all at once.

Blogging is journalism. Blogging is personal opinions. Blogging is keeping in touch with friends and acquaintances.

Blogging is good photography. Blogging is screencasts. Blogging is videos. Blogging is podcasts.

Blogging is learning the software necessary to produce your content, be it images, audio, video, or more. Blogging is knowing how to optimize content for delivery over the web.

Blogging is being happy enough with your work to share it, but unhappy enough to keep trying to improve it.

Blogging is targeting a niche. Blogging is ignoring potential audiences completely and publicly sharing your passion.

Blogging is learning to read statistics about your site’s visitors, whether for practical reasons or navel gazing. Blogging is analyzing your site’s traffic and working to improve the blog’s appeal or usefulness or advertising revenue.

Blogging is finding a way to monetize your hobby. Blogging is entirely personally driven, and need involve no monetary kickback at all.

Blogging is marketing your content. Blogging is trying to catch a lucky mention or link to swell your readership. Blogging is not giving a damn about whether people visit your site, and publishing for the sake of creating something interesting, public, and potentially useful for others.

Blogging is a hobby. Blogging is a job. Blogging is a passion.

Blogging is sharing something you have created online. And then doing it again tomorrow (or next week, or next month, or next year). And again.

Blogging is as varied as the people who call themselves bloggers.

I hope that Jalkut does in fact start such a site. Given the wide range of topics blogging encompasses, I suspect a properly moderated and maintained site focused on the act of blogging would be useful and interesting even to people who are already comfortable writing blogs, and as a purveyor of blogging software Jalkut is uniquely situated to benefit from such a site without needing to fill it with ads or articles focusing solely on monetization.

But I will not be buying another upgrade, because I am sick of Adobe and their bullshit. I have grown increasingly disenchanted with Adobe for several years, but the last straw for me was my recent attempt to update to Photoshop CS5.

I have purchased the CS3 Web Premium bundle and the CS4 Web Premium upgrade, but since I barely use anything except Photoshop anymore I decided this time around to upgrade Photoshop only. I went through the Adobe store checkout process, ordered my CD, and it arrived recently.

When I went to install it, however, I ran across a hitch: the installer wouldn’t accept my CS4 Web Premium registration number as my license to upgrade.

Turns out that Adobe only offers upgrades on single products if you have purchased a previous version of that single product in the past. You cannot upgrade a bundled copy of Photoshop. Of course, they don’t tell you this anywhere in the store that I noticed while checking out.

So I’m done. I had been planning to upgrade Photoshop to CS5, and then likely the whole bundle to CS6 when it came out. After this little stunt on Adobe’s part, though, I think I would rather make a public promise not to spend money on Adobe software anymore. Adobe is a classic example of a company who doesn’t give a shit about their existing users, and I am fed up with it. I will make do with Photoshop CS4 and let them go alienate someone else.

The classic Adobe experience for me was when I was upgrading CS4. I called their sales number because the web store was being wonky on me, and the guy I got into contact with was great. Wonderful speaking voice on the phone, extremely helpful, clear, and concise. It was a great experience. At the end of the call, he transferred me to their technical support (I had some account management issues that he was unable to deal with), and I spent a good 45 minutes wading through the classic outsourced tech support experience. Low speaking voice, heavy accent, apparent inability to understand my non-accented English, unhelpful, and ultimately did not do what they said that they would to help me. That dichotomy stuck with me as the perfect example of how Adobe approaches its customers. If you are a potential buyer, they will treat you great. After the fact? You should consider yourself lucky that Photoshop crashes every time you quit, and leave them the hell alone.

I have tried writing to Adobe. It doesn’t work. The only thing that I can do is vote with my feet.

Good-bye, Adobe. For a company that made software that really lit a creative fire under me years ago, you certainly turned into a disappointment.

Yet as a web developer who has been observing the recent landscape of the latest incarnation of browser wars, I have to say: we as web developers and web users need Internet Explorer.

Not IE 6, of course. That shit needs to die, and the sooner the better. There is no excuse for someone still using a browser that old and insecure.

But in general IE, with its massive (if shrinking) userbase and slow acceptance of burgeoning web standards, is a good thing because it forces us to stop and think about what we’re doing. Web developers have a problem, which is they tend to want to jump on the latest developments as soon as a major browser offers them, and because two of the major browsers (WebKit/Safari and Firefox) are open source they often have bleeding edge functionality implemented before it’s even a twinkle in the W3C’s eye.

This is bad for several reasons:

• Early implementations are often confusing or poorly designed. Take a look at -webkit-gradient, for instance (the first available in-browser gradient syntax) and then compare it to Firefox’s implementation (which is the W3C recommended syntax). Firefox’s is legible, WebKit’s requires a documentation lookup every time you want to use it to try and remember what order all the darn properties go in.
• Differing early implementations mean that sometime down the road, someone is going to have to change before it can be accepted as a general standard. When web standards change, it breaks sites. Granted, WebKit will likely provide backwards compatibility for their gradient syntax, but for how long after they switch to the spec? At some point, if you have coded a site with WebKit gradients and forgotten about it, that site will likely break. Of course, IE doesn’t support gradients yet, which means that if you want to use them you’ll need to come up with a workaround for browsers that don’t support them, making your site not only backwards but forwards compatible.
• Web developers tend to forget how much hardware can matter. The other day, I create a CSS-only image zooming effect as a proof of concept. When I showed it to another developer, their comment was “Wow, is that slow!” For me, the transition takes less than a second, but because of hardware differences his experience was completely different. Yes, hardware affects everything, but considering that I can replicate the CSS transition in Javascript (which has been ruthlessly optimized over the years) without degrading performance on either end, Javascript is the clear better choice at this point in time.

The web moves fast. Open source browsers move fast. IE’s slow movement can feel frustrating for developers who see their lives getting easier thanks to improvements on the bleeding edge, but trust me: it is a good thing that Microsoft spends so much time considering what to include and what to exclude. Web developer’s lives may be a little bit more onerous now, but because we are forced to wait on irregularly implemented and insufficiently optimized new technology we end up creating sites that perform correctly for more people (and will continue to perform correctly for more years down the road), web standards have a chance to arrive at more elegant solutions than they would otherwise (making coding for those features when they are widely available far easier), and we web developers are reminded that what we see locally on our computer is not necessarily what the rest of the world will experience when they visit our site (leading to better tested and more resilient designs).

Firefox would prefer to reduce the argument over what constitutes a modern browser down to a list of bullet points because that makes Firefox look best, but to do so belies the greater picture. You wouldn’t want to drive a car with only an accelerator; you also need to have brakes.

Just sayin’.

About ten months ago (or April 2010 for those who don’t like to cross-reference dates) and in the midst of the highest level of pessimism about Palm’s survival that had occurred to date, I went out and bought a Palm Pre Plus from Verizon to replace my iPhone.

“Wow,” some of you are thinking. “Why on earth would you do that? Were you taking stupid pills?”

No, the pills that I was taking were more commonly known as the “fed up with AT&T and uncomfortable with Apple’s increasingly closed environment” pills. A free dose came packaged with my vitamin supplements.

And it didn’t hurt that Verizon had too good a deal to pass up (free web tethering for the life of the device was something I couldn’t easily ignore, and the fact that a device with the same specs as the iPhone 3GS cost me a measly $50 was pretty awesome, too).

(Author’s note: as of this writing, the Palm Pre 2 is currently available on Verizon with the same free-tethering deal. I was tempted, but I’m holding out for the Pre3 which has far better promised hardware. However, for anyone who wants WebOS 2.0 right now, oh my god I can’t wait, that’s a surprisingly excellent deal.)

For those of you who enjoy digging into multi-thousand word product reviews, I’m about to make you very happy. If, however, you just want the quick and dirty version, well here it is:

The Palm Pre is physically smaller than the iPhone, and despite similar specs feels slower thanks to WebOS’s resource-intensive nature (likely exacerbated by the iPhone 4′s even better hardware, but I haven’t used one of those much in person). It is also a dream to use, has changed my entire conception of the ease of use of Apple devices, and continues to delight me on a day-to-day basis almost a year after I purchased it. Even with the iPhone recently released on the Verizon network and my dissatisfaction with HP’s handling of the future, I wouldn’t switch back.

Put that in your pipe and smoke it, Apple.

What makes a smartphone?

The smartphone market has been indelibly changed thanks to the iPhone, and I’m very glad that I used one for a while (although I was by no means an early adopter; I bought a used original iPhone when the 3G was announced). It’s not often that a product completely redefines a market in such a short time, and in the iPhone Apple definitely made good its reputation for creating visionary products.

Thanks to Apple’s influence, there are now four things that make up a quality smartphone:

1. Hardware; the phone itself
2. Operating system; the core software
3. Bundled software; what the phone can do out of the box
4. Apps; third party software for extending the phone’s functionality

(Used to be the only thing that mattered was hardware, and the software was always shit-tastic or crazy complex. Thank goodness we’re past that.)

A fifth item, the wireless network, is also usually a factor, but since we do not yet know what networks will support the Palm Veer or Pre3, I can’t really comment on it.

An overview of the Pre

It is safe to say that without the iPhone, the Palm Pre and WebOS would never have existed. It only takes a couple of minutes with the device to realize that it has been heavily inspired and influenced by the iPhone, both in the areas where Palm has imitated Apple and those where they have departed.

The Palm Pre Plus has roughly the same specs as an iPhone 3GS, but with a smaller screen and a WiFi mobile hot spot. If you care about that sort of thing, I encourage you to check out other Palm Pre reviews.

However, the form factor is quite different. The Pre is quite a lot smaller than an iPhone (both physically and in the size of the screen), but also thicker thanks to its slideout hardware keyboard.

The WebOS operating system also follows some very similar lines to iPhone OS, particularly where it comes to user interactions. You tap things to interact with them, flick the screen to scroll, pinch to zoom, and slide across items in lists to delete them. The biggest difference is the gesture bar below the screen where you have a small number of universal gestures that you can use to control the phone.

Hardware

The word I’ve seen used most often for the Palm Pre’s hardware recently is “aging”. When I originally wrote this review that was accurate; now it’s more euphemistic. The Pre 2 seems like a step in the right direction, but does not offer the amount of improvement that I was hoping for. The Pre3 seems like a much larger step in the right direction, but of course won’t be available for six months or so.

Despite the lackluster hardware compared to recent smartphones, however, I’ve still been very happy with my Pre Plus. At this point in its lifespan, the Pre isn’t going to make your jaw drop, but the form factor and hardware options have proven well capable of providing me with a good experience.

I don’t have the expertise to intelligently discuss things like the camera (which is the best camera in a phone I’ve used, but that’s not saying much), and I have no interest in quantitative testing of the other hardware specs. What I can say, however, is that the Palm Pre’s form factor is a refreshing departure from the blocky designs that have been running rampant in the iPhone and Android camps. At first I wasn’t sure if I’d like the smaller screen, but I’ve found that it’s worth it for the smaller form factor (which is a lot easier to carry around and manipulate with one hand than my iPhone ever was). I can see why Palm has stuck with the basic Pre design through three iterations of hardware with little deviation. The form factor is easy to scoff at if you’re used to a brick-shaped iPhone or Android, but the more you use it the more you’ll appreciate it.

I’m ambivalent to the Pre’s hardware keyboard. I like that the keyboard doesn’t take up screen real estate, but it also requires two hands to type anything. Additionally, Palm seems to have assumed that because they have a hardware keyboard they didn’t need to take as much care with their autocorrection system as Apple, which is a shame. In particular WebOS doesn’t have nearly as many corrections for mis-typing that occurs when you hit an adjacent letter instead of the one you’re going for, which is just as much a problem on the Pre as it is on the iPhone thanks to the tiny key size. I fortunately have pretty dexterous, slim fingers. Someone with large fingers would not be happy with this keyboard. Additionally, ten months into the life of the device some keys are starting to be unresponsive when I click them. This is a major issue, and annoys me almost every time I need to use the keyboard recently.

Although several of the Palm Pre reviews that I’ve read have mentioned build quality as one of the downsides to the phone, I personally have never experienced any problems (aside from the keyboard key issue I just mentioned). The keyboard slides out nicely and locks into place, the keypad is a pleasure to type on (when the keys function), and nothing is cracking or sliding out of alignment. Your mileage may vary, of course. Certainly you’ll have more risk of physical problems with the Pre than with a brick like the iPhone that practically doesn’t have moving parts.

Most of the Pre’s hardware may be losing its pizazz compared to the competition, but there are two areas where the Pre is flat-out fantastic even today.

First, the built-in mobile hotspot. It’s ridiculous how easy it is to turn your Pre into a wireless hotspot and use your 3G connection with whatever WiFi device you happen to have nearby. The mobile hotspot functionality is a fantastic confluence of hardware and software; it just works right out of the box. With AT&T still floundering about trying to figure out its data plan and tethering support options, the mobile hotspot functionality of the Pre is a great reason to buy the phone all on its own.

Second, the Touchstone wireless induction charging station. It may have cost as much as the phone, but this has literally changed my life.

You may not realize it, but if you are currently using an Apple iDevice you are shackled to your desk. In order to charge and sync an iPhone you have to plug it in, wait for iTunes to start up, sit through the synchronization process (which can take a while, given the need to back things up), and then wait for the thing to charge. This seems like a small thing if you aren’t used to anything better, but it’s not. This is a huge amount of headache for a device that doesn’t need wires to function at all.

With induction charging, I set my Palm Pre down and it starts to charge. When I need it, I simply pick it up. It synchronizes contacts, calendars, and so forth wirelessly over the 3G connection (or wireless, if available), and backs the phone up the same way (this is through the “cloud”, folks; no need to have my computer on, be on the same network, or any of that rigamarole). The only time I have to physically plug the thing into my computer is when I want to transfer music onto the phone or video off the phone.

This is the way things should be (actually, it should wirelessly sync music through my local WiFi network, too, but whatever). When I finally caved and bought an iPad, it felt like a huge leap backwards to boot it up for the first time and see an iTunes logo with a USB cord image staring me in the face. The Palm Pre is the first wireless device that I’ve owned that is truly wireless with all the headache relief that entails.

The operating system: WebOS

Quite simply, WebOS is why you should be using a Palm phone. Their hardware is adequate but mostly subpar compared to the competition (with the exceptions I noted above), but WebOS is fantastic. I have no regrets abandoning iOS for WebOS.

Of course, things are not all sweetness and light. WebOS uses HTML, CSS, and Javascript to power its apps and because these are all high-level interpreted languages the operating system requires much more raw power to perform up to speed. Compared to the iPhone, the Palm Pre feels slower and less responsive, particularly when scrolling. How unresponsive will vary depending on how many apps you have running at once, but even when I only have one app open scrolling doesn’t feel as immediate as it does on the iPhone because the page simply doesn’t keep up with my finger in the granular way that iPhone scrolling does. There’s often a slight delay, or the page will scroll slightly out of sync with what my finger is doing (either dragging a little bit behind, or moving a little too far after I let go). If you’re very quickly flicking through a long list, things behave about as they do on the iPhone, but as soon as you start dragging slowly to scroll a little bit at a time you’ll start to feel the difference.

Additionally, the use of the gesture bar below the touchscreen has its bad points. For one thing, there isn’t a whole lot of feedback when you successfully perform a gesture. Sure, the lights in the middle are supposed to flicker, but sometimes I’ll perform a gesture, the lights will flicker, and nothing will happen. This can be frustrating, since without visual feedback the whole gesture idea crumbles a bit.

The second downside of the gesture area is that it makes it more difficult to use the phone initially. On the iPhone, any idiot can use the thing because everything you want to do is staring you in the face. Want to go back to the previous screen? Tap the Back button. Want to close the app? Click the home button. It takes maybe thirty seconds to a minute of playing with an iPhone to figure all that out through straight trial and error.

Picking up the Palm Pre, however, takes a little more learning because there is never a back button: instead you have to know that swiping from right to left on the gesture area will perform the universal “back” gesture. Granted, there’s only two gestures that you need to know to get up and running, but this still provides a steeper learning curve than the iPhone, and it’s highly unlikely you’ll discover the gestures on your own without prior knowledge.

Of course, the plus side is that once you’ve learned the gestures, life improves drastically. Having a universal back gesture means that apps never have to complicate their interfaces with back buttons leaving you with less visual clutter in your apps.

The last major downside of WebOS is the text editing. I’ve already mentioned the less-robust autocompletion engine in WebOS compared to iOS, but cursor placement and text selection is equally frustrating. Like on the iPhone, you tap to place the cursor. However, if you then want to move the cursor (because your relatively huge, inaccurate finger placed it a character or two away from where you wanted) you have to hold down the symbol key and drag anywhere on screen except on top of the cursor. This is fantastically frustrating for several reasons:

• First, you’ll never discover this on your own. I noticed when I pressed the symbol key that the cursor turned into an arrow, but had to go digging through the documentation to figure out what this even meant.
• Second, this interaction removes all of the immediacy of touch. I may as well be using arrow keys on a keyboard (in fact, I’d prefer that, because then at least it would be accurate). On the iPhone I tap and hold to get a magnifying glass that shows me exactly where the cursor is under my finger. This is far more efficacious than dragging around on an unrelated part of the screen and watching a little compass rose jump around.

Similarly, if you want to select text you have to hold down the shift key and drag on screen somewhere away from the cursor. I inevitably find myself overshooting, unable to get the selection to encompass the right characters or lines. And heaven help you if you try to drag the actual cursor. You won’t be able to see what you’re doing, and half the time it doesn’t do anything, anyway.

On a different note, one of the best parts of WebOS is the card-based multi-tasking metaphor. iOS pseudo-multitasking (which I’ve been using on the iPad for several months) doesn’t hold a candle to WebOS. Palm’s multitasking is immediately obvious, elegantly easy to manipulate, and places more power and choice in the user’s hands. After using my Pre for about a week, I booted up my old iPhone to do something, and found myself trying futilely to perform the upward swipe to get to the card view.

Additionally, although the “swipe upwards” gesture to access the Launcher (where your app icons are stored) is hard to discover, I love the launcher itself. Yes, it would be nice to have more than three pages of apps, but I have found that practically I only use about as many apps as fit comfortably into three visible pages, anyway, and scrolling to the others isn’t a big deal. What’s great about the launcher is that it doesn’t clutter up your phone with icons. iOS devices now feel incredibly busy to me, with every screen having apps screaming “use me, use me!”. On WebOS, apps are there when I need them, but by default I get a beautiful (and clean) desktop image.

As a former iOS user, WebOS’s notifications system was another breath of fresh air. Notifications slide quietly up from the bottom of the phone and wait there until you wish to deal with them, allowing applications in the background to inform you of whatever without interrupting your current task. Thanks to WebOS’s true multitasking, some apps do not even need to be running as a card to post notifications (the email and SMS clients are great examples of this) or are capable of running solely in the notifications area. This is worlds away better than iOS’s modal dialogs and icon badges, and I would be hard-pressed to go back.

Another standout feature of WebOS is Synergy. Synergy on a WebOS phone means that you can log into several web services (like Gmail and Facebook) and have your contacts downloaded, synched, and intelligently merged together. So if your Gmail account has your friend’s email, and your Facebook has your friend’s phone number, Synergy knows to combine them into a single person with all of that info available. That info can then be extended by third party apps, or used within third party apps (with your permission, of course).

There are lots of other great little touches in WebOS compared to iOS, as well (dropdown menus that don’t necessitate jumping onto a new screen, a universal menu with battery info and a shortcut to turn on airplane mode, app menus so that common things like preferences don’t have to take up screen real estate all the time, and more). Suffice it to say that WebOS is hands down the best reason to consider migrating from an iOS device to a Pre.

Bundled software

Not much to say here, really. The email, calendar, and contact apps are excellent (particularly with their synergistic sharing of Google logins, for instance). Apps like Tasks or Memos are visually appealing, but almost completely useless. The music playing app words great, except that you cannot create playlists, and other apps like the browser, videos, and Google Maps apps are competent but nothing to write home about.

As I mentioned above, the wifi hotspot app is shockingly easy to use, and a good example of an app that Palm got exactly right. My only quibble with it is that it does not give any indicator for how much bandwidth I am consuming (but then again, neither does Verizon; wouldn’t want me to know if I’m likely to be charged for exceeding my limit, would we?).

The third party question: apps

I have mixed feelings when it comes to the apps on WebOS. On the one hand, I am now able to code apps to meet my own needs, something that I never felt capable of doing on iOS. On the other, the app catalog has relatively few standout third party applications, and finding the good ones amidst the dross of sound effect apps, one-off ebooks, wallpapers, and ringtones is challenging at best.

Fortunately, with the help of third party apps I am able to do everything I needed to do regularly on iOS (like check bus schedules, access visual voicemail, use Twitter, and so forth). However, a number of the third party alternatives are not as appealing as their iOS equivalents, or just flat-out don’t work as well. A good example is the visual voicemail client, which cannot play audio through anything but headphones or the speakerphone thanks to limitations in the OS, and is generally a lot less aesthetically pleasing than anything Apple has produced. Another thing I miss: although wholly functional, none of the RSS readers are remotely as awesome as Reeder or numerous other iOS RSS alternatives.

When you come down to it, I cannot recommend WebOS based on its existing third party apps. I think this is likely to change (and if you are a developer and willing to roll your own solutions, it’s a great development environment), but right now the app scene is nowhere near as exciting, vibrant, and interesting as the iOS app store. If you are trying to figure out if switching from iOS to WebOS is viable for you, definitely take a long hard think about exactly what apps (or features of apps) you would find a hard time living without and check to see if an equivalent exists before you jump ship.

The final verdict: is it worth it?

I must admit that—despite my incredibly positive experiences with the Palm Pre Plus—at this point in time it is likely not worth buying a Palm Pre. If you absolutely must have a new smartphone, and don’t mind missing out on the promised awesomeness of the Pre3, then a Pre 2 might be an excellent investment (particularly with Verizon’s free tethering deal) as long as knowing that next-generation hardware is just around the corner does not rub you too raw.

On the other hand, if you are going to be in the market for a new smartphone within six months or so, then a Pre (or its little sibling, the Veer) will be well worth your attention. Announcing their hardware so far in advance was a pretty dumb move on the part of HP in many ways, but the positive side of it is that we know that their upcoming phones at least have some exciting features (how they stack up with their competition when they are finally released I leave to you to discover, although I suspect given the historical rate of change, at least WebOS and iOS will remain similarly matched).

The bottom line for me is that I have loved—and still love—my Pre Plus on Verizon. As a developer, I am not very happy with HP’s handling of upcoming changes to WebOS and their devices, but as a user and iOS-switcher I am far more optimistic. We will see if HP delivers on the promise of their recently announced hardware and software changes, but in the interim I am more than happy to continue using my Pre Plus.

Moments later, I receive an email:

Dear ianbeck

We have found that your email is shared in tweets. We advise you to hide your email from spammers by sharing email address as an image or hide it behind a url.

Visit us at : [REDACTED] to find how you can do this.

Happy Twitting !!!
“2 million emails are sent every second. About 70% to 72% of them might be spam and viruses.”

(I’m a little sad that the web doesn’t let you see all the lovely extra spaces in the message, too. It is truly a work of negative-space-leveraging art.)

I was curious how you would classify this email, and Wikipedia provided a concise definition:

E-mail spam, also known as junk e-mail or unsolicited bulk e-mail (UBE), is a subset of spam that involves nearly identical messages sent to numerous recipients by e-mail

This message is unsolicited email. Based on the format of the email, it is apparent that they are sending this nearly identical message to numerous recipients.

So why would I trust a spammer to protect me from spammers?

Oh, right, I wouldn’t. Blocked and reported for spam.

The ways that people find to abuse Twitter never cease to amaze me.

Incidentally, I have just finished twitting the fools who sent this email. Had I posted to Twitter instead, I would be “tweeting”. Words matter, people. Even if you’re a sleazy spammer.