Why you no sync with Box.net, TapNote?

(Fair warning: this is only going to be interesting if you are a TapNote user who is interested in Box.net synching.)

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.

2 responses to “Why you no sync with Box.net, TapNote?”

Leave a response

  1. What about the $35,000 cash that Box is offering to developers that use their API?

    • Ian Beck says:

      The $25,000 first place (or even the $10,000 second place) from the Box.net Mobile Dev Challenge are indeed very tempting for a small time dev like myself. However, there are several reasons the challenge did not sway me towards trying to switch to Box.net for synching (or adding it as an additional option):

      No guarantees. Participating in the Box.net challenge would take up a huge amount of time (see the impact on my development time argument above) on a very short timeline, but without any guarantee of payoff. In all likelihood if I won at all I would be one of the ten devs to receive a free TouchPad. And I already have a TouchPad.

      Short deadline. The deadline for the challenge is September 9. Dropbox took probably 4-6 months of solid work to implement, and I would have needed to compress that down into an even shorter time for Box.net.

      Poor fit. From the challenge’s description: “We’re looking for the next generation of enterprise-grade mobile applications that will enable workers to be as productive in the field as they are in the office. Judges will be looking for apps that are innovative and useful to the mobile workforce. … Finally, we want to see apps that are deeply integrated with the Box functionality. Go beyond uploading and downloading files.” This does not describe TapNote. TapNote in general is not very innovative (the basic concept was inspired by an entire niche of iOS apps I missed using after switching to webOS), and although I have plans for features that are not like anything I have seen in other Dropbox text editors they are down the road and require fairly significant work in their own right. Additionally, as I mentioned in the post, TapNote’s focus is on making individual users lives easier and more productive. Although it could be used in an enterprise setting, it is not focused in that direction and that would have been very obvious for the judges (making my chances of winning significantly less, lending the “no guarantees” argument even more weight).

      Wrong direction. Again from the contest description: “[Box.net is] offering prizes that we hope will help turn those apps into a venture backed business”. This is actually a deterrent to me. I have no interest in growing my app business through venture capitol. Doing all aspects of app design and development for me is personally fulfilling, and if I am unable to bootstrap it up as a business solely funded and supported by myself, then there is little point in doing it. My grandiose dream is not of having an app snapped up by some larger company or receiving some crazy windfall of venture capitol; rather, I would prefer to quietly make enough money from my independent endeavors to support myself and my family without outside assistance because that offers more personal fulfillment, seems more attainable through my direct effort, and also seems more sustainable long-term. The “mom and pop” approach to development that Anil Dash discusses or the one-man show best personified by Marco Arment are my models.

      Oof. And now you know why I left that out of the blog post: could have written a second post answering that question alone. :-)

Leave a response