Brian and Mimi,
I am in the middle of designing the workflow which will answer these
questions, and of formatting the workflow in a way I believe Brian
will understand. This takes a little time. I expect to have a clear
set of workflows and a clear explanation in two days time. If we can
pause this discussion, I think you will find it worthwhile.
-Priscilla
On Oct 31, 2006, at 4:28 PM, Brian Moseley wrote:
On 10/31/06, Mimi Yin <[EMAIL PROTECTED]> wrote:
1. Disable automatic login if user is clicking on a URL for a
share they are
not already subscribed to in Cosmo.
can you explain what you mean by "automatic login"?
2. Disallow login when user clicks on a URL for a new share. Users
can only
log in by adding the share to their Cosmo account.
is what you're saying here that you don't want the login form to show
up on the calendar page? in essence, getting rid of the "logging in
from the calendar page" section of my writeup?
1 and 2 would get rid of the need for temporary subscriptions in the
pulldown menu.
i can't agree or disagree with this assertion until i understand what
1 and 2 mean ;)
I have a preliminary mockup here:
http://wiki.osafoundation.org/bin/view/Journal/
CosmoMagicURLStoryboardsTake2
hate to sound like a broken record, but i don't understand the
workflow description on this page. you have steps 1 through 10, which
imply the user goes through that entire sequence, but then i see lots
of "and"s and "or"s in the text, which implies there are choices and
subflows. could you perhaps use separate lists for the subflows, and
use "goto" statements or something like that to show where one flow
leads to the next? maybe a flowchart would help.
While this proposal is flexible for the end-user, it's simpler to
understand
and it's arguably not that important to provide a seemless way for
users to
navigate between shares they're previewing (temporary
subscriptions) versus
shares they've already subscribed to.
hm. if you really think that's the case, then i suggest removing any
ability to navigate the app from the preview screen. no calendar
selector at all. was that part of the idea as well?
Another way to think about it is: How often are Cosmo users going
to be
subscribing to new shares in the Preview timeframe? All things
being equal,
probably not that often.
really? do you think casual collaboration will be that casual? i'd
think that if somebody wanted to share a calendar with me, i'd be more
interested in the calendar than just looking at it for a couple
minutes. in fact, the example that you guys have been using for this
use case is one where the hub and the cc iterate several times over an
event. seems to me that the cc would definitely want to subscribe to
the share in that case.
PS As for free-busy, is there a reason why it can't be treated
like any
other calendar subscription? We just simply don't display any
event details?
Instead, we only show blocks of confirmed and tentative time?
That's what
we're doing in Chandler today.
that's what i figured. i don't see any major problems with doing this.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
