

How Google Docs Killed GDrive - timf
http://googlesystem.blogspot.com/2011/05/how-google-docs-killed-gdrive.html

======
riobard
GDrive = “syncing files, viewing files on the Web, shared spaces for
collaborating on a document, offline access, local IO speeds” sounds exactly
like Dropbox.

Apparently they are thinking too far ahead in the future where Internet
connection is ubiquitous and super fast while ignoring the reality.

Dropbox's popularity proved GDrive would be a great product. I would guess the
engineers at Google should be as good as, if not better than, guys at Dropbox.
Given the planned launch time in 2008, it might very well kill Dropbox right
at the beginning, or Dropbox might be a no-go for YC since Google would be
doing it so good for free.

PS: Does anyone feel this is just internal politics to kill competing projects
so his own project (Sundar is the lead of Chrome) can get more resources?

~~~
dsplittgerber
It's really interesting. When you read 'In the Plex' - which is superb and
totally awesome -, there are several instances where you get the sense that
Googlers are living in a kind of perfect bubble, shielding them from the kind
of problems and hassles regular people have to deal with.

Things like super-fast wireless access (= 24/7 in the cloud) everywhere, being
surrounded by like-minded rationalists etc. wind up hurting your products, as
you cannot easily relate to the worldview of regular people anymore. Witness
the launch of Buzz and it's default opt-in and several other privacy disasters
- it made perfect rational sense to launch several features and products the
way they were launched as it enhanced efficiency and ease of use etc. But no
one at Google apparently thought about your abusive ex-boyfriend now being
able to see your buzz activity etc - probably because for rational people such
a scenario just isn't in the realm of scenarios one considers. But real life
is messy that way.

This is perfectly understandable, though. From the book you get the sense that
Googlers are in a way already living several years ahead of regular people,
which shapes their products - in good and bad ways.

------
xtacy

        "I don't think we need GDrive anymore." Horowitz
        asked why not. "Files are so 1990," said Pichai.
        "I don't think we need files anymore."
    

I wonder what they would think of that statement given Dropbox's adoption.

~~~
wahnfrieden
I don't doubt that they knew lots of people would use GDrive. It sounds like
their decision to drop it ha more to do with it's impact on their other
products, and to fit in with their longterm vision. Google Docs might not have
met as much use if GDrive helped solve some of the problems with MS Office,
for example. It also sets user expectations.

------
neworbit
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.

~~~
nezumi
How would the GDrive help you with that?

~~~
nemeth
If the GDrive were similar to Dropbox, a copy of all files would be stored
locally and be accessible without an Internet connection.

Google Docs offline access isn't even going to relaunch till later this year,
so right now, storing files exclusively in Docs is a non-starter without an
always-on Internet connection.

~~~
TeMPOraL
And that's the primary reason I don't even think of using Docs for anything
except on-line surveys - I often work offline, and I need local files.

------
amorphid
I've mostly stopped using Google Docs because MS Office + Dropbox is so much
more handy in the majority of situations for me.

------
magicalist
"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 way to sync files, but the documents API is pretty
decent when I've used it (but maybe you can only sync docs, not any file??
a-ha!)

~~~
derefr
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 permissions to the file.)

Google Docs has documents, but doesn't have files. iOS _usually_ doesn't have
files. Etc. It's not that the application-level services don't _use_ files
somewhere internally, but the fact that they do is an _implementation detail_
, rather than an exposed part of the _client protocol_. 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.

~~~
jamesbritt
_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.-

~~~
derefr
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.)

------
yuhong
Note that you can always import/export documents off Google Docs in another
format.

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

------
Lmclean
<http://cyberduck.ch/> allows access to google docs via it's FTP client,
pretty sweet.

I still prefer dropbox though but I use encrypted disk images for documents.

------
bauchidgw
so google docs is the google wave of file storage?

said that: i use google docs but i just love my dropbox (after i got rid of
the growl spam the installed on my system)

