Lightning 1.0 Roadmap
Stephan Schaefer
As a follow-up to yesterday's status meeting
http://wiki.mozilla.org/Calendar:Status_Meetings:2006-03-30 I would like
to start a discussion in order to reach a consensus on a road map
towards Lightning 1.0.
A hierarchical approach seems to make sense here, which means we would
find high level goals that describe the individual milestones (and
eventually the final release) by a single phrase. These goals will be
defined by a certain feature set for every milestone. The features
itself will be specified on wiki pages as suggested in Joey's recent
posting. The specifications do not have to be final before an
implementation can start but provide a starting point and have to be
updated to reflect the implementation.
As it can be difficult to drive this process top-down it will be easier
to brain storm feature areas first and decide when (and may be how) they
will be implemented to find the milestone goals. And this is exactly
what this thread is about.
So I would like to start the discussion by proposing feature areas and
priorities that we found to be useful after evaluating requirements
collected from customers, power users (e.g. admins) and end users.
To illustrate the feature areas I put short descriptions to each of
them. In some cases the functionality is already there but we should
nevertheless make sure that it really is and write it down for
testing/documentation/tracking reasons.
Feel free to add other feature areas, refine existing ones or come up
with high-level goals that might be reachable in steps of ~3 months. The
final(?) road map should be the obvious result then ;)
Regards,
Stephan
1. Timeline
Taking into account that Lightning 1.0 should be fully compatible to
Thunderbird 2.0, which is planned to be released by end of this year,
and adding some buffer I would propose Spring 2007 as a release date for
Lightning 1.0. A beta version should be available together with
Thunderbird 2.0.
2. Priority 1 Features - Lightning 1.0 cannot ship without these
a) Calendar Views
- modern look and feel
- navigation via keyboard, scrolling
- customizable
- multiple calendars at once, display of conflicts
- display of multiple time zones
b) Appointments/Meetings
- fully support basic attributes and recurrence rules
- invitations via address book
- reminders via email and or message box
- external alarm daemon independent of lightning (may be 1.x)
- iTIP/iMIP support
- use and provide free/busy information
c) Tasks/Todos
- due dates, recurrence rules
- may be assigned to another person (access rights)
d) Printing
- day/week/month view
- single view per page
e) Offline support
- access cached (remote) calendar data when being offline
- sync upon reconnect
3. Priority 2 Features - Required for 1.0 but only after Prio1 is done
a) Search
- simple fulltext search, selects first hit
- advanced (boolean) search with result window
b) Configuration/Administration
- support access rights for remote calendars
- allow for delegation of access rights
- backup/restore of all calendar data and configuration when migrating
to another machine/platform or for security reasons
4. Required functionality - Similar to Prio1 but more technology/concept
based
a) Accessibility
- especially the views should support keyboard navigation
- high contrast desktop themes should be supported/picked up properly
(i.e. no constant colors in the UI)
- toolbar icons must be available in high contrast versions
b) undo/redo support
- minimum: the last delete/change operation must be revertible
- advanced: full undo/redo stack
c) Performance
- no obvious delay in drawing/resize operations (TBD)
- Thunderbird startup must not be delayed by more than x seconds due to
Lightning (TBD, eg, 3 seconds)
- dialogs must appear within reasonable time (TBD, eg, ~500ms)
d) Help system
- tooltips
- online help
- offline help
Simon Paquet
Hi Stephan,
thanks for starting this.
> So I would like to start the discussion by proposing feature
> areas and priorities that we found to be useful after evaluating
> requirements collected from customers, power users (e.g. admins)
> and end users.
>
> To illustrate the feature areas I put short descriptions to each of
> them. In some cases the functionality is already there but we should
> nevertheless make sure that it really is and write it down for
> testing/documentation/tracking reasons.
>
> Feel free to add other feature areas, refine existing ones or come
> up with high-level goals that might be reachable in steps of ~3
> months. The final(?) road map should be the obvious result then ;)
>
> 1. Timeline
> Taking into account that Lightning 1.0 should be fully compatible
> to Thunderbird 2.0, which is planned to be released by end of this
> year, and adding some buffer I would propose Spring 2007 as a
> release date for Lightning 1.0. A beta version should be available
> together with Thunderbird 2.0.
Given our release history, I'm not fully convinced that we can pull
this off till TB 2.0. IMO instead of disappointing user expectations
one more time, we should realistically plan for our 1.0 release, when
TB 3.0 comes out. For the TB 2.0 release I see us only at 0.6 or 0.7
at the maximum.
> 2. Priority 1 Features - Lightning 1.0 cannot ship without these
> a) Calendar Views
> - modern look and feel
> - navigation via keyboard, scrolling
> - customizable
What do you mean with customizable? Creating your personal views,
e.g. a 3-month view or do you mean adjusting the colors, the borders,
the padding of the views, or something else?
--
Simon Paquet
Sunbird/Lightning/Calendar website maintainer
http://www.mozilla.org/projects/calendar
Michiel van Leeuwen
> Given our release history, I'm not fully convinced that we can pull
> this off till TB 2.0. IMO instead of disappointing user expectations
> one more time, we should realistically plan for our 1.0 release, when
> TB 3.0 comes out. For the TB 2.0 release I see us only at 0.6 or 0.7
> at the maximum.
That fully depends on how you define 1.0. To me, 1.0 more means: all
features and all UI just works, and are well-tested. The name 1.0 is all
about stability and reliability. It doesn't have to mean that a
pre-defined set of features are included. So I think we can release
something called 1.0 whenever we want, as long as we start to focus on
it in time.
But this doesn't mean that having a set of features wan't be needed. It
is very much needed, to keep the right focus. Otherwise, you get all
sort of half-implemented features.
Also, even if we can release 1.0 at a certain time doesn't mean we
should want it. We can decide that we really want a certain feature.
Michiel
Joey Minta
> ...snip...
The following additional items come to mind:
P1:
-Full compliance with the iCalendar spec
-Full compliance with the CalDAV spec (note that this is a moving
target for now)
P2:
-Integration with internet calendaring websites
Required Functionality:
-Simple, intuitive user interface
In most of the proposals you made, Stephan, I think the devil is in the
details. I'd like clarifications on what you meant by the following items:
>
> 2. Priority 1 Features - Lightning 1.0 cannot ship without these
> a) Calendar Views
> - customizable
> - display of conflicts
> - display of multiple time zones
I'd also like to say that I don't believe
> b) Appointments/Meetings
> - external alarm daemon independent of lightning (may be 1.x)
should be a P1. Since this will be used in Thunderbird, which doesn't
have an external daemon for checking email, I think in the vast majority
of cases Thunderbird will remain open on the user's computer and the
external daemon will not be needed.
I'd like to see 'Search' become a P1. Searching is what defines the
internet today, and people increasingly seem to want to create
information overloads for themselves, where they never delete anything.
Finding that needle of an event in the haystack of your last 3 years
of calendaring is difficult, and, I think, a pretty common use case.
Finally, some comments on the timeline issue:
I'm not sure I agree with the methodology here. I definitely
disagree with mvl's comment that "So I think we can release something
called 1.0 whenever we want, as long as we start to focus on it in time."
Being a 1.0 feature is not a subjective characteristic, no matter how
much it may seem to be because of this debate. If something is a key
feature, then 1.0 should not be released without it, regardless of where
we are in a timeline. I'd much rather see this roadmap firmly grounded
in a feature set, rather than tentatively grounded in a feature set that
may be changed based on various factors.
I also agree with sipaq that the currently proposed timeline is likely
too ambitious.
I still need to think about this more though, so I reserve my right to
amend, modify, correct, expand, etc.
-Joey
Michiel van Leeuwen
> I'm not sure I agree with the methodology here. I definitely
> disagree with mvl's comment that "So I think we can release something
> called 1.0 whenever we want, as long as we start to focus on it in time."
You are taking my comment out of the context. I replied to sipaq's post,
saying that we would be at 0.6/0.7 at the time of tb2.0. His comment
seemed to be based on the current speed of releases and the idea that we
need of of 0.[3-9] before we can release a 1.0. My reply was that we can
do a 1.0 by that time, if we want. It just depends on what we want for 1.0.
If decide on a certain featureset, it might be to big to reach in the
timeframe. But to say that, you need to define the featureset. We
haven't done that yet, so we can't speak about timeframes yet, if 1.0 is
to be feature-based.
If 1.0 is time-based, we need to define the timeframe, and decide a
featureset which we think we can meet in that timeframe.
But we haven't decided yet, so saying that at the time of tb2.0, we will
be at a 0.6 release is just to premature.
That's what my statement was about.
Michiel
Stephan Schaefer
>> Taking into account that Lightning 1.0 should be fully compatible to
>> Thunderbird 2.0, which is planned to be released by end of this year,
>> and adding some buffer I would propose Spring 2007 as a release date
>> for Lightning 1.0. A beta version should be available together with
>> Thunderbird 2.0.
>
> Given our release history, I'm not fully convinced that we can pull
> this off till TB 2.0. IMO instead of disappointing user expectations
> one more time, we should realistically plan for our 1.0 release, when
> TB 3.0 comes out. For the TB 2.0 release I see us only at 0.6 or 0.7
> at the maximum.
>
My hope is that we resolve the Thunderbird dependencies for Lightning
1.0 as early as possible. By submitting the required code changes for a
smooth integration quite early, we would gain more flexibility in our
own release planning. In other words, I don't see a reason to wait for
Thunderbird 3.0. Instead, we should try to find a reasonable date after
Thunderbird 2.0 which, hopefully, should already include anything we need.
The proposed time line is about one year from now. I'm pretty sure that
once we defined the feature details we can distribute the feature areas
among the active contributors and should make good progress. Anyway, to
be sure that the time line is reasonable we have to define the feature
details, provide estimates, accumulate them, and see what the outcome is.
>> 2. Priority 1 Features - Lightning 1.0 cannot ship without these
>> a) Calendar Views
>> - modern look and feel
>> - navigation via keyboard, scrolling
>> - customizable
>
> What do you mean with customizable? Creating your personal views,
> e.g. a 3-month view or do you mean adjusting the colors, the borders,
> the padding of the views, or something else?
Customizable in a first approach could mean user defined working hours
and hour increments in the day/week view, and start/end day of the week.
(eg 5 day week vs. 7 day, start on sunday vs. monday).
Advanced customization could allow for changing the visual appearance
exactly as you proposed, i.e. fonts, colors, etc. and may be even saving
them as different profiles.
Stephan
Stephan Schaefer
> Stephan Schaefer wrote:
>> ...snip...
> The following additional items come to mind:
> P1:
> -Full compliance with the iCalendar spec
May be we should add this to the list of technology requirements as it
is not a feature in the sense of a workflow. Anyway, it makes sense to
have it on the list.
> -Full compliance with the CalDAV spec (note that this is a moving
> target for now)
This is why I would not give it a P1 priority. It is an evolving
standard and we should not count on it being final in our time frame.
Additional dependencies will most probably hinder us from reaching our
goal. In fact I would not start putting resources on it right now. Once
it is final, or at least stable, it should not be too problematic to
release a CalDav extension independently of an official Lightning
release. So I would see as P3 for now which means it is optional.
> P2:
> -Integration with internet calendaring websites
> Required Functionality:
> -Simple, intuitive user interface
>
Things like icalshare, right ? Would be interesting to know if they
provide some webservices in order to present the hosted calendars within
the lightning UI.
But I'm not sure if I would see this as a Lightning 1.0 requirement.
Advanced UI features like this should probably be postponed and would
make up good candidates for 1.x or 2.0.
> In most of the proposals you made, Stephan, I think the devil is in the
> details.
I agree ;)
>>
>> 2. Priority 1 Features - Lightning 1.0 cannot ship without these
>> a) Calendar Views
>> - customizable
>> - display of conflicts
>> - display of multiple time zones
Customizable: please see my earlier reply in this thread
Display of conflicts: if you display multiple calendars at once,
appointments that conflict should be easily recognizable. It would for
instance be very bad if you could see only one of the colliding events.
Multiple time zones: an additional time zone could be displayed for
reference by using a second vertical time bar in parallel to the
existing one.
This would simplify setting up meetings across time zones - a problem we
all just experienced with our IRC meeting :)
>
> I'd also like to say that I don't believe
> > b) Appointments/Meetings
> > - external alarm daemon independent of lightning (may be 1.x)
>
> should be a P1. Since this will be used in Thunderbird, which doesn't
> have an external daemon for checking email, I think in the vast majority
> of cases Thunderbird will remain open on the user's computer and the
> external daemon will not be needed.
Yes, you're right. Alarm functionality is of course a must have but the
daemon is not. May be we change the 1.x into 2.0 or something.
>
> I'd like to see 'Search' become a P1. Searching is what defines the
> internet today, and people increasingly seem to want to create
> information overloads for themselves, where they never delete anything.
> Finding that needle of an event in the haystack of your last 3 years of
> calendaring is difficult, and, I think, a pretty common use case.
>
I also think that search is important. So I proposed two versions of it,
simple and advanced. The simple version should definitely make it into
Lightning 1.0.
> Finally, some comments on the timeline issue:
> I'm not sure I agree with the methodology here. I definitely
> disagree with mvl's comment that "So I think we can release something
> called 1.0 whenever we want, as long as we start to focus on it in time."
>
> Being a 1.0 feature is not a subjective characteristic, no matter how
> much it may seem to be because of this debate. If something is a key
> feature, then 1.0 should not be released without it, regardless of where
> we are in a timeline. I'd much rather see this roadmap firmly grounded
> in a feature set, rather than tentatively grounded in a feature set that
> may be changed based on various factors.
>
The intention of my proposal is to find a road map for 1.0. This should
be clearly defined and missing features will block the release. But we
might reach the point where we want to (have to ?) release something
stable and useful. If we define priorities (not only 1-3 but 1-n) we can
start moving the line that defines what features will make it into the
next major release. This would allow us to release a 1.0 with a smaller
but still useful feature set than initially planned. Keep in mind that
during the development new requirements may arise and that estimations
might just be wrong. But this cannot postpone the release by another
year or something. So, we should focus on defining a reasonable feature
set that can be implemented in an acceptable time frame. All with the
best knowledge we currently have. But we have to be prepared that we
will not reach all of our goals.
> I also agree with sipaq that the currently proposed timeline is likely
> too ambitious.
>
That has to be found out by clearly defining the feature areas.
> I still need to think about this more though, so I reserve my right to
> amend, modify, correct, expand, etc.
>
Please do so!
Stephan
Joey Minta
> Joey Minta wrote:
>> Stephan Schaefer wrote:
>> -Full compliance with the CalDAV spec (note that this is a moving
>> target for now)
>
> This is why I would not give it a P1 priority. It is an evolving
> standard and we should not count on it being final in our time frame.
> Additional dependencies will most probably hinder us from reaching our
> goal. In fact I would not start putting resources on it right now. Once
> it is final, or at least stable, it should not be too problematic to
> release a CalDav extension independently of an official Lightning
> release. So I would see as P3 for now which means it is optional.
is the right way to tackle CalDAV. Given especially that CalDAV could
help with some of the other requirements you listed (access control), I
think we need to take a pro-active approach with it in order to ensure
that it satisfies our needs and the needs of our users.
>
>> P2:
>> -Integration with internet calendaring websites
>> Required Functionality:
>> -Simple, intuitive user interface
>>
>
> Things like icalshare, right ? Would be interesting to know if they
> provide some webservices in order to present the hosted calendars within
> the lightning UI.
and the ics provider has authorization prompts written in to even handle
the password protected case. A few sites also provide a more expansive
API to interact with the entire database of calendars.
> But I'm not sure if I would see this as a Lightning 1.0 requirement.
> Advanced UI features like this should probably be postponed and would
> make up good candidates for 1.x or 2.0.
I'm told that the reason I should accept Attendees etc for personal
users is that they're likely to share their calendars as well. Personal
users, however, do not have a multimillion-dollar company to provide
them with a server to publish their calendar on. Instead, their
publishing/sharing *will* come from these services. If we really do
believe that they're going to share their calendars in this way, we
shouldn't leave them out of this functionality. I also don't think it
qualifies as 'Advanced UI'. A simple 'search for calendars' box (like
the google box) and a publishing wizard (a good idea anyway) would
probably be sufficient.
>
>> In most of the proposals you made, Stephan, I think the devil is in
>> the details.
>
> I agree ;)
>
>>>
>>> 2. Priority 1 Features - Lightning 1.0 cannot ship without these
>>> a) Calendar Views
>>> - customizable
>>> - display of conflicts
>>> - display of multiple time zones
>
> Customizable: please see my earlier reply in this thread
> Display of conflicts: if you display multiple calendars at once,
> appointments that conflict should be easily recognizable. It would for
> instance be very bad if you could see only one of the colliding events.
So, essentially, this is already done with the way the event-map
displays conflicting events side-by-side?
> Multiple time zones: an additional time zone could be displayed for
> reference by using a second vertical time bar in parallel to the
> existing one.
> This would simplify setting up meetings across time zones - a problem we
> all just experienced with our IRC meeting :)
Ouch. This seems like it should definitely be an extension, or at the
very least, a Pn for n >= 3. The IRC meeting was the only time I ever
had a need for this, and I'm the only one I know who ever even had that
minimal amount of need. This definitely seems like distracting UI in my
book.
> ...But we
> might reach the point where we want to (have to ?) release something
> stable and useful. ... This would allow us to release a 1.0 with a smaller
> but still useful feature set than initially planned.
This is the step that I have a problem with. Either a feature is
important enough to be 1.0, or it isn't. It isn't "Important enough to
be 1.0 unless people start complaining that we aren't releasing 1.0
yet". I'd much rather see us release 0.15 than release 1.0 without
features that this discussion (and future discussions) labeled as
important in a 1.0 release.
-Joey
Joey Minta
>>> 2. Priority 1 Features - Lightning 1.0 cannot ship without these
>>> a) Calendar Views
>>> - modern look and feel
>>> - navigation via keyboard, scrolling
>>> - customizable
>>
>> What do you mean with customizable? Creating your personal views,
>> e.g. a 3-month view or do you mean adjusting the colors, the borders,
>> the padding of the views, or something else?
>
> Customizable in a first approach could mean user defined working hours
> and hour increments in the day/week view, and start/end day of the week.
> (eg 5 day week vs. 7 day, start on sunday vs. monday).
>
> Advanced customization could allow for changing the visual appearance
> exactly as you proposed, i.e. fonts, colors, etc. and may be even saving
> them as different profiles.
MozSuite type situation where everything becomes a pref. Just because
it's possible to allow a customization of a feature doesn't mean that it
needs to be exposed. Sane defaults can go a really long way.
-Joey
Dan Mosedale
> Stephan Schaefer wrote:
>> Joey Minta wrote:
>>> Stephan Schaefer wrote:
>>> -Full compliance with the CalDAV spec (note that this is a moving
>>> target for now)
>>
>> This is why I would not give it a P1 priority. It is an evolving
>> standard and we should not count on it being final in our time frame.
>> Additional dependencies will most probably hinder us from reaching our
>> goal. In fact I would not start putting resources on it right now.
>> Once it is final, or at least stable, it should not be too problematic
>> to release a CalDav extension independently of an official Lightning
>> release. So I would see as P3 for now which means it is optional.'
>
> It's already quite stable, and I don't think the 'wait and see' approach
> is the right way to tackle CalDAV. Given especially that CalDAV could
> help with some of the other requirements you listed (access control), I
> think we need to take a pro-active approach with it in order to ensure
> that it satisfies our needs and the needs of our users.
One of the reasons that CAP died on the vine was that people waited to
implement it until it was done, and then discovered that various
architectural decisions had been problematic, and by then it was too
late. CalDAV has been going out of its way to avoid that, and we need
to help as much as we can so that it doesn't suffer the same fate.
As it turns out, CalDAV is either close to or already in last-call
status, so it is in fact pretty stable, and the upcoming weeks would be
a great (and the last for quite a while, I suspect) time to get any
final comments in and hope to have them heeded.
> I'm told that the reason I should accept Attendees etc for personal
> users is that they're likely to share their calendars as well. Personal
> users, however, do not have a multimillion-dollar company to provide
> them with a server to publish their calendar on. Instead, their
> publishing/sharing *will* come from these services. If we really do
> believe that they're going to share their calendars in this way, we
> shouldn't leave them out of this functionality. I also don't think it
> qualifies as 'Advanced UI'. A simple 'search for calendars' box (like
> the google box) and a publishing wizard (a good idea anyway) would
> probably be sufficient.
This sounds reasonable to me. In reality, I think "good internet
integration" is likely to be an ongoing quest with various features.
Perhaps just having a reasonable "end-user calendar sharing experience",
and "find existing internet calendars" would be sufficient but not
over-broad goals for 1.0. That said, it might also be reasonable to
simply declare one or both of these things as goals, but for post 1.0.
>> Multiple time zones: an additional time zone could be displayed for
>> reference by using a second vertical time bar in parallel to the
>> existing one.
>> This would simplify setting up meetings across time zones - a problem
>> we all just experienced with our IRC meeting :)
> Ouch. This seems like it should definitely be an extension, or at the
> very least, a Pn for n >= 3. The IRC meeting was the only time I ever
> had a need for this, and I'm the only one I know who ever even had that
> minimal amount of need. This definitely seems like distracting UI in my
> book.
I'm not sure I agree with this. This is part of the target-user
discussion, I think. My inclination is to think that we want to come up
with a set of fictional target users as suggested by Spolsky so that
we'll have a framework that will help us think about these things.
Target users I can imagine for Lightning include: grandma on her desktop
at home, student with laptop, organizational executive with a laptop who
has an admin to do scheduling for her and travels a lot, corporate
exec's admin, 30-something employee of a small organization. Maybe
that's not exactly the right split, but it's an example of what I'm
referring to.
The way this would help us is that we can then start to think about
which users would find a such a thing useful. I can imagine anyone who
travels regularly, or who is part of an organization that needs to
collaborate or interact with folks in other areas wanting such a feature.
I kind of suspect that this may be something that should, in fact, be
pref controlled, whether it's as an individual pref, or part of
"collaboration mode" or somesuch.
>> ...But we
>> might reach the point where we want to (have to ?) release something
>> stable and useful. ... This would allow us to release a 1.0 with a
>> smaller but still useful feature set than initially planned.
>
> This is the step that I have a problem with. Either a feature is
> important enough to be 1.0, or it isn't. It isn't "Important enough to
> be 1.0 unless people start complaining that we aren't releasing 1.0
> yet". I'd much rather see us release 0.15 than release 1.0 without
> features that this discussion (and future discussions) labeled as
> important in a 1.0 release.
I wonder if there are, perhaps, two overlapping goals here. In
particular, one is "release something good enough for some set of users
with Thunderbird 2.0", and the other is "release 1.0 with the feature
set we think is important." I (personally) think it would be a great
success condition if these two goals could be met with the same release.
That said, if there's no practical way to do that, it's not the end of
the world.
Dan
Dan Mosedale
> Joey Minta wrote:
>> Stephan Schaefer wrote:
>>> ...snip...
>> The following additional items come to mind:
>> P1:
>> -Full compliance with the iCalendar spec
Were you thinking of just "can roundtrip arbitrary ICS file data without
dataloss", or did you have something more than that in mind? For
example, it wouldn't bother me if 1.0 could roundtrip VJOURNAL
components, but not actually display or manipulate them in any way.
> May be we should add this to the list of technology requirements as it
> is not a feature in the sense of a workflow. Anyway, it makes sense to
> have it on the list.
Sure.
> I also think that search is important. So I proposed two versions of it,
> simple and advanced. The simple version should definitely make it into
> Lightning 1.0.
This sounds like a good strategy to me.
Dan
Dan Mosedale
> Being a 1.0 feature is not a subjective characteristic, no matter how
> much it may seem to be because of this debate.
It's not a random characteristic, but we do need to have some
flexibility there. As an example, one of the original goals for
Lightning 0.1 was "no dataloss". Eventually, it became clear that this
was incompatible with the even more important goal of "release something
that some set of users can use sooner rather than later", so the goal
was gradually shrunk to be "no dataloss on lightning-only data in normal
day-to-day use, not including CalDAV".
> If something is a key
> feature, then 1.0 should not be released without it, regardless of where
> we are in a timeline. I'd much rather see this roadmap firmly grounded
> in a feature set, rather than tentatively grounded in a feature set that
> may be changed based on various factors.
There are certainly some key features that we can't possibly ship 1.0
without. There other features which could, if push came to shove, be
shrunk or even cut. Giving priorities to things which are very
desirable but not actually required seems likely to be helpful, if for
no other reason than that they will allow us to sort our work by working
on the more critical features sooner. This way, if many things take
longer than we initially hope, we avoid the quandry where a bunch of
less important work is done but the important work isn't.
Dan
Joey Minta
> Stephan Schaefer wrote:
>> Joey Minta wrote:
>>> Stephan Schaefer wrote:
>>>> ...snip...
>>> The following additional items come to mind:
>>> P1:
>>> -Full compliance with the iCalendar spec
>
> Were you thinking of just "can roundtrip arbitrary ICS file data without
> dataloss", or did you have something more than that in mind? For
> example, it wouldn't bother me if 1.0 could roundtrip VJOURNAL
> components, but not actually display or manipulate them in any way.
a) Can roundtrip arbitrary ICS file data
b) Gracefully handles ics data too complex to be generated by
Lightning (eg. multiple RRULEs, foreign timezones)
c) Exports/provides all data in an ICS format upon request.
As just a gloss on (c), this could be re-phrased as 'interoperability
with majority of other calendaring clients'. We've received a bit of
flack about the sqlite storage mechanism particularly because, in its
most rudimentary form, this data is not inter-operable. We need to
emphasize that although Lightning is a great client, nothing is lost
when it interacts with, say, iCal.
Joey Minta
> Joey Minta wrote:
>> Being a 1.0 feature is not a subjective characteristic, no matter how
>> much it may seem to be because of this debate.
>
> It's not a random characteristic, but we do need to have some
> flexibility there. As an example, one of the original goals for
> Lightning 0.1 was "no dataloss". Eventually, it became clear that this
> was incompatible with the even more important goal of "release something
> that some set of users can use sooner rather than later", so the goal
> was gradually shrunk to be "no dataloss on lightning-only data in normal
> day-to-day use, not including CalDAV".
>
version 0.x can be released, to borrow mvl's phrase 'whenever we want'.
On the other hand, 1.0 means something special that we don't really
have control over. If we're shrinking or cutting features, then in my
opinion, we should be in the process of releasing 0.n+1, rather than
1.0. Only when we're not doing that do we really have 1.0.
Joey Minta
> ...My inclination is to think that we want to come up
> we'll have a framework that will help us think about these things.
> Target users I can imagine for Lightning include: grandma on her desktop
> at home, student with laptop, organizational executive with a laptop who
> has an admin to do scheduling for her and travels a lot, corporate
> exec's admin, 30-something employee of a small organization. Maybe
> that's not exactly the right split, but it's an example of what I'm
> referring to.
this week's meeting? What's the best approach to this?
-Joey
Clint Talbert
Stephan Schaefer wrote:
> Joey Minta wrote:
>
>> Stephan Schaefer wrote:
>>
>>> ...snip...
>>
>> The following additional items come to mind:
>> P1:
>> -Full compliance with the iCalendar spec
>
>
We would certainly want this, if only to ensure that we have all the
proper architecture in place so that we could expand functionality
without significant back-end re-writes for version 2.0, for instance.
>
>> -Full compliance with the CalDAV spec (note that this is a moving
>> target for now)
>> -Integration with internet calendaring websites
>> Required Functionality:
>> -Simple, intuitive user interface
I might be mistaken, but I believe these two go hand-in-hand. Some sites
use site-specific mechanisms, some use webdav, but it seems that CalDAV
is where internet calendar server technology is going. The better we
support CalDAV, the further ahead we will be of other calendaring
applications.
Timezones:
The method we hacked into Sunbird for Simdesk Orgaizer was this: The
calendar chose your default timezone based on your operating system
timezone. We included an option in the View menu (and on the toolbar)
that allowed you to change your viewing timezone. So, you could
instantly see your events in whatever timezone you chose (this choice is
displayed for the user along the top of the calendar). This was a global
operation and converted all events. We also allowed the user to pick a
timezone for an event from the event dialog itself, and added the
event's timezone to the information that appeared when the user
moused-over the event.
And a candidate that no one has mentioned:
Importing data from other applications
I haven't tested Lightning's current ability to import calendar
information, but there does need to be a very seamless strategy for
guiding a user through the import process, especially when the user is
migrating from calendaring systems that do not readily export iCAL
formated data. (Last time I saw Outlook they didn't do this--perhaps it
changed for Outlook 2003?).
Clint
Michiel van Leeuwen
> I see this as a fundamental difference between 0.x and 1.0. In that,
> version 0.x can be released, to borrow mvl's phrase 'whenever we want'.
> On the other hand, 1.0 means something special that we don't really
> have control over. If we're shrinking or cutting features, then in my
> opinion, we should be in the process of releasing 0.n+1, rather than
> 1.0. Only when we're not doing that do we really have 1.0.
That means that you want 1.0 to be feature-driven?
That sounds like a good idea, but I'm really afraid that it will mean
that releases can be delayed for ages. That's not a good thing. So I am
more in favor of at least some time-driven component. (you can't do 100%
time driven releases when you work with lots of volunteers. Maybe not
even in general)
Time-driven means that some features have to be cut, with the reward of
actually releasing.
Michiel
Stephan Schaefer
I only had the feeling that the current CalDAV support is quite basic
and was not sure what the reason was. I just assumed it was due to the
draft status of the standard. But if the standard is going to be final
soon and there is a server implementation available, too (providing
access control etc.), it makes of course sense to support it.
>> I'm told that the reason I should accept Attendees etc for personal
>> users is that they're likely to share their calendars as well.
>> Personal users, however, do not have a multimillion-dollar company to
>> provide them with a server to publish their calendar on. Instead,
>> their publishing/sharing *will* come from these services. If we
>> really do believe that they're going to share their calendars in this
>> way, we shouldn't leave them out of this functionality. I also don't
>> think it qualifies as 'Advanced UI'. A simple 'search for calendars'
>> box (like the google box) and a publishing wizard (a good idea anyway)
>> would probably be sufficient.
>
> This sounds reasonable to me. In reality, I think "good internet
> integration" is likely to be an ongoing quest with various features.
> Perhaps just having a reasonable "end-user calendar sharing experience",
> and "find existing internet calendars" would be sufficient but not
> over-broad goals for 1.0. That said, it might also be reasonable to
> simply declare one or both of these things as goals, but for post 1.0.
>
I fully agree. My 'advanced UI' objection referred to an integrated UI
that is able to display lists of calendars hosted by different
providers. A search box is of course no big UI feature but the
implementation of the search seems non-trivial to me. I don't know how
standardized the calendar providers offer their lists, so you might end
up with some complicated parsing that might easily break if they change
their site's layout.
I'm pretty sure we cannot ship Lightning 1.0 without the ability to
share and publish calendars, but we should not make a corresponding UI
or search a must have for the initial release.
>>> Multiple time zones: an additional time zone could be displayed for
>>> reference by using a second vertical time bar in parallel to the
>>> existing one.
>>> This would simplify setting up meetings across time zones - a problem
>>> we all just experienced with our IRC meeting :)
>> Ouch. This seems like it should definitely be an extension, or at the
>> very least, a Pn for n >= 3. The IRC meeting was the only time I ever
>> had a need for this, and I'm the only one I know who ever even had
>> that minimal amount of need. This definitely seems like distracting
>> UI in my book.
>
> I'm not sure I agree with this. This is part of the target-user
> discussion, I think. My inclination is to think that we want to come up
> with a set of fictional target users as suggested by Spolsky so that
> we'll have a framework that will help us think about these things.
> Target users I can imagine for Lightning include: grandma on her desktop
> at home, student with laptop, organizational executive with a laptop who
> has an admin to do scheduling for her and travels a lot, corporate
> exec's admin, 30-something employee of a small organization. Maybe
> that's not exactly the right split, but it's an example of what I'm
> referring to.
>
> The way this would help us is that we can then start to think about
> which users would find a such a thing useful. I can imagine anyone who
> travels regularly, or who is part of an organization that needs to
> collaborate or interact with folks in other areas wanting such a feature.
>
That's exactly where this requirement comes from. Setting up conference
calls with colleagues in a different time zone. A quite common scenario
in big firms.
> I kind of suspect that this may be something that should, in fact, be
> pref controlled, whether it's as an individual pref, or part of
> "collaboration mode" or somesuch.
>
Correct. This is a really 'simple' feature as it will only display an
additional time bar in your views which has to be configured to a
certain time zone anyway. The UI to toggle and configure it can be
hidden on some settings page and should not hurt the end user.
>
>>> ...But we
>>> might reach the point where we want to (have to ?) release something
>>> stable and useful. ... This would allow us to release a 1.0 with a
>>> smaller but still useful feature set than initially planned.
> >
>> This is the step that I have a problem with. Either a feature is
>> important enough to be 1.0, or it isn't. It isn't "Important enough
>> to be 1.0 unless people start complaining that we aren't releasing 1.0
>> yet". I'd much rather see us release 0.15 than release 1.0 without
>> features that this discussion (and future discussions) labeled as
>> important in a 1.0 release.
>
> I wonder if there are, perhaps, two overlapping goals here. In
> particular, one is "release something good enough for some set of users
> with Thunderbird 2.0", and the other is "release 1.0 with the feature
> set we think is important." I (personally) think it would be a great
> success condition if these two goals could be met with the same release.
> That said, if there's no practical way to do that, it's not the end of
> the world.
>
And it would be the first project where an estimate over a range of
12-15 months would be correct right from the beginning. It is just
impossible to predict where the project will be in a year. All we can do
is to plan carefully now and to continually adjust our goals in order to
meet the deadline. If we don't plan for a certain release date we will
probably never release anything, at least nothing labeled 1.0. There
will always be bugs and missing features, but if you want to attract an
audience (users and developers) you must provide them with a reasonable
schedule and stick to it.
In my eyes the release date has a higher priority than the
functionality. I would rather skip a feature than shifting the release
by 3 or 6 months. There will be a life after 1.0 and having all planned
features prioritized will allow for shifting the less important features
into the next version.
Stephan
Andrew N Dowden
> I meant this to be a multi-faceted goal, with at least the following
> parts:
> a) Can roundtrip arbitrary ICS file data
> b) Gracefully handles ics data too complex to be generated by
> Lightning (eg. multiple RRULEs, foreign timezones)
> c) Exports/provides all data in an ICS format upon request.
> As just a gloss on (c), this could be re-phrased as 'interoperability
> with majority of other calendaring clients'. We've received a bit of
> flack about the sqlite storage mechanism particularly because, in its
> most rudimentary form, this data is not inter-operable. We need to
> emphasize that although Lightning is a great client, nothing is lost
> when it interacts with, say, iCal.
'what iCal elements are supported' threads of this discussion.
Is this best handled as a 'Bug#', on going discussion (in this list), or
some of the existing bugs?
I have already been mapping holiday logic, and real-world schedule
issues; how they are defined in iCalendar syntax, and whether they work
or can be viewed / edited in Sunbird.
Thoughts?
--
_______________________________________________
SoftDesign Group
Dowden Software Associates
P O Box 31 132, Lower Hutt 6315, NEW ZEALAND
Dan Mosedale
> Dan Mosedale wrote:
>> ...My inclination is to think that we want to come up with a set of
>> fictional target users as suggested by Spolsky so that we'll have a
>> framework that will help us think about these things.
>
> this week's meeting? What's the best approach to this?
>
I'll put it on the agenda for this week's meeting. I think it might be
worth kicking off with some sort of meeting including mconnor and
beltzner, after which we could take it to the usual newsgroup/wiki combo.
Dan
Dan Mosedale
> Joey Minta wrote:
>> I see this as a fundamental difference between 0.x and 1.0. In that,
>> version 0.x can be released, to borrow mvl's phrase 'whenever we
>> want'. On the other hand, 1.0 means something special that we don't
>> really have control over.
>
> That sounds like a good idea, but I'm really afraid that it will mean
> that releases can be delayed for ages. That's not a good thing. So I am
> more in favor of at least some time-driven component. (you can't do 100%
> time driven releases when you work with lots of volunteers. Maybe not
> even in general)
> Time-driven means that some features have to be cut, with the reward of
> actually releasing.
I tend to agree that a balance between time-driven and feature driven is
likely to be a good thing. Joey's certainly right that 0.x and 1.0 mean
very different things, and as a result balance should be likely to be
tilted a bit more towards features in 1.0 than in 0.x releases.
There are clearly set of features that we can't possibly cut for 1.0
(dataloss bugs), and others that perhaps we could (offline, pda sync).
Part of the question here is, what does 1.0 mean? A calendar app that's
usable by a specific users? Or does it need to be a more than that,
such as also including one or two features that distinguish it from
other clients, or simply that enhances basic usability.
Dan
Dan Mosedale
>>> -Full compliance with the CalDAV spec (note that this is a moving
>>> target for now)
>>> -Integration with internet calendaring websites
>>> Required Functionality:
>>> -Simple, intuitive user interface
>
> I might be mistaken, but I believe these two go hand-in-hand. Some sites
> use site-specific mechanisms, some use webdav, but it seems that CalDAV
> is where internet calendar server technology is going. The better we
> support CalDAV, the further ahead we will be of other calendaring
> applications.
I think we definitely want to support the CalDAV calendar creation /
discovery mechanisms. If this is sufficient to allow end-users to take
advantage of key sharing sites on the net, that's great.
> Timezones:
> The method we hacked into Sunbird for Simdesk Orgaizer was this: The
> calendar chose your default timezone based on your operating system
> timezone. We included an option in the View menu (and on the toolbar)
> that allowed you to change your viewing timezone. So, you could
> instantly see your events in whatever timezone you chose (this choice is
> displayed for the user along the top of the calendar). This was a global
> operation and converted all events.
I must admit, I kinda like ssa's suggestion of having an extra
guide/legend, as it allows you to see where an event lies in multiple
timezones at once while you're placing it with drag-n-drop.
> We also allowed the user to pick a timezone for an event from the event dialog itself, and added the
> event's timezone to the information that appeared when the user
> moused-over the event.
One thing that has been pointed out to me in the past is that in order
to be able to express airplane flights reasonably, you actually need a
timezone on both start & end times. However, this is certainly going to
be 1% of anyone's events, so one way to avoid complexity there might be
to have that hidden in some sort of "advanced" UI.
> Importing data from other applications
I agree that importing is key. My belief is that this helped Firefox
adoption grow in a significant way, because it lowered the barrier to
entry for folks who already had bookmark data and needed that in order
for any browser they tried to be useful.
Dan
Michael Eckardt
I'm new to this, so please forgive me if I pipe up with inappropriate ideas.
As a real-world end-user in a 150 employee manufacturing company, I see
a few points that need to be brought up:
1. Timezones, IMHO, are not a priority. If you have an appointment, you
can always add or deduct the timezone differential manually. How many
users (like me) really need this task automated? It's not a show stopper.
2. Import from the popular sources, esp. Sunbird, is a must.
3. I would love to see an intelligent email interpreter that would let
me highlight a section of text and turn it into an event or a task
without having to type anything.
4. Customizing the look is not so important - I need something that
works and prints.
Just my 2 cents (Canadian)...
Michael Eckardt
Dan Mosedale
> I am very interested in tracking and resolving the "round trip", and
> 'what iCal elements are supported' threads of this discussion.
> Is this best handled as a 'Bug#', on going discussion (in this list), or
> some of the existing bugs?
https://bugzilla.mozilla.org/show_bug.cgi?id=129660 is the meta-bug that
is intended to track iCalendar standard lossage. In reality, lots of
the bugs with the "dataloss" keyword are iCalendar round-tripping
issues. Someone needs to go through and look at the dataloss bugs and
make any appropriate ones block 129660. If you (or anyone else reading
this) has any interest in doing that, that would be great.
Dan
Dan Mosedale
> Dan Mosedale wrote:
> I only had the feeling that the current CalDAV support is quite basic
> and was not sure what the reason was. I just assumed it was due to the
> draft status of the standard.
It was really just a resource issue. Getting Lightning 0.1 out the door
in a finite amount of time meant cutting some stuff, and CalDAV was one
of the things that got cut.
> But if the standard is going to be final
> soon and there is a server implementation available, too (providing
> access control etc.), it makes of course sense to support it.
There are a number of open source ones (see
http://ietf.webdav.org/caldav/homepage/projects.html for a list). There
are also commercial offerings in the works, I believe.
> I fully agree. My 'advanced UI' objection referred to an integrated UI
> that is able to display lists of calendars hosted by different
> providers. A search box is of course no big UI feature but the
> implementation of the search seems non-trivial to me. I don't know how
> standardized the calendar providers offer their lists, so you might end
> up with some complicated parsing that might easily break if they change
> their site's layout.
One possible way I can think of to do some trivial to implement UI for
this would be to have the search box simply send a search URI to the
system web-browser.
> I'm pretty sure we cannot ship Lightning 1.0 without the ability to
> share and publish calendars, but we should not make a corresponding UI
> or search a must have for the initial release.
Somehow, I suspect that some folks might disagree with you on the
"should not". I think that the best way to resolve questions like this
is likely to come out of having a good set of hypothetical end-users
defined and a crisp product definition, a couple of things that I'll go
into more towards the end of this post.
> And it would be the first project where an estimate over a range of
> 12-15 months would be correct right from the beginning. It is just
> impossible to predict where the project will be in a year. All we can do
> is to plan carefully now and to continually adjust our goals in order to
> meet the deadline. If we don't plan for a certain release date we will
> probably never release anything, at least nothing labeled 1.0. There
> will always be bugs and missing features, but if you want to attract an
> audience (users and developers) you must provide them with a reasonable
> schedule and stick to it.
I completely agree with the above paragraph. Given the number of
features we want to add, I'll be really surprised if some of them don't
turn out to be harder than we expect. Furthermore, I'll be really
surprised if we aren't forced to stop and re-think our priorities
multiple times between now and 1.0. Even just releasing Lightning 0.1
required this.
> In my eyes the release date has a higher priority than the
> functionality. I would rather skip a feature than shifting the release
> by 3 or 6 months. There will be a life after 1.0 and having all planned
> features prioritized will allow for shifting the less important features
> into the next version.
I think this again begs the bigger question, "what do we think 1.0 is?".
For example, in my mind, 1.0 is the first real "ready for
non-testing users" release, in the sense that it has sufficient polish,
performance, experience, and reliability that people can depend on.
So in its most barebones form, 1.0 could be a "basic calendaring
application" without any snazzy features like PDA sync, Internet
integration, freebusy, or offline use. Alternatively, we might decide
that one or more of those features is so central to our raison d'etre
that we don't want to release something without it. Perhaps because not
enough people would find a compelling reason to switch, perhaps because
then our "brand" would mean "nothing new and innovative" to folks who
used 1.0, perhaps for some other reasons.
So this suggests to me that we need to jump up a level further, and
think about our product definition as a whole, not just in terms of 1.0.
This is something that might (or might not) be significantly different
w.r.t. Lightning and Sunbird. I'll put "product definition" on the
agenda for this week's meeting, as I think this really is part of the
same question as the "fictional end users" that we want to create.
Dan
Stephan Schaefer
> Stephan Schaefer wrote:
>> Dan Mosedale wrote:
>> I only had the feeling that the current CalDAV support is quite basic
>> and was not sure what the reason was. I just assumed it was due to the
>> draft status of the standard.
>
> It was really just a resource issue. Getting Lightning 0.1 out the door
> in a finite amount of time meant cutting some stuff, and CalDAV was one
> of the things that got cut.
>
Ok, makes sense.
>> I fully agree. My 'advanced UI' objection referred to an integrated UI
>> that is able to display lists of calendars hosted by different
>> providers. A search box is of course no big UI feature but the
>> implementation of the search seems non-trivial to me. I don't know how
>> standardized the calendar providers offer their lists, so you might
>> end up with some complicated parsing that might easily break if they
>> change their site's layout.
>
> One possible way I can think of to do some trivial to implement UI for
> this would be to have the search box simply send a search URI to the
> system web-browser.
>
That would be a good start.
>> I'm pretty sure we cannot ship Lightning 1.0 without the ability to
>> share and publish calendars, but we should not make a corresponding UI
>> or search a must have for the initial release.
>
> Somehow, I suspect that some folks might disagree with you on the
> "should not". I think that the best way to resolve questions like this
> is likely to come out of having a good set of hypothetical end-users
> defined and a crisp product definition, a couple of things that I'll go
> into more towards the end of this post.
>
Yes, you're right. With 'should not' I just wanted to express that I do
not think it is a requirement which might block the release. But it
depends on other decisions as well.
>
>> In my eyes the release date has a higher priority than the
>> functionality. I would rather skip a feature than shifting the release
>> by 3 or 6 months. There will be a life after 1.0 and having all
>> planned features prioritized will allow for shifting the less
>> important features into the next version.
>
> I think this again begs the bigger question, "what do we think 1.0 is?".
> For example, in my mind, 1.0 is the first real "ready for
> non-testing users" release, in the sense that it has sufficient polish,
> performance, experience, and reliability that people can depend on.
>
> So in its most barebones form, 1.0 could be a "basic calendaring
> application" without any snazzy features like PDA sync, Internet
> integration, freebusy, or offline use. Alternatively, we might decide
> that one or more of those features is so central to our raison d'etre
> that we don't want to release something without it. Perhaps because not
> enough people would find a compelling reason to switch, perhaps because
> then our "brand" would mean "nothing new and innovative" to folks who
> used 1.0, perhaps for some other reasons.
I like the idea to concentrate on "basic calendaring" first, as it will
provide a foundation for more interesting features. Basic calendaring,
however, should not exclude certain audiences like eg, enterprise
customers. For those people 'basic' means I can invite somebody to a
meeting and I can see if he has other appointments at the planned time.
So, may be we could write down the possible target audiences and put
features to them that we would call 'basic'. And then let's see what we
have and what can be achieved in the proposed time frame.
> So this suggests to me that we need to jump up a level further, and
> think about our product definition as a whole, not just in terms of 1.0.
> This is something that might (or might not) be significantly different
> w.r.t. Lightning and Sunbird. I'll put "product definition" on the
> agenda for this week's meeting, as I think this really is part of the
> same question as the "fictional end users" that we want to create.
>
Sounds good.
Stephan