Re: Proposal: gnome-user-share

On Thu, 2004-12-02 at 17:19 -0800, Ken Harris wrote:
> > ~/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?

The fact that it's not just "Foo clicks 'Blah' and chooses 'Share'" and
instead two extra steps, one of which is rather technical (difference
between link and copy is, from the user model, what exactly?) and the
other is equally conceptually fuzzy ("magic" folder that has super-
secret-cranky-office-temp sharing powers).

> 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

Definitely not.  Maybe simplest implementation model and simplest
working model for a UNIX geek, but not necessarily for average users.

Getting into this argument is pretty pointless though.  Someone needs to
get some real data on this.  Us guessing which is easier isn't going to
get us anywhere useful.

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

And how are they going to see it?  Are you going to go door to door to
teach people?

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

So once its already shared, what does this menu item do?  Does it, for
every file, have to check if a link exists (because there are no reverse
lookups for links) ?  If the user moves the file, does the system
automatically delete the link or leave this weird, dead file in ~/Shared
Files ?  Does the menu item just let users re-share (and thus link) the
file over and over, giving no useful indication of its state other than
that it *could* be shared?

Heck, do we even want to allow symlinks out of ~/Shared Files?  Isn't
that a potential security hole?  I don't let users put symlinks in their
web folders on systems with general apache setups, I don't see why this
should be any different.

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

As someone who is most definitely not a Windows users, I can tell you
that sharing files by marking the file itself is not at all easy simply
because it's similar to Windows.

I've seen Windows users permanently store files in that Shared Documents
folder they have (I'm assuming that does what ~/Shared Files is proposed
to do) - doesn't that seem a little wrong and perhaps indicate that the
system you're proposing might have a huge conceptual model flaw as well?
One at least as bad as some of the alternatives?

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