However, over time I realized when I visited other sites that did similar things that I really hated it, and I stopped publishing Amazon affiliate links. Clearly marked affiliate links are one thing; I have no problem with sites that review a product in depth and at the end say something like, “Hey, if you buy this product through this link I’ll get a little kickback.” It’s a great way to thank blog authors for taking the time to write an article that introduced you to a product you expect to love.

But all too many sites will route you to Amazon affiliate links without any sort of warning, and that just feels incredibly skeezy to me. For me, discovering that I’ve clicked an Amazon affiliate link without prior warning throws into question the veracity of the site where I found it. Is this product actually something I will enjoy, or were they just looking to make a quick buck?

The problem is particularly acute on Twitter and elsewhere where shortened URLs have thrived. Often, it isn’t possible to discover if a link is an Amazon affiliate link until you’ve clicked through it.

Personally, I like having control over whether or not I am going to give someone a kickback through an Amazon affiliate link, so to that end I created Affiliate Me Not: a new Safari extension that does just that (note: requires Safari 5.1).

If you install Affiliate Me Not, when you try to visit an Amazon page with an affiliate tag in the URL, you will see something like this before the page even tries to load:

This way, you get to decide if you want to use the affiliate link or not, and if you check the “do this by default” checkbox you won’t have to see the interim screen the next time you click on a link with that particular affiliate tag. You can additionally control which tags are whitelisted or blacklisted in the Safari Preferences (using a comma-delimited strings of tags).

You can download Affiliate Me Not, or view the source code if that’s your sort of thing. Enjoy!

• All-new file format allows synching via Dropbox or version control (like git)
• Markdown pages (with syntax coloring, and smart Markdown authoring features like automatically extending lists)
• New event scripts make automating document tasks a lot more consistent

Also, VoodooPad just generally rocks. Go buy it; it’s on sale for a limited time.

There’s a ton of other new stuff, but I’ll leave it to you to read about it if you so desire.

Instead of gushing on about the new version, I wanted to share a project of mine that provides a starting point for using the new VoodooPad 5 hotness to create a static website. I call it, creatively enough, my VPWebsiteTemplate:

https://github.com/onecrayon/VPWebsiteTemplate

VoodooPad 5 already offers a lot of great features for exporting a website version of your document. What the VPWebsiteTemplate does is provide some scripts that offer additional functionality:

• Automatic renames pages when you create them to be URL-friendly
• Automatically generates page breadcrumbs using tags
• Copies image and Javascript assets into folders (instead of having everything cluttering up your root website directory)
• Adds support for Markdown-Extra style header IDs for easier same-page navigation
• Automatically strips out nested links if VoodooPad and Markdown interfere with one another

And a number of features that stem from its origins as a static app documentation site generator:

• Converts -> and => into → entities
• Converts shortcuts using the format `command H` to use <kbd> elements (for easier styling as shortcuts)
• Fixes paragraphs wrapping <aside> elements (since Markdown doesn’t handle HTML5 elements well)

VoodooPad isn’t appropriate for everything, but if you need to manage a static site with a single shared template (or a single template with minor variations), it’s hard to beat. The Markdown handling, dead-easy synching, and fact that you can package up absolutely everything about your site into a single file that is shareable with other VoodooPad users make it a really compelling solution for anyone who has had to fight with command-line static site generators before.

Documentation for using the VPWebsiteTemplate is available inside of the file itself, so go download it from GitHub already if you’re wondering how everything works. Happy Voodoopadding!

One of those tasks is building Enyo for use in a production environment, and since I’ve been fighting with this over the course of my development of TapWatch, I figured I would share how I am doing things.

Project organization

To start, here’s how I typically organize things in my project’s root folder (this is certainly not proscriptive, but you need to know it to understand the logic behind the scripts that follow):

- build/
- css/
- images/
- source/
  - enyo/
  - lib/
    - onyx/
  - kinds/
  - package.js
- tools/
  - build.sh
  - package.js
- dev.html
- index.html

Working top to bottom, build is where my final production builds will end up, while css and images are where I store my common stylesheets and image files. Keeping these both in the root of the project makes things easier when it comes to previewing the app during development.

The source folder is where I store all of my Javascript files. Enyo 2 will automatically load package.js when you link against its parent folder, so the root package.js file is my access-point for all of my app-specific functionality. I typically store my custom app kinds in the kinds folder, although depending on the complexity of the app I might break them up differently (for instance, organize based on views, models, and so forth). Where you store your app code doesn’t matter a jot, to be honest. You can go as simple or complicated as you want.

I use git to manage my project, and the enyo and onyx folders are git submodules pointing to their respective GitHub repositories. I like using submodules because it makes it ridiculously easy to test out bleeding edge additions, while still being able to fall back to a particular commit or tag that I know is stable if I need to prep a build for distribution. Using submodules also allows me to experiment with different versions of Enyo and Onyx for different apps. If I were storing it in a central location, I could inadvertently break things in one app by updating Enyo for use with another. GitBox, my favorite Mac git client, provides great support for submodules; after you add them, you can manage the submodule just like another repository, and it’s one click to revert to your last saved commit if you are experimenting with bleeding edge commits.

The relationship between the enyo folder and the lib folder containing Onyx and any other official or third-party packages is something you will want to maintain. By placing your packages in lib next to the enyo root folder you can very easily access your packages without worrying about their specific placement using the special strings $lib and $enyo in your package.js files.

The tools folder is where I store my build.sh script that is responsible for putting together my production builds along with other utilities; more on that in a bit. The package.js file inside of tools simply links against the Enyo source and my app’s main package; this is used by Enyo when building itself for production use.

Lastly, dev.html is my entry point to quickly preview my app in a browser, while index.html is the actual HTML file that I will use in my production builds. These two are different because the development version needs to link against my various CSS resources, Enyo, and my app source separately, while the production version links against a much smaller number of compressed files.

Of course, I include a number of other things in my project root folder that aren’t shown here both to cut down on the complexity and because they are not applicable to all projects. For instance, I typically store platform-specific code and resources in top-level folders (iOS, webOS, etc.).

HTML files

Before you need to worry about building your production scripts, you will want to setup your HTML to allow you to process your app. As you can see above, I keep at least two copies around: a dev.html file for quick browser testing, and index.html for the actual production code.

My TapWatch dev.html files looks like this:

<!DOCTYPE HTML>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
    <title>TapWatch Dev</title>

    <!--Include Enyo (debugging); automatically includes Enyo styles-->
    <script src="source/enyo/enyo.js" type="text/javascript"></script>

    <!--Include styles-->
    <link rel="stylesheet" href="css/styles.css" type="text/css">

    <!--Include application-->
    <script src="source/package.js" type="text/javascript"></script>

    <!--Configure for viewing on mobile devices-->
    <meta name="viewport" content="initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

    <!--LiveReload, for live refreshing-->
    <script>document.write('<script src="http://' + (location.host || 'localhost').split(':')[0] + ':35729/livereload.js?snipver=1"></' + 'script>')</script>
</head>
<body>
    <script type="text/javascript">
        new TapWatch.app().write();
    </script>
</body>
</html>

Most of this is stuff you can just copy and paste straight into your own app (aside from the point where I initialize TapWatch, of course).

One item of interest is the LiveReload integration. LiveReload is an awesome tool for Macs (although I believe there’s a Window pre-release version, too) that can watch your web folder and do things like automatically compile LESS files every time you save and then ping the preview that the styles have changed. I use this in conjunction with the Espresso preview to have a preview of my app in my editor that updates while I work. This is an insanely helpful bit of wizardry; being able to see my changes in live time really speeds up my workflow.

As for the production-ready index.html, it’s a bit simpler:

<!DOCTYPE HTML>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
    <title>TapWatch</title>

    <!--Include our styles-->
    <link rel="stylesheet" href="css/styles.css" type="text/css">

    <!--Include our application sourcecode-->
    <script src="sources.js" type="text/javascript"></script>

    <!--Configure for viewing on mobile devices-->
    <meta name="viewport" content="initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
</head>
<body>
    <script type="text/javascript">
        new TapWatch.app().write();
    </script>
</body>
</html>

The links to sources.js and so forth rely on my specific build layout; trying to preview this file from anywhere but a final build folder does nothing.

The tools folder and build.sh

In order to build your production app you are going to need to get your hands dirty with a little shell scripting. Never fear, though! The process is fairly simple, and the necessary shell commands innocuous.

You will probably want to do some or all of the following:

• Compile Enyo, any third-party packages you depend on, and your app’s code into a single file (this is a very easy one-step process, but it will require that you install node.js first)
• Concatenate and minify your built app with third-party scripts (like cordova.js if you are building a PhoneGap app)
• Concatenate and minify your CSS, if you have more than one CSS file
• Copy the files you need for a production build (and only those files) into your build directory for distribution
• Perform any platform-specific logic

In order to accomplish these tasks, my personal build.sh script does the following:

1. Creates a tools/compiled/ folder in which it will collect in-process files (I exclude the compiled folder from git in my .gitignore file)
2. Creates a build/www/ folder in which it will output the final production build
3. Uses Enyo’s built-in minifier to package the app’s core files
4. Further concatenates and minifies CSS and Javascript using YUICompressor (this step is entirely optional, or you could always use a different minifier); I have yuicompressor-2.4.7.jar installed in the tools folder so I don’t have to worry about where it is in the path
5. Copies images, css, compiled scripts, and the index.html file into the build/www/ folder

And here is the code:

#!/bin/bash

# Setup path to node (to make sure it's in the path)
export PATH="/path/to/node/bin:$PATH"
export NODE_PATH="/path/to/node:/path/to/node/lib/node_modules"

# Make sure the base directory is the tools directory
# This makes sure relative paths always work right
ORIGINAL_PWD="$pwd"
cd "$( dirname "${BASH_SOURCE[0]}" )"

# Ensure basic paths exist
# If we don't do this, later actions might fail
mkdir -p compiled/enyo-min
mkdir -p compiled/css
mkdir -p ../build/www/images
mkdir -p ../build/www/css

# Build the app and Enyo
../source/enyo/tools/minify.sh -no-alias -output compiled/enyo-min/app package.js

# YUI compress our Javascript
cat compiled/enyo-min/app.js | java -jar yuicompressor.2.4.7.jar -o compiled/sources.js --type js

# YUI compress our CSS, as well
cat compiled/enyo-min/app.css ../css/styles.css | java -jar yuicompressor-2.4.7.jar -o compiled/css/styles.css

# WWW build
# Copy our latest images, CSS, and HTML to the www directory
rsync -av ../images/ ../build/www/images/
cp compiled/css/styles.css ../build/www/css/styles.css
cp ../index.html ../build/www/index.html
cp compiled/sources.js ../build/www/sources.js

# Resume our working directory
cd "$ORIGINAL_PWD"

Of course, this is pretty specific to my own project; you would likely be using completely different paths for some of the items, and you might not want the extra minification and so forth.

The most important bit is the line that builds Enyo and the app:

../source/enyo/tools/minify.sh -no-alias -output compiled/enyo-min/app package.js

As best I can tell, the -no-alias argument has to do with how Enyo dependency loading is handled. I have not had a chance to test what aliases do, though. The -output argument specifies the file name (with optional folders prepending it). So in this case, the final files will be called app.js and app.css, and will be stored in the compiled/enyo-min/ folder. There are a couple of other arguments, but when loading the minify script from directly within your Enyo installation, they don’t appear to be necessary. You can always use the -h argument for a full listing.

In order for the Enyo minify.sh script to work, you will want to include this in your tools/package.js file to tell it to combine Enyo with your app:

enyo.depends(
    '$enyo/source/minify/',
    '../source/'
);

There are some other fun things you can do in the build script, as well. For instance, if you are building an iOS app using PhoneGap or similar, you can use the following conditional statements to process differently when you are running the script from an Xcode build step vs. directly:

if [ -z "$IPHONEOS_DEPLOYMENT_TARGET" ]; then
    # SCRIPT EXECUTED DIRECTLY
fi
if [ -n "$IPHONEOS_DEPLOYMENT_TARGET" ]; then
    # EXECUTED FROM XCODE IOS BUILD STEP
fi

And of course you can add platform-specific build steps using the same basic tools (rsync -av to copy all files in a folder, cp to copy a single file, and mkdir -p to make sure an entire directory path exists are all very handy).

Once you have your build script setup, you can create a custom build by executing the build script in the Terminal, or by adding it to your build steps in Xcode or similar if you are building for a specific platform.

Go forth and build

Hopefully my particular setup has provided you with some ideas or a starting point for organizing and building your own app’s source for production distribution. Enjoy!

Frankly, the way I learn a new language or tool is by using it. I start with a project, usually something I want to use myself, and then just jump in feet first. This typically involves scouring the internet for example code, tutorials, and prior art that I can implement and tweak to my own needs while regularly banging my head against the wall. I’ve bought a few coding books aside from Dynamic HTML over the years, but I never make it very far past the introduction. They bore me to tears. Head-to-wall contact is admittedly a bit painful, but it’s a lot more interesting and the things that I learn tend to stick.

So recommending books is out. I’ve heard good things about a few of them, but having never read any (or learned anything substantive the few times I did try to crack their covers), I’m rather unqualified.

But saying, “Just find a project and run with it!” isn’t terribly helpful, either. That’s a great way to encourage a proto-coder to drop the whole idea before they really get started. Especially if their ultimate goal is writing an app for their favorite iOS device, which can be a complicated and frustrating process even for veteran coders.

And at this point I find myself staring at a blank email, certain I am about to send my young relative down the path to a sad and codeless life.

Though I may not have a lot of practical knowledge when it comes to easing your way into coding, I do have a fair bit of observations based on first-hand experience to offer. Perhaps that will be helpful instead.

Overcoming the wall

The land of coding is a wonderful, magical, frustrating place but to get there you have to find your way over the wall that surrounds it. This isn’t a learning curve (although you’ll find plenty of those beyond); it is a wall. Steep, high, and not exactly obvious in approach. The simple fact is that coding is unlike anything you have ever done previously. When you write code, what you are actually doing is using a specialized language to lay out simple, logical instructions for a device that can only make the mistakes you inadvertently tell it to make (the trick is that huge numbers of other people have already layered on numerous strata of instructions with their own inadvertent mistakes that you are building on top of, so even if your code is perfect you still may find yourself running into problems that encourage head-meet-wall interaction).

There are analogs to other things you might have learned in the past (other countries’ languages, scientific experiments, math, art), but particularly if you do not know what you are getting into, jumping into coding will likely feel like running into a wall. You can vaguely see where you want to be when you back up far enough, but when you get close the whole thing is simply overwhelming.

But do not fear! Many of the other people who have scaled this wall in the past are there to help you over, through, or under it.

Your first coding lesson

I shall now give you your first coding lesson. Learn this, and you’ve basically lopped off the top few feet of the wall before you ever reached it.

Here it is: dream big, act small.

There are numerous desires that lead people to coding, but probably the two most common I run across are the desire to make money and the desire to make a tool you yourself want to use. And make it right this time, because darn it those other developers are approaching the problem all wrong.

Both are great motivations, but keep in mind that neither is something you are likely to accomplish immediately. Especially when it comes to app development a lot of people nowadays are going into it with stars in their eyes, imagining their app taking off on the bestselling charts and making hundreds of thousands of dollars in a month or two. Banish this fantasy! Yes, it is remotely possible you could succeed wildly with your first app/website/whatever, but the chances of it are vanishingly slim. Striving for widespread adoption is laudable, but if you measure your success solely against it you will quickly become discouraged, and discouraged people don’t ship software.

So have your big dream, but act on smaller things. Coding is about taking a complex problem and breaking it down into manageable smaller steps. It is about understanding the limitations and restraints you are working with and finding ways around them or adapting your code and vision to work within them. It is about having a laundry list of features that you know you absolutely must implement, but being able and willing to ship only the tiniest subset of them in your initial 1.0 release, and then steadily adding more as you go.

It is about realizing that you are not, in fact, facing a wall. You are facing a collection of stones, each of which is much easier to deal with on its own.

Three things to master

At root, there are only three things you have to learn:

1) The basic building blocks: variables (typically composed of arrays, strings, numeric types, dictionaries), functions, loops, conditional statements, and (for most modern languages) classes and objects. Learning about this stuff pretty much allows you to write in any coding language you want; usually the only thing that differs between languages is the specific syntax you use, which is (typically) easy to pick up. Coding is simply a specific, logical way of thinking and communicating using a small number of standard tools.

For basic building blocks, you can find any number of “getting started with language X” tutorials and resources online. Look for the very early introductory materials that introduce variables, functions, etc. and read through them. Once you understand if/elseif/else blocks, for and while loops, variables, and functions you will have the basics for what you need to read and write code.

2) The syntax: every language is different, so before you can write one or another you have to figure out how it handles the basic building blocks from above. For instance, here’s the same variable (a string) in three different languages:

Javascript:

var helloString = 'Hello world!';

PHP:

$helloString = 'Hello world!';

Objective-C:

NSString *helloString = @"Hello world!";

Exact same meaning in all three, but slightly different requirements for each. When you are learning the building blocks above, try to find a tutorial for whatever language you are most interested in working in right away, because all the examples will use its syntax, allowing you to learn both at once.

3) Specific capabilities: every language and environment offers slightly different built-in functions and so forth that you can call upon. This is the stuff that I typically spend very little time learning, and look up as I work.

For instance, PHP has a zillion functions that help with anything from manipulating strings to connecting to databases, and it would be a complete waste of my brain to try and memorize them. Instead, I keep the PHP documentation handy when I am working in that language and reference it when I need to figure out how to do a particular task.

The same applies to Objective-C; a lot of the complication behind Objective-C is that most of what you will be doing is working with the framework’s provided objects, functions, and methods, and since there are so many of them it can be overwhelming when you get started. Instead, ignore them. It might be worth skimming over some of the functions provided for working with the basic types of variables like strings, arrays, and dictionaries so you have an idea of what things you can do out of the box, but typically it’s easier to look this stuff up as the need arises.

Practical application

Lovely abstract overviews and pithy sayings may make you feel good, but coding is a practical activity and up to now I admittedly haven’t offered much specific, practical advice. Let’s change that, shall we?

When you are first getting into coding, any language you learn is going to help. They all will teach you the basic building blocks (and for a lot of them, you’ll pick up a fair amount of common syntax, too), so it doesn’t matter at all where you start. The corollary of this is that learning a language other than the language you want to work in might be a good idea, particularly if it will allow you to see results more quickly (and based on my own experience, seeing results quickly is important; there is something truly magical about using something you have programmed that pays for the frustration and difficulty leading up to that point).

For instance, if I were just now getting into coding with the ultimate goal of publishing a native Objective-C app, I would not start off working in Xcode and trying to learn Objective-C.

I would learn Javascript.

The benefit of Javascript is that a lot of the syntax is very similar to C, but because it is a high-level language you can go from learning the building blocks to actually creating something a bit quicker (and typically with less frustration, although there are certainly pain points in Javascript, as well). Javascript has its share of unique quirks, but with your pick of frameworks like Enyo, jQuery Mobile, Sencha Touch, and others you have some very useful tools that can speed things up by providing common interface elements and other niceties.

Granted, you will likely want to learn a framework in addition to the language itself to use them, but the same is true of Objective-C (coding in Objective-C is practically nothing but learning to use a framework).

How I would learn Javascript is a little more up in the air, but I have heard excellent things about Codecademy, so I would likely start there, and then quickly transition into writing my own app as soon as I learned enough to be dangerous. Most Javascript frameworks also have active communities surrounding them, so I would try to leverage those to help me get over the difficulties of going from idea to actual working interface elements on screen.

Once I had a working, simple Javascript app, then I would start digging deeper into Objective-C as I moved toward my true goal.

Other resources

Not everyone learns the same way as I do. If you learn better through books, then by all means visit your local bookseller, consult some Amazon reviews or similar, and try one of them.

Regardless of what you are interested in coding, I would also highly recommend taking a course in C if the chance arises (or C++, but C is far more universally useful). A local community college would probably be the most likely place to find something like this. When I was in college, taking a course in beginning C++ was an incredible boon. It taught me a lot about not only C (which has been useful when I need to write Objective-C or try to read other source code written in other low-level languages), but also introduced me to the command line. Getting enough knowledge not to be scared of the command line is incredibly liberating.

General courses on how to think about and approach code would also likely be useful, but you can usually achieve the same knowledge through active curiosity and a willingness to read a bunch of articles and blog posts online.

Go forth and code

How you go about it and what language you use doesn’t matter. Ultimately, what matters is that you get out there and start writing code. Come up with your big dream, and for your first small act create something simple but useful, be it a website, a mobile app, or a script that makes a repetitive action on your computer less onerous. Learn Javascript, or buy a book about Objective-C, or find a course to take. Experiment, fail, and try again.

No matter what route you choose, it will be frustrating, it will be difficult in the beginning, but it will be worthwhile. Even if you never spend the time to get particularly fluent in any given language, understanding the basic building blocks of code and knowing just enough to be dangerous can open a lot of doors and give you a way to tweak the devices that you rely on every day to better suit your needs.

Good luck!

Not that long ago, I needed to time something. Having my iPhone handy, I figured it would be the work of a moment to find a simple stopwatch app and get on with things. I had wanted but three things in my stopwatch:

• No buttons
• Aesthetically pleasing design
• A log of recent times

Half an hour later, I emerged from the morass of the stopwatch apps in the App Store without having found anything that even satisfied two out of three (including the stopwatch mode in the built-in Clock app).

Clearly developing a stopwatch is something people do as a learning exercise, and then forget about. But simply because a niche is unprofitable does not mean that it should not have at least one beautiful option. So I decided to write my own stopwatch, and thus TapWatch was born.

TapWatch offers the following niceties:

• Tap anywhere to start and stop the timer: no more hovering your finger over small buttons!
• Double tap anywhere while a timer is running to start a new lap: you won’t lose any time, because TapWatch notices the timestamp from your first tap, and picks things up from there on the second
• Slide left to view your 50 most recent times (automatically saved!)
• The screen will stay awake as long as TapWatch is active and a timer is running, so feel free to watch what you’re timing
• Multitask: exit TapWatch while a timer is running with impunity; even if iOS quits it in the background it will continue timing
• Scales beautifully when timing things that last anywhere from tenths of a second to hours

If you ever need to time anything, I hope you will give TapWatch a try! I would also love to hear from you if you think the app needs improvement; my personal uses for stopwatches are pretty basic, so I would particularly love to hear how people who need to time things often like the app (coaches, teachers, etc.).

The short story is pretty boring, isn’t it? Thought so. Here’s the long version:

Since moving from doing web development to being the guy who does whatever needs doing at MacRabbit (mostly involving Espresso plugins and customer support), I haven’t been using Photoshop as often. However, I do still need it from time to time; Photoshop is always central when it comes time to redesign one of my sites, and I crafted all of the UI for TapNote and my upcoming iOS app TapWatch in Photoshop (there was a brief stint where I spent a huge amount of time and pain trying to do the same thing in other apps, but it wasn’t remotely worth it).

But there’s one aspect of using Photoshop I always dread: slicing and exporting my images. It sucks. A lot. Always. I can spend almost as much time rearranging and slicing a file in order to get the right transparency and backgrounds as I spend designing the darn thing.

And what particularly sucks is that after I’ve painstakingly sliced my document and created a total mishmash that looks nothing like the original mockup, I inevitably discover that some small thing doesn’t work. Perhaps a button needs to be just a little bigger, or I want to change the color palette slightly.

This wouldn’t be a big deal, except that I no longer have a working mockup. I have my original mockup, and then I have the sliced-up mess that I have to use to actually generate my site files. Trying to move changes between these two versions is soul-destroying.

If you use Photoshop with any regularity to prepare graphics for apps, the web, or just about anywhere that necessitates the “save for web” dialog, you know what I mean.

Time to cue the heavenly light and choir, though, because our savior has arrived and its name is Layer Cake:

Using Layer Cake is ridiculously simple: in your Photoshop file you name your layer or layer groups the same as the file you want to output, then drop the PSD on Layer Cake and watch it work its magic.

For instance, I recently had to design an iOS app icon for TapWatch, which thanks to the sheer number of iOS device resolutions meant I was actually designing five versions of the same icon. When it came time to export my various icons, I simply named the appropriate layer groups “icon.png”, “icon@2x.png”, and so forth, then dropped the PSD on Layer Cake to export all of them without needing to hide or remove the background layers that provided me context for the icons (or do any other configuration). When it was done, Layer Cake asked me if I wanted it to watch that particular file for updates and automatically do the same export whenever it changed. I checked “yes”, and now as long as Layer Cake is running I can make a minor change to my TapWatch icons and export them all simply by hitting command-S.

It’s a completely different way of working, and I wish that it had been around when I was doing web work. There were so many times when the graphic designer wanted to change some small thing, and sent the change over in their original mockup, which I then had to re-translate into my sliced version (and just hope that I noticed all the changes). With Layer Cake, I could have renamed the layers appropriately, sent the mockup back, and they would be able to make their changes right in the same file. Once they were done, all I’d need to do would be to toss the file in Layer Cake once more and go.

At this point, the people who are regular users of Photoshop have probably already bought Layer Cake, but in the interest of helping people get the most out of it, here are some additional fun things to know:

• If you need to define a specific region for your image to live in, just add a square vector or layer mask to the tagged layer group. Layer Cake will base the dimensions of the final image off the mask instead of auto-generating them based on the surrounding transparency (this also works to explicitly define the image area if Layer Cake is missing an outer stroke or shadow, which occasionally happens in v1.0). If for some reason you don’t want to add a layer mask, you can stick a square vector shape layer named @bounds inside of the layer group, and Layer Cake will use it to calculate the boundaries of the image instead.
• As you would expect, layers do not need to be visible for Layer Cake to export them (or even completely contained in the canvas, for really large vector images and so forth).
• If you name multiple layers identically with an .icns extension, Layer Cake will automatically combine them all into a single Mac icon file.
• If you need to slice something like you would traditionally in Photoshop (so that the background layers are visible and so forth), add a group called @slices, and populate it with square vector shapes named after the images you want to export. Layer Cake will calculate the size and position of the images, and include everything in the group that contains the @slices group (which could be the entire PSD, if you place it at the root level).

Layer Cake is still a 1.0 product, so it doesn’t support everything (notable exceptions are CMYK documents and advanced filters), but MacRabbit will of course continue to improve it to try and address the edge scenarios. If you would like to buy it, you can find it in the Mac App Store, and if you would like to see a Photoshop file formatted for use in Layer Cake there are several examples on the Layer Cake website.

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!