imaginary users and product definition
Dan Mosedale
to discuss product definition and imaginary target users. I've talked
to Mike Beltzner and Mike Connor, and we've got one tentatively
scheduled for Wednesday at 10:00 AM PDT / 17:00 UTC:
My hope is that this is a workable time for most people and that we'll
get a good turnout. With luck, we'll be able to actually have a phone
conference for this one with toll-free dial-in for folks in the US,
Canada, and Europe.
http://groups.google.com/group/mozilla.dev.apps.calendar/browse_thread/thread/babba9eab651bbf2/937e8f6ab6bf6945#937e8f6ab6bf6945
is the thread where all this discussion got started.
I'll post a little more with some thoughts on target users and product
definition either tonight or tomorrow. Let the brainstorming begin...
Dan
Joey Minta
> At our most recent meeting, I promised to organize another get-together
> to discuss product definition and imaginary target users. I've talked
> to Mike Beltzner and Mike Connor, and we've got one tentatively
> scheduled for Wednesday at 10:00 AM PDT / 17:00 UTC:
I can't make this time. I'm busy on Wednesday from 8:30 AM PDT until
11:00 AM PDT and from 2:00 PM PDT to 3:00 PM PDT. If the conflict is
unavoidable, I'll just write up some of my imaginary users in the coming
days so that they're at least down on paper.
-Joey
Michiel van Leeuwen
> At our most recent meeting, I promised to organize another get-together
> to discuss product definition and imaginary target users. I've talked
> to Mike Beltzner and Mike Connor, and we've got one tentatively
> scheduled for Wednesday at 10:00 AM PDT / 17:00 UTC:
Unfortunatly, I will only be able to attend the first 30 minutes of that
timeframe.
> I'll post a little more with some thoughts on target users and product
> definition either tonight or tomorrow. Let the brainstorming begin...
Ok, because you asked for it:
I can think of some types of users (still short stories, not really
verbose):
- The user that uses firefox a lot, has tons of extensions is sure that
web2.0 is really the future. He gets his data for events from a lot of
different places: email, websites, manual entry etc. Might want to sync
to his uber-cool new mobile phone
- The office worker, who currently uses outlook. All his colleagues use
outlook. But now, he is trying thunderbird + lightning and wants it to
work together with the outlook users. He gets most of his event data
from email, send by outlook as meeting invitation. Might have a PDA.
- The home user, just wanting to keep a list of upcoming events. Enters
all the data by hand.
- The system administrator of a medium sized company, want to implement
sunbird or lighting as calendar app in his company.
I'm sure there are other usage types, but this is what i could come up with.
Dan Mosedale
> Dan Mosedale wrote:
>> At our most recent meeting, I promised to organize another
>> get-together to discuss product definition and imaginary target
>> users. I've talked to Mike Beltzner and Mike Connor, and we've got
>> one tentatively
>> scheduled for Wednesday at 10:00 AM PDT / 17:00 UTC:
>
> Unfortunatly, I will only be able to attend the first 30 minutes of that
> timeframe.
Since we can only have mvl for part of the time, and jminta for none of
it, I think we need to re-schedule. One possibility would be Friday at
the same time. If that doesn't work for a quorum, we could just
substitute this meeting for the usual Thursday general issue meeting,
also at the same time.
Thoughts?
Dan
Michiel van Leeuwen
> Since we can only have mvl for part of the time, and jminta for none of
> it, I think we need to re-schedule. One possibility would be Friday at
> the same time. If that doesn't work for a quorum, we could just
> substitute this meeting for the usual Thursday general issue meeting,
> also at the same time.
I'll be away on a short vacation from Thursday evening to Monday
evening. That means i won't be able to attend the thursday meeting, or a
Friday meeting.
Michiel
Dan Mosedale
OK, it looks like we're going to have to punt on any sort of meeting
until next week.
Do any of these times work for people?
17:00 UTC Wednesday
http://www.timeanddate.com/worldclock/fixedtime.html?year=2006&month=4&day=19&hour=17&min=0&sec=0
16:00 UTC Tuesday
http://www.timeanddate.com/worldclock/fixedtime.html?year=2006&month=4&day=18&hour=16&min=0&sec=0
16:00 UTC Wednesday
http://www.timeanddate.com/worldclock/fixedtime.html?year=2006&month=4&day=19&hour=16&min=0&sec=0
Since we're going to have to punt on having a meeting until next week,
I'd like to start hashing out these issues here in the newsgroups now,
rather than mostly waiting. mconnor/beltzner: any chance I can convince
you guys to follow along in UI / product definition threads here in
m.d.a.calendar?
Dan
Joey Minta
> At our most recent meeting, I promised to organize another get-together
> to discuss product definition and imaginary target users.
>
> definition either tonight or tomorrow. Let the brainstorming begin...
>
> Dan
>
>
>
what the question is, so I may be a bit off with this analysis/breakdown:
Student (<21yrs old)
-Overall schedule appearance
-Largely repetitive, repeating weekly
-Amount of time spent in Calendar
- <30min/day
-Function of calendar
-As a 'reminder system' for:
-tasks
-unexpected scheduling changes
-Sharing own data
-little to none
-Publish free-busy for activities planning
-Publish entire calendar for parental information
-Sharing other data
-View published *public* calendars (sports/movies/etc)
-Accept tasks emailed by parents/teachers?
Stay-at-home-mom/dad
-Overall schedule appearance
-Somewhat repetitive, repeating at varied intervals
-Fairly task-heavy
-Timezones only for occasional vacations
-Amount of time spent in Calendar
-30-45min/day
-Function of calendar
-organize daily schedule/task list (ensure time for essentials)
-prioritizing when conflicts appear
-coordinate family planning/scheduling (assigning chores, etc)
-Sharing own data
-little to none
-Publish free-busy for recreation planning
-Sharing other data
-View semi-public calendars (child's soccer schedule)
-Assigning tasks, placing events on other family members schedules
Grandparent
-Overall schedule appearance
-Somewhat repetitive, repeating at varied intervals
-More sparse than other users
-Amount of time spent in Calendar
- <30min/day
-Function of Calendar
- reminder of upcoming events/tasks
-Sharing own data
-little to none
-Publish full calendar to restricted set of viewers
(safety/security)
-Sharing other data
-little to none
-View public calendars of local events
Self-employed business owner
-Overall schedule appearance
-Fairly full, not very repetitive
-Amount of time spent in Calendar
-60-90min/day
-Function of Calendar
-Planning (with more long-term emphasis?)
-Reminders
-Sharing own data
-little to none
-Advertisement?
-Sharing other data
-little to none
Low/mid-level corporate employee
-Overall schedule appearance
-Fairly full, not very repetitive
-Some timezone issues
-Amount of time spent in Calendar
-60-120min/day
-Function of Calendar
-Schedule organization
-Prioritization of conflicts
-Coordination with other employees
-Group meeting planning
-Sharing own data
-high level
-Publish free-busy for coordination with others
-Publish entire calendar for billing
-Accepting assignments/tasks from others
-Delegating tasks to others
-Sharing other data
-high level
-view many free-busy schedules for others
CEO/High level corporate employee
-Overall schedule appearance
-Full, not very repetitive
-Many timezone issues
-Amount of time spent in Calendar
-60-120min/day
-Function of Calendar
-Coordination of many people's schedules
-See 'big picture' of scheduing situation
-Analogous to SAHM, but on much larger scale
-Sharing own data
-medium amount
-Publish free-busy to allow for easy scheduling by others
-Sharing other data
-extreme amount
-view many free-busy schedules for coordination
-view many non-public calendars for oversight purposes
Overall patterns/conclusions
-Time spent in Calendar remains small for all cases
-Desire to "get in and get out"
-Much larger need to find/view other data than publish one's own data
-Easy subscription interface needed
-Calendars often used as reminder systems (alarms are key)
Split between non-corporate (1, 2, 3, and 4) and corporate (5 and 6)
-Timezones only major factor in corporate
-Corporate Calendars will involve significantly more calendar
subscriptions
-Amount of sharing of own data is much higher in corporate
-Time spent in Calendar increases (easy-of-use less of a factor wrt
power-use?)
Joey Minta
up at: http://www.google.com/calendar/ical/jmi...@gmail.com/public/basic
for further available timeslots/planning.
Dan Mosedale
>> Since we're going to have to punt on having a meeting until next week,
>> I'd like to start hashing out these issues here in the newsgroups now,
>> rather than mostly waiting. mconnor/beltzner: any chance I can
>> convince you guys to follow along in UI / product definition threads
>> here in m.d.a.calendar?
>
Since only one per replied to this, and he can only make Tuesday, it
seems like we're not likely to have a quorum for the meeting this
Tuesday. Instead, I'd like to propose that we devote this Thursday's
meeting to this topic. I've already verified that Mike Beltzner can
make it. Any objections?
Dan
Dan Mosedale
>
> Here's what I've come up with so far. I'm still not entirely certain on
> what the question is, so I may be a bit off with this analysis/breakdown:
In general, this seems like a good level of granularity to me. Beltzner
had an interesting comment in IRC yesterday about the value of the
imaginary user exercise as being more in the discussion than the actual
end product. This was, as I understand it, because it's pretty hard (ie
requires a bunch of work) to verify that the your imaginary user set is
actually a good / meaningful one. Mike, would you care to comment on
what you think the most effective tack for us to take here is?
> [... user descriptions elided for now; want to hear back from Mike as
> well as focus on some higher-level product discussion first ...]
>
> Overall patterns/conclusions
> -Time spent in Calendar remains small for all cases
I would tend to agree, with possible exceptions for administrative
assistants and project managers.
> -Desire to "get in and get out"
I think this is a key observation: that a calendar is very much a tool
to do other things. My suspicion is that the easier it is to use, and
the less time one has to spend in it will make for happier users, as it
leaves them more time to do whatever those other things are. I remember
hearing similar discussions about how to focus Firefox UI back in the
day, and in my mind, this is one of the things that has made it as
successful as it is.
> -Much larger need to find/view other data than publish one's own data
> -Easy subscription interface needed
I assume that by this, you mean that most users are likely to spend more
time worrying about looking through other data than they are worrying
about publishing their own. I assume this is true even for users who
care a lot about publishing, in the sense that you configure publishing
once, and then pretty much forget about it, at least as far as sharing
your overall calendar data. Even for the case of scheduling
meetings/events using (say) iTIP, unless you are a project manager or
admin assistant, chances seem high that you will respond to more
invitations than you send out. Do you agree?
> -Calendars often used as reminder systems (alarms are key)
>
> Split between non-corporate (1, 2, 3, and 4) and corporate (5 and 6)
> -Timezones only major factor in corporate
One up-and-coming non-corporate use case I can imagine would be people
having community meetings over the Internet (eg groups of people in
flickr, or google groups). Another might be someone who has family in
another timezone and wishes to regularly schedule calls with them. How
important these use cases are is not clear to me.
> -Corporate Calendars will involve significantly more calendar
> subscriptions
What makes you say this? I don't see why people would necessarily
subscribe to a lot of calendars just because they're in the corporate
world. And I very much hope to be subscribing to various local
entertainment and event calendars for my personal life in the
not-too-distant future.
> -Amount of sharing of own data is much higher in corporate
I agree, given that calendaring within an organization is typically
deployed very specifically to facilitate intra- (and, to a lesser extent
inter-) organizational scheduling.
> -Time spent in Calendar increases (easy-of-use less of a factor wrt
> power-use?)
I'm not sure I buy this. I can imagine that in some cases you might
sacrifice discoverability/learnability for power if you absolutely had
to, but I think it's still really key that the day-to-day usage is easy,
and that the calendar stays out of the user's way.
Dan
Joey Minta
> Joey Minta wrote:
>> -Much larger need to find/view other data than publish one's own data
>> -Easy subscription interface needed
>
> I assume that by this, you mean that most users are likely to spend more
> time worrying about looking through other data than they are worrying
> about publishing their own. I assume this is true even for users who
> care a lot about publishing, in the sense that you configure publishing
> once, and then pretty much forget about it, at least as far as sharing
> your overall calendar data. Even for the case of scheduling
> meetings/events using (say) iTIP, unless you are a project manager or
> admin assistant, chances seem high that you will respond to more
> invitations than you send out. Do you agree?
see actually three distinct categories of data, rather than just
mine/not-mine. Instead, I see 'My Data', 'Data direct towards me'
(invitations) and 'Data I want to find' (subscriptions/search). The
comment was intended to contrast 1 and 3, rather than 1 and 2.
>
>> -Calendars often used as reminder systems (alarms are key)
>>
>> Split between non-corporate (1, 2, 3, and 4) and corporate (5 and 6)
>> -Timezones only major factor in corporate
>
> One up-and-coming non-corporate use case I can imagine would be people
> having community meetings over the Internet (eg groups of people in
> flickr, or google groups). Another might be someone who has family in
> another timezone and wishes to regularly schedule calls with them. How
> important these use cases are is not clear to me.
>
>> -Corporate Calendars will involve significantly more calendar
>> subscriptions
>
> What makes you say this? I don't see why people would necessarily
> subscribe to a lot of calendars just because they're in the corporate
> world. And I very much hope to be subscribing to various local
> entertainment and event calendars for my personal life in the
> not-too-distant future.
Both of these points seem to bring up a fundamental question about this
discussion: Are we talking about ideal imaginary users or current
imaginary users? It seems to me that if 1.0 were to happen tomorrow, my
points would be more valid, whereas if 1.0 were to happen 5 years from
now, your points would be more likely to be valid (but my crystal ball
is a bit hazy today). Talk of subscribing to local calendars, etc still
feels to me like a bit of a nerd-niche. Even RSS, which seems to be all
the rage, still only seems to be used by about 10% of web-users (or so
says a quick google search). My fear here is that, in designing a UI
designed for this kind of sharing, we're going to be hurting
early-adoption, because we won't be meeting present use-cases/demand.
>> -Time spent in Calendar increases (easy-of-use less of a factor
>> wrt power-use?)
>
> I'm not sure I buy this. I can imagine that in some cases you might
> sacrifice discoverability/learnability for power if you absolutely had
> to, but I think it's still really key that the day-to-day usage is easy,
> and that the calendar stays out of the user's way.
As a power-user, by definition, you want/use more features/aspects of
the program. While good UI design minimizes the intrusiveness of these
additional features for the non-power-user, it's not at all clear to me
that it can ever be done in a 0-impact way. Not only do we want the
calendar to stay out of the way, but we want the bits of the calendar
that aren't used/desired to stay out of their way too.
-Joey
Dan Mosedale
> Dan Mosedale wrote:
>> Joey Minta wrote:
> Both of these points seem to bring up a fundamental question about this
> discussion: Are we talking about ideal imaginary users or current
> imaginary users? It seems to me that if 1.0 were to happen tomorrow, my
> points would be more valid, whereas if 1.0 were to happen 5 years from
> now, your points would be more likely to be valid (but my crystal ball
> is a bit hazy today). Talk of subscribing to local calendars, etc still
> feels to me like a bit of a nerd-niche. Even RSS, which seems to be all
> the rage, still only seems to be used by about 10% of web-users (or so
> says a quick google search).
It would be interesting to know the number of Firefox users that use
RSS. That would presumably be effected by both the demographic that
happens to use Firefox, as well as the fact that Firefox comes with
built-in RSS support, while IE currently does not.
It seems to me that this goes to the higher-level question of
innovation, in general, as it came up in our meeting last week and that
I touched in my "raison d'etre" post today. In particular, I think the
places in which its important to innovate are the places in which users
currently aren't being well-served. Indeed, you're quite right that the
features we want to develop are the ones we think users would find to be
significant value-adds to the way they do calendaring today.
> My fear here is that, in designing a UI
> designed for this kind of sharing, we're going to be hurting
> early-adoption, because we won't be meeting present use-cases/demand.
We'll definitely need to find the right balance. Clearly, any
enhancements that actually break or worsen the task flow for the things
that people spend most of their time doing are going to be a problem,
and should perhaps be re-thought. I'd suggest that we need to take this
sort of thing on a feature-by-feature basis. I don't see why making for
easy calendar sharing/scheduling has to interfere with the basic
time-management use cases. One nice resource that we have available to
us is that there are plenty of existing calendar apps (web-based and
otherwise) that do various flavors of sharing that we can look at to
help us get a feel for what sorts of UI we like, and what sorts we don't
like.
>>> -Time spent in Calendar increases (easy-of-use less of a factor
>>> wrt power-use?)
>>
>> I'm not sure I buy this. I can imagine that in some cases you might
>> sacrifice discoverability/learnability for power if you absolutely had
>> to, but I think it's still really key that the day-to-day usage is
>> easy, and that the calendar stays out of the user's way.
> As a power-user, by definition, you want/use more features/aspects of
> the program. While good UI design minimizes the intrusiveness of these
> additional features for the non-power-user, it's not at all clear to me
> that it can ever be done in a 0-impact way. Not only do we want the
> calendar to stay out of the way, but we want the bits of the calendar
> that aren't used/desired to stay out of their way too.
I think I agree with the above paragraph in general.
Dan
Mike Beltzner
I can't think of a larger intersection of technology-users and
socially active individuals than this group. I think you're
underestimating the potential desire here for sharing calendar
information, especially in the post-high-school group, which is
disparately located group that also tends to play with free software a
lot :)
> Stay-at-home-mom/dad
> -Overall schedule appearance
> -Somewhat repetitive, repeating at varied intervals
> -Fairly task-heavy
> -Timezones only for occasional vacations
> -Amount of time spent in Calendar
> -30-45min/day
> -Function of calendar
> -organize daily schedule/task list (ensure time for essentials)
> -prioritizing when conflicts appear
> -coordinate family planning/scheduling (assigning chores, etc)
> -Sharing own data
> -little to none
> -Publish free-busy for recreation planning
> -Sharing other data
> -View semi-public calendars (child's soccer schedule)
> -Assigning tasks, placing events on other family members schedules
This is interesting; do you not think working parents would have these
same issues? I would assert that those parents might use whatever
corprorate calendaring solution their office has rolled out, and
either cram their personal data into that solution or use a different
product for home data both at the office and at home. This speaks to a
requirement for multiple access points, and data import/export so that
they can make sure that their 5pm conference call doesn't conflict
with little Jane's soccer practise.
Think you're underestimating the desire to share again. SMB owners
meet with suppliers, contractors, customers, etc, really frequently.
Think of a real estate agent, a dentist, or a plumber. The ablity to
issue and consume events seems key to these individuals.
Hm. All your time estimates seem radically high to me. Also, instead
of thinking about it by the paradigm currently set out by calendaring
software (ie: publish/subscribe) it might be helpful to think of it at
a task basis - what do people want to be able to do with their
calendars?
The number of profiles here seems about right; I'd probably collapse
the business users into different groups, though: SMB/Self-Employed,
Business User, and Admin Assist; while the nature of a CEO's calendar
might be different than that of a corporate drone, the nature of the
calendaring tasks are not really that different. I might also ignore
the "Grandparent" audience for now. Or maybe just make the statement
that we aren't considering them a primary user. Maybe I'm being
ageist. :)
cheers,
mike
--
/ mike beltzner / user experience lead / mozilla corporation /
Mike Beltzner
> In general, this seems like a good level of granularity to me. Beltzner
> had an interesting comment in IRC yesterday about the value of the
> imaginary user exercise as being more in the discussion than the actual
> end product. This was, as I understand it, because it's pretty hard (ie
> requires a bunch of work) to verify that the your imaginary user set is
> actually a good / meaningful one. Mike, would you care to comment on
> what you think the most effective tack for us to take here is?
Personae, as originally expressed as Cooper, were to be fleshed out to
the point where they could act as surrogates for the actual users.
Instead of holding a focus group to get feedback on a design decision,
one could merely consult the personae. This required, however, that
the personae were extremely well researched, validated, and fully
understood. Cooper talked at length about how he uses Personae, but
not at how he creates them, since -- well -- he wants people to hire
his company to do that.
Since the concept was introduced, companies have been creating
personae for their user profiles. They've taken some of the good parts
of it (ie: making design discussions center on people instead of
demographic groups, so "Fred wouldn't use that feature" instead of "Do
we think that feature is required by SMB?") but also introduced some
bad parts (ie: including information about how Frank likes chocolate;
fantastic news! but we're not putting chocolate in the box, are we?).
The goal of personae should be to come up with concise answers to
common questions developers might have. What terminology is the user
group familiar with? What sort of applications do they commonly use?
What tasks are important to them, and what sort of stuff do they do
every day vs. once in a blue moon?
The discussion in creating these is indeed useful for exploring the
edges, but without basing it on some sort of demographic or primary
reserach data, all you're doing is dressing up your assertions and
making them seem more real. In a project such as this -- where funding
is scarce and time is short -- I think there are several good
assumptions and assertions that we can base this stuff on. The key is
to make sure we *declare* the assertions and our relative confidence
level in them. That way, should time or opportunity arise to validate,
we can go after our least secure assumptions first.
Dan Mosedale
>
> The number of profiles here seems about right;
OK, so it sounds like the foremost thing to do here is reach consensus
on this list. So, the current set of users on the table seems to be:
Student
Stay-at-home Parent
(Grandparent)
Small/Medium Business
Business
Admin Assistant
(CEO)
> I'd probably collapse
> the business users into different groups, though: SMB/Self-Employed,
> Business User, and Admin Assist; while the nature of a CEO's calendar
> might be different than that of a corporate drone, the nature of the
> calendaring tasks are not really that different.
I'm not sure I agree with this. The main reasoning here is that I think
the CEO is likely to have delegated most calendaring-level work to the
admin assistant. This means that both of these users are going to need
to deal with calendar delegation and access-rights, but from different
perspectives. The average Business User may well not need this sort of
functionality.
> I might also ignore the "Grandparent" audience for now. Or maybe just
> make the statement that we aren't considering them a primary user.
Maybe I'm being
> ageist. :)
I also wouldn't be too upset about not worrying about the Grandparent
demographic at this point, largely because my suspicion is that the
number of users in that group likely to have a strong interest in
tracking their lives on the computer may not be super-high. That's
merely speculation on my part, though; I'd be curious to hear about
Mike's reasoning as well.
Dan
Joey Minta
> Student
> Stay-at-home Parent
> (Grandparent)
> Small/Medium Business
> Business
> Admin Assistant
> (CEO)
>
that it would be a big mistake to try to go feature-for-feature with
Outlook. Accordingly, going after the CEO/Admin Assistant is going to
be difficult to do out of the gate, simply because 'missing "feature" X'
isn't a good selling point, even if X is fairly useless. My
unscientific, unsubstantiated impression is that Firefox made inroads
into the corporate market by first being something that
businessmen/women were using at home. That might seem like a reasonable
strategy here as well. The result here would be to concentrate 1.0 on
everyone up to Small/Medium Business/Business, but keep the last 2
around as an eventual target.
-Joey
Mike Beltzner
> Dan Mosedale wrote:
> > Student
> > Stay-at-home Parent
> > (Grandparent)
> > Small/Medium Business
> > Business
> > Admin Assistant
> > (CEO)
> >
> One of the things I took away from last week's meeting was the notion
> that it would be a big mistake to try to go feature-for-feature with
> Outlook. Accordingly, going after the CEO/Admin Assistant is going to
> be difficult to do out of the gate, simply because 'missing "feature" X'
I tend to agree with this, as my anti-chase-the-enterprise-bias in the
meeting may have led you to predict. Dan's points about the CEO having
different tasks than the Admin Assist is absolutely correct in an
Outlook paradigm where one delegates authority to calendar as per some
corporate directory. If you generalize that out to giving another user
write permission to your calendar, it not only sounds less
enterprise-y, but becomes a task you might see that admin assist doing
with their home calendar and their spouse. :)
Stephan Schaefer
with all the comments below I don't think that the personae approach is
a useful tool in order to find (or define?) a target audience.
Especially if we would use it to decide if a certain feature should be
implemented or not. This decision would be based on no reasonable data
at all but on what we think a user might probably want.
Our goal should be to build an application that can be used by end-users
and enterprise users with the same satisfaction.
The biggest concerns against enterprise features like inviting people is
that it might clutter the UI and confuse the user who has no need for
it. Wouldn't it be useful to discuss those features step-by-step and see
if the UI should be simplified or not ?
Sorry, but I have the feeling that the personae discussion does not
provide any help in reaching the goal to come up with a useful road map
towards Lightning 1.0, which I still hope can be shipped in the not too
distant future.
Stephan
> cheers,
> mike
>
> --
> / mike beltzner / user experience lead / mozilla corporation /
> _______________________________________________
> dev-apps-calendar mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-calendar
Michiel van Leeuwen
> Our goal should be to build an application that can be used by end-users
> and enterprise users with the same satisfaction.
>
> The biggest concerns against enterprise features like inviting people is
> that it might clutter the UI and confuse the user who has no need for
> it. Wouldn't it be useful to discuss those features step-by-step and see
> if the UI should be simplified or not ?
I think the discussion so far has shown that there are other markets
then just the enterprise with big servers and everything. So the
discussion did have some use.
To discuss those features, you need to define them first. Having an idea
of who your users are will be helpful in doing that.
Also, there are features which have overlap between the different user
groups. For example, inviting somebody to an event. For the enterprise
user, that might mean actually putting an item in somebody else's
calendar. For the home-user, it might be sending out an imip invitation.
Have two separate UI elements for that seems bad.
> Sorry, but I have the feeling that the personae discussion does not
> provide any help in reaching the goal to come up with a useful road map
> towards Lightning 1.0, which I still hope can be shipped in the not too
> distant future.
I partly agree. But we need some discussion about the product
definition. See also the raison d'etre post. Defining the users-groups
you are targetting still sounds useful to me. Just don't go to deep into it.
Michiel
Dan Mosedale
> Hi,
>
> with all the comments below I don't think that the personae approach is
> a useful tool in order to find (or define?) a target audience.
> Especially if we would use it to decide if a certain feature should be
> implemented or not. This decision would be based on no reasonable data
> at all but on what we think a user might probably want.
It sounds to me like you're objecting to a concern that Mike voiced in
the posting you quoted:
>> The discussion in creating these is indeed useful for exploring the
>> edges, but without basing it on some sort of demographic or primary
>> reserach data, all you're doing is dressing up your assertions and
>> making them seem more real. In a project such as this -- where funding
>> is scarce and time is short -- I think there are several good
>> assumptions and assertions that we can base this stuff on. The key is
>> to make sure we *declare* the assertions and our relative confidence
>> level in them. That way, should time or opportunity arise to validate,
>> we can go after our least secure assumptions first.
In particular, it seems like your objection is to the fact that we don't
currently have data to back up our assertions, not to the personae model
itself.
> Our goal should be to build an application that can be used by end-users
> and enterprise users with the same satisfaction.
So if I'm understanding your objection correctly (am I?), it seems to me
that you've simply replaced the model with a couple of much more general
assertions, and not actually addressed the lack-of-data issue at all.
The model here is merely a way of framing/expressing our combination of
assertions and/or data. And, indeed, the more data that we can get to
back up our assertions, the better. But that's likely to be the case
regardless of whether we go with the personae model or not.
> The biggest concerns against enterprise features like inviting people is
> that it might clutter the UI and confuse the user who has no need for
> it. Wouldn't it be useful to discuss those features step-by-step and see
> if the UI should be simplified or not ?
Yes, clearly. However, the idea is that having these discussions is
likely to be significantly easier if we can make statements along the
lines of "this feature is likely to be used by all of our model users",
or "users A, B, and D are likely to want this feature a lot; users C & E
will probably never use it; user F is likely to want it occasionally."
> Sorry, but I have the feeling that the personae discussion does not
> provide any help in reaching the goal to come up with a useful road map
> towards Lightning 1.0, which I still hope can be shipped in the not too
> distant future.
The concept here is that we need to have a good framework to understand
how any given user is likely to want to use their calendar. That is,
what set of tasks that user is likely to do most frequently and in what
context. Nailing down a specific set of personae seems like it would
make it easier to construct an idea of which tasks are most common to
the largest set of users, which, in turn, I would expect to help us
decide both how features should best be exposed as well as their
relative priorities.
Dan
Matthias Schäfer
Till now I just followed this thread silently.
But let me contribute one quite simple (possible) solution to this:
As I understood your thoughts you think more or less about two groups of
users: "professionals" and "amateurs". Which of your "Personae" belongs
to which group should be not so hard to associate. (If you would need
more than two groups read below)
In my (maybe poor) opinion this two groups distinguish in their
different needs on the UI. The pro will need many features that are
easily accessible from the UI. The amateur maybe will be disturbed or
even confused by too many available options.
If you define a global preference like "simple/advanced" you can give
the user the choice what he wants to see on his UI and what meets his
needs. So the simple option can just hide same not very common used
points from the UI e.g. Attendees, URL, Timezones,.. or even total sub
menus (from the Edit dialog) while advanced shows the full dialog.
The default setting probably should be simple. A user who needs the
advanced features should be able to find the switch and turn this option
on ;-)
I'm sure you will get user feedback if the users think you disabled a
key feature in the simple view or you activated one that nearly never is
needed or so on. This concept will evolve!
This model can be extended easily to lets say three or even more groups
if necessary.
I know this can only cover the UI concerning part of this topic and will
not solve the priority problem.
Hopefully I have not stolen your precious time. Go on with your great
work on Sunbird/Lightning. Many Thanks!
Best regards
Matthias
Dan Mosedale schrieb:
Joey Minta
> If you define a global preference like "simple/advanced" you can give
> the user the choice what he wants to see on his UI and what meets his
> needs. So the simple option can just hide same not very common used
> points from the UI e.g. Attendees, URL, Timezones,.. or even total sub
> menus (from the Edit dialog) while advanced shows the full dialog.
> The default setting probably should be simple. A user who needs the
> advanced features should be able to find the switch and turn this option
> on ;-)
underlie it. That being said, you're certainly not alone in proposing
it, so we'll see. Some potential issues that I see arising are:
1.) It's entirely possible that the set of features for one set of users
would be ready prior to the set of features for another. Should we hold
back that version since 'toggling the pref' is not ready? Why should
those users be forced to wait?
2.) Limited resources. Splitting 'advanced' and 'simple' features
forces our developers to split there time working on these different
sets too. This means that it will take us longer to reach a
high-quality product for either set.
3.) Additional testing. Splitting these features puts an incredible
strain on our QA folks. They have to test both these options, as well
as the myriad of different interactions between them. The end result is
an increase in complexity that is greater than merely additive.
'Expanding to additional groups' magnifies this problem.
4.) I think creating 2 groups is opening the door to problems. Very few
people will fall perfectly into those groups. Instead, I think taking
advantage of the mozilla extension system is the way to allow all users
to customize their desired level of complexity/features.
-Joey
Stephan Schaefer
> I think the discussion so far has shown that there are other markets
> then just the enterprise with big servers and everything. So the
> discussion did have some use.
Yes, but regarding basic calendaring functionality it seems a little bit
too ambitious to distinguish between multiple end-user groups on the way
towards 1.0. If we start checking for every feature if it suits the
needs of all the potential imaginary users (which we do not know
personally) we will have severe difficulties to come to an end. This is
why I would like to concentrate on the two canonical groups we
determined quite early: corporate users and end users.
> To discuss those features, you need to define them first. Having an idea
> of who your users are will be helpful in doing that.
That's exactly what the Lightning 1.0 Roadmap thread was about, and it
would be great if we could continue discussing the proposed features
there or on corresponding wiki pages. Matching those proposals to too
many groups will be difficult if not impossible and we might end up with
no useful conclusion. That's why I would like to stick to only two
rather simple groups in order to reach consensus for 1.0. Once those
features are in we are free to refine them by taking real user input
into account.
> Also, there are features which have overlap between the different user
> groups. For example, inviting somebody to an event. For the enterprise
> user, that might mean actually putting an item in somebody else's
> calendar. For the home-user, it might be sending out an imip invitation.
> Have two separate UI elements for that seems bad.
>
That's exactly the kind of discussion I would like to see: Pick a
requirement (inviting people), propose an implementation (certain
controls in the event dialog) and see if it conflicts with any of the
two(?) user groups. In this special case there is no conflict at all!
Depending on the invitee's calendar an imip invitation will be send or
the corresponding server where the invtee's calendar is stored will
handle the invitation. There is no difference in the UI, everything will
happen under the hood.
>> Sorry, but I have the feeling that the personae discussion does not
>> provide any help in reaching the goal to come up with a useful road
>> map towards Lightning 1.0, which I still hope can be shipped in the
>> not too distant future.
>
> I partly agree. But we need some discussion about the product
> definition. See also the raison d'etre post. Defining the users-groups
> you are targetting still sounds useful to me. Just don't go to deep into
> it.
Exactly. Please stick to simple groups and let's come to conclusions
regarding our road map. We should not strive to be too innovative for
the first release. Let's do the basics first.
Stephan
Stephan Schaefer
>
> In particular, it seems like your objection is to the fact that we don't
> currently have data to back up our assertions, not to the personae model
> itself.
>
Well, if the preconditions are wrong the conclusions will be arbitrary.
And because it is so easy to define personas and assign them
characteristics you had in mind anyway I see it as a drawback of the
whole model.
Again, Christian has a proper knowledge in that area and can probably
give more input on that.
>> Our goal should be to build an application that can be used by
>> end-users and enterprise users with the same satisfaction.
>
> So if I'm understanding your objection correctly (am I?), it seems to me
> that you've simply replaced the model with a couple of much more general
> assertions, and not actually addressed the lack-of-data issue at all.
>
Before contributing to this project we talked to our users and customers
to get an idea what they would expect from a PIM application. From
direct feedback, discussions, and email replies we compiled a list of
requirements and grouped them into feature areas that I posted a while
ago in the Lightning 1.0 Roadmap thread. So, those features are based on
real data. Now its up to us to decide how we want to offer those
features in the most user friendly way but the features itself are
either obvious (basic functionality) or at least often requested
(offline use, stability, performance).
So I would like to come back to our plan of putting the proposed feature
areas on their own pages and see if we can agree on them step-by-step
and start implementing it.
>> The biggest concerns against enterprise features like inviting people
>> is that it might clutter the UI and confuse the user who has no need
>> for it. Wouldn't it be useful to discuss those features step-by-step
>> and see if the UI should be simplified or not ?
>
> Yes, clearly. However, the idea is that having these discussions is
> likely to be significantly easier if we can make statements along the
> lines of "this feature is likely to be used by all of our model users",
> or "users A, B, and D are likely to want this feature a lot; users C & E
> will probably never use it; user F is likely to want it occasionally."
>
As I said in an earlier posting discussions like this bear the risk of
not coming to a useful conclusion. Making it right for 5 parties is much
more difficult than concentrating on only 2. Just multiply the number of
imaginary users with the number of people discussing here. It just does
not scale.
>> Sorry, but I have the feeling that the personae discussion does not
>> provide any help in reaching the goal to come up with a useful road
>> map towards Lightning 1.0, which I still hope can be shipped in the
>> not too distant future.
>
> The concept here is that we need to have a good framework to understand
> how any given user is likely to want to use their calendar. That is,
> what set of tasks that user is likely to do most frequently and in what
> context. Nailing down a specific set of personae seems like it would
> make it easier to construct an idea of which tasks are most common to
> the largest set of users, which, in turn, I would expect to help us
> decide both how features should best be exposed as well as their
> relative priorities.
Without having those users at hand I don't see this as a useful approach.
Stephan
Matthias Schäfer
Joey Minta schrieb:
> Matthias Schäfer wrote:
>> If you define a global preference like "simple/advanced" you can
give the user the choice what he wants to see on his UI and what meets
his needs. So the simple option can just hide same not very common used
points from the UI e.g. Attendees, URL, Timezones,.. or even total sub
menus (from the Edit dialog) while advanced shows the full dialog.
>> The default setting probably should be simple. A user who needs the
advanced features should be able to find the switch and turn this option
on ;-)
> I think this 'simple' solution hides a lot of the gory details that
may underlie it. That being said, you're certainly not alone in
proposing it, so we'll see. Some potential issues that I see arising are:
> 1.) It's entirely possible that the set of features for one set of
users would be ready prior to the set of features for another. Should
we hold back that version since 'toggling the pref' is not ready? Why
should those users be forced to wait?
I do not get the point!
I was just talking about the GUI implementation! This could e.g. meen
Event/Task dialog, Calendar selection pane with flat/foldered structure,
printing options, even visible "preferences" in the Settings dialog, ...
I would ship all features that are available. Just make a decision
whether they are so important that they should be visible for every user
or (visibility) should be switched on for advanced users only.
In my opinion it is normal, that not all feature sets will be available
at the same time. Something that is not jet available could be grayed
out in its corresponding view.
> 2.) Limited resources. Splitting 'advanced' and 'simple' features
forces our developers to split there time working on these different
sets too. This means that it will take us longer to reach a
high-quality product for either set.
That is not what I wanted to say!
I think it should not be a big problem to hide available features from
the GUI (similar to the more/less button in the current event dialog but
with this "unvisible" global pref) if they are not important for the
simple user!
> 3.) Additional testing. Splitting these features puts an incredible
strain on our QA folks. They have to test both these options, as well
as the myriad of different interactions between them. The end result is
an increase in complexity that is greater than merely additive.
'Expanding to additional groups' magnifies this problem.
I suggest not to split the features but only their appearance, what
should not be such a big problem. Means that you just hide away features
from the simple user that he will not use. For example you can right now
create an event without seeing the recurrence or attendees tab! There
are no different feature sets!
> 4.) I think creating 2 groups is opening the door to problems. Very
few people will fall perfectly into those groups. Instead, I think
taking advantage of the mozilla extension system is the way to allow all
users to customize their desired level of complexity/features.
Maybe two is enough for the beginning. Later you can refine this in e.g.
simple/advanced/pro.
I hope I could make it more clearly, what I wanted to say.
Best regards
Matthias
>
> -Joey
>
>
>>
>> I'm sure you will get user feedback if the users think you disabled
a key feature in the simple view or you activated one that nearly never
is needed or so on. This concept will evolve!
>>
>> This model can be extended easily to lets say three or even more
groups if necessary.
>>
>> I know this can only cover the UI concerning part of this topic and
will not solve the priority problem.
Joey Minta
things from an 'end-state' point of view, while I'm talking about things
from a methods approach (How do we get there?) If we already had all
these features, then your approach might work. However, we do not.
They need to be written, tested, reviewed, etc. This is where the
difficulty arises.
-Joey
[rest of quote trimmed]
Joey Minta
> Hi Dan,
>
>>> Our goal should be to build an application that can be used by
>>> end-users and enterprise users with the same satisfaction.
>>
>> So if I'm understanding your objection correctly (am I?), it seems to
>> me that you've simply replaced the model with a couple of much more
>> general assertions, and not actually addressed the lack-of-data issue
>> at all.
>>
>
> Before contributing to this project we talked to our users and customers
> to get an idea what they would expect from a PIM application.
striving to be.
From
> direct feedback, discussions, and email replies we compiled a list of
> requirements and grouped them into feature areas that I posted a while
> ago in the Lightning 1.0 Roadmap thread. So, those features are based on
> real data. Now its up to us to decide how we want to offer those
> features in the most user friendly way but the features itself are
> either obvious (basic functionality) or at least often requested
> (offline use, stability, performance).
> So I would like to come back to our plan of putting the proposed feature
> areas on their own pages and see if we can agree on them step-by-step
> and start implementing it.
I'm a bit concerned that there seems to be an implication here that
these features all need to be included. The discussion here about
imaginary users is useful because it's likely to show us which of those
features aren't really essential to the audience we want to target.
I think we have these users 'at hand' to some useful extent. Whether
via the forums, bugzilla, etc, we've already got a decent idea of the
kinds of things that people are looking for in a calendaring application
I think. We may not have perfect reports, but I don't think we're
completely fumbling around in the dark.
-Joey
Stephan Schaefer
>> customers to get an idea what they would expect from a PIM application.
> Since when are we a PIM? I wasn't aware that this was what we were
> striving to be.
What's wrong with PIM ? The good point is that email is already done, so
we can concentrate on the calendaring aspects.
> From
>> direct feedback, discussions, and email replies we compiled a list of
>> requirements and grouped them into feature areas that I posted a while
>> ago in the Lightning 1.0 Roadmap thread. So, those features are based
>> on real data. Now its up to us to decide how we want to offer those
>> features in the most user friendly way but the features itself are
>> either obvious (basic functionality) or at least often requested
>> (offline use, stability, performance).
>> So I would like to come back to our plan of putting the proposed
>> feature areas on their own pages and see if we can agree on them
>> step-by-step and start implementing it.
> I'm a bit concerned that there seems to be an implication here that
> these features all need to be included. The discussion here about
> imaginary users is useful because it's likely to show us which of those
> features aren't really essential to the audience we want to target.
Yes, we're definitely sure that these features have to be implemented,
because this is what real users told us. Imaginary users can only tell
you what you already know and will then be used to emphasize your
personal opinion.
>>
>> Without having those users at hand I don't see this as a useful approach.
> I think we have these users 'at hand' to some useful extent. Whether
> via the forums, bugzilla, etc, we've already got a decent idea of the
> kinds of things that people are looking for in a calendaring application
> I think. We may not have perfect reports, but I don't think we're
> completely fumbling around in the dark.
>
Hmm, so you found out by reading bug reports and forum posts how many
minutes per day a CEO is doing calendaring tasks ? And then you are
going to base a decision if and how a certain feature will be
implemented on those findings ? I'm definitely not convinced by this method.
Stephan
Christian Jansen
Hi,
I support the idea of creating imaginary users because they can help us
to determine what a product should do and how it should behave. These
personas could help us to keep the design centered on the users.
And they resolve three user-centered design issues that might arise
during the development of Lightning.
* The elastic user
* Self-referral design
* Design of edge cases
But Personas need to be based on research. Gathered from real world
observations especially ethnographic interviews and contextual inquiries.
It is a fact that quality of the data gathered directly impacts the
efficacy of personas in directing design solutions. Collecting these
data 30 - 50 interviews are recommended are a long time process.
Before we can start doing interviews we should agree on the target
group. This is a thing which need to be defined by us. Just because the
user will not tell us what he misses or he needs.
As we haven't the resources for creating (on research based) personas I
suggest to create User Scenarios instead. User Scenarios are light weight.
A user scenario could be for example:
Peter and Mary are exchanging documents fairly often by email. Mary
rates it a lazy attitude of Peter that he does not send his documents in
a cleaned up fashion. She always has to scroll to the top before she can
start editing her part of the document.
Peter himself likes the property that a document remembers the position
where he was last editing.
- Christian
Michiel van Leeuwen
> But let me contribute one quite simple (possible) solution to this:
> As I understood your thoughts you think more or less about two groups of
> users: "professionals" and "amateurs". Which of your "Personae" belongs
> to which group should be not so hard to associate.
No, that are the wrong groups. For most professionals, interacting with
their calendar is not their primary job. For most, the computer is a
tool that should just work. They are not more able to work with computer
applications then home users. Because they are the _same people_. After
they stop working and go home, they don't suddenly forget all they know.
And when the leave home to go to work, the don't suddenly get a whole
lot more knowledge about how to work with some random tool (in this
case, a computer application)
> If you define a global preference like "simple/advanced" you can give
> the user the choice what he wants to see on his UI and what meets his
> needs. So the simple option can just hide same not very common used
> points from the UI e.g. Attendees, URL, Timezones,.. or even total sub
> menus (from the Edit dialog) while advanced shows the full dialog.
> The default setting probably should be simple. A user who needs the
> advanced features should be able to find the switch and turn this option
> on ;-)
All I can think when somebody proposes this is: NO, NO, NO!!! prefs are
bad. real bad. We shouldn't add the complex code for just a very small
part of the users. The app should just work. And if it work for most
users, it will also work for those that think they are advanced users.
Michiel
Joey Minta
>>> Before contributing to this project we talked to our users and
>>> customers to get an idea what they would expect from a PIM application.
>> Since when are we a PIM? I wasn't aware that this was what we were
>> striving to be.
>
> What's wrong with PIM ? The good point is that email is already done, so
> we can concentrate on the calendaring aspects.
just never heard lightning and/or sunbird placed in this category. Nor
had I heard the term mentioned in any of our planning, so I found it a
bit striking. It's not clear to me if using 'PIM' would result in any
difference in the decision making/development process.
>
>> From
>>> direct feedback, discussions, and email replies we compiled a list of
>>> requirements and grouped them into feature areas that I posted a
>>> while ago in the Lightning 1.0 Roadmap thread. So, those features are
>>> based on real data. Now its up to us to decide how we want to offer
>>> those features in the most user friendly way but the features itself
>>> are either obvious (basic functionality) or at least often requested
>>> (offline use, stability, performance).
>>> So I would like to come back to our plan of putting the proposed
>>> feature areas on their own pages and see if we can agree on them
>>> step-by-step and start implementing it.
>> I'm a bit concerned that there seems to be an implication here that
>> these features all need to be included. The discussion here about
>> imaginary users is useful because it's likely to show us which of
>> those features aren't really essential to the audience we want to target.
>
>
> Yes, we're definitely sure that these features have to be implemented,
> because this is what real users told us. Imaginary users can only tell
> you what you already know and will then be used to emphasize your
> personal opinion.
Real users tell Firefox and Thunderbird that they *need* features all
the time but still get those bugs marked WONTFIX. This is usually a
good thing, because most of the time the feature is either a need not
shared by the majority of users, or worse, satisfying the need would
harm the majority of users. It's precisely these kinds of features that
I'm arguing against. I haven't seen an evaluation of these proposed
features in that context.
>
>
>>>
>>> Without having those users at hand I don't see this as a useful
>>> approach.
>> I think we have these users 'at hand' to some useful extent. Whether
>> via the forums, bugzilla, etc, we've already got a decent idea of the
>> kinds of things that people are looking for in a calendaring
>> application I think. We may not have perfect reports, but I don't
>> think we're completely fumbling around in the dark.
>>
>
> Hmm, so you found out by reading bug reports and forum posts how many
> minutes per day a CEO is doing calendaring tasks ? And then you are
> going to base a decision if and how a certain feature will be
> implemented on those findings ? I'm definitely not convinced by this
> method.
(Ignoring the sarcasm) No, I intuited this by looking at the bugs
filed, the tasks people say they're trying to accomplish, and the
feedback they give on the current state of affairs. No one has ever
filed a bug about eye-strain or fatigue related to Sunbird/Lightning,
which means that most users don't use the program for the majority of
their day.
-Joey
Matthias Schäfer
Michiel van Leeuwen schrieb:
> Matthias Schäfer wrote:
>> But let me contribute one quite simple (possible) solution to this:
>> As I understood your thoughts you think more or less about two groups
>> of users: "professionals" and "amateurs". Which of your "Personae"
>> belongs to which group should be not so hard to associate.
>
> No, that are the wrong groups. For most professionals, interacting with
> their calendar is not their primary job. For most, the computer is a
> tool that should just work. They are not more able to work with computer
> applications then home users. Because they are the _same people_. After
> they stop working and go home, they don't suddenly forget all they know.
> And when the leave home to go to work, the don't suddenly get a whole
> lot more knowledge about how to work with some random tool (in this
> case, a computer application)
Sorry, if I choose the wrong words!
If I used the word "professional" I was not thinking of a person who is
payed for working with computers. That was my fault! Sorry about this!
If I used the words professional and amateur I thought of some kind of
experienced user that uses the tool computer and knows how to use in
opposite to the person that tries to use a computer but only knows how
to do simple things. I think (my personal opinion) that there are at
least two types of users (perhaps there is a intermediate type but see
it as a first approximation). The first group will be glad to have some
choice to decide how the computer helps to solve a problem and the
second (extremal) group is maybe not even aware of this problem or
possibility and will only be confused by the possible choice (e.g. some
additional button, option,...)
Remember: I was just talking about the representation on the GUI, not
the function itself!!!
My intention was to have the possibility to have a simple, nice looking
GUI for people that are not aware that something is missing and if you
switch to the other mode (because you need it) the program will provide
you with all the available features and special functions!
The program should be easy enough to let "grandma" make a simple
reminder for a appointment with just date and time while let an other
person invite some people in different timezones in dependency of their
free/busy to a meeting or so (a feature that grandma will never need -
and if she possibly evolves so, I would no more call her "grandma")!
>> If you define a global preference like "simple/advanced" you can give
>> the user the choice what he wants to see on his UI and what meets his
>> needs. So the simple option can just hide same not very common used
>> points from the UI e.g. Attendees, URL, Timezones,.. or even total sub
>> menus (from the Edit dialog) while advanced shows the full dialog.
>> The default setting probably should be simple. A user who needs the
>> advanced features should be able to find the switch and turn this
>> option on ;-)
>
> All I can think when somebody proposes this is: NO, NO, NO!!! prefs are
> bad. real bad.
Why are Prefs bad? Ok, its your opinion but they are not bad "per se"!
A knife is not bad, even if you can kill people with it! Not the Prefs
are bad - perhaps their usage!!!
> We shouldn't add the complex code for just a very small
> part of the users. The app should just work. And if it work for most
> users, it will also work for those that think they are advanced users.
I would not call them a small part, I would call them more than half!!!
I was just talking of the users that may be confused by to many options
of a "mature" piece of software (to what Sunbird/Lightning hopefully
evolves) like "Grandma"! I only wanted to show a possibility how Grandma
and the CEO of a company could be satisfied both by the same software
(hopefully Mozilla and not Microsoft!!!). And this has been both
possible users in this thread but with totally different needs and
expectations.
I know, I was talking about future! But you need a target!!!
And once more - I did not want to solve the problem "which feature to
implement first" but to show, that the needs of a CEO (as defined in
this thread) will not necessarily conflict with Grandmas needs if you
give the user the choice whether he is Grandma or CEO!!!
Because I had the impression that some people in this discussion argue
like: "we can not implement because it will look to complicated..."
Excuse me if I said something wrong!!!
Matthias
>
>
> Michiel
Dan Mosedale
> Stephan Schaefer wrote:
>>>> Before contributing to this project we talked to our users and
>>>> customers to get an idea what they would expect from a PIM application.
>>> Since when are we a PIM? I wasn't aware that this was what we were
>>> striving to be.
>>
>> What's wrong with PIM ? The good point is that email is already done,
>> so we can concentrate on the calendaring aspects.
> I don't know if there's anything *wrong* with PIMs in principle, I had
> just never heard lightning and/or sunbird placed in this category. Nor
> had I heard the term mentioned in any of our planning, so I found it a
> bit striking. It's not clear to me if using 'PIM' would result in any
> difference in the decision making/development process.
One of the areas that didn't get too much discussion on the phone
meeting is that this is where the product definitions of Lightning and
Sunbird may differ somewhat. Lightning leans more in this direction,
since today it's especially tailored to run in an app that already
manages email and addressbooks. If we can agree on the goals we have
for the product, I don't know if spending too much time worrying about
whether it's a 'PIM' or not is necessarily going to buy us a lot, but
perhaps I'm wrong about that.
>> Yes, we're definitely sure that these features have to be implemented,
>> because this is what real users told us. Imaginary users can only tell
>> you what you already know and will then be used to emphasize your
>> personal opinion.
>
> Real users tell Firefox and Thunderbird that they *need* features all
> the time but still get those bugs marked WONTFIX. This is usually a
> good thing, because most of the time the feature is either a need not
> shared by the majority of users, or worse, satisfying the need would
> harm the majority of users. It's precisely these kinds of features that
> I'm arguing against. I haven't seen an evaluation of these proposed
> features in that context.
One of the things we learned while producing the suite is that there is
some set of users who will say they want any given feature that you can
think of, even features that are in direct opposition to each other
("let's add another pref!"). One of the reasons for this is that users
are often are not good at differentiating between "it should be easy for
me to invite people to events" and "there should be an attendee tab in
the event dialog" - desired features are often coached in terms of
what's been seen in the past, regardless of whether that makes sense
given the current overall design and goals. So I'm strongly in
agreement that we need to evaluate each feature in terms of the bigger
picture tasks and goals.
>>>> Without having those users at hand I don't see this as a useful
>>>> approach.
>>> I think we have these users 'at hand' to some useful extent. Whether
>>> via the forums, bugzilla, etc, we've already got a decent idea of the
>>> kinds of things that people are looking for in a calendaring
>>> application I think. We may not have perfect reports, but I don't
>>> think we're completely fumbling around in the dark.
I agree both that we're not in a position to do all the research that
might given more resources, and that we're also not completely in the
dark. The high-level question, it seems to me, is what model (personae,
user scenarios, ...) is likely to give us the most bang for our buck
(developers, designers, ship dates, etc) in the face of partial
information. Given the success of Firefox, I'm inclined to speculate
that we're likely to be able to do noticeably better with some sort of
model other than "list of features". That said, I'm sure we'll still
make plenty of mistakes. I'd be very interested in hearing other
opinions on this, especially mconnor's, since he's been involved with
Firefox for quite some time.
Dan
Dan Mosedale
>
> As we haven't the resources for creating (on research based) personas I
> suggest to create User Scenarios instead. User Scenarios are light weight.
>
> A user scenario could be for example:
>
> Peter and Mary are exchanging documents fairly often by email. Mary
> rates it a lazy attitude of Peter that he does not send his documents in
> a cleaned up fashion. She always has to scroll to the top before she can
> start editing her part of the document.
> Peter himself likes the property that a document remembers the position
> where he was last editing.
This sounds like it's got good potential. Do you have any URLs to
recommended reading about these? What sort of difficulties are likely
to crop up in picking a set of user scenarios without having a
relatively specific list of imaginary users that one is willing to base
them on?
Dan
Dan Mosedale
> Yes, but regarding basic calendaring functionality it seems a little bit
> too ambitious to distinguish between multiple end-user groups on the way
> towards 1.0. If we start checking for every feature if it suits the
> needs of all the potential imaginary users (which we do not know
> personally) we will have severe difficulties to come to an end. This is
> why I would like to concentrate on the two canonical groups we
> determined quite early: corporate users and end users.
You make a good point that the more needs we try and address, the more
complex we make it. However, it strikes me that having "corporate
users" and "end users" as our target groups doesn't actually reduce the
set of needs we're trying to address, but instead masks the complexity.
As an example, "corporate users" sounds to me like it includes the needs
of people at large companies, which seems to me likely to be a superset
of the needs of people at small organizations of any sort. Large
companies typically have a whole bunch of conference rooms, and
resources like audio-visual equipment that need to be booked.
Organizations with just a few people generally have no such need.
So I guess I'd argue that (at least some) more specificity now will
allow us to make better decisions about which features really are common
to most or all of our users, which in turn should help us prioritize.
> Exactly. Please stick to simple groups and let's come to conclusions
> regarding our road map. We should not strive to be too innovative for
> the first release. Let's do the basics first.
Completely agree on the innovation front. Even assuming that innovation
is part of our road map (which I would vote for), innovation doesn't
help much if we don't at least get the majority of the basics right. I
suspect one or two key innovations (hCalendar?) would be likely to go a
long way.
Dan
Dan Mosedale
>
> As I said in an earlier posting discussions like this bear the risk of
> not coming to a useful conclusion.
This is, indeed, a danger. The way this has been solved in Thunderbird
and Firefox has been with strong, careful UI ownership by one or a few
people. Discussion is encouraged up to a point, but there are still
deadlines, and as the deadlines approach the UI owner makes the final
decisions. The ownership stuff I've been working on (and haven't yet
posted; apologies!) has been mostly related to code ownership; how we
deal with UI ownership in Sunbird & Lightning is open for discussion.
Dan
Stephan Schaefer
>
> You make a good point that the more needs we try and address, the more
> complex we make it. However, it strikes me that having "corporate
> users" and "end users" as our target groups doesn't actually reduce the
> set of needs we're trying to address, but instead masks the complexity.
>
Well, of course. That's exactly the idea. If you have so many groups
that you cannot make it right for everybody you have to choose an
hierarchical approach and reduce the complexity by collapsing or merging
the groups. The proposed personaes perfectly fit into two groups:
end-users: student / parent / grandparent
corporate users: small-to-medium business / large business / admin / CEO
May be you could shift the small business user into the end-user group
but it doesn't make much of a difference, especially if you have no idea
how many of your potential customers may fall into this group.
> As an example, "corporate users" sounds to me like it includes the needs
> of people at large companies, which seems to me likely to be a superset
> of the needs of people at small organizations of any sort. Large
> companies typically have a whole bunch of conference rooms, and
> resources like audio-visual equipment that need to be booked.
> Organizations with just a few people generally have no such need.
That's a good example. Booking of resources is an important requirement
for corporate users especially those used to outlook. Technically there
is only a small difference between a user and a resource. Users get
invited and may confirm or decline even if conflicts would arise.
Resources can do this automatically. They are either booked or not. This
feature is typically implemented in the calendar server which means it
could be a feature that depends on the chosen server and its
capabilities. If the server provides this feature the corresponding
connector has to support it and the corresponding UI will be displayed.
If your server has no resource management you have to create a dummy
user that represents the resource and you have to use the standard UI.
Large companies will tend to use servers with resource management while
smaller companies might choose the dummy user approach.
As a result the feature 'resource planning' can be implemented and will
only show up where it is useful.
> So I guess I'd argue that (at least some) more specificity now will
> allow us to make better decisions about which features really are common
> to most or all of our users, which in turn should help us prioritize.
>
That's correct. But it requires that you know the size of the individual
groups. If you choose a higher level in the hierarchy it's a lot
simpler. You could even assume that both of those groups are of equal size.
Sorry that I insist, but it's really all about complexity. We neither
have the knowledge nor the resources to reliably base our feature
decisions on 7 different user groups.
>> Exactly. Please stick to simple groups and let's come to conclusions
>> regarding our road map. We should not strive to be too innovative for
>> the first release. Let's do the basics first.
>
> Completely agree on the innovation front. Even assuming that innovation
> is part of our road map (which I would vote for), innovation doesn't
> help much if we don't at least get the majority of the basics right. I
> suspect one or two key innovations (hCalendar?) would be likely to go a
> long way.
I also would like to provide innovative features but this is really
difficult at this early stage. It may sound like sarcasm, but it is
meant seriously: have you tried to use the persona approach in order to
find a justification for supporting hCalendar ?
Regards
Stephan
Stephan Schaefer
> Stephan Schaefer wrote:
>>
>> As I said in an earlier posting discussions like this bear the risk of
>> not coming to a useful conclusion.
>
> This is, indeed, a danger. The way this has been solved in Thunderbird
> and Firefox has been with strong, careful UI ownership by one or a few
> people. Discussion is encouraged up to a point, but there are still
> deadlines, and as the deadlines approach the UI owner makes the final
> decisions.
This sounds like a useful approach and brings us back to the roadmap
discussion. What do we want to have achieved in 3-6-9 months from now
on. Having clear deadlines will help to make decisions.
> The ownership stuff I've been working on (and haven't yet
> posted; apologies!) has been mostly related to code ownership; how we
> deal with UI ownership in Sunbird & Lightning is open for discussion.
>
Wouldn't this be a useful agenda point for one of the next meetings ?
Stephan
Stephan Schaefer
>> so we can concentrate on the calendaring aspects.
> I don't know if there's anything *wrong* with PIMs in principle, I had
> just never heard lightning and/or sunbird placed in this category. Nor
> had I heard the term mentioned in any of our planning, so I found it a
> bit striking. It's not clear to me if using 'PIM' would result in any
> difference in the decision making/development process.
>
It's the big picture. If you have it in mind you can start thinking
about features that make use of the given environment. Invite people
from your address book, make appointments directly from emails, invite
all people from an email thread or a mailing list, sync
adresses/appointments to your pda,...
>> Yes, we're definitely sure that these features have to be implemented,
>> because this is what real users told us. Imaginary users can only tell
>> you what you already know and will then be used to emphasize your
>> personal opinion.
> Real users tell Firefox and Thunderbird that they *need* features all
> the time but still get those bugs marked WONTFIX. This is usually a
> good thing, because most of the time the feature is either a need not
> shared by the majority of users, or worse, satisfying the need would
> harm the majority of users. It's precisely these kinds of features that
> I'm arguing against. I haven't seen an evaluation of these proposed
> features in that context.
>
What features exactly do you have in mind here ? Is there any feature
where you think it is the opinion of only a single user ?
>>
>> Hmm, so you found out by reading bug reports and forum posts how many
>> minutes per day a CEO is doing calendaring tasks ? And then you are
>> going to base a decision if and how a certain feature will be
>> implemented on those findings ? I'm definitely not convinced by this
>> method.
> (Ignoring the sarcasm) No, I intuited this by looking at the bugs
> filed, the tasks people say they're trying to accomplish, and the
> feedback they give on the current state of affairs. No one has ever
> filed a bug about eye-strain or fatigue related to Sunbird/Lightning,
> which means that most users don't use the program for the majority of
> their day.
>
Sorry for the sarcasm, I just wanted to pick a prominent example in
order to express my doubts in this method. And it seems that this was
just confirmed again, because I cannot understand how you derived exact
usage times for 7 different user groups from the sheer lack of
eye-strain bugs.
Stephan
Michiel van Leeuwen
> Why are Prefs bad? Ok, its your opinion but they are not bad "per se"!
> A knife is not bad, even if you can kill people with it! Not the Prefs
> are bad - perhaps their usage!!!
In first approximation, prefs are bad :)
Sure, there not all prefs are bad. I would not oppose to a pref to allow
the user to set their timezone, by picking their city or country or
region form a list. But i would oppose to a pref that allows to set the
timezone by allowing them to enter the offset to UTC, when daylight
saving starts etc.
What's the difference? The second option seems to allow for more
flexibility. But it forces the user to solve a problem that the
developers already can solve. They don't have to know what their offset
to UTC is.
The point is that a pref forces a choice to be made by the user. If we
can avoid that, we should. In the case of picking the timezone from a
list, that choice will be different for all users. But for a lot of
other possible prefs, most users will pick the same. So we should just
not add them.
> I would not call them a small part, I would call them more than half!!!
> I was just talking of the users that may be confused by to many options
> of a "mature" piece of software (to what Sunbird/Lightning hopefully
> evolves) like "Grandma"! I only wanted to show a possibility how Grandma
> and the CEO of a company could be satisfied both by the same software
> (hopefully Mozilla and not Microsoft!!!).
This CEO usually is as confused by the option as a grandma is. So, we
should just not offer the options.
Michiel
Stephan Schaefer
> One of the areas that didn't get too much discussion on the phone
> meeting is that this is where the product definitions of Lightning and
> Sunbird may differ somewhat. Lightning leans more in this direction,
> since today it's especially tailored to run in an app that already
> manages email and addressbooks. If we can agree on the goals we have
> for the product, I don't know if spending too much time worrying about
> whether it's a 'PIM' or not is necessarily going to buy us a lot, but
> perhaps I'm wrong about that.
>
I also thought it would not make much of a difference until this
discussion came up. Somehow it seems to be an issue so I would like to
make my standpoint clear. I always regarded Lightning as part of a PIM
consisting of email and address book and may be synchronization
features. The tight integration in Thunderbird potentially opens up more
possibilities than a standalone app could offer. You do not have to care
about and check against multiple different email clients and address
books that may behave differently on the various platforms. For the user
this integration also makes sense as there is only one application that
manages all the data. You could argue that the suite started this way as
well but was broken up into the different apps as this was what the
users really wanted. I think that this does not necessarily apply to
calendaring as there seems to be a bigger difference between browsing
and email than between calendaring and email. The latter deals
exclusively with your own personal data while the former only uses the
same media.
That's the reason why our goal is to improve Lightning in order to have
an integrated solution for your personal emails, addresses, tasks,
schedules and appointments, or in other words a PIM.
> One of the things we learned while producing the suite is that there is
> some set of users who will say they want any given feature that you can
> think of, even features that are in direct opposition to each other
> ("let's add another pref!"). One of the reasons for this is that users
> are often are not good at differentiating between "it should be easy for
> me to invite people to events" and "there should be an attendee tab in
> the event dialog" - desired features are often coached in terms of
> what's been seen in the past, regardless of whether that makes sense
> given the current overall design and goals. So I'm strongly in
> agreement that we need to evaluate each feature in terms of the bigger
> picture tasks and goals.
>
Absolutely. And that's why it makes sense to collect requirements first
and not solutions. The requirement here is "possibility to invite
people" (I skipped the word 'easy' as this is ambiguous) and the
solution could be providing an attendee tab. So it is important to
listen to the users and collect the requirements first. The solutions
can be derived when you have the big picture about what should be in and
what not. This typically also requires prioritisation.
Stephan
Christian Jansen
"User and Task Analysis for Interface Design" [1]. If you want it a
little bit shorter http://www.jeanweber.com/howto/usecase.htm is also a
good resource.
- Christian
Dan Mosedale
>> So I guess I'd argue that (at least some) more specificity now will
>> allow us to make better decisions about which features really are
>> common to most or all of our users, which in turn should help us
>> prioritize.
>
> That's correct. But it requires that you know the size of the individual
> groups. If you choose a higher level in the hierarchy it's a lot
> simpler. You could even assume that both of those groups are of equal size.
For perfect results, it requires that you know the size of the group,
that's true. But it can help in other cases too. For example, if there
is stuff that is needed by all users of group scheduling (e.g.
attendees), that presumably needs to be higher on the list than stuff
that is only needed by some users of group scheduling (e.g. resources).
> Sorry that I insist, but it's really all about complexity. We neither
> have the knowledge nor the resources to reliably base our feature
> decisions on 7 different user groups.
While that's certainly plausible, it also strikes me as plausible that
masking the complexity of our users rather than taking an educated guess
may make our jobs harder instead of easier. I'd be very interested in
hearing from folks who have actually used this approach in the past.
(On that note, I've pinged a couple of our local UI wizards, and
hopefully they will get a few moments to shed a bit of light in here soon).
>> Completely agree on the innovation front. Even assuming that
>> innovation is part of our road map (which I would vote for),
>> innovation doesn't help much if we don't at least get the majority of
>> the basics right. I suspect one or two key innovations (hCalendar?)
>> would be likely to go a long way.
>
> I also would like to provide innovative features but this is really
> difficult at this early stage.
Agreed. The current draft of our proposed goal statement does not
specifically call out innovation, but instead speaks to making things
easier for the user. I think this is likely to help us by only
suggesting innovation if it's going to drive our the higher level goal
of helping the user.
> It may sound like sarcasm, but it is
> meant seriously: have you tried to use the persona approach in order to
> find a justification for supporting hCalendar ?
Not yet, since we haven't come to any sort of agreement on personae.
But I do think that would be a constructive thing to do. For example,
one use case I can imagine would involve subscribing to events on a web
page such as that posted by an entertainment venue. I suspect having a
list of users in hand would make it easier to think about how that model
could (or should) be generalizable in a way that's useful to the other
specific users. For example, a stay-at-home parent might be interested
in something similar for church events, which would seem to suggest that
the "entertainment venue" phrasing above is really too specific. If
Joey hadn't posted his list of proposed users, I doubt I would have ever
thought of this case.
Dan
Mike Beltzner
how things were going. This discussion seems to have gone down to gory
details, up to high level abstractions, then back down again. I think
everyone needs to take a breath, grab their copy of "Joel on
Software", and maybe flip through a summary of "The Inmates are
Running the Asylum", and return to first principles.
The goal of this discussion is to decide on what type of user you will
support, which will inform you as to what calendaring tasks are to be
considered primary and essential to a successful product. Abandon all
thought of "advanced" and "more >>" for the purposes of this
discussion; those things should be dealt with on an issue-by-issue
basis during the design phase. For now, keep it simple: who are you
building this product for, and what do you believe that person will
want to do with it?
I think that the best thing to do would be to pick *one* of the
personae listed above, and declare that persona the user you're
targeting. My gut says the right one is "Student" or "Small Business
Owner", since that seems to be where Thunderbird enjoys the majority
of its success, and running a home is an awful lot like running a
small business. Anyway. Pick one. Then pick another and call that your
"secondary" user.
Maybe the secondary user should be the corporate user. Many of the
contributors here are from corporations who have a vested and
expressed interest in having their environments supported. That's a
discussion for the module owners to have. My feeling is that
enterprise should follow non-enterprise use, since it's easier to add
server interop and scheduling feature goop than it is to design a
system which gracefully moves between enterprise and non-enterprise
tasks, and iterative design is always more successful than designs
that try to hit something out of the park on the first go. But maybe
that means people from Sun and Oracle get less interested in the
project. Pick your poison, but do so in a declarative fashion and
stick with it.
Once you've picked your target user and your secondary user, start
thinking of tasks. Better yet, go talk to users that fit those
personae. Ask them how they use their current calendaring solutions.
Ask them what bugs the shit out of them about their current
calendaring solutions. Ask them to picture utopia, and describe the
calendaring solution they see there. Better yet, go visit your users.
People lie, so observational research is always superior to survey and
interview reports. Sit at their desks, follow them around. Intuit does
this all the time, and I'm trying to build a program to do this for
Firefox as well. It's the best way to find those things that are
pissing your users off without them even realizing it.
Write a charter. It should include: who is it for, what does it want
to let them do, what are the principles of development, and what are
some basic criteria that must always be met. Make the criteria
quantifiable (download size, startup time, memory footprint, etc).
Make lists. Aggregate. Get people together to come up with FIVE THINGS
that you want your application to do well based on the lists of what
your users really want to do with their calendars, beyond the basics.
I'm talking things like "Send an email reminder to invitees", or "Find
a task in the task view". Five. No more. That's your first alpha,
right there. Make a list of the next five, and if you can get to them
for a second alpha, great.
Without this sort of focus, I fear that we'll continue to circle
around on these debates, where people are talking cross purposes and
not getting at the essence of the question, which again is: WHO is
this thing for, and WHAT will they want to do with it.
cheers,
mike
Dan Mosedale
>
> I think that the best thing to do would be to pick *one* of the
> personae listed above, and declare that persona the user you're
> targeting. My gut says the right one is "Student" or "Small Business
> Owner", since that seems to be where Thunderbird enjoys the majority
> of its success, and running a home is an awful lot like running a
> small business. Anyway. Pick one. Then pick another and call that your
> "secondary" user.
Mike and I spent some time talking about this yesterday, and we came to
the conclusion that it might work better to pick "Small Business Owner"
as the primary user and have "Student" as the secondary user. Here's
the thinking:
It seems likely that almost all small business owners are likely to use
a calendar relatively heavily, and additionally, are likely to exercise
a lot of interesting use cases. In particular, because they're in the
work force, they're likely to separate "personal" and "work" lives
somewhat more strictly than students. Because they tend to be a bit
older, they'd be more likely to have a spouse with whom they would need
to coordinate events. In addition to just calendaring, they're likely
to be interested in scheduling meetings with people both inside and
outside of their company. Additionally, they're likely to travel for
scheduled business trips occasionally exercising timezone and location
issues, rather than just vacations, which are often pretty free-form.
Lots of students don't use calendaring all that heavily, and those that
do may only use them for some of their functionality: eg just
calendaring, not scheduling or todo lists, and they may well only keep a
smaller number of key events in the calendar. This would seem to make a
better secondary user because it can help us ensure that it's still easy
for less-heavily-booked users to learn and work with.
Or at least, this is how I remember the conversation. Mike may want to
correct me here. Anyway, what are people's thoughts on this?
> Write a charter. It should include: who is it for, what does it want
> to let them do, what are the principles of development, and what are
> some basic criteria that must always be met. Make the criteria
> quantifiable (download size, startup time, memory footprint, etc).
Fortunately, we've got a rough draft of this already:
has the details. It still needs some polishing up and figuring out the
right quantifiable numbers. However, I think we've got enough consensus
now that using "that post + firefox charter" as a working document is
good enough for the moment. If someone else wants to drive the
polishing and posting of that sooner, however, I'd be happy to let them
take that piece of work off my plate.
> Make lists. Aggregate. Get people together to come up with FIVE THINGS
> that you want your application to do well based on the lists of what
> your users really want to do with their calendars, beyond the basics.
> I'm talking things like "Send an email reminder to invitees", or "Find
> a task in the task view". Five. No more. That's your first alpha,
> right there. Make a list of the next five, and if you can get to them
> for a second alpha, great.
I like this quite a bit, because it leads us from users -> product
definition -> roadmap.
> Without this sort of focus, I fear that we'll continue to circle
> around on these debates, where people are talking cross purposes and
> not getting at the essence of the question, which again is: WHO is
> this thing for, and WHAT will they want to do with it.
This does seem to be be the crux of the matter, and I appreciate your
taking the time to help us focus back in on it.
Dan
Stephan Schaefer
> Mike and I spent some time talking about this yesterday, and we came to
> the conclusion that it might work better to pick "Small Business Owner"
> as the primary user and have "Student" as the secondary user. Here's
> the thinking:
>
This sounds like a good compromise.
> It seems likely that almost all small business owners are likely to use
> a calendar relatively heavily, and additionally, are likely to exercise
> a lot of interesting use cases. In particular, because they're in the
> work force, they're likely to separate "personal" and "work" lives
> somewhat more strictly than students. Because they tend to be a bit
> older, they'd be more likely to have a spouse with whom they would need
> to coordinate events. In addition to just calendaring, they're likely
> to be interested in scheduling meetings with people both inside and
> outside of their company. Additionally, they're likely to travel for
> scheduled business trips occasionally exercising timezone and location
> issues, rather than just vacations, which are often pretty free-form.
>
I think it makes sense to choose those use cases as the primary ones as
they tend to be more feature rich or complex and will require more
discussion than basic features that are quite obvious. Giving them lower
priority would be in contrast to their required effort and will make
them more expensive than they need to be, just because they were not
considered right from the beginning.
> Lots of students don't use calendaring all that heavily, and those that
> do may only use them for some of their functionality: eg just
> calendaring, not scheduling or todo lists, and they may well only keep a
> smaller number of key events in the calendar. This would seem to make a
> better secondary user because it can help us ensure that it's still easy
> for less-heavily-booked users to learn and work with.
I fully agree.
>> Make lists. Aggregate. Get people together to come up with FIVE THINGS
>> that you want your application to do well based on the lists of what
>> your users really want to do with their calendars, beyond the basics.
>> I'm talking things like "Send an email reminder to invitees", or "Find
>> a task in the task view". Five. No more. That's your first alpha,
>> right there. Make a list of the next five, and if you can get to them
>> for a second alpha, great.
>
> I like this quite a bit, because it leads us from users -> product
> definition -> roadmap.
>
We started to compile such a list yesterday, based on a survey that
asked people about their primary calendaring tasks. Christian has the
details and is preparing a page with the outcome, open for discussion.
The idea is to start, as proposed, with the task and connect it to the
affected feature page(s). The feature page has all the details (eg
mini-month behaviour) and eventually points to the corresponding
bugzilla tasks. Does this sound reasonable ?
Stephan
Dan Mosedale
>> Mike Beltzner wrote:
>>> Make lists. Aggregate. Get people together to come up with FIVE THINGS
>>> that you want your application to do well based on the lists of what
>>> your users really want to do with their calendars, beyond the basics.
>>> I'm talking things like "Send an email reminder to invitees", or "Find
>>> a task in the task view". Five. No more. That's your first alpha,
>>> right there. Make a list of the next five, and if you can get to them
>>> for a second alpha, great.
>
> asked people about their primary calendaring tasks. Christian has the
> details and is preparing a page with the outcome, open for discussion.
> The idea is to start, as proposed, with the task and connect it to the
> affected feature page(s). The feature page has all the details (eg
> mini-month behaviour) and eventually points to the corresponding
> bugzilla tasks. Does this sound reasonable ?
Sounds sensible to me. I'd definitely be interested in seeing what sort
of data you've collected, and from what sorts of users. I'd still like
to hear from Joey and Michiel re their opinions on the revised target
user proposal before we go too far, though...
Dan
Dan Mosedale
> Hi Mike, hi everybody,
> As this is related to my daily business (I'm part of the
> OpenOffice.org/StarOffice User Experience Team) I would like to
> volunteer for this task. If this is ok for you, I would be pleased if
> somebody could review the first drafts of the characters.
>
I assume the task you're volunteering for is putting together more
detailed drafts about the users in question. If so, that sounds great
to me. That said, let's wait to hear back from Joey and Michiel about
the revised proposal before going ahead.
Dan
Joey Minta
Sorry, I thought I mentioned previously that I like this proposal and
have no problems with it.
-Joey
Christian Jansen
I've started publishing the page here:
http://wiki.mozilla.org/Calendar:Task_Feature_Matrix
It is still an early draft (I had some trouble to get the table into the
wiki. I'll fix the formatting glitches tomorrow)
What I did was to create to users and assign them sample use cases plus
feature areas which are needed to use for solving the task.
The ranking on the right hand side bases currently on first guesses. But
in long term these should be replaced by real data.
As always feedback is welcome. For tomorrow I plan to fill in the the gaps.
Regards,
Christian