Is Dropbox the Mobile File System Standard

I’ve started using Dropbox on my Android devices recently (and my laptop as a result,1) and I’m incredibly impressed with the software and with the way that this service is a perfect example of the kind of web services that we need to see more of. While I have some fairly uninteresting concerns about data security and relying on a service that I’m not administrating personally, I think it’s too easy to get caught up the implications of where the data lives and forget what the implications of having “just works,” file syncing between every computer.

I used to think that the thing that kept mobile devices from being “real” was the fact that they couldn’t sell “post-file system” computer use. I’m not sure that we’re ready to do away with the file system metaphor yet. I think Dropbox is largely successful because it brings files back and makes them available in a way that makes sense for mobile devices.

The caveat is that it provides a file system in a way that makes sense in the context for these kinds of “file systemless” platforms. Dropbox provides access to files, but in a way that doesn’t require applications (or users) to have a firm awareness of “real files. Best of all, Dropbox (or similar) can handle all of the synchronization, so that every application doesn’t need to have its own system.

This might mean that Dropbox is the first functionally Unix-like mobile application. I think (and hope) that Dropbox’s success will prove to be an indicator for future development. Not that there will be more file syncing services, but that mobile applications and platforms will have applications that “do one thing well,” and provide a functionality upon which other applications can build awesome features.


This isn’t to say that there aren’t other important issues with Dropbox. Where your data lives does matter, who controls the servers that your data lives on is important. Fundamentally, Dropbox isn’t doing anything technologically complicated. When I started writing the post, I said “oh, it wouldn’t be too hard to get something similar set up,” and while Dropbox does seem like the relative leader, it looks like there is a fair amount of competition. That’s probably a good thing.

So despite the concerns about relying on a proprietary vendor and about trusting your data on someone else’s server, data has to go somewhere. As long as users have choices and options, and there are open ways of achieving the same ends, I think that these issues are less important than many others.


  1. To be fair, I’m using it to synchronize files to the Android devices, and not really to synchronize files between machines: I have a server for simple file sharing, and git repositories for the more complex work. So it’s not terribly useful for desktop-to-desktop sharing, But for mobile devices? Amazing. ↩︎

Android Tablets and the Workstations of the Future

I’ve only had the tablet for a few weeks, but I’m pretty sure the tablet incarnation of Android is probably 80% of what most users need in a workstation. I’m not most users, but I figure: hook up a big screen and a real keyboard. Create some key bindings to replace most of the gestures, and write a few pieces of software to handle document production, presentations, and spreadsheets in a slightly more robust manner, and you’re basically there. I wouldn’t give up my laptop today for a tablet, and I think the platforms still have a ways yet to go, but that’s not insurmountable.

Prediction: in the next decade, we’ll see embeded tablet-like devices begin to replace desktops computers for some classes of use and users. General web surfing, reading, quick email, and watching videos on YouTube seem like the obvious niche for now. I started to explore this in “Is Android the Future of Linux,” but it’s not abusrd to suggest that Android or iOS like devices might begin to address more “general purpose desktop computing.”

I want to be clear: we’re not there yet. These systems aren’t versatile and fully featured enough to keep up with full time use on an extended basis. This is mostly an application/software problem. As applications evolve and as more functionality moves to remote systems anyway (this is the “cloud,” we’ve heard so much about,) tablet operating systems will seem much more capable for general purpose work. Better mobile productivity software will help as well. Eventually, I think Android and similar platforms will have a shot at the desktop market for most usage because:

  • IT departments will get a lot more control over intra-organization information flow, which could save a lot of money for various IT categories: administration, support, and data protection costs.

  • Behind the firewall dropbox-like services, and creating some sort of centralized workstation configuration management (which makes sense for a flash based device,) means backups can happen automatically, and if devices need to be re-imaged or are lost or damaged, it only takes a few minutes to get someone back to work after a technology failure.

  • Limited multi-tasking ability will probably increase productivity.

  • Disconnecting keyboards from the screen will probably lead to better ergonomic possibilities.

  • Eventually, it will be easier to integrate Android-like devices with various workflow management/content management systems.

    The technology needs to mature and workers and IT departments need to become more comfortable with tablets, without question. Also, there are some fundamental developments in the technology that need to transpire before “desktop tablets” happen, including:

  • More power user-type interface features.

  • Split screen operation. There are enough “common tasks” that require looking at two different pieces of information at the same time that I think tablets will eventually have to give up “full screen everywhere,” operation. Conventional windowing is unnecessary, and I don’t think anyone would go for that, but displaying two different and distinct pieces of information at once is essential.

  • Better “Office” software for spreadsheets, presentations and document preparation. A necessary evil.

  • Behind the firewall (preferably open source) solutions to replace services like Dropbox/Box.net and whatever other services emerge as essential parts of the “tablet/smartphone” stack.

  • VPN clients and shared file system clients that are de ad simple to use. I think these are features for operating system vendors to develop.

Thoughts? Onward and upward!

Org Mode and Mobile Writing

This post is adapted from a post I made to the org-mode email list a few weeks ago. I proposed an application to compliment MobileOrg for writing. Where MobileOrg collects the core bits of org-mode’s task planning functionality in a form that makes sense for smart phone users, the parts of org-mode functionality that people use to for writing and organizing the content of larger form projects isn’t particularly accessible.

I spend (or should spend) 70% or more of my time in front of a computer writing or editing something in org-mode. Most of my org files have tens of thousands of words of blog posts, notes, drafts of articles, and so forth. While I can store that data on an android device with only minor problems using a little script that I put together, and I can capture content into my org-files using email and some nifty filters, and there are text editors that can let me edit these files: it could be better.

The proposal is simple. Can we build something like Epistle for org-mode? It might just render org-mode text to HTML, and frankly that would be enough for me. If the editing interface had an org-indent-mode equivalent, org-syntax highlighting, and even collapsing trees or org-narrow-to-subtree, that’d be kind of like heaven.

I’m not a mobile developer, so I can’t promise to start making an app this instant if there’s interest but if anyone’s bored and thinks this might be a good idea (or knows of something that might work better for this.) I’d love to hear about it. If someone wants to start work on this, I’ll do whatever I can to help make this a reality.

Onward and Upward!

Tablet Interfaces and Intuition

I’ve been using FBReaderJ to read .epub files on my tablet recently, and I discovered a nitfty feature: you can adjust the screen’s brightness by dragging your finger up or down the left side of the screen. Immediately this felt like discovering a new keybinding or a new function in emacs that I’d been wishing for a while time. Why, I thought, aren’t there more tricks like this?

The iPhone (and the iPad by extension) as well as Android make two major advances over previous iterations of mobile technology. First, they’re robust enough to run “real” programs written in conventional programming environment. Better development tools make for better applications and more eager developers (which also makes for better applications.) Second, the interfaces are designed to be used with fingers rather than stylus (thanks to capacitive touch screens) and the design aesthetic generally reflects minimalist values and simplicity. The mobile applications of today’s app stores would not work if they were visually complex and had multi-tiered menus, and hard to activate buttons.

The tension between these two features in these platforms makes it difficult to slip nifty features into applications. Furthermore, th economy of application market places does not create incentives for developers to build tools with enduring functionality. The .epub reader I mentioned above is actually free software.1 I write a couple of posts a while back on innovation (one and two) that address the relationship between free software and technological development but that’s beside the point.

Given this, there are two major directions that I see tablet interfaces moving toward:

1. Tablet interfaces will slowly begin to acquire a more complete gestural shorthand and cross-app vocabulary that will allow us to become more effective users of this technology. Things like Sywpe are part of this, but I think there are more.

2. There will be general purpose systems for tablets that partially or wholly expect a keyboard, and then some sort of key-command system will emerge. This follows from my thoughts in the “Is Android the Future of Linux?” post.

I fully expect that both lines of development can expand in parallel.


  1. I also found the base configuration of FBReader (for the tablet, at least) to be horrible, but with some tweaking, it’s a great app. ↩︎

Is Android the Future of Linux?

By now, several weeks ago, in correspondence Matt Lundin that he thought Android was probably future of Linux," mostly as a throw away line. This feels like a really bold statement,1 and I’ve enjoyed thinking about Android and “the future of Linux."2

On the face of it, Android is the future of Linux. Android is the Linux that most people will interact with before all others in a concrete manner. In all likelihood The future of Linux is probably mostly in running web servers, virtualization hosts, and any other server that matters. At this point, Linux’s platform support and use cases is far less interesting than its prevalence: the ubiquity of Linux, GNU, and BusyBox, is more import an that the fact that Linux runs everywhere in hundreds of different usage profiles.

And really, “desktop Linux” or even “Linux for end-users,” is something of a distraction. We don’t all have to use Linux on the machines beneath our fingers for Linux to be successful. I’m a desktop Linux user because it’s the right system for the work I do, and I can’t work the way I need to with any other kind of system. But I use my systems in a very peculiar way and the thing that makes Linux ideal for me (and the people who are good at building Linux systems,) is not necessarily the qualities that make the best Linux distributions for most users.

As someone who cares about Linux adoption and the use of free software, I don’t want my argument to lead to the very common “let non-technical users use Macs” argument. Although it’s true that OS X can be a convincing introduction to power and use of having a full UNIX-like system on your lap: this was my root (as it were.) Rather, I think that the way to encourage Linux adoption is to increase computer literacy until users respect and value and power that Linux-based systems offer.

Easier said than done, of course.

If this is the case, then Android isn’t a very good introduction to Linux-based operating systems. Not because it’s bad software, but because the kernel is pretty irrelevant to the overall user experience, or the interface that most users have.

Regardless, while madalu is probably right, I don’t think it matters. Android is largely orthogonal to the adoption of Linux. The bigger questions are:

  • Does Microsoft have a tablet strategy? Really? The last time Linux made headway into users' hands (i.e. netbooks,) Microsoft changed strategies, and not only pushed Linux-based systems out of the market, but they also basically killed the device class. Netbooks really aren’t a thing anymore.
  • How close are we to tablet-like (or tablet-derived) devices from replacing general purpose computers for some classes of day to day activity. I suspect corporate machines will be the first to fall (more constrained/specific use cases; tablet systems give IT administrators more control, and increasingly work happens in web apps.)

If corporate fleets are the first to fall, the first question becomes much more important. In any case, stay tuned, I’m working on collecting the rest of my thoughts on these questions. In the mean time, I’d look forward to hearing from you.

Onward and Upward!


  1. I would like to fully apologize ahead of the time if I’m characterizing the argument unfairly. ↩︎

  2. Though mostly ceremonial to mark the 20th anniversary, and because there have been 39 releases of the 2.6.x series kernel which is absurd to keep track of after a while, Linux is getting a version boost to version 3.x. ↩︎

And Then I Broke Down and Got a Tablet

Ok, I caved and got a tablet. This is a post about my experiences with the tablet and some general thoughts on the format.

I opted for the Motorola Xoom. It’s an Android device, I appreciate the Motarola build quality, and I’m very pleased with my choice. First impressions first:

  • Reading on the tablet is great. I have a Kindle, and while I respect how lightweight the Kindle is itself. Despite the extra weight, the slightly larger screen and the back light is very very nice and very welcome.
  • I don’t expect that I’ll be doing a lot of writing on the tablet, a laptop is never really going to be that far away, but I’m really surprised by how easy it is to (almost) touch type on the tablet. A number of very simple and probably straightforward innovations to the keyboard could make things so much better.
  • I think all devices need some sort of “don’t auto rotate” hardware switch. In fact, I think apple’s whole “lets get rid of hardware buttons,” movement to be really annoying. Buttons should be overloaded, sure, but I hate having to hunt through menus to modify basic behavior. Having said that, the “software control bar” at the bottom of Android 3.0 is brilliant and a good move (given screen rotation.)
  • I lament not having a Google voice widget for the tablet. Makes sense that they wouldn’t want this for tablets that had data plans, but I just have a wifi tablet.
  • The Kindle app doesn’t let you bookmark your place in periodicals. Which might make sense if you were reading the Times, but doesn’t make a lot of sense when reading fiction magazines with articles in the rage of 10k words.
  • I’m in love with the calendar application, except for the “full month view,” in which you scroll by weeks, not by months. Even with this glitch, I’m curious as to why there aren’t (stand alone) calendar applications of this quality for desktops.
  • I’ve tended to use the tablet for situations where I want to have a distraction free experience (usually for reading,) or where I want to do “computer things” in a situation where I might need to interact with other people. Having a tablet in your lap is more social than a laptop. As such, I don’t think it would ever be able to replace a “real” computer for very long, but that doesn’t make it less useful.

I’ll be writing more about the tablet experience and some cyborg features of tablet use and usability.

Onward and Upward!

Mobile Productivity Challenges

I’ve never really figured out how to do work with anything less than a full computer. I’ve tried everything: Palm Pilots and Pocket PCs in the early 2000s, laptops, and eventually I just settled on just dragging a (smaller) laptop almost everywhere circa 2005. I get the feeling that, most people who have been thinking about mobile technology and productivity assume that the only impediments to mobile productivity are better hardware and software. Contemporary (multi)touch screen devices are the current embodiment of this theory.

I’m convinced that the theory is wrong.

Having better and more powerful technology doesn’t hurt anything. I’m a huge fan of the smaller, integrated, and more powerful devices. Software written specifically with mobile users in mind does improve the potential for productivity. These technological improvements, however, make the underlying problem more apparent.

The challenge of getting things done when mobile has little to do with the capabilities of the mobile platform, and more with the way people think about and plan work when mobile. Not only is this hugely frustrating to users, but technological capability that people can’t use threatens the ongoing development and adoption of new technology.

Using Mobile Technology More Effectively

The solution, here, I think is two-fold:

Fully Integrated Applications

Let’s develop integrated applications, not just integrated devices with different applications. Just as we didn’t need separate devices for every mobile function: telephony, music playing, book reading, mobile internet, and so forth. We don’t need different applications for every function: calendaring, messaging, email, contact management, notes, reading, and so forth.

At the very least applications need to be highly interoperable, so that users can send data between application functions easily, and synchronize data back to desktop and web portals seamlessly.

Task Planning Strategies for Mobile Productivity

I don’t think that the “user stories” for mobile technology are really fully developed, and as a result any interaction with a mobile device that isn’t responsive (i.e. there’s an alert of a new event, and people respond to it,) is either “twiddling nobs” (i.e. non productive,) or entertainment focused (i.e. playing music, video, or opening a book.) Perhaps that’s enough for some uses, but these this kind of workflow covers a small percentage of what people do with computers.

If mobile technology is going to replace a general purpose laptop, ever, even in limited situations, we need to figure out how to work in different ways. I know that I am loosing a great deal of time, when I’m using my phone switching between the notes app, the reader, the task list, and the calender. This task switching gets in the way of doing things to a much larger extent than similar behavior does when using a conventional computer. I would even posit that, the cost of context switching is inversely related to the size of the interface.

Better application integration will help this, but I think the real solution is providing a method for people to organize their mobile time more effectively. The task list that we build for ourselves when we’re doing “conventional” work (i.e. things that we need to remember to do, open projects, open issues,) aren’t particularly useful or usable when we’re looking at a tablet or a phone. If we don’t know what we ought to be doing, it doesn’t matter what the device or software is capable of in theory.

There are probably a dozen or more solutions to this problem, but here’s my first stab at it. What if there was a way to “forward tasks” to ourselves when we’re on the run, but have a few moments? We all loose time waiting in queues, or waiting for trains, and these seem like ideal phone times. If we had a way to queue things for ourselves, so we could spend the time doing something. Even better, would be software that would not only collect and display the queue but would also connect with the application where whatever needed to be done was and then record the results and send the back to our desktops when we were done.

Thoughts?

On Wireless Data

It’s easy to look around at all of the “smart phones,” iPads, wireless modems, and think that the future is here, or even that we’re living on the cusp of a new technological moment. While wireless data is amazing particularly with respect to where it was a few years ago--enhanced by a better understanding of how to make use of wireless data--it is also true that we’re not there yet.

And maybe, given a few years, we’ll get there. But it’ll be a while. The problem is that too much of the way we use the Internet these days assumes high quality connections to the network. Wireless connections are low quality regardless of speed, in that latency is high and dropped packets are common. While some measures can be taken to speed up the transmission of data once connections are established, and this can give the illusion of better quality, the effect is mostly illusory.

Indeed in a lot of ways the largest recent advancements in wireless technology have been with how applications and platforms are designed in the wireless context rather than anything to do with the wireless transmission technology. Much of the development in the wireless space in the last two or three years has revolved around making a little bit of data go a long way, in using the (remarkably powerful) devices for more of the application’s work, and in figuring out how to cache some data for “offline use,” when it’s difficult to use the radio. These are problems that can be addressed and largely solved in software, although there are limitations and inconsistencies in approach that continue to affect user experience.

We, as a result, have a couple of conditions. First that we can transmit a lot of data over the air without much trouble, but data integrity and latency (speed) are things we may have to give up on. Second that application development paradigms that can take advantage of this will succeed. Furthermore, I think it’s fairly safe to say that in the future, successful mobile technology will develop in this direction as opposed against these trends. Actual real-time mobile technology is dead in the water, although I think some simulated real-time communication works quite well in these contexts.

Practically this means, applications that tap an APO for data that is mostly processed locally. Queue-compatible message passing systems that don’t require persistent connections. Software and protocols that assume you’re always “on-line” and are able to store transmissions gracefully until you come out of the subway or get off of a train. Of course, this also means designing applications and systems that are efficient with regards to their use of data will be more successful.

The notion that fewer transmissions that consist of bigger “globs” of data will yield better performance than a large number of very small intermediate transmissions, is terribly foreign. It shouldn’t be, this stuff has been around for a while, but nevertheless here we are.

Isn’t the future grand?