How Google Docs Killed GDrive • Hacker News Board

Re: How Google Docs Killed GDrive

#21

Post by neworbit » Sun, May 22, 2011, 1:19 PM UTC

nezumi wrote: post #6

neworbit wrote: post #4

Dear Google, you're doing it wrong. We understand that you would like google lockin on our file system, but the rest of us who do not necessarily have 24-7 100% reliable connectivity or prefer to work on things quietly offline (for instance, competing search technology) might think files resident somewhere else might not be so bad.

How would the GDrive help you with that?

If you mean "how do I use Dropbox to do exactly that", I share encrypted files with coworkers so that they are automatically replicated when connectivity is available. This addresses both the security-of-content perspective and the fact that even in the best of circumstances we will find necessity for offline access.

Re: How Google Docs Killed GDrive

#22

Post by neworbit » Sun, May 22, 2011, 1:20 PM UTC

asmithmd1 wrote: post #19

magicalist wrote: post #14

"I don't think we need files anymore." what does that even mean? even excusing the technical silliness of the statement, it's not even sound conceptually, unless "docs" are somehow not files. maybe, "we don't need a (hierarchical) file system"? I also don't believe that "The service still doesn't offer a way to sync files" is true, incidentally. You could say that the service doesn't offer a pre-built, user-friendly…

Hasn't the iPad abandoned files?

In the same sense perhaps; hidden them from the end user.

Re: How Google Docs Killed GDrive

#23

Post by hnsmurf » Sun, May 22, 2011, 3:24 PM UTC

I suppose the fact that more people use Dropbox than Google Docs shows they overestimated the speed of the transition.

Re: How Google Docs Killed GDrive

#24

Post by wahnfrieden » Sun, May 22, 2011, 7:21 PM UTC

neworbit wrote: post #20

wahnfrieden wrote: post #13

Earlier quoted context omitted.

Google is adding back the offline support for Docs this summer (they had it before with Gears, but removed it). So your point is inaccurate soon enough.

FUD about what Google might do in the future does not help me today nor really invalidate the point

No, but announcing the feature and showing a demo of it in action is not quite "FUD about what Google might do." It's also in line with the trend of their other products adding offline support.

Re: How Google Docs Killed GDrive

#25

Post by jamesbritt » Sun, May 22, 2011, 11:26 PM UTC

derefr wrote: post #17

magicalist wrote: post #14

"I don't think we need files anymore." what does that even mean? even excusing the technical silliness of the statement, it's not even sound conceptually, unless "docs" are somehow not files. maybe, "we don't need a (hierarchical) file system"? I also don't believe that "The service still doesn't offer a way to sync files" is true, incidentally. You could say that the service doesn't offer a pre-built, user-friendly…

A "file", in almost all usage, refers to a specific kind of data structure: a stream of serialized data that presents random block-level access but which is most efficient when sequentially accessed, and which has a filesystem-defined structure of metadata attached that can be read more efficiently than reading a single block of the file (and is usually available even when the file isn't—e.g. when you don't have read…

Thus, Google could just as well store all your docs as structured data in a BigTable db (they probably do, actually), and you wouldn't know the difference.

This may be a terminology issue. Whether my files are stored on disk or in a database makes no difference to me so long as I can still interact with my files. The actual persistence mechanism for "file" is an implementation detail.

The key thing I get from "the end of files" discussions is how a user interacts with data. From a file point of view you select a file pick an app to pass it to (though usually opting for a default). With an app POV you have to first pick an app and then have it open (or not) some file.

Most of the time, in practice, it amounts to the same thing. E.g. rarely does one navigate to a .doc file then ponder what app to pass it to. But in some cases, such as with audio or graphics files, you do want to consider what app to use with a file, and it may be easier to first find the file and then pass it off to an app based on what you want to do with it.

The other day I noticed something interesting on my Mac Mini. I wanted to manipulate an image file, and the default app association (Preview, I think) was not what I wanted. So I right-clicked to get a choice of apps. Windows and Ubuntu are pretty good about showing a subset of all possible apps for assorted file types, offering likely candidates (e.g. gimp, Paint.net, Photoshop) as top options.

But with OSX I was just given the full list of every app I have installed. I'm not a frequent Mac user (don't care for the UI choices) but I got the feeling that I was doing something completely out of bounds, that OSX was not meant to help guide me from file to app, that I really should be picking the app first.

It left me feeling that this sort of casual exploration and discovery was frowned on, but that might be my OSX-aversion acting up. Still, I can see the same thing with Google; there's not need for users to think about trying different apps with their data because that's already been decided.-

Re: How Google Docs Killed GDrive

#26

Post by derefr » Mon, May 23, 2011, 2:56 AM UTC

jamesbritt wrote: post #25

derefr wrote: post #17

Earlier quoted context omitted.

A "file", in almost all usage, refers to a specific kind of data structure: a stream of serialized data that presents random block-level access but which is most efficient when sequentially accessed, and which has a filesystem-defined structure of metadata attached that can be read more efficiently than reading a single block of the file (and is usually available even when the file isn't—e.g. when you don't have read…

Thus, Google could just as well store all your docs as structured data in a BigTable db (they probably do, actually), and you wouldn't know the difference. This may be a terminology issue. Whether my files are stored on disk or in a database makes no difference to me so long as I can still interact with my files. The actual persistence mechanism for "file" is an implementation detail. The key thing I get from "the en…

OSX is actually pretty good about file associations in general; every app publishes a list of extensions it can open, and the list you get in the Open With context menu is generated from that. The difficulty is simply that almost everything in OSX can do one thing or another with image files, and without any association to an already-open app, the OS doesn't know what you're trying to accomplish. Are you converting the image to a different format? Viewing it? Editing it? Attaching it to an email? Setting it up as album art for some songs you have? Etc.

The real problem is that files represent a noun-based model of user interaction, and apps a verb-based model, but what we want is neither; in the user's mind, he is actually performing a task, and both the relevant data and the functions to manipulate it are subservient to the task being accomplished. (Disclaimer: with this in mind, I've been working on a GUI that would have a sort of to-do list/notification system as the system shell and hierarchy of organization under which both data and applications reside, thus always giving both each datum and app a context it can examine to determine what apps, or data, respectively, are relevant to its current instantiation.)