Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Going forward with the prototype event dialog

0 views
Skip to first unread message

Michiel van Leeuwen

unread,
Jan 19, 2007, 5:52:50 PM1/19/07
to
Hi,

As you all likely know, there has been a new proposed event dialog in
the tree for some time new, as a prototype. This ask the question: what
to do with the prototype?
This has been discussed on irc in the last few days, and i'll try to
summarize the results.

- We think the dialog looks better then the current one used in base
sunbird and lightning
- Only exception is the attendees part. The UI has a big part reserved
for freebusy information. But that information is not needed (or not
even available) in a lot of cases. You only hae freebisy when you have a
wcap server, which most users have not. And then the information shown
is only needed when you schedule an event. It's not needed afterward,
when you just want to see who is coming. So there should be UI where you
see attendees, but not a whole lot of freebusy information
- We do want to give the code at least some review. But it is quite a
bit of code, so reviewing it all will be a task that nobody is willing
to do. Just too much work
- 'Cherrypicking' would be a solution: pick small pieces of the new
dialog and get that reviewed and used in the base dialog
- Need to identify the cherries we could pick. Too large, and the review
is just too much work. Too small, and the number of cherries means that
it will takes ages to pick all of them.

We came up with the a few cherries that seem to have a reasonable size.
But there is something to say about each of them
- attendees dialog: See above. The UI is complex and needs freebusy support
- alarm dialog: The dialog looks cluttered, and both dmose and me though
we were setting the properties of the alarm of the event, while we were
editing the possible custom alarm settings
- main layout: good but needs some issues resolved (more below)
- recurrence dialog: decent, but needs issues resolved in the code. One
thing that was obvious in the code was the double copy of the xul code
of the minimonth grid
- attachments UI: reasonable size, there is not much too it.

There is something more to say about the main dialog layout. We liked
the general look of it: less cluttered then the current dialog. The
menus provided a nice way to hide some of the less used features. But
they also have a usability problem on Mac. Apparently, it's not clear
that there is a menu. You don't expect one on a sheet.
The use of the menu and the toolbars is controversial. We are not sold
on the idea of using them. We do understand the idea to make it look
like a mail composition window, but it's not clear that it really looks
like it. After all, the mail window has one big document like part where
you write the actual mail. Not so in the event dialog. It has a lot of
small widgets, all being important.
In short: the dialog looks nice, but needs some thought and discussion.
Maybe we should only pick parts of it. For example, the addition of the
separator bars really help in reducing the visual clutter. A quick
experiment showed that they can clean up the current dialog, without
much code effort.


And finally, we discussed when to go forward with this. The idea was to
pick one or two of the above mentioned cherries for 0.5. Because we want
to have a 0.3.1, there is less rush to get 0.5 done, and we can add some
more UI features to it.
As you can see, there is no concrete plan yet. That's because the
discussion didn't reach a final conclusion yet. But we wanted to let you
all know what we have been talking about lately. We really do want to
make progress.


Michiel

Michiel van Leeuwen

unread,
Jan 22, 2007, 3:50:42 PM1/22/07
to
Michiel van Leeuwen wrote:
> We came up with the a few cherries that seem to have a reasonable size.

After looking a biut more at the code, I found another cherry: the
timezones part of it. From a quick look at the code, i think the
zonepicker wants to be reused from the preferences, so likely wants to
be xbl. But, for now, I think we can use it as plain xul, given that we
don't actually use the code somewhere else (it is no code duplication yet).
So, to me, this sounds like a good candidate for porting to the default
event dialog.

Michiel

Clint Talbert

unread,
Jan 23, 2007, 11:51:45 AM1/23/07
to
I will go through the prototype event dialog and the core dialog and
come up with a list later today. But in the meantime, I wanted to let
everyone know that I have opened up a bug on this effort (so I could
dupe another bug). That bug is: 367893.

Clint

0 new messages