|
List Info
Thread: First draft of the 0.3 spec
|
|
| First draft of the 0.3 spec |
|
2006-07-17 22:24:47 |
Last week I finally buckled down and sketched out/wrote down
in
detail the features we've talked about for planning Scooby
0.3. Here
is the first draft of the spec for review. We're still
working out
the details (per the discussion on the list) on some of the
features–
though this may be a good place to start in terms of
understanding
where features may fit and why we chose these features for
0.3.
http://svn.osafoundation.org/docs/trunk/docs/sp
ecs/scooby/rel0_3/
zeroDot3.html
Thanks, -Priscilla
BTW. I'm sending this to the scooby-dev list for this time,
but in
future, all specs relating to Scooby planning will be sent
to the
design list tagged with
[Scooby]._______________________________________________
scooby-dev mailing list
scooby-dev lists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| First draft of the 0.3 spec |
|
2006-07-19 18:32:58 |
Priscilla,
Some questions about the flowchart you presented:
Scenario A)
----------------
You can't have Scooby or any webapp pre-populate the body
of an email
message.
"Email Message notifies changes on the office
calendar" - Do you mean
all future changes? Or just the ones made during this round
of editing?
Scenario C)
----------------
You have the workflow continuing like normal after the paste
into
iCal. Are you saying that there will be a similar mail
notification
link in ical? And that Jump-2-Date happens in ical?
On Jul 17, 2006, at 3:24 PM, Priscilla Chung wrote:
> Last week I finally buckled down and sketched out/wrote
down in
> detail the features we've talked about for planning
Scooby 0.3.
> Here is the first draft of the spec for review. We're
still working
> out the details (per the discussion on the list) on
some of the
> features–though this may be a good place to start in
terms of
> understanding where features may fit and why we chose
these
> features for 0.3.
>
> http://svn.osafoundation.org/docs/trunk/docs/sp
ecs/scooby/rel0_3/
> zeroDot3.html
>
> Thanks, -Priscilla
> BTW. I'm sending this to the scooby-dev list for this
time, but in
> future, all specs relating to Scooby planning will be
sent to the
> design list tagged with
>
[Scooby]._______________________________________________
> scooby-dev mailing list
> scooby-devlists.osafoundation.org
> http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| First draft of the 0.3 spec |
|
2006-07-19 19:02:08 |
|
On Jul 19, 2006, at 11:32 AM, Bobby Rullo wrote: Scenario A) ---------------- You can't have Scooby or any webapp pre-populate the body of an email message.
"Email Message notifies changes on the office calendar" - Do you mean all future changes? Or just the ones made during this round of editing?
I know I've seen this done before. But I'd like Matthew to investigat e.
Scenario C) ---------------- You have the workflow continuing like normal after the paste into iCal. Are you saying that there will be a similar mail notification link in ical? And that Jump-2-Date happens in ical?
You are correct. I mislabeled it. Ok, I just realized you wouldn't be sending the notification from iCal because even with a read-write ticket, collection is not editable. So I'll rework the work flow so that the user would:1. Click on the link, Scooby calendar would appear. 2. JTD 3. Enter PTO and description 4. Click on notification link 5. Send out notification 6. Click on the subscribe link 7. Dialog box appears with URL 8. User copies the URL and paste into iCal. (Currently in iCal nothing is editable when you subscribe so the user would have to edit in Scooby/Chandler and update the calendar in iCal)
It's a stretch, but does that make sense? -Priscilla
|
| First draft of the 0.3 spec |
|
2006-07-19 18:32:58 |
Priscilla,
Some questions about the flowchart you presented:
Scenario A)
----------------
You can't have Scooby or any webapp pre-populate the body
of an email
message.
"Email Message notifies changes on the office
calendar" - Do you mean
all future changes? Or just the ones made during this round
of editing?
Scenario C)
----------------
You have the workflow continuing like normal after the paste
into
iCal. Are you saying that there will be a similar mail
notification
link in ical? And that Jump-2-Date happens in ical?
On Jul 17, 2006, at 3:24 PM, Priscilla Chung wrote:
> Last week I finally buckled down and sketched out/wrote
down in
> detail the features we've talked about for planning
Scooby 0.3.
> Here is the first draft of the spec for review. We're
still working
> out the details (per the discussion on the list) on
some of the
> features–though this may be a good place to start in
terms of
> understanding where features may fit and why we chose
these
> features for 0.3.
>
> http://svn.osafoundation.org/docs/trunk/docs/sp
ecs/scooby/rel0_3/
> zeroDot3.html
>
> Thanks, -Priscilla
> BTW. I'm sending this to the scooby-dev list for this
time, but in
> future, all specs relating to Scooby planning will be
sent to the
> design list tagged with
>
[Scooby]._______________________________________________
> scooby-dev mailing list
> scooby-devlists.osafoundation.org
> http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| First draft of the 0.3 spec |
|
2006-07-19 19:02:08 |
|
On Jul 19, 2006, at 11:32 AM, Bobby Rullo wrote: Scenario A) ---------------- You can't have Scooby or any webapp pre-populate the body of an email message.
"Email Message notifies changes on the office calendar" - Do you mean all future changes? Or just the ones made during this round of editing?
I know I've seen this done before. But I'd like Matthew to investigat e.
Scenario C) ---------------- You have the workflow continuing like normal after the paste into iCal. Are you saying that there will be a similar mail notification link in ical? And that Jump-2-Date happens in ical?
You are correct. I mislabeled it. Ok, I just realized you wouldn't be sending the notification from iCal because even with a read-write ticket, collection is not editable. So I'll rework the work flow so that the user would:1. Click on the link, Scooby calendar would appear. 2. JTD 3. Enter PTO and description 4. Click on notification link 5. Send out notification 6. Click on the subscribe link 7. Dialog box appears with URL 8. User copies the URL and paste into iCal. (Currently in iCal nothing is editable when you subscribe so the user would have to edit in Scooby/Chandler and update the calendar in iCal)
It's a stretch, but does that make sense? -Priscilla
|
| First draft of the 0.3 spec |
|
2006-07-19 21:18:35 |
On 19 Jul, 2006, at 12:02, Priscilla Chung wrote:
>> Scenario A)
>> ----------------
>> You can't have Scooby or any webapp pre-populate
the body of an
>> email message.
>>
>> "Email Message notifies changes on the office
calendar" - Do you
>> mean all future changes? Or just the ones made
during this round
>> of editing?
>
> I know I've seen this done before. But I'd like
Matthew to
> investigate.
I'm not sure if this is what you're thinking of, but try
enter the
following URL in your browser:
mailto:design%40osafoundation.org?subject=How%20about...&
;body=this%3F
--Grant
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| First draft of the 0.3 spec |
|
2006-07-19 21:18:35 |
On 19 Jul, 2006, at 12:02, Priscilla Chung wrote:
>> Scenario A)
>> ----------------
>> You can't have Scooby or any webapp pre-populate
the body of an
>> email message.
>>
>> "Email Message notifies changes on the office
calendar" - Do you
>> mean all future changes? Or just the ones made
during this round
>> of editing?
>
> I know I've seen this done before. But I'd like
Matthew to
> investigate.
I'm not sure if this is what you're thinking of, but try
enter the
following URL in your browser:
mailto:design%40osafoundation.org?subject=How%20about...&
;body=this%3F
--Grant
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| First draft of the 0.3 spec |
|
2006-07-24 20:43:29 |
On Jul 19, 2006, at 11:32 AM, Bobby Rullo wrote:
> Priscilla,
>
> Some questions about the flowchart you presented:
>
> Scenario A)
> ----------------
> You can't have Scooby or any webapp pre-populate the
body of an
> email message.
Yes, you can, actually. Check www.sharemation.com, where
you can get
an account, create a file, click "info", click
the "email" button,
and this will construct an email prepopulated with the text
for example:
"Use the following links to access the corresponding
files:
/~milele/public/images/americangothic.png:
http://www.sharemation.com/xythoswfs/webu
i/_xy-3404414_files-t_6PB4BWql"
This feature is brought to you by little-known features of
the
"mailto:" URI.
Lisa
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| First draft of the 0.3 spec |
|
2006-07-24 20:43:29 |
On Jul 19, 2006, at 11:32 AM, Bobby Rullo wrote:
> Priscilla,
>
> Some questions about the flowchart you presented:
>
> Scenario A)
> ----------------
> You can't have Scooby or any webapp pre-populate the
body of an
> email message.
Yes, you can, actually. Check www.sharemation.com, where
you can get
an account, create a file, click "info", click
the "email" button,
and this will construct an email prepopulated with the text
for example:
"Use the following links to access the corresponding
files:
/~milele/public/images/americangothic.png:
http://www.sharemation.com/xythoswfs/webu
i/_xy-3404414_files-t_6PB4BWql"
This feature is brought to you by little-known features of
the
"mailto:" URI.
Lisa
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| First draft of the 0.3 spec |
|
2006-07-31 19:45:37 |
|
| Priss,
This looks really good. The flowcharts are really helpful for visualizing all the various workflows. A few comments about the overview section.
-> Target user + I think it's important to note that all the work detailed in this spec really covers 2 types of users, not just the Casual Collaborator that we describe specifically as the OSAF employee adding PTO to the calendar. Some of these features really fall into the needs of a Chandler desktop checking their personal calendars on the web + The high-level feature list could then map back to each type.... + #1 - Casual Collaborator + Anonymous Access + Navigation + Notification + #2 - Support remote access for Chandler desktop user + Account viewing + Calendar canvas + Managing time-zones + Managing events
+ Pulling this out into a section that just talks about users would perhaps make this a bit more obvious and address some of Mimi's feedback about the features that don't fall into the target usage scenario.
-> Assumptions + I believe what we are trying to convey is that the features for supporting user #1 will be a higher priority for 0.3 than the feature work for supporting user #2. This is kind of spelled out by the fact that we have this very specific usage scenario for a Casual Collaborator. + This does not mean that we do not do any of the work that supports user #2. Depending on how all the work resources out, we could make significant progress on some of these items. + Prioritizing the stuff for our target use case has implications on what gets worked on first, what gets punted to 0.4 and how we triage bugs at the end of the release. + I would suggest perhaps an assumptions section after the target user section that talks about this specifically. + The assumptions would also include listing out stuff like... + The anonymous access issue. As an interim 0.3 solution we are going to not require an account to edit the calendar + Getting this working depends on Chandler desktop publishing a different kind of URL than we do currently. + I know you have some of this in the spec all ready but reiterating it into an assumptions section just re-enforces this stuff better.
-> 0.3 Usage Scenario - adding PTO to the office calendar + Think it would be good to detail out the usage scenario separately since it's kind of separate from proposing anonymous access as a solution.
+ What we do today.... + Send an email to everyone at OSAF and cc Esther and Bianca with PTO dates + Esther adds to the iCal office calendar
+ What we will have to do in the future... + Get rid of iCal version and use Chandler only + People will have to access or subscribe to read-write version of office calendar + Esther will no longer be responsible for updating the calendar + People will have to add their PTO to the calendar individually as well as notify Bianca.
-> Anonymous Access + Like you have currently, I would than talk about why we are proposing anonymous access for 0.3 with a few elaborations... + Giving users an interface via Scooby and not requiring people to run the desktop app. + Making it as simple as possible - few steps. + Small group interaction - assumptions about high level of trust. + We can't force all users to login so if we can't have both in 0.3 and have to choose between that and anonymous access we will go with anonymous access until a tiered solution can be implemented. + I think we can also go ahead and say that this is a 0.3 interim solution and we are working on something better for Beta and 1.0 which should help address many of the concerns.
Cheers, Sheila On Jul 17, 2006, at 3:24 PM, Priscilla Chung wrote:
Last week I finally buckled down and sketched out/wrote down in detail the features we've talked about for planning Scooby 0.3. Here is the first draft of the spec for review. We're still working out the details (per the discussion on the list) on some of the features–though this may be a good place to start in terms of understanding where features may fit and why we chose these features for 0.3.
Thanks, -Priscilla BTW. I'm sending this to the scooby-dev list for this time, but in future, all specs relating to Scooby planning will be sent to the design list tagged with [Scooby]._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
|
|
|