12:49 a.m.
Hello Assaf,
Here are some comments on the first portion of your original message.
I'll respond to the remaining parts of your original message in separate
emails. The following comments refer to changes made in change set 2556.
Assaf Gordon wrote:
1) Steps needed to share histories
----------------------------------
Usage scenario: User A wants to share datasets with User B.
'New way' (still with public datasets, no security):
1. Login as User A.
2. Select History.
3. Click "Options"
4. click "share"
5. Enter email of user B.
6. click "share"
Outcome:
user B doesn't have the history in his histories list.
This is true, but now user B has a link to a history which he can clone
1 or more times as long as sharing link remains.
What User B needs to do:
1. click "options"
2. click the *other* list link (there are two of them, both named 'link', and one
has to actually read the rest of the sentence to know what's the different between
them).
The first 'list' is now "Previously stored histories" and the 2nd
'list'
is now "Histories shared with you by others".
3. Find the needed shared history, no dates or options to sort by.
The list of "histories shared with you by others" is now a "grid"
layout
which displays the following for all shared histories: history name,
number of datasets ( for each state ), date created, last updated date,
shared by ( user email ). You can sort by most of these columns.
4. click on the tiny triangle button, which will show a pop-up menu
with only one button 'clone' (which he's going to click anyway, so why not
make it available as a huge button on the main page?).
There are buttons on the grid layout that allow you to either clone a
selected history or unshare it.
5. click 'clone'.
6. User sees a technical question about cloning deleted items. there's no default
selection, so you can't just click "clone". you have to read and understand
what's going on.
Don't underestimate the annoyance of this:
You advertise galaxy as easy to use for biologists, who don't need to understand the
technical aspects - so why make them read technical details and choose these options?
This technical question has been eliminated, and only the active (
undeleted ) datasets are copied in the cloned history.
7. Only then, the shared+cloned history appears in the history list.
With security model in place (meaning datasets are not public), things get more
confusing.
User A wants to share history with user B.
User A's implied wish: "I want User B to view my files".
When User A clicks "share", enters the email and click "share", he is
then presented with four permission related options.
The last one is "Don't Share".
This is kind of funny. it reminds me of clicking the "start" button to shutdown
the computer in you-know-which operating system.
The scenario of selecting "Don't Share" and clicking "Go" button
- this is a no-op. why is it needed ?
If this wasn't a web-application - then yes, this modal dialog would require a
'cancel' button.
But this is a web-application. just click on another link instead of clicking
"go".
A "go" button implies something will be done.
The "Don't share" option has been eliminated.
The second-to-last is "Share Anyway (don't change any
permission)".
This is a problem waiting to happen - you are explicitly allowing the user to do
something that you know will not work.
>From a technical perspective, that's OK - a knowledgeable user can later on
manually set permissions, or can later on whine to the administrator about permission
problems (or my favorite: User A tells User B to ask the admin to give him permissions).
IMHO, a program should not allow a user to do anything that will definitely not work.
Actually, this option generally will work. The only time that it will
not work is if there are no histories being shared that include datasets
that require no permissions changes. I've added a check to ensure that
at least 1 history includes at least 1 dataset on which permissions do
not need to be changed, and if there is not a history that falls into
this category, this option is not displayed.
The first option is "make datasets public".
This is bad option for two reasons:
Hmm, I disagree with this issue. There are times when a user may have
restricted datasets that he now wants to make public.
1. User A don't want to make his datasets public (otherwise he
would not set permissions on them). All he wants is to allow User B to view his files.
If he only wants user B to view his file, he has that option available
to him.
2. If permissions problem persist, Users will get accustomed to just
'make everything public' because that's the easy solution. and this will make
the whole security thing redundant.
I disagree with this issue as well. If a user is familiar enough with
setting various permissions on datasets, then he will be able to
understand the difference between sharing a dataset with 1 or more other
users ( but keeping it restricted from all of the public ), and making
it public so anyone can see it.
Also remember that PUBLIC means anybody can view them - anybody, not
just people you shared it with. This is not obvious. this means "no security".
The option to make datasets public is fairly obvious in this regard as
the option states "Make datasets public so anyone can access them". \
The second option is "make datasets private to me and the user...".
This seems like what the user actually wants, but it has strange side effects (see item
3, below).
I'll look into the remaining issues in a separate change set / email
response.
Thanks very much for all of you valuable feedback!
Greg Von Kuster
Galaxy Development Team