W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2014

Re: [whatwg] Shared storage

From: Brett Zamir <brettz9@yahoo.com>
Date: Mon, 10 Nov 2014 18:08:38 -0700
Message-ID: <54616196.4070701@yahoo.com>
To: whatwg <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
(Apologies...resending due to my inadvertent use of generic "whatwg" subject...)

On 10/28/2014 12:06 PM,whatwg-request@lists.whatwg.org  wrote:

> Date: Tue, 28 Oct 2014 17:33:02 +0000 (UTC)
> From: Ian Hickson<ian@hixie.ch>
> Subject: Re: [whatwg] Shared storage
> On Sat, 15 Feb 2014, Brett Zamir wrote:
>>> The desktop PC thankfully evolved into allowing third-party software
>>> which could create and edit files shareable by other third-party
>>> software which would have the same rights to do the same. The importance
>>> of this can hardly be overestimated.
>>>
>>> Yet today, on the web, there appears to be no standard way to create
>>> content in such an agnostic manner whereby users have full, built-in,
>>> locally-controlled portability of their data.
> Why can't you just do the same as used to be done? Download the resource
> locally ("save", using <a href download>), then upload it to the new site
> ("open", using <input type=file>)?

Yes, as mentioned by others, this can become a terrible user experience,
and this is not to speak of user agent reasons.

Besides the added challenges mentioned by Katelyn Gadd when live updates
occur on multiple instances of the file across different applications,
there is also the even more common use case of a particular app being
able to remember the files used previously and let the user access them
without needing to remember their exact location in a hierarchy (though
allowing a hierarchy is desirable to the user for flexibility in
organization).

Such recall of, and access to, previously used files without repeated
need for manual selection is commonly found in apps which use the likes
of a "recent files" drop-down or, perhaps even more commonly, by a set
of tabs which open with the last set of used files.

There is also the specific desirability for functionality to iterate
through file names (or other shared data) so that apps can provide their
own UI, perhaps filtered down by file type according to the types of
files consumable by the app, such as an IDE project viewer which still
allows the user to group files app-agnostically and where they wish
along with other file types.

The ability to store files of different types within the same
user-viewable and user-creatable folder is compelling because the user
has freedom to group like content together even if the file types
differ. A user might wish to store an email draft, a word processing
file, and a set of images all in the same folder to keep track of them,
even if a given web app might not utilize all of these types. While
there are apps which aggregate data from different sources and then let
the user tag them in such a manner as to mimic this functionality, this
is again application-specific and not necessarily portable or as
flexibly under user control as would be a shared and hierarchical file
storage area.

Best,
Brett
Received on Tuesday, 11 November 2014 01:45:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:32 UTC