Re: [Evolution-hackers] functional specification for list view

[Tim Lee <tim ximian com>]

Hi Anna,


On Wed, 2003-09-10 at 18:45, Anna Marie Dirks wrote: 
> Hi Tim,
> 
> On Tue, 2003-09-09 at 20:14, Tim Lee wrote:
> 
> > Would a meeting's status ( tentative vs. accepted vs. canceled ) be
> > displayed.
> 
> Well, it certainly *could* be.
> 
> A status column for all events might be nice now that you mention it (to
> let you know if an appointment has started, is finished, or what the
> status of a meeting is). 
> 
> Generally, I am wary of adding too many columns (to the default view,
> anyway) which are very specific to only one event type -- because the
> more you do this, the more the chance that half the columns shown are
> not related to half of your events.
> 
> You do still have the preview pane to in which to read all about the
> event in question - my preference for the default view is to keep the
> number of columns shown fairly small. (Because if the columns are too
> crowded to be easily read, then what is the point of this view?)
> 
I was actually just thinking of adding it as one of additional/optional
columns not as a default column.

> > Would all day events be differentiated from "normal" events? Would they
> > start at midnight?
> 
> My thought was that they (all day events) would start at the time that
> the user has selected as the start of his or her day.
> 
> We currently have a specific icon in the "new" button for "all day
> appointment". In my view, this icon is barely distinguishable from the
> icon for a standard appointment. We should get a better icon, and use
> that in the "Type" column to differentiate between appointment types.

> > Will people be allowed to add new events in this view? 
> 
> Of course. The gui elements that I listed as being needed were only
> those specific to this view; standard stuff like the "new" button was
> implied to exist. 
> 
I was thinking of some method specific to the list view. Currently you
can add events to the calendar directly in the views ( day/month/etc. )
without having to use the New button or the menu's. Also the default
Task view and Contact's phone list view allow you to add a new item by
typing directly into a special blank row at the head of the list. Was
just wondering if we were going have the same functionality in the
calendar list view to be consistent.

> > Will there be a way of showing meetings with conflicting/overlapping
> > times? I think this will be necessary if people are going to be able to
> > edit event times in the view.
> 
> There is no mechanism in the specification I provided for that.
> 
I was actually suggesting that this might be a useful additional
feature.

> > Under other columns I would add a meeting organizer column.
> 
> I have no objection to such a column per se -- again, my concern is that
> I really don't want to add many columns (to the default view) that only
> pertain to one type of event. 
> 
> 
Wasn't suggesting the column be added to the default view.

> > I think it might be useful to provide a means of filtering/viewing the
> > list by date/time. The simplest would be to filter events occurring
> > between two dates. For example only display events that occur on M-F
> > this week. Though more sophisticated filters might be useful ( events
> > ending after 5:00 PM, starting before 10:00 AM on Mondays, etc. ). 
> 
> These filters sound like "advanced searches" (done by using the search
> bar) to me. Is that what you intended? Would that suffice for your
> purpose? 
> 
I actually suggesting something more permanent than a search. I guess
what I was proposing might be thought of more like a vfolder for
calendars. I think the list view gives us the opportunity to treat
calendars as a more general "database" of events than the day/week/month
view paradigm allows. 

> > Other useful filters/views might include:
> > - meeting attendee(s)
> > - my/other attendee status
> > - meeting organizer
> 
> Again, when you say filters/views, do you mean "criteria that you could
> use to create a search using the search bar (or advanced search
> dialog)"? Or do you mean "columns that one could add to the list of
> events"?
> 
> I definitely don't think that columns for attendees and attendees
> statuses would work very well in this table -- simply because of the
> probablity that you would need to devote the whole width of the table to
> those columns in order to see all of the items within them. Those items
> seem much more suited to the view in the preview pane to me. 
> 
I wasn't suggesting adding columns for attendees.

> Now, your mail gives me the feeling that you use Evo's meeting
> scheduling functionality very often. What I think we should do is try to
> work together to write a usage scenario which is very meeting focused
> (see the other two usage scenarios I provided for examples). Then, we
> can analyze this spec in terms of that scenario. This gives us enough
> information to walk through the spec with a specific goal in mind, and
> see how and where it fails.
> 
Sure I'll try to write something up this weekend.

> 
> > Would events that have their time shown as Free vs. Busy be
> > differentiated?
> 
> Based on my current understand of how this view is likely to be used,
> I would probably not count this is important enough to have a column
> added for it by default.
> 
> Was there a specific usage case that you had in mind which would require
> this? It is how to weigh its importance in without one.
> 
All day events are created with the time shown as free by default. For
example in Outlook if you can select an option to add holidays to your
calendar. If a list view has more that a couple of calendars where
people have done that you could end up with a lot appointments that are
are free. Actually ettore suggested changing a color for row's where the
event's time is Free rather than adding a column.

> > Would the fields in the preview pane be editable? That might be a nice
> > feature, but how difficult would it be to implement?
> 
> I doubt that they would be editable. Someone else with more of a hacking
> perspective needs to comment on the feasibility of this. What I'd prefer
> to do is to slim down the event editor a bit so that the way it displays
> its events more resemebles the way the information is shown in the
> preview pane (as I provided it in the spec). 
> 
I agree that the event editor could use some improvement ( I have some
thoughts about that as well if you're interested ). I was just
suggesting this as a nice to have feature. Though if the editor comes to
resemble the preview panel closely enough, could it be used to preview
events as well? It would mean one less UI component people would have to
learn.

> Anna