0.3 Work flows

• zeroDot3WorkFlowsDS.pdf: For Discussion in the Design Session

High level workflow diagram

Created by MimiYin

• Andi_PTO_Workflows.pdf: Andi_PTO_Workflows.pdf

A couple of things to note:

1. On Slide 1: Getting the URL to Andi: A lot of time may pass between when Andi receives an URL and when he accesses the share to add PTO. as a result, Andi will need to retrieve the URL either by:

• Looking for it in his email
• Asking someone else to forward it to him
• Going to find it on the wiki

2. Slide 2 describes what Andi does once he accesses the share. Again, Andi may need to get information out of his email in order to add his PTO days to the calendar.

Both of these things are reasons why it's so hard to get people to use shared web calendars.

So we need to build as many ramps as we can to the shared collection on Cosmo, so that ecosystem sharing

• Not requiring Andi to have an account in order to view and edit the shared calendar
• Making it really easy for Andi to retrieve the URL to the share by making that URL really simple and easy to pass around
• Making it easy for Andi to send out notifications from Scooby
• Making it easy for Andi to pull down the share via whatever tools he's already using: Email, RSS Reader, iCal.

The alternative workflow is:

1. Andi sends an email to everyone
2. Esther drags it from her email client directly onto the Office calendar

Usage scenarios

Created by PriscillaChung

The proposed usage scenarios which outline how a 0.3 target user would receive and edit a shared calenadar (collection):

• zeroDot3UsageWorkflowsV2.pdf: Proposed: Usage scenarios

• A user that does not use a calendar but want to be able to view and/or edit (depending on the url) information in this share.
• A user that does not use a calendar, but decides to sign up for a new Scooby account.
• A user that wants to view the calendar in iCal or some other CalDAV client.
• A user with a Scooby account, signs in and adds the calendar to their share.

*Note: A UI still needs to be worked out in which a shared collection could be sent to the user with out any calendar data. How will that appear in Scooby?

• Would there be some message at the top of the screen to inform the user about the shared collection that may not include calendar items? Could the message be displayed only if there are no calendar items? Or would the message confuse the user?

*Note the 'remember me box' would ask permission if we could add store a cookie on the user's computer. The cookie would store the URL tickets you've used Scooby to access. Would this make sense if the target user for Scooby may not always be accessing Scooby from their computer.

*Note: Usage scenario A - There seems to already be a business decision in place that do not require a user to "Log in" to Scooby and have read/write access once they have received the ticket/URL. These reason our outlined as follows:

Reasons why not to have a log in?

• To meet the beta goal, this will make people start using the web application sooner.
• To make things as simple as what they are used to today. ie. send an email out about their PTO. vs. clicking on a URL to edit the calendar, then click on another link to launch their email. Note the second work flow is still more steps then the first.

Although this decision seems to already be in place as isproposed in the usage scenarios. I feel it is my responsibilty to also outline reasons why making people sign up for an account to "Log in" is a good thing.

Why have a log in?

• Prevent spam, malicious behavior from anyone who could potentially erase the collection.
• Identify who the user is who made changes to the 'public' calendar to the collection owner
• Help determine if the user does not have a Scooby account on the cosmo server and can spit out a message that says something along the line as, "You do not appear to have a Scooby account with this server. Please click on the subscribe link to add this calendar to your Scooby account"
• Could potentially help determine if there is more then one person access the calendar at the same time--> Check w/ Mde two people could edit a calendar at the same time?
• Though this may be a weaker argument, it is the industry standard to sign up for an account. Even for photo web sites, where the biggest harm is to spam your grandmother's photos, a "Log in" is still required to do anything besides just viewing the photos.
• Having a 'Log in" is not incompatable with tickets. Tickets would still be used to identify your share and the permissions granted to that user by the owner of the share.

Phasing proposal

• Perhaps all other Cosmo servers could register to an OSAF service and this service allows the transmission of the subscription information across Cosmo nodes. For example:
  • Joe runs a small business and he has Cosmo hosted by his ISP.
  • He receives an invite from Esther to view a public calendar, clicks on the link and attempts to log in.
  • This is to OSAF's Como sever, OSAF doesn't recognize his credentials.
  • Cosmo looks up his email in a central registry identifies his "small business" Cosmo server and does the right thing so that he is transfered to his "small business" server with the subscription added.
  • The OSAF Cosmo server notifies the "small business" Cosmo server about the subscription request.

This document is the first draft of the usage scenario.

• zeroDot3UsageWorkflows.pdf: First draft: Usage scenarios

I was looking at solving a number of problems, such as making it easier to share the calendar and still preserving their intent that some people have read only access and some people will have read/write access. That is to say, not everyone would have read/write access to the calendar. This is to balance the need of the calendar owner with a calendar participant. This work flow is probably not realistic in the 0.3 timefram because it requries efforts from both the Scooby and Chandler development teams.

Please note the changes in the draft proposal.

• The sharing work flow in Chandler is different then what exists today.
• The work flows helps guide the Chandler user, walking them through a wizard, preventing the user from making mistakes in copying the wrong ticket/URL to the wrong person and composing a form letter that clearly explains what to do with the link.
• Calendars which are sent with tickets are public in that they accessed by anyone with the right link, but would need a log in to read/write. Anyone can view it, but only selected, and trackable people can edit. This may also prevent spamming. In addition this would help the calendar owner (Chandler user) to moderate the process of making changes.