Re: Proposal: gnome-user-share



On Thu, 2004-12-02 at 16:23 +0100, Maciej Katafiasz wrote:
> Well, give me one reason that prevents us from fixing that flaw? If we
> face problems, we should be fixing them, not putting some gross hacks
> and sticking with model that's inherently less capable. Hardcoded

I see no gross hacks here.  How is it inherently less capable?  (It
looks inherently *more* capable to me, because you can share things with
file-level granularity.)

> ~/Public is going to suck in two major use-cases: small/medium-scale
> inter-company sharing ("Ann works on annual reports, but her entire
> section needs to access them"), and neighbourhood-type sharing of movies
> and music ("Tom wants to share his 10GB music collection with Tim next

Ann clicks "Annual Reports", chooses "Make Link", chooses Places->Shared
Files, drags link to Shared Files.  (Or, unless she works at a really
small company, Ann makes a new folder on the file server.)

Tom clicks "Music", chooses "Make Link", chooses Places->Shared Files,
drags link to Shared Files.  (Or, if he's good at dragging, he chooses
Places->Shared Files, and control-shift-drags Music there.)

Where's the suck?

> door"). So, unless you consider sharing silly flash files and random
> pictures the only use-case worthy of supporting, ~/Public[1] is
> hopelessly limited, and in the end, user-unfriendly.

I don't see how sharing ~/Public/ is in any way limited to "silly flash
files and random pictures".  Nobody mentioned that restriction before.

It's also how the Mac (and Nextstep?) does user file sharing.  I've
heard many people (new and old) give many complaints about the Mac OS X,
but I've never heard anybody say that its file sharing is "hopelessly
limited" or "user-unfriendly".  (The opposite of the latter, in fact.)

It's also trivial to share (or un-share) files and folders from the
Terminal ("ln -s ~/Shared\ Files/Bananas ./Bananas").  Or to get a list
of what's shared ("ls -l ~/Shared\ Files/").

If you do a lot of file sharing, you could drag Shared Files to your
panel, and then just control-shift-drag (=link) files and folders to it
to share them, so it's even faster and easier than "right-click,
sharing, ...".  (Well, you can't right now, it seems, but you should be
able to.  :-)

There seem to be 3 user file sharing proposals on the table:
1. Mac-style: share ~/Shared Files/
2. Windows-style: share any folder (right-click, tweak some properties;
also a global list somewhere so you can keep track of everything)
3. Both...

#1 seems to have the simplest mental model.  What's the argument in
favor of #2/3?  The ones I can come up with are:

- Tom might not understand that he should make a *link* to his 10 GB
Music folder.  (I think it'll be pretty obvious when he drags it and it
disappears from his Home folder.  I think the word "Link" might be bad,
but I don't think users will have any trouble with the concept once they
see it.  User testing?)

One idea is to add a "Share this {File,Folder}" menuitem to Nautilus,
which would put a link to it in ~/Shared Files/ (and then open Shared
Files and select the link so you can see what it did).  This makes it
more discoverable, and makes it faster even for "power users".

- It's not what Windows users are used to.  (The first time they open
"Home", they'll see "Shared Files", or whatever we call it.  And this
way is simpler, so if they understand Windows file sharing, they can
understand this.  And this "problem" is why you write good and
easily-findable help documents, and advertise on www.gnome.org for
"switchers" that Gnome's file sharing is oh-so-much-simpler, not an
excuse to make file sharing more complex so Windows users feel at home.)

I'm not sure a more complex mental model is worth it.  To spin your
rhetorical question the other way: give me one reason why we should pick
the file sharing method with a known obvious flaw, and add more UI to
fix that flaw, and add a new shell command to let geeks share things
from the Terminal, instead of simply picking the simpler, more powerful
method to begin with?


- Ken




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]