[Design] Accepting Invitations

[Mimi Yin]

Well, you could try thinking of it as: I'm sending an Invitation. I  
know it's an Event. That in and of itself is a valuable piece of meta- 
data to capture, even if you have no other pieces of Event-specific  
meta-data to record.

1. As a sender, I can look through my Outbox and easily pick-out  
Invitations, distinguishing them from just normal Communications.
2. As a recipient, I know immediately the nature of the  
communication, without having to do anything more than notice the  
Calendar Stamp icon.

However, you could imagine that users might want to capture meta-data  
beyond Event-ness.

E.g. I know where the event is going to be located. I know that it's  
recurring. Maybe I know the start time, but I don't know the end time.

I think again, the idea of allowing people to make iterative progress  
on their tasks is the underlying principle here. I have a task to  
schedule  a meeting. I know that it's a meeting. I know that it's  
weekly. I know who should be invited and what the agenda should be. I  
know where the meeting needs to be. But we still need to work out the  
right time. (Even with free-busy, the right time is not always  
evident.) I even know that it should start soon or ASAP!.

I should be allowed to record all this stuff I already know, even if  
I'm missing the Start time. In other words, we shouldn't force the  
user to know the right Start date/time in order to kick-off the  
"invitation" workflow.

My feeling is that a big barrier to people using more formalized  
invitation software is this need to propose a specific time. Some  
people feel it's rude. They prefer to send email and work it out first.

The idea here is to make the invitation workflow feel more like  
email. Let people fill in the blanks over time, as they figure it  
out. But don't force them bury important meta-data in the body of  
emails (e.g. Event-ness, Location, Recurrence) along the way.

Mimi :o)

On Apr 28, 2006, at 3:24 PM, Sheila Mooney wrote:

> Mimi,
>
> So are you suggesting that people will create a "shell" event with  
> no date/time information, stamp this as a communication to send to  
> others, then eventually the date/time details get filled in later  
> as negotiations go back and forth over time? I assume this is what  
> you mean by adding gobbledy-gook to the date/time fields. My  
> interpretation of  tentative events are events that are fixed but I  
> don't know if I am going to attend. I don't think of these as  
> events with no specific date/time. Do we think this is a common use  
> case?
>
> How are people going to discover this workflow in the first place?  
> Isn't it more likely that negotiations would start via email going  
> back and forth before it would ever occur to anyone to create and  
> event?
>
> I see your point about gobbledy-gook in the mail fields...like for  
> a draft but I am not sure people will create these "shell" items  
> and send them to others. Imagine, I get an email from a friend  
> about a new restaurant in his neighborhood, I would likely just  
> reply "hey we should setup a time to go" and iterate on that until  
> I do pick a date/time. I can't imagine replying with an event that  
> has no date/time just because I am suggesting we have dinner.  
> Perhaps I am not thinking about this workflow correctly.
>
> Sheila
>
> On Apr 28, 2006, at 2:28 PM, Mimi Yin wrote:
>
>> The thread on Lozenge shape started wandering in the direction of  
>> Invitation workflow issues, in particular, how we decide when to  
>> "Add an Event Invitation to your Calendar" if we don't support an  
>> explicit "Accept/Tentative/Decline" workflow.
>>
>> I think this brings us back to a discuss we had about Negotiation  
>> and Scheduling in December: http://lists.osafoundation.org/ 
>> pipermail/design/2005-December/003687.html
>>
>> Generally speaking, if an event is really tentative, as in the  
>> Organizer really has no idea of when the right time would be, the  
>> Organizer should be able to initiate the Invitation workflow by  
>> sending an Event Invitation with no specific Date/Time  
>> information. Instead, negotiations about time are worked out in  
>> the Body field.
>>
>> However, the item is still a Communications/Event item, therefore,  
>> it shows up in the Dashboard and the Calendar App area in the In/ 
>> Out collections, but doesn't show up the Calendar.
>>
>> Users should also be able to type gobbledy-gook into the date/time  
>> fields and have them stored and displayed in the Date column and  
>> Detail view as text strings. (e.g. ASAP or Soon! or Whenever).
>>
>> This means that only as an Invitation solidifies over time, after  
>> negotiation and input from all participants, does someone  
>> (probably the Organizer) finally put in specific date/time, at  
>> which point, it appears on everyone's Calendars.
>>
>> We've discussed this ability in the past. This is also related to  
>> the ability to store gobbledy-gook (non-email addresses) in the  
>> Addressing fields as text strings.
>>
>> Is this something we should/could tackle as part of lightweight  
>> Scheduling and Invitations in 0.7?
>>
>> Mimi
>>
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>