Re: Proposal: gnome-user-share

[Maciej Katafiasz <ml mathrick org>]

Dnia 02-12-2004, czw o godzinie 17:19 -0800, Ken Harris napisał: 
> > 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.)

It's inherently less capable since it's equivalent to single, "magical"
folder made shared in Windows-type sharing ("Windows" is bad here, let's
call it "multiple shares" instead), and then artifically limited to that
special case. It is strict subset of multiple shares model (not that
this itself means anything yet), and more importantly, it's subset that
does *not* suffice for two biggest sharing use-cases mentioned (see
below)

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

Uh-oh, yeah, she figures it herself that she should create link. With
context menu. Cool. How does she know *what* link is, and that she
should use it? (Users *do* have problems understanding links, really).
Not to mention she needs series of closely connected, directed steps to
perform now, none of which is obvious.

> 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?

Uh-oh again. Tom wants to share his 10GB collection he keeps
on /dev/hdd, mounted in /mnt/Data. He drags the folder to ~/Shared. It
starts moving his 10GB worth of data. Now, will Tom figure out he can
cancel the move (hint: answer is "probably not". Users *are* afraid of
cancelling moves before they finish. Which means Tom is stuck there for
15mins waiting till it finishes, *and* he has to copy it back to Data,
*poof* another 15mins)?. Will he figure out he has to create link *or*
copy (hah, I can just pictire him, tossing 10GB around)? Will he just
give up?

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

~/Public is great for files that do not belong clearly elsewhere. Like
silly.swf. But files like ~/Documents/ProjectX/important.sxw already
have their place, it is, surprisingly enough,
~/Documents/ProjectX/important.sxw. Why do I have to move somewhere else
with my work to share it?

> 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?)

There's one, small flaw in your logic -- namely, how is Tom supposed to
learn about links, and that he needs to use it in this situation?

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

Very, very bad. This has several issues:

1. There is unobvious asymmetry between sharing and un-sharing, for no
good reason
2. If we create links to outside world, we lose security-wise, and
honestly, we don't get much when it comes to good overview of what's
shared, as Nautilus doesn't give enough info to be able to take a look
over linkfarm and see immediately what files are shared. And it
generates instant name-clash opportunities, or requires using clunky
subfolder-per-shared-file or similar hacks
3. If we copy, we lose *majorly* usability-wise, as copies will go out
of sync, and it'll be extremely unintuitive what causes that, not to
mention simply forgetting about syncing them all the time. And don't
forget that Tom *will* attempt to share his 10GB collection, at least
once he will, until he learns it's bad idea :\

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

Pfft. Man, do you really think it's all about Windows users? It's about
choosing model that would not suck.

> 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?

As shown above, it's neither really simpler (ie, it's not simpler for
two biggest use-cases), nor more powerful (being strict subset of
multiple-shares approach). The single-share method is the one that has
obvious flaws, and instead of fixing one, well known deficiency in
current implementations it sidesteps the issue and concentrates on
creating hacks instead of solution.

Cheers,
Maciej

PS.I have read Alex's rationale, I can understand it, and given the
intended use-case, implementation he has chosen is perfectly
justifiable, although I'm of opinion "Send to..." type of functionality
might be even better. BUT, if anyone's still trying to convince me that
dropping files into ~/public_html is *everything* I could ever need wrt
sharing, he's officially getting punch in the guts next time I forget to
sync my shared copy with working one :P