Re: Proposal: gnome-user-share
- From: Maciej Katafiasz <ml mathrick org>
- To: Kai Willadsen <kaiw itee uq edu au>
- Cc: Havoc Pennington <hp redhat com>, Alexander Larsson <alexl redhat com>, Desktop Devel List <desktop-devel-list gnome org>
- Subject: Re: Proposal: gnome-user-share
- Date: Wed, 01 Dec 2004 12:57:36 +0100
Dnia 01-12-2004, śro o godzinie 14:44 +1000, Kai Willadsen napisał:
> > The
> > user can freely delete ~/Public if they don't want to put anything in
> > it. It's not like ~/Evolution where you had to have that if you wanted
> > to use Evolution.
>
> You could delete ~/Public, but then you just have a serious
> discoverability issue, given that you've hard-coded the directory that
> they have to use, and you don't expose the capability anywhere else in
> the interface.
>
> How does a user know that this directory is used to share files? If they
> decide that they don't want to share files now and delete the directory,
> and then decide at some point in the future that they do, how will they
> work out how to do it under this system? And you can be sure that users
> *will* randomly delete directories that they don't understand and that
> contain no files.
Exactly
> > $HOME should not be used for "implementation detail" files, with the
> > exception of dotfiles. Only user-should-care files. But ~/Public should
> > contain user-should-care files, so it makes sense in a $HOME non-
> > dotfile.
>
> How is the fact that files can only be shared from the ~/Public
> directory *not* an implementation detail? That's like saying that the
> fact that xchat (used to, iirc) download to ~/dcc is fine, because the
> user cares about the contents of ~/dcc.
Very good example, and example of very annoying behaviour too. It took
me good 10 minutes to find where the file landed first time I used DCC
with xchat, and it was so short only because I accidentally stumbled
upon (then empty) ~/dcc few days earlier, which I eventually remembered.
~/Public has exactly the same problems as ~/Templates, where people
learning about that functionality are all "Cool, but how was I supposed
to know about that?", plus its own issue of keeping shared files in sync
with master copies. This is clearly inferior to ease of what Windows and
(AFAIK) Mac do, where you simply mark the folder as "shared" to make it
shared. Let's not take design that has obvious inherent problems, when
what we really need is solution to "it's not clear what's the full set
of folders shared by user" problem. Correct way to solve it is to come
up with good UI for managing shares (and permissions in general), not to
introduce arbitrary and non-obvious limitations in design.
Cheers,
Maciej
--
Maciej Katafiasz <ml mathrick org>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]