Hi, see in-line...
On Nov 6, 2006, at 11:06 AM, Priscilla Chung wrote:
That's fine. One of the questions I've been pondering is if the
users who would use file sharing might also be a casual
collaborator (CC) target user. So my original thought would be to
have an 'advance features' link in the 'settings' dialog. See
image on update wiki page: http://wiki.osafoundation.org/bin/view/
Journal/WorkflowsZeroDotSix
After speaking with Mimi last Friday, she mentioned that it sounded
like the 'file sharing' user and the CC were two different types of
users and why expose the calendar UI to users who want to just do
file sharing. The proposal she suggested would be to differentiate
the user when logging on. Our original thought would be to add a
check box somewhere on the log in page for admin user, file sharing
user and uncheck both if you're a CC. (Mimi feel free to chime in
if you were thinking differently here…)
Oh I think it was just to have separate links (off to the side) on
the Login page for:
+ Login as admin
+ Login for filesharing UI
This proposal bothered me for various reasons:
+ Why confuse the user with all these checkboxes before log in?
Users do not define themselves as CC as we're doing to meet product
goals for 'Preview'. Additional checkboxes on login will just
confuse users.
+ Would a user who is using file share also want to use the
calendar UI? Though there are different types of usage for Cosmo
this early in the stage, there is no reason why the file sharing
user and the CC are the same person. So then I would ask, why would
you have to force the user to sign in and out (switch identities)
of the web app to go from one area to another?
I think the question is less: Should we prevent file-sharing users
from accessing the Casual Collaborator UI?
It's more: Is it important to design the right UI to allow file-
sharing users to access the CC UI?
So here is an alternate proposal I'd like to suggest:
1. Opposed to having login checkboxes, use separate subdomains for
capabilites. This is the model followed by a number of web apps,
for example calendar.google.com, mail.yahoo.com. A user may login
to any google of google's 'properties' such as gcal or gmail, enter
the subdomian url of another property and preserve their login status.
For an OSAF example, it might be:
remotedisk.osaf.us/cosmo --> file sharing UI (currently part of
automation, but really should be its own application)
osaf.us/cosmo -->the web ui for calendar and collections, as
supported by cosmo.
admin.osaf.us/cosmo --> the current administration interface.
I think this is a better alternative in that it doesn't confuse
Casual Collaborators with links for admin/file-sharing login.
2. In addition to the subdomains, I propose we also keep the
advance link within the settings dialog to allow users to
administer their own collection. This 'advance' link will open the
admin interface in a separate browser window thus providing a
direct connection between the calendar UI and home collection.
My only confusion about this proposal is that I don't really think of
the file-sharing and admin UIs as settings. Settings connotes
preference settings for the CC UI.
i would also like to point out that we shouldn't be overly worried
about time constraints at the moment. you guys should just spec out
what you want to ultimately happen, and the devs will analyze and do
time estimates, and if the whole team decides we need to cut things,
we will. don't pre-emptively cut, please :)
Yup. As I had mentioned to you in passing, there are lots of things
which run though our heads when we're coming up with design
workflow and this is sometimes our way of suggesting priority. That
if we were to cut features, how would the design workflow behave?
Does it still make sense if we don't complete the full feature.
This is why we come up alternate designs and iterate with
development. ;)
-Priscilla
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
