Calendar:Status Meetings:2006-04-20:PhoneLog

Calendaring Goals
dmose - mentions news group posts about goals and users.

beltzner - come up with tight set of criteria like firefox charter: this is the
problem we want to solve, this is what we want to address, used in order to 
constrain design discussions from erring down rabbit holes.
1. interoperability – explosion of calendaring online offerings they work with a 
sticky data model can't get data out of the things. Our calendar client should 
not prevent you from talking to other clients in order to allow interoperability 
and innovation
2. Not an alternative to outlook because that pigeon holes us. We should find the
tasks that Outlook performs for people and decide from that how we address those 
tasks. Look at Palm calendar (for personal calendar) look at Notes etc.  With 
Palm, people are accustomed to entering events quickly and then drilling down for
more information.

About users: personae concept – think of users as people who have tasks and 
concerns not related to your software. They use the tool, not because they like 
it, but because it does something for them. Think in context of actual user goal 
and task. 

dmose? -  come up with small set of personae with a little bit of concept of the 
people and not go too much detail

beltzner – figure out the type of software that they are using, types of tasks 
that they are performing, what kind of terminaology are they accustomed to, and 
the features they find lacking

dmose – Our goal might be to interact with anyone else who has calendar data. We 
should drive standards based calendaring to become the way that email is today.

mhovis – There are still issues with interoperability with email – even with 
standards Example: mime handling is different across clients

dmose – Not saying there are no problems, but I'm looking at the open standards 
email case as the best case because it is fairly functional

lilmatt – There's a minimum level of functionality that you can expect to work 
regardless of what ever type of email client that you're using. Over time, the 
assumption of people to be able to deal with certain things has changed as well. 
Attachment difficulties were the norm in PINE, and now attachments are normal. 
Fragmentation of email client is not that big of a deal and we'd be able to shake
 out any inconsistancies over time

dmose – Mime is the success story in that regard. it wold be a fine thing if we 
could do something similiar with calendaring

lilmatt – that's happend without making it tougher for grandma to use email. We 
have to aim to do this without making it too hard to use.

jminta, dmose agree

dmose – For an overal goal: Use the net to make time management and scheduling 
easier for people. does that sound reasonable?

-- silence -- 

dmose – Resounding yes

dmose Because of the data stickiness issue, we might want a high level goal for 
import/export functionality. We want the barrier to entry very very low.

connor – Being able to import from Outlook, Evolution, or Ical to pull that data 
in would be great. Export is cool but i think ultimately if you're able to 
operate with the different server back ends, that reduces the importance of 
import/export on the client side as a means to address data stickiness. I think 
the goal should be more about being able to use different server technologies on 
the backend like exchange or google calendar

dmose - no plans for exchange

? – is corporate market interesting to you? is that what we're targeting 

dmose – i think so, yes, that's been an issue. 

lilmatt – It's not the best use of resources to target entrenched Outlook shops, 
instead we should target small SMB where Ical is not enough and they want 
something simple – corporate time or meeting maker type of spaces. If we target 
companies that use IIS and ASP then that's not the best place for us.

dmose – we can't go against Outlook because they are so entrenched and feature 
rich

lilmatt we're an alternative to ppl who want one, one that's easy to use and 
provide (support) for.

? - Target people who are not so entrenched and tied to exchange back end. 
Perhaps small businesses where they don't have ppl who manage IT; that is 
somewhere we can have some effect

dmose - Given resources, dealing with exchange is really not an issue  we're 
prepared to deal with yet

? - Exchange connector code is out there, but I don't know how much work it would
 be to use it

? - What percentage of ppl with calendaring apps actually use exchange

beltzner – Going after markets that are already locked up doesn't work for us

connor? - Firefox got accepted by being a good product that met needs of users; 
not by focusing on being an IE replacement. And I don't know that we need to be 
an exhcange supporter in order to be accepted.

beltzner - Freedom to get data out of the application lowers barrier to entry.

dmose – True especially because there are so many calendar applications right 
now. 

beltzner – A quick route to success would be to pick one of two markets – end 
user or enterprise

dmose – We've been trying to bridge what contributors are interested in because 
we have people interested in both. We need both sets of contributors feel that 
they are getting something useful out of this that they care about.

beltzner – If you still focus your design and capabilities on the common tasks, 
those don't change based on what type of backend that you support (exchange or 
caldav)

dmose – It would be cool to have discovering local events and things like Evite 
be more standards based. There is a market yet to be discovered there, and can we
 use that to develop the calendar so it works for eveyone in it.

beltzner or lilmatt - Following Ical model of having multiple calendars in a 
single view gets you further down that road.

lilmatt – If you have a local calendar that you don't share then you might show 
it differently than a shared calendar

dmose – Event dialog could change dependent on what type of calendar you have 
selected – might show freebusy or attendees  which wouldn't be there if calendar 
is standalone

jminta – I don't want to clutter the UI. As long as the UI doesn't grow as we 
keep trying to support these extra options, then it's great to have them. Don't 
want end user to be distracted by all these options.

lilmatt – Some of it has extra UI (free busy) It might be possible to hide it 
from people that don't care 

beltzner|connor - As long as you align the UI by tasks – different tasks to 
create the event and invite someone to it. For example Task 1. Is creating event,
 Task 2. is inviting people Task 3. is adding meta data

dmose – But creating it might depend on times people are available. So those are 
not separate tasks. 

.. Implementation discussion, talk of how to put dialog together, referencing old
 event dialog, talking about tabs included since that's a topic on ng right now..
 
beltzner – Tabs sort of harm discoverability, but you have to figure out what is 
common to every task and put that as your common UI. Then you add things to get 
more information like free busy. It is possible to layer design so that single 
user and sharing/publishing can all exist in the UI and the UI isn't 
overburdening. The primary tasks are all the same across them. There is just 
extra stuff for the publish/sharing

dmose – Sounds like the task based analysis is going to get us a long way

beltzner – It's like timezones – some users rely on it, some don't

dmose – right. 

? - It's the sort of thing that the first time the user requests it, we know we 
show it

beltzner – Talking of adding features, how about ability to have start time for 
an event in timezone A and end time in timezone B. 

? - There's a lot of choice in calendaring applications out there, but none of 
them do much innovation. Defining and creating these tasks, then providing 
interesting solutions for them is really going to be where we demonstrate our 
innovation.

beltnzer – Come up with top 5 things each user will do with calendars

dmose – cool

jminta leaves

-- Lighting product definition --

dmose – Lightning defined as a PIM – should it be definined in concert with 
thunderbird (tbird)? How far down that road to we want to go? How does that make 
lightning diverge from sunbird (sbird)?

dmose – We want to keep them closely aligned, but from an end user standpoint, 
they are very different solutions

gary – Lightning can receive meeting requests more easily than sbird

dmose – On the mac, Ical can launch the Mail application to handle its mailing 
and receiving of meeting requests. We could do something like that.

.. discussion of address book integration – it is very easy to solve in 
Lightning's case, and very difficult on Sunbird...

ctalbert – I've seen one application that assumed your addressbook data was 
stored in your primary mail client (which it found through MAPI). That's one 
idea...

mhovis – You've got separate backends for your address book data (LDAP, Exchange 
etc) and so how do you allow these people to collaborate with these different 
backends

beltzner – That's something not solved by any piece of software right now. being 
able to do that would be a major win for the product in general.

dmose – I want to really know what places  is the UI affected in a significant 
way due to the fact that we are in Lightning versus Sunbird? What other issues 
are there like the addressbook issue. What implications does that have for sbird?

beltzner – You have more control over the UI in sbird because you're not 
constrained by the tbird UI.

.. discussion some points ..

Ensure that we can do iTIP and iMIP reardless of mail client that you're dealing 
with.
Can integrate with system level address book (mac) actually work underway for this on tbird
Can we use the system addressbook or assume that the default mail client is where your contacts live
There are also issues where in POP email cases that you may not have mtg requests
 available to the client b/c of loss of state information. (If another email 
client downloaded the meeting message on a separate machine). Solution there is 
to make POP users keep messages on the server.

lilmatt needs to leave, discussion wraps up 

beltzner – Feel free to ask for help with the user stuff

connor – Same goes for me

dmose – This has been useful feedback. We have to determine how we can serve a 
good set of users, and we can do that by focussing on their tasks.