node-webkit

C3D Buddy 2.0 in action — built in an evening using node-webkit
C3D Buddy 2.0 in action — built in an evening using node-webkit

I don’t do very much desktop software development these days, and I’ve become increasingly frustrated with Realbasic (now Xojo), so the prospect of forking out $500 for an upgrade that may or may not be usable did not fill me with glee. Furthermore, as the years roll on, there’s more and more functionality tied to the web that desktop-centric development tools struggle to work with.

I was dimly interested in a thread on Hacker News this morning concerning a workflow for developing desktop applications with node. Turns out that the workflow was mostly to do with things like angular and jade, which I’m not especially keen on, and not so much with the actual desktop stuff — the heavy lifting for which is all done by node-webkit. So I started looking into node-webkit.

I like a tool which has you up-and-running in about three paragraphs.

It goes something like this:

Download an appropriate node-webkit binary. (Disappointingly, the Mac version is restricted to 32-bit.)

  • Write an index.html file. (The sample “hello world” app calls node inline.)
  • Write a package.json file. (The documentation suggests it’s like a “manifest” file, but really it’s more like a configuration file.)
  • Zip this stuff into a file into an archive whose name ends in .nw.
  • Double-click the archive.
  • Voila, your app works.

After working on this for about fifteen minutes, I knocked up a bash script (which I turned into a .command file, allowing me to double-click it in Finder) which does the archiving and then launches the file in one step. (It does leave dead terminal windows lying around, and it doesn’t quit the app if it’s still running. I think I may build an app for building apps if I do much more of this.)

And to build a distributable application you can simply put the archive in the application bundle (on the Mac) renaming it “app.nw” or name the file package.nw and put it in the same directory as the application (for those benighted platforms that don’t have bundles). One minor annoyance is that it’s not clear exactly what needs to be changed in the Info.plist file to fully customize your application.

So what is node-webkit? It’s essentially a version of Chromium that puts node.js alongside the DOM in your web pages, along with a few custom HTML and DOM extensions that let you do things like handle platform-native file requesters).

I should note that it’s a potential security nightmare as it stands. There’s no sandboxing (that’s kind of the point), so deploying an app that loads your banking website and then watches you press keys is totally doable. That said, it’s a desktop app so it can also delete all your files or encrypt them and hold them hostage.

Anyway, I had a lot of fun this evening rewriting a utility application I originally wrote in Realbasic a few years ago. It probably took me about twice as long to write it as it took me to do it in Realbasic. Part of that is I know (or knew) Realbasic very well, and I don’t know node very well. Another part of it is that Realbasic is almost always synchronous while node is almost always asynchronous. Writing code that spelunks a directory tree asynchronously is a lot more complex both conceptually and in practice than doing so in linear fashion, but the payoff is quite impressive — despite running an “interpreted” language, a task that took significant time in Realbasic (loading and displaying hundreds of thumbnails) happens in the blink of an eye.

One of the things that’s especially intriguing about node-webkit is that it gives you control over the browser you normally don’t have (e.g. window placement, file system access) — these are a constant usability sore-point in the project I am currently working on (which is a web app that is replacing a suite of desktop apps). It would be so much easier to get a lot of the things we want to do working smoothly using a hybrid desktop application built on top of something like node-webkit — it’s kind of a lemma of Alan Kay’s observation that anyone who wants to write really good software needs to build hardware — anyone who wants to write really good web apps really needs to build the browser.

The github repo for my project is here. It’s not a very general-purpose application; if you don’t use Cheetah 3D it’s completely useless.

iDraw Review

iDraw showing texture map

A while back I reviewed Artboard — an inexpensive Illustrator-replacement-wannabe — fairly positively. I then discovered a bunch of limitations and bugs, and tried iDraw. (Note this is a review of the Mac version of iDraw. I haven’t tried the iPad version yet.)

Having used iDraw quite extensively for the last few months I can only say that, for my uses, iDraw pretty much kicks not only Artboard’s butt, it kicks Illustrator’s as well (until you get to Photoshop integration). The only application that holds a candle to it is Sketch (another excellent program I need to review).

The most challenging thing I’ve been doing with iDraw is texturing a 3d character. Normally I would do something like this in Photoshop or some other dedicated bitmap graphics program, but I wanted a simple, clean look, and ended up trying a wide variety of programs including Photoshop, Acorn, Pixelmator, Mischief, and Artboard — before settling on iDraw. For the kinds of things I was trying to do, iDraw was simply head-and-shoulders above the rest. Color me very impressed.

Now if only iDraw could include Sketch’s ability to set named export areas with specific objects included or excluded from export it would be awesome. But as it is, Sketch and Artboard can talk to each other via SVG so it’s no big deal.

(If you’re looking for a replacement for Fireworks, Sketch isn’t exactly that — but as a tool for creating pixel-perfect vector art, it’s probably better.)

Solid Drawing Tools

Screen Shot 2013-10-03 at 10.18.32 PM

iDraw’s drawing tools are solid and well-implemented (better than most — note the compound path support), with good snapping (both to grids and other objects). Indeed, unlike Sketch (which I also like a great deal) iDraw’s snapping works correctly when dragging multiple objects (no need to great groups just to make snapping work).

Powerful Styling

iDraw's style interface

Like any useful bezier drawing application, iDraw supports booleans. Unlike most of its rivals, iDraw provides an incredibly powerful and flexible set of tools for styling shapes. Again, Sketch comes close to iDraw in this regard, but iDraw lets you explicitly reorder the different effects whereas Sketch (as far as I can tell) does not.

Artboard's mystifying style palette
Artboard’s mystifying style palette

iDraw’s styling UI is not only better than Artboard’s (or Illustrator’s or Sketch’s for that matter), it has most of the precision controls you need — e.g. you can control whether a stroke runs inside, outside, or centered on a path — although you don’t have Sketch’s or Illustrator’s fine control over corners and caps. In comparison, Artboard’s styling controls are crude and in many cases simply mystifying.

 

Screen Shot 2013-10-03 at 8.43.19 AM

 

Here’s some detail from the texture map I was working on. Note there’s all kinds of subtle layered effects on the different components of the pupil.

Sketch pupil detail imported

 

Here’s the same pupil exported from iDraw as SVG and then imported into Sketch. (No, it didn’t get turned into a bitmap en route!)

Artboard imported pupil detail

 

And here’s the same pupil imported into Artboard. Also note the horribly rendered bezier handles on the selected object. Not a functional problem (they work just fine) but ugly.

Workflow

Clearly, iDraw can export SVGs that other programs can read, which is a great start. (Artboard can export to PDF but not, as far as I can tell, SVG, which is a huge black mark.)

iDraw's export dialogiDraw can in fact export to pretty much any file format you’d want (no EPS! — how times have changed) but it doesn’t have the export workflow niceties of Sketch (which lets you create named export regions and if necessary specify exactly which objects get rendered within each region, and then allows every region to be exported with one click).

Shortcomings

Probably the single biggest failing of iDraw is its weak typography. If you’re looking for  any typographic tools beyond pair kerning, look elsewhere. It is possible to get good type out of iDraw but it has a weird bug in the default style of text where text by default seems to have text, fill, and stroke styles (and looks awful). If you turn off everything except the fill style it looks fine. But there’s no real ability to deal with body type conveniently (or tables), so if you need to do anything more than a logo, you probably need a different program.

Unlike Artboard, iDraw allows you to use CMYK colors. If you’re working in print, you’ll still probably want Illustrator, but unlike Artboard or Sketch, it’s at least usable.

Aside from these two items, I’d like to see some more control over strokes (corners and caps), and there are a few fit and finish problems (e.g. the way styles are rendered in the style palette is a bit wonky, especially for text styles).

Conclusion

Overall, iDraw is my favorite vector drawing program right now, although for drawing UI components I’d give the edge to Sketch, which deserves its own review. There are some other programs I haven’t mentioned, such as Lineform, ZeusDraw, and Intaglio. These are all not bad — probably better than Artboard — but I prefer iDraw to all of them, and at $24.95 (in the App Store) I believe it’s cheaper than any of them.

 

It’s time for a change: Adobe jumps the shark

Grant will get you one month of Adobe Creative Cloud with an annual commitment
Grant will get you one month of Adobe Creative Cloud with an annual commitment

I love Adobe and its products, despite their eccentric UIs, awful installers, and the mystery that is Bridge. The fact is Adobe knows its shit and does it better than anyone else. However, while for many years I considered myself a “power user” of Photoshop and competent enough with Illustrator, the capabilities of Photoshop have long outstripped my needs, and Adobe’s marketing team has done a remarkable job of alienating me with pricing shenanigans.

My first experience with Adobe Software was learning to use Illustrator 88 in a production environment — mainly tracing logos. I was introduced to Barneyscan (the program that became Photoshop) when the multimedia startup I joined acquired a Barneyscan Slide Scanner. We soon discovered that Barneyscan was actually a very capable graphics program that was better for handling 24-bit color images such as scanned photographs than anything else on the market.

Then Fractal Painter and Color Studio came out and, briefly, it was a three horse race. When Photoshop introduced, in quick succession, a better implementation of Painter’s layers and editable text layers, the competition fell by the wayside. Other competitors, e.g. Macromedia’s ill-fated xRes, the amazing Live Picture, and Microsoft’s Expression Studio, came and went.

Despite its many virtues, I couldn’t justify buying my own copy of Photoshop until it started being bundled with scanners. I literally paid $500 for a scanner and didn’t use the scanner in order to get Photoshop 4. Adobe’s upgrade pricing led to my upgrading Photoshop as each new version came out until Adobe got me to upgrade to Creative Suite for not much more than the cost of just upgrading Photoshop, but then made further upgrades horribly expensive (and also made skipping versions very expensive). My last CS purchase was CS4 Web Pro academic (I was working for a University at the time) just after Adobe announced that anyone buying CS4 would receive a free CS5 upgrade.

Over the years, Adobe’s other applications rose and fell in my esteem. I used Premiere for years, and once found After Effects to be an unbeatable combination of power and usability — I haven’t touched either in years, and Apple’s $50 Motion does everything I need. (Indeed, I don’t have any use for Final Cut Pro, either.)

Now Adobe is essentially offering us three options: pay $50/month to get access to all Adobe software, pay $20/month to get access to Photoshop (both require one year commitments, it’s higher if you go month-to-month), or somehow get academic pricing for $20/month to get everything. The plans also come with 100GB of cloud storage (which would cost you $10/month on its own from Dropbox — of course Dropbox’s 100GB is a lot more flexible).

So for me, that means it’s time to kiss Adobe good-bye. (Except for Adobe Ideas of course — I love Adobe Ideas.)

Alternatives to Adobe’s key products

  • Photoshop: Acorn (Mac), Photoline (Mac/Windows), Pixelmator (Mac), Paintshop Pro (Windows), Painter (Mac/Windows)
  • Illustrator: Inkscape (Mac/Windows/Linux), iDraw (Mac), CorelDRAW (Windows), Intaglio (Mac), Lineform (Mac), Artboard (Mac), ZeusDraw (Mac), EasyDraw (Mac)
  • Dreamweaver: a good text editor (e.g. BBEdit (Mac), Sublime Text (Mac/Windows), Vim) or web-centric IDE (e.g. Webstorm (Mac/Windows), Coda(Mac))
  • Fireworks: no direct replacements that I know of, but UI-oriented graphics apps like Sketch (Mac) seem like replacements to me.
  • InDesign: Pages (Mac), TeX or Latex (Mac/Windows/*nix) or even Quark XPress (Mac/Win).
  • After Effects: Motion (Mac), or one of the fire-related products (Inferno, Flame, Flint, Combustion, Smoke, etc.)
  • Edge: haven’t used it, but I’m guessing something like Hype (Mac) or learn to use CSS and jQuery.

Chances are, if you’re a hardcore InDesign or After Effects user, you probably pay Adobe $600/year for the privilege and the new pricing policy doesn’t faze you. The problem you need to worry about is just how badly is Adobe going to hurt itself by its new pricing policy, because I suspect that the new pricing policy will convince a lot of people to live without Adobe for as long as possible, which will turn out to be forever.

Adobe is bucking a big trend — software is getting cheaper and more powerful — and a major perception issues — most people hate recurring expenses. See, I can splurge on a big software purchase because I’m flush with cash or have a big check coming in or some kind of weird justification. I don’t think of a $2000 camera purchase as, say, $55/month based on my using the camera for three years. No, I think of it as “can I afford a $2000 camera?” If you tried to sell me a camera that was just as good as my $2000 camera for $55/month with a one year commitment, I’d probably laugh at you. Do I need to pay as much for my camera as I do for cable internet? No way!

I strongly suspect this move by Adobe will be catastrophic. At this point in their old marketing cycle they’d be offering free upgrades to any new buyers of CS6 — instead they will at most be getting a few $50/month subscriptions. Next, they’d be offering time-windowed discounts on the new suite once it shipped. That’s not going to happen. So at best they get slightly more money than they’d have gotten with their old model, only spread out over twelve months. How likely does anyone think this is? I suspect they’ll instead get less money spread over a longer period. And they run the very significant risk of simply losing customers the way, say, Netflix did with its Quickster fiasco. My CS works fine, I’ll think about the Adobe cellphone plan when I need to. The difference here is that, as far as I can tell, time isn’t on Adobe’s side the way it, arguably, was with Netflix. Streaming video on demand is the way of the future, so Netflix (and Hulu) can probably afford to stumble. Adobe is the king of print media and web worst practices — it probably can’t afford too many mistakes.

The Browser as Word-Processor

Like, I think, most web developers, I assumed that making a decent WYSIWYG editor that works inside a browser is difficult and tedious, and assumed the best solution was to use something off-the-shelf — especially since there are what look like pretty good free options such as TinyMCE and CKEditor.

Upon close — or even superficial — examination, these editors (and there are a lot of them) seem to pretty much suck. As a simple pons asinorum try the following test (incidentally, the editor in the latest version of WordPress scores quite well here):

  1. Create a simple document with a heading and a couple of paragraphs of text.
  2. Bold a couple of words in one of the paragraph (not two consecutive words).
  3. Now, while observing the editor’s toolbar, try a series of selections:
  • Select a bold word
  • Select a plaintext word
  • Select from a bold word to some plaintext
  • Select within the different paragraphs and headings
  • Select across two paragraphs with different styles

If you didn’t encounter several WTF moments then either the state of off-the-shelf JavaScript text editors has improved markedly since I wrote this or you’re not paying close attention.

Google Documents — errr Google Drive — handles all this with aplomb, which is to say it behaves exactly like Microsoft Word (which is kind of dumb, but at least (a) what users probably expect, and (b) reasonably consistent). E.g. if you select a mixture of bold and non-bold text the bold toolbar icon will be “unlit” indicating (my colleague and I assume) that when you press it the selection will turn bold. In most of these editors either the bold button exhibits random behavior or goes bold if the selection starts in bolded text. (The latter at least accurately foreshadows the behavior of the bold button: more on that later.)

Assumed Hard, Left Untried

My experience as a JavaScript coder has been that there are only really two levels of difficulty for doing stuff in JavaScript — not that hard and practically impossible (and every so often someone will surprise me by doing something I assumed was practically impossible).

I knew that there’s a trick for editing any web page, e.g. the following scriptlet will allow you to edit any web page (with spellchecking for bonus points):

javascript: document.body.contentEditable = true; document.body.attributes[“spellcheck”] = true;

So, I knew that something like this was easy. What I didn’t realize was that at some point in the browser wars Microsoft implemented pretty much all of Microsoft Word (modulo some UI glitches) into Internet Explorer, and then everyone else simply implemented most of their API.

So, for example, the following scriptlet used in conjunction with the preceding one allows you to bold the current selection in any web page:

javascript: document.execCommand(“bold”);

If  nothing else, you can have a lot of fun defacing web pages and taking screenshots:

CKEditor Home Page (Defaced)While I knew about the contentEditable “trick”, I didn’t put all this together until — frustrated by the huge and unwieldy codebase of CKEditor (which, at bottom, is really just a custom UI library that calls execCommand) and unimpressed by alternatives (aside from Redactor.js, which looks pretty good but is not free or open source) I found this thread on Stackoverflow.

editor.js in action on its documentation demo page

I cleaned up the example and had a working text editor in a few dozen lines of code. (I’d post them but they’re written for a client. I believe the whole project will eventually be open-sourced, but right now it hasn’t been. If and when it ever gets open-sourced, I’ll link the code. Failing that I may write my own simpler version for personal use (and integration with Foldermark).

document.execCommand implements most of the functionality you need to write a perfectly good word-processor from scratch in a browser. In fact, if you’re willing to put up with some UI quirks, pretty much all you need to do is implement some trivial UI components. Almost all the implementations out there create a complete blank document inside an iframe by default, but it’s perfectly viable to edit inline in a div, especially if you’re planning to use the ambient styles anyway.

The beauty of writing your own word processor using execCommand is that the browser gives you fine-grained access to all events, allowing you to arbitrarily fine-tune the low-level behavior of your word-processor. Microsoft Word, for example, has always had unfathomable UI quirks.

What don’t you get?

First, you do get pretty solid table support.

You don’t get fine control over styling, although there’s nothing to stop you from implementing a CSS editor of some kind (disguised or not). From my point of view, the default behavior of the browser word-processor is to be very styles-driven, and that’s a good thing. It’s not so easy out-of-the-box to, for example, set a specific point size for text.

Some execCommand commands don’t work very well. E.g. you can implement a “hiliter” using execCommand(“backColor”…) but there’s no way to toggle it off (unlike bold) so to properly implement it you need to directly mess with the DOM, which — given the way selections are represented, can be a tad ugly.

There’s stuff that is simply difficult because you’re in a browser. E.g. without implementing some kind of service platform (or perhaps leveraging an existing one) you’re not going to be able to drag-and-drop a picture from your desktop into a document. It would be fairly straightforward, I suspect, to integrate DropBox with a word-processor to allow drag-and-drop images and attachments — anything that can be represented by a url is, of course, golden.

Most of the missing features from the free word-processor in your browser are what you’d expect. E.g. anything to do with overall document structure: automatic index and table of contents generation, footnotes, endnotes, headers, footers, and so forth. None of this stuff is hard to do in a browser. The real problem is support for printing — browsers generally suck at targeting printers — so you’re not going to replace Quark or InDesign — but if you’re targeting ePub rather than paper, I don’t see why you’d want to use anything else.

Final Thoughts

The advantages of “owning” your word processor’s codebase are enormous, especially if you’re trying to integrate it into a complex workflow. You can fine-tune exactly what happens when a user hits delete (e.g. we need to track dependencies — was this paragraph based on that paragraph template or not?), and what is editable or not. You can do validation inside input fields while allowing other text to be edited free-form. It’s pretty wonderful. One day, perhaps, there will be free off-the-shelf editor that solves key UI and workflow integration issues, but we’re a ways from there.

 

Transparency is a Feature

Somehow or other I ended up finding a hosting provider named Site5. They’re currently my front-runner. They offer a guaranteed 99.9% uptime on their shared hosting accounts, and have an interesting “Cloud Hosting” account which promises 99.99% uptime (they claim that in the event of a complete hardware failure, your site will be back up in less than ten minutes; 0.01% uptime is about 4 minutes per month). This latter costs roughly the same as a Pair “advanced” shared hosting account.

The thing that impresses me most about Site5 is their transparency: they have user forums with complaints from users (and responses from the CEO and CTO) out in plain sight, and they have pages showing the status and uptime statistics for all of their servers; judging from my random spelunking of these pages it seems to me that their 99.9% uptime guarantee for shared hosts is slightly optimistic (at least on a monthly basis). I went and looked at a server that had gotten lots of complaints recently, and sure enough its stats sucked.

After seeing how well Site5 does this stuff, I tried googling for server status pages for other hosting providers and pretty much came up empty. (In general, it’s not that there’s not some kind of server status page for most providers, it’s just that it’s useless.)

Uptime

Our local power company advertises 99% uptime. (I may be mis-remembering, it may have been 99.5%.) The point is that 1% of a month is about seven hours (and we do get a lot of outages here, in no small part thanks to frequent thunderstorms and tornadoes). 99.9% uptime is not really all that much to ask — the only downtime I get on my Macs (which aren’t managed by anyone) is for power outages and major system updates every couple of months (which involve a sub-60s reboot). 99.99% uptime is a lot more ambitious.

(By way of comparison, Joyent advertises “telco reliability”, which I guess is “five nines”. (Or, in Alabama, “two nines”.) If I could justify getting a Joyent account, I’d love to, since they’re a big backer of node.js and offer support for it “out of the box”.)