Please see my comment inline:
On Nov 2, 2006, at 12:32 PM, Brian Moseley wrote:
On 11/2/06, Priscilla Chung <[EMAIL PROTECTED]> wrote:
Ok, here are the workflows:
http://wiki.osafoundation.org/bin/view/Journal/WorkflowsZeroDotSix
good work. this is a very helpful way of illustrating the workflows,
and i like the ideas.
Great thanks. I will put his in the 0.6 spec.
except...
the home collection browser needs to remain accessible to all users. i
don't care how much we de-emphasize the link to it in the ui or how
ugly the browsing ui looks - the functionality must remain. i don't
have any suggestions about where/how to link to it, but hopefully we
can come up with something that will satisfy everyone.
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…)
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?
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.
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.
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
