Confirm
656
edits
Changes
→MakeDrive's Sync UX
==MakeDrive's Sync UX==
With MakeDrive we have a chance to do something different, offer something familiar, but re-imagined for something useful, and something of the web.
<blockquote>''I want the web to win because it is going to enable rich always-up-to-date, safe, frictionless, easy-to-share, instant-on, multi-screen experiences. All of these are features targeted at users, and none of them possible in a native world.--from http://paulbakaus.com/2014/04/16/winning-for-users/''</blockquote>
There are lots of cloud-based storage systems, and we can learn from them. None of them is specifically designed for the web, all of them assuming an OS and native filesystem. Often, they work best when their design is so carefully folded into the OS that you don't have to learn how to use them (e.g., the /Dropbox folder).
MakeDrive is also a cloud-based storage system, but with a browser and a browser-filesystem replacing the OS + native filesystem. This design has some drawbacks:
* the browser filesystem can't be merged into the native filesystem. It's possible to get files in and out of the browser and native filesystems, but it requires careful design work
* the user is likely going to struggle with the idea of a "filesystem in their browser," and so it has to be carefully disguised so as not to confuse
* the browser filesystem is tied to a particular browser
This design has some advantages:
* you don't have to install anything to create a new client--just visit a web page, and it happens automatically
* you can get your filesystem on any computer or device that has a web browser, including mobile devices, where creating your own sync apps can be greatly restricted by App Stores
* you can move your files (sync) across devices, operating systems, etc. The browser, and the web, are the platform
Designing an always-available, always sync'ing web filesystem isn't as simple as copying what's been done before. Browser users are different from desktop/OS users. For example, a desktop storage client can run at startup and then stay active all the time in the background. A browser storage client has to deal with the transient nature of the user, who is unlikely to spend hours on the same thing. Moving data from the cloud to the local/browser filesystem is still the same problem (i.e., you have to more the same number of bits either way).
The problem can be described as the problem of connecting ''Here'' and ''There''. ''Here'' is where we are, where we are working ''right now''. This ''Here'' is unstable, and may move from computer to computer, device to device. We can better think of ''Here'' as ''This Here'' since it doesn't have the same stability as ''There''. ''There'' is always elsewhere, but may or may not be accessible from ''This Here'' (e.g., no Internet), and it's important to note that we may choose this situation, or it may be chosen for us. In other words, there is sometimes a way from ''This Here'' to ''There'', but not always.
The relationship from ''This Here'' to ''There'' is less interesting to users than to us. As a user, I am always ''Here''. I may want to work with a particular file or set of files, and they might be ''There'' or available in ''This Here'', but neither matters to me: I want them ''Here''. This requires one of a number of things to happen:
* Some automatic system needs to sync files between ''This Here'' and ''There'' such that I can satisfy myself with only ever being ''Here''; or
* I need to be made aware of what is available ''There'' vs. in ''This Here'' and be able to choose what I sync between the two.
There are tradeoffs. We need to think about the size of data we'll need to share over the current connection. We also need to decide how much we want to decide this for the user. On the one hand, it seems like access to everything is better, always. But in the case of an untrusted computer, I want as little to get sync'ed as possible--just enough to work right now ("Open my folder for Project X but nothing more").
The design problem is one that needs to use familiar UI, but augment it in ways that allow us to solve for our problems above. That is, we have dialog boxes for Open, Save As..., trees of files and folders, etc. and we have to add to these in ways that let us do what we need. Dropbox achieves this with extra icon overlays (green checkmarks, animated syncing arrows) to show the status of a file/folder.
==Questions==
