Dropbox vs. Box vs. HubiC

Edit: Brain Fart — I seem to have omitted about a paragraph of pertinent information.

I’ll assume you all know what Dropbox is. If you don’t, go get Dropbox now. It’s free and it’s awesome.

The only downside of Dropbox is that if you want more than the 2GB of storage you get for free, it gets more expensive, and the upper limit on how much you can store is (for practical purposes) quite low. Personally, I haven’t found either of these an issue — but thanks to my link on opensourcemac.com, I have a pretty huge “free” account. But it would be awesome to have something like Dropbox that was so big I could just stop managing what I keep on it altogether (of course, this is the problem with stuff that’s free — you waste it).

Box.com has been around about as long as Dropbox (heck, it has an even better domain name, right?) but has been targeted at the enterprise.

hubiC.com (their capitalization) I just found out about via Hacker News. It offers more free storage than Dropbox, but not quite as much as Box, and vastly cheaper paid plans, including about $140/year for 10TB. (I’m not sure how you can actually get 10TB into it, short of using a ZFS or Drobo style multi-disk volume.)

2GB vs 50GB vs 25GB

This is how much storage you get for free.

$100/year for 100GB vs. $10/month for 100GB vs. $13.60/year for 100GB (or $136/month for 10TB)

Edit: I’ve corrected the costs for HubiC.

This is how much it costs for more storage. Box gives you — by far — the most free storage but gets more expensive than Dropbox (while offering various enterprisey features). HubiC is insanely cheaper than both of them. By way of comparison, iCloud costs $20/year for 20GB, so in terms of dollars per unit storage, only HubiC is a better deal. In terms of useful features out of the box, Dropbox support is built into far more programs while iCloud offers useful functionality (notably over-the-air backups of devices and integration with Apple products) to Mac and iOS users that no other platform can (currently) match.

For Android users, the iCloud equivalent is Google Drive, which gives you 15GB free, and costs $60/year for 100GB, making it a bit cheaper (and less useful) than Dropbox.

Mac OS X Integration

All three programs appear as folders in your home directory by default, and stick shortcuts to themselves in Finder’s sidebar. Having installed HubiC and then Box after installing Dropbox, Box was very flaky when first installed. Its installer provided no feedback, and the first few times I tried to launch the application nothing seemed to happen, followed by weird broken delayed launches. Once I’d patiently killed a bunch of Box.app instances and started over it worked well.

Box and Dropbox have similar levels of Finder integration — they indicate the state of files and provide context menu items for sharing links. HubiC appears not to do anything like this, unfortunately.

All three applications provide status menus — those icons that appear in the menubar to the left of the Spotlight magnifying glass. I should note that HubiC’s icon looks like a shapeless blue blob — a blue cloud? — which is an anti-feature. The status menus of all three seem to be perfectly fine and offer decent functionality. Oddly enough, Box and Dropbox no longer keep you apprised of your usage level whereas HubiC does.

Box has one glaring defect — it won’t sync Mac OS X “bundles” (i.e. directories masquerading as files). I have no idea why — they’re just directories. It tells you to zip them up first (gee, how about doing it yourself?)

All three services offer support for all the usual platforms — although I can’t comment on how good any of them are (except the Dropbox client for iOS is decent, and all three work decently in a web browser, although HubiC’s in-browser account management is awful). I cannot yet comment on the security of Box or HubiC. Dropbox offers, and I use, two-factor authentication, and I’m pretty sure HubiC does not (but its website is pretty hard to navigate so maybe it’s there somewhere).

Conclusion

If you just want some free storage and don’t mind not being able to sync bundles then Box is a better deal than Dropbox and it’s probably quite robust given the money behind it. If you’re already using Dropbox and don’t need more storage, Box does not work as well so unless you want its enterprisey features (and you know who you are) you might as well stick with Dropbox. I can’t really comment on HubiC until I’ve exercised it by, saying syncing a buttload of RAW files to it (if I’m going to get more cloud storage, I want enough of it to not need more than one service). If you’re interested, HubiC is a damn good deal for free and it works side-by-side with the others. If it turns out to deliver the goods, I may well end up buying a 10TB plan and switching to it from Crashplan.

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.