As you may or may not know, I am an employee of MacRabbit, the company responsible for CSSEdit and Espresso. I typically don’t like to mix work and pleasure on my personal blog, but today MacRabbit has some exciting news: we have released a public beta (or “kaboom”, as we call our pre-release versions) for Espresso 2.0!

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!

I do not—and have never—used Final Cut Pro. Or really any version of Final Cut. I remember one day I was sort of bumming around, looking at software, and I wondered briefly if the slimmed-down version would be worth it before I woke up to reality and realized that the few times in my life that I needed to edit video, I hated it. So that was that.

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.

Back on February 9th, although HP announced some awesome-looking new products they also slipped in the fact that their current development framework, Mojo, was being deprecated on their upcoming TouchPad tablet. This offering displeased me, for it meant that small-time WebOS developers like myself were faced with a nasty quandary: do we abandon our existing userbase in hopes of having an app on the TouchPad when it comes out, or ignore the new Enyo framework and continue focusing on legacy WebOS devices (a market that is stagnated and actively dying)?

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.

One of my main annoyances with WebOS is that it can be really difficult to figure out why an element is displaying improperly on-screen. Up until WebOS 2, Palm provided a tool called the Palm Inspector that allowed you to use the WebKit Inspector to take a look at what was going on under your app’s skin, but it sucked for numerous reasons (first and foremost being that it didn’t work at all with apps that ran in “headless” mode—which means every app that has the capability to create new cards or dashboard stages).

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.

As anyone who follows me on Twitter or this blog is no doubt sick of hearing, TapNote 1.2 is now available and includes Dropbox sync!

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.

Quick and dirty: if you want to view the TapNote short description or see a video of it in action, check it out in the Palm App Catalog or take a gander at the official TapNote webpage. Otherwise, read on for details about what’s new with TapNote 1.2!

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.

Mariner Software is the publisher of some of my favorite Mac applications, including StoryMill. However, they do not actually want anyone to download their software. This is evidenced by the fantastically user-unfriendly process you have to go through to download their products.

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.