324657 - Proposal for an improved Event Dialog

Status: RESOLVED FIXED

(Calendar :: Lightning Only, enhancement)

Description

[Christian Jansen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8) Gecko/20051111 Firefox/1.5

Hello,
I would like to propose to you a redesigned Events Dialog.
Goal of the design is to follow a workflow which is some kind similar to composing an e-mail. The attached mock-up shows rough sketches from the UI and explanations of the features & workflow. 

Thanks in advance for your valuable feedback
Christian

Reproducible: Always

Comment 1

[Christian Jansen]

Attachment: Mock-up of redesigned event dialog

Comment 2

[Christian Jansen]

ccs added

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

It seems to me that the next steps in our event dialog evolution are going to take a bunch of energy to sort out, in part because they are likely to depend on us more crisply articulating a couple of things.  Specifically: 1) who are our target users, exactly?  2) how do we want to segment our users and feature sets such that lightning and sunbird are effective tools for users who have different (and possibly conflicting) needs?

I have some ideas on what I think the answers to these questions should be, but since we've just landed one big iteration on the event dialog and we still have a bunch of work between now and 0.1, I would like to respectfully propose that we postpone this discussion until at least after 0.1 ships and after we've decided what sort of browser calendaring strategy we want to pursue (since that strategy may or may not Lightning to some degree).

Comment 4

[Michael Büttner (no reviews TFN)]

taking responsibility for this one...

Comment 5

[Joey Minta]

I second dmose's desire to post-pone this for a bit, in an effort to get 0.1 out the door.  I just wanted to jot down my thoughts on one of the main issues here, though, since I have a habit of forgetting them.

This is the second time I've seen an attempt to create an analogy between creating events and composing emails.  As a personal calendar user (resp. business user), this analogy doesn't make sense for me.  When I create an event, it's blocking out time (hence the strong focus on the datetime-picker's in the current dialog revision), it's not a social/communicative task.  Business users, on the other hand, probably do have this analogy more in mind, since they're most often scheduling meetings, which necessarily involve others.  Here the focus isn't on the time, but on the people.

This returns us to the target-audience question, and almost tend to lead towards two versions of the program, one for business users (with an email-analogy dialog) and one for personal users (with a time-centered dialog).

That's just my $.02.

(Oh, and events can start and end in different timezones (roadtrip!), so the tz picker probably needs to be associated with each the start and end timepicker, not just the event.)

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

Just a few footnotes in response to Joey, and then I'll be quiet on this topic until post 0.1.

(In reply to comment #5)
> I second dmose's desire to post-pone this for a bit, in an effort to get 0.1
> out the door.  I just wanted to jot down my thoughts on one of the main issues
> here, though, since I have a habit of forgetting them.
> 
> This is the second time I've seen an attempt to create an analogy between
> creating events and composing emails.  As a personal calendar user (resp.
> business user), this analogy doesn't make sense for me.  When I create an
> event, it's blocking out time (hence the strong focus on the datetime-picker's
> in the current dialog revision), it's not a social/communicative task. 
> Business users, on the other hand, probably do have this analogy more in mind,
> since they're most often scheduling meetings, which necessarily involve
> others.  Here the focus isn't on the time, but on the people.

One problem here is the lack of widely-deployed, interoperable Internet calendaring software.  In other words, one reason that business users are the main customers of this functionality now is that they're the only ones who have historically had access to it.  If CalConnect and others are successful at driving deployment of standards-based calendaring, this is likely to become a much more common activity.

> This returns us to the target-audience question, and almost tend to lead
> towards two versions of the program, one for business users (with an
> email-analogy dialog) and one for personal users (with a time-centered dialog)

I'm not sure I agree with this.  It seems to me that there is enough overlap in these particular two use cases that this is exactly the sort of problem that can be well-solved using the extension subsystem.

Comment 7

[Christian Jansen]

Hi all,
I've updated some of the designs.
I would like to talk (chat) about these designs in the week.

As always any feedback is welcome.

Thanks,
Christian

Comment 8

[Christian Jansen]

Attachment: Mocku-of of All Day & Attach File feature

Comment 9

[Christian Jansen]

Attachment: Mock-up of "Invite Attendees"

Comment 10

[Christian Jansen]

Attachment: Mock-up of Recurrence handling

Comment 11

[Christian Jansen]

Attachment: Mock-up of "Time Zones" dlg

Comment 12

[Joey Minta]

I much prefered the initial proposal to the changes that are appearing here.  Some reasons:
-I *strongly* oppose moving the attendees to the top line.  The event title should be the first line.  Without exception, every calendar program I've used puts the event title on the first line.  I understand we're trying to follow an 'email model' here, but that should not be done at the expense of shocking the user's expectations.  You don't move the back/forward buttons in a browser to the right side of a toolbar, and you don't move the event title from the top line.

-Attendees should not be a textbox.  In a textbox, you can usually view 2-3 email addresses, and viewing more requires holding down the cursor to scroll to see more.  With a listbox, 4 are visible and each click reveals a new one, making it much easier to see the entire list.

-The previous timezone suggestion made it easier for users to handle the common cases.  In that option, users only had to look at/understand the complex dialog if the desired timezone was not the default or one of their 1-2 most used.  Here, they always must understand this large dialog to make any timezone changes.  Additionally, this model does not allow different timezones for start and end times, while the other proposal was easily adapted to accomplish this.  (Note that airlines always publish departure/arrival times in the timezone where the event is occurring.  This seems like a common use-case for the split-tz.)

-The previous attendees suggestion allowed for personal users to handle minor attendee usage without using the complex dialog.  If we want to try to encourage more people to use invitations/itip/imip, we need to make the bar as low as possible.  The new dialog does not do that.

-In personal use cases, I think it's unlikely that users would have the calendar data for most potential attendees stored in their calendar.  This bottom half of the attendees dialog would be useless in that case.

General concerns:
-Toolbars are not easily accessible
-The new proposal will have difficulty fitting on a 640x480 screen
-We need to be consistent with our extra dialogs.  Some of them have their information in a read-only format on the main dialog (recurrence), some in an editable format (attendees), and some not at all (timezone).  I think they should all behave the same way.
-We've lost some of the fields the current dialog offers.  Specifically URL, Priority, and Status
-What are the reasons for changing 'Category' to 'Label'?  mvl did some work with making categories more like tags, which I tend to prefer.  Are there underlying semantic changes intended here or was that just a slip in the mock-up?

Comment 13

[Michael Büttner (no reviews TFN)]

I'm going to implement a prototype for this proposal. Christian will address the above mentioned concerns, new version and more explanation to clarify the concept is on it's way.

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

I havent had a chance to really dig into this, though I hope to get some time to do so over the next few days.  One comment that strikes me, however, is this:

(In reply to comment #12)
>
> -In personal use cases, I think it's unlikely that users would have the
> calendar data for most potential attendees stored in their calendar.  This
> bottom half of the attendees dialog would be useless in that case.

I think this is an example of a couple of something I mentioned in comment 6: an artifact of the lack of widely-deployed implementations of an interopable standard.  I hope I can convince folks that it's worthwhile and in our interest to make part of our overall goal be driving deployment and development of such standards.  In a world where Internet-Free-Busy is widely deployed, the above statement won't be true, and I think Sunbird & Lightning have the opportunity to be part of what drives that deployment.  ifreebusy.com is a start at such infrastructure, and I believe this is something CalConnect cares about also.

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

It strikes me that it's going to be really hard to review and give useful feedback on the proposals until we've answered the questions mentioned in comment 3.  Additionally, we clearly don't have some of the high-level goals entirely pinned down yet, as evidenced by the discussion between Joey and myself in this bug.

While attempting to drive this bug forward right now is certainly possible, I suspect it's likely to be frustrating for everyone involved and require (otherwise unnecessary) iterations of coding and design as our collective vision comes into sharper focus over time.

0.1 is still not quite out the door, and while starting discussion on these questions is at the top of my list for post-0.1, I do need to take a week off to decompress after the release.  Getting from starting discussion to real consensus is not likely to happen in the next few weeks, I don't think.

So I'd like to make another plea to put this on the back burner for a month or two while we sort out the higher-level questions.  I believe there is plenty of basic coding and UI design work that needs to happen that doesn't trip on these big-picture issues.

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

I'd like to echo dmose's thoughts in comment 15 and add the following off the cuff observation:

 - These dialogs remind me of the outlook/notes UIs for calendaring, which is
   to say that they are heavyweight, option-laden and enterprise-centric. If
   enterprise calendar management is a primary use case for Sunbird/Lightning
   then I guess that's appropriate. But if we're going after the home user,
   then we should consider lightning (hah! is pun, jah!) the dialog by dropping
   the toolbar and burying a lot of the options under some "more options" button

 - This approach is antithetical to the iCal approach, which is non-enterprise
   centric and focuses more on the quick experience of creating an event. Now,
   having been an iCal user for a few months, they are almost *too* lightweight
   to the point of frustration. From the leaked screenshots (and maybe from my
   own beta test experince :) I can also confidently predict that Google's CL2
   will also be going after the lighter-weight experience, btw.

 - I believe that there's a happy medium.

 - I believe that we can get there by doing the sort of task analysis dmose
   proposes in comment 3 and comment 15

I'll attach an iCal screencap next ...

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: apple iCal Add Event dialog

Apple iCal new event dialog

 - picking timezones is done through a drop down that features the most 
   recently used and an "Other..." entry that pops up a more advanced dialog

 - the most complicated recurrence is "Custom ..." which pops up a way of 
   picking 1..n days of the week for the event to occur on

 - all these pop-up dialogs pop up over the add new entry sidebar and are
   "sheets" to that part of the UI, modal yet not detachable

 - the whole time, you can see your entire calendar in the main UI

Comment 18

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #16)
> I'd like to echo dmose's thoughts in comment 15 and add the following off the
> cuff observation:
> 
>  - These dialogs remind me of the outlook/notes UIs for calendaring, which is
>    to say that they are heavyweight, option-laden and enterprise-centric. If
>    enterprise calendar management is a primary use case for Sunbird/Lightning
>    then I guess that's appropriate. 

It is; what we don't have such a good handle on is how the enterprise use-case overlaps with the other Lightning use cases, which, I think, is key to figuring out how we factor both code and UI.  In particular, I'm advocating that we should be trying to make Internet-based scheduling features more accessible to the home user.  This happens to, I think, given the use cases more overlap rather than less, which may (or may not) help us here.

>  - I believe that there's a happy medium.

That would be a fine thing.

Comment 19

[Michiel van Leeuwen (email: mvl+moz@)]

Why this distinction between enterprise users and home users? Those two are really the same persons. IF the UI is too complicated for them to use when at home, it still is to complicated when they arrive at work.

Comment 20

[Stephan Schaefer]

(In reply to comment #16)
>  - I believe that we can get there by doing the sort of task analysis dmose
>    proposes in comment 3 and comment 15

So, it seems the biggest concerns regarding this proposal are:
- we do not know yet who our target audience is
- if we are targeting the end-user he might be confused by a dialog page that allows him to invite attendees
- there might be too many options for the average user

It think a good point regarding the target audience is the fact that iCal does not and CL2 probably will not target enterprise customers. In other word they represent a strong competition in the end user calendar market. In order to be different (and successful!) Lightning definitely has to offer features that will attract enterprise customers. Inviting attendees based on free/busy information is probably *the* feature enterprise users will love the most and use on a regular basis. Putting the whole feature into a separate dialog page that the home user will probably never open seems to me like a good compromise. It only requires a single click for the advanced user and is nearly invisible for those who don't care.
Why not starting to implement this proposal in order to know how it feels ? How are we going to make a decision regarding the audience by waiting several months ? The whole invitation and free/busy area is quite a big feature and once the UI is there we can start to play with it and connect it to useful data. If you postpone important and probably quite time consuming features like this you will not be able to finish them until a reasonable deadline. 
My proposal is to continue the implemenation of this dialog. It will be done in its own extension and thus will be optional until the cosmetic problems are sorted out.
I do not think we should cut the feature set offered by this dialog. Otherwise there will probably be few reasons for larger communities to migrate to Lightning and making it an alternative calendar client.

Comment 21

[6e77a 70 6e 6e7a]

(In reply to comment #20)
> So, it seems the biggest concerns regarding this proposal are:
> - we do not know yet who our target audience is
> - if we are targeting the end-user he might be confused by a dialog page that
> allows him to invite attendees
> - there might be too many options for the average user
> 
> It think a good point regarding the target audience is the fact that iCal does
> not and CL2 probably will not target enterprise customers. In other word they
> represent a strong competition in the end user calendar market. In order to be
> different (and successful!) Lightning definitely has to offer features that
> will attract enterprise customers. Inviting attendees based on free/busy
> information is probably *the* feature enterprise users will love the most and
> use on a regular basis.

Allow me to describe my point of view as someone who wants to use an open-source calendar in a commercial setting.  I probably represent a large portion of your "audience".  I know there are other people like me (in my office alone), so you could target us to build a strong user base and start growing market share.

I can't stand using Outlook.  I would be very happy just having a calendar that does what Outlook does; but none exists.

Yes, I also need to be able to schedule meetings, but first I need a calendar I can use in place of Outlook.  That should be what the home user wants, too.  (I, for one, will be using these same features at home.)  If my Outlook-using coworkers and I can't interoperate through email, I will not be allowed to use an open source calendar, so I urge you to just copy the dialogs that exist in Outloook to start gaining market share.

I think this is a situation where you have to "embrace and extend" Outlook, before you try to leapfrog it.  While I'm an enterprise-class user, I don't need need more features than the home user.  For now.

Please, think of the kittens! ;-)

Comment 22

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #20)
>
> So, it seems the biggest concerns regarding this proposal are:
> - we do not know yet who our target audience is
> - if we are targeting the end-user he might be confused by a dialog page that
> allows him to invite attendees
> - there might be too many options for the average user

Well, I think that we know that we want to target both the end-user and enterprise customers, but what's not entirely clear is how much those sets of users overlap and in what way.

> Why not starting to implement this proposal in order to know how it feels? 

My main concern was simply requiring extra iterations over the UI and code.  However, what you're suggesting has definite advantages as well...

> How are we going to make a decision regarding the audience by waiting several
> months ? 

Well, the idea is not that waiting is going to make the decision, but that we'll be having discussions that lead to the decision which will mostly be done by a few months from now.  That said, you're quite right that having a prototype to play with is likely to help those discussions along.

> The whole invitation and free/busy area is quite a big feature and
> once the UI is there we can start to play with it and connect it to useful
> data. If you postpone important and probably quite time consuming features like
> this you will not be able to finish them until a reasonable deadline. 

This is certainly a valid concern.

> My proposal is to continue the implemenation of this dialog. It will be done in
> its own extension and thus will be optional until the cosmetic problems are
> sorted out.

OK, that sounds reasonable enough.

> I do not think we should cut the feature set offered by this dialog. Otherwise
> there will probably be few reasons for larger communities to migrate to
> Lightning and making it an alternative calendar client.

I completely agree, and, in fact, think that it would be a real success condition if we could expose freebusy/scheduling features to non-enterprise users in a way that they would find simple and compelling.

Comment 23

[Michael Büttner (no reviews TFN)]

Attachment: prototype v1

The first version of the prototype implementation arrived. I wrapped it into an extension so everybody can try it out. Please note that the code is not review-ready.

There are also some minor bits and pieces missing. The dialog can't handle tasks in this version, warning messages in the dialog have been removed, etc. The probably most annoying issue currently is that the free/busy-information relies on code which is not yet contributed. So the grid-control to the righthand-side of the attendee-list won't show anything else but 'no information available'.

Besides those issues the dialog pretty much shows most of the stuff from the proposal at http://wiki.mozilla.org/Calendar:Event_Dialog. The appropriate newsgroup-thread can be found at http://groups.google.com/group/mozilla.dev.apps.calendar/browse_frm/thread/a76865e53a9b501d/c1fe8e50e944bc30#c1fe8e50e944bc30.

Comment 24

[gekacheka]

> Created an attachment (id=220921) [edit]
> prototype v1
> 
> ...wrapped it into an extension so everybody can try it out.

Thanks.  (Bug: Install.rdf should specify a unique GUID.)  Thoughts:

Tabs can be suboptimal for a few reasons:
* size: all tabs have to be size of largest tab.  With subdialogs,
  a main dialog can be small with a large subdialog (freebusy).
* visibility: content is hidden on separate pages, and tabs don't
  provide a way to include an indication (such as a checkbox or
  summary) whether content has been set on the other pages.
* validation: users can switch tabs at any time, and only closing the
  entire dialog is prevented by invalid entries.  But by then the user
  may have switched to another tab so the problem may be hidden.  With
  separate dialogs, each subdialog can be validated before closing it,
  so the problem does not disappear from view before the user takes
  care of it.
* speed: all the tabs are loaded, slowing down dialog popup.
  Especially an issue with many or complex tabs.  Separate dialogs help
  divide the time to keep the common case (main page) faster.
  (Also, all the tabs may need be updated when data changes.  Separate 
  dialogs can divide the time so the each subdialog only has to be 
  updated when it is loaded.)

Freebusy table:
* Needs an option to change freebusy table time scale.  For some
  kinds of work (maybe on-site contractors) (or vacations), days might
  be a better time scale than quarter hours.  Options might be
  quarter hours (like current size), hours, half-days, days, weeks,
  one character-width per slot (mouseable so can drag to pick a slot).
* The meaning of the icons is not obvious.
* May need to be able to specify freebusy times manually for an attendee.
* May still want a contacts sidebar so it's easy to add a list of
  people without remembering their names individually.
* Need to indicate how many attendees of each type can actually make
  each proposed time slot.  Otherwise users may have to scroll and count.
* The prototype does not have the datetimepickers or the "find slot"
  shown in http://wiki.mozilla.org/images/0/00/Attendee-page.png
  Maybe the date should be above and the "find slot" should be below,
  since the duration is a prerequisite for finding a slot.

alarm: 
* This menulist takes more space for "custom" times not in menulist.
* A menulist with just a few set times may not work well for people who
  often set specific anticipation times based on the time they need
  to prepare and get to that event/meeting location.  It slows
  down the process of setting a specific time.  
* Would the list of defaults be automatically extended based on recently
  edited events? 

recurrence:
* Seems misleading to create recurrences that do not include the
  start date.  (So someone could set the start date to
  one day, but use the recurrence page to set it to another day.)
* Not clear how to manage exceptions.
* Not clear how to manage list of specific dates (e.g., religious holidays related to moon or non-gregorian calendar).  Maybe click preview?  But then not clear where dates are outside view.  Maybe give index (2/5) and buttons to navigate to next.

Hope this helps.

Comment 25

[Justin Wood (:Callek)]

re: c#24
>Tabs can be suboptimal for a few reasons:
>* validation: users can switch tabs at any time, and only closing the
>  entire dialog is prevented by invalid entries.  But by then the user
>  may have switched to another tab so the problem may be hidden.  With
>  separate dialogs, each subdialog can be validated before closing it,
>  so the problem does not disappear from view before the user takes
>  care of it.

I ass-u-me that changing tabs can have an event which prevents the actual change if there is an error (with some sort of UI to indicate this)

>* speed: all the tabs are loaded, slowing down dialog popup.
>  Especially an issue with many or complex tabs.  Separate dialogs help
>  divide the time to keep the common case (main page) faster.
>  (Also, all the tabs may need be updated when data changes.  Separate 
>  dialogs can divide the time so the each subdialog only has to be 
>  updated when it is loaded.)
>

The Preferences window rewrite (present in toolkit based apps post Gecko 1.8) uses "Dynamic Overlays" to accomodate this concern.  The normal case of opening the window only loads the needed overlays, while when switching to a needed one, the overlay for that 'pane' is then loaded and viewed.

Your concern on updating a 'hidden' tab can also be postponed until next view of the tab, I imagine

>recurrence:
>* Seems misleading to create recurrences that do not include the
>  start date.  (So someone could set the start date to
>  one day, but use the recurrence page to set it to another day.)

While I agree with the concept here; *one* use case could be an event "Celebrate Justin's Birthday" (to use my name) with the start-date the exact day I was born; but exclude the start date, since they don't necessarily celebrate my birthday on my initial birthday.  (It is usually entered AFTER a person's day of birth)

Comment 26

[Michael Büttner (no reviews TFN)]

The final specification for this dialog is available on the wiki (http://wiki.mozilla.org/Calendar:SMB_Event_Dialog), marking the obsolete attachments accordingly.

Comment 27

[Michael Büttner (no reviews TFN)]

Attachment: patch v1

this patch modifies the lightning/jar.mn to address the new files for the prototypes-folder.

Comment 28

[Michael Büttner (no reviews TFN)]

Attachment: prototypes patch - part 1

this patch implements the specification available at http://wiki.mozilla.org/Calendar:SMB_Event_Dialog, just for reference purposes. the previously submitted patch addresses the necessary fixes to lightning/jar.mn.

Comment 29

[Michael Büttner (no reviews TFN)]

Comment on attachment 242406 [details] [diff] [review]
patch v1

passing review-request to lilmatt as discussed on IRC.

Comment 30

[Matthew (lilmatt) Willis]

Comment on attachment 242406 [details] [diff] [review]
patch v1

General comment: 
Please don't add any tabs to jar.mn. In Mozilla files, tabs basically only belong in targets inside Makefiles.  I generally don't go fixing existing tabs unless I'm replacing that line (so I don't screw up cvs blame), but we definitely don't want new tabs added.  I suggest two spaces between each left and right column (and not trying to align them).  I also have been using 4 spaces between "#expand" and the next non-space character so that when the file is preprocessed, stuff still lines up properly, 4 spaces from the left edge.

> #expand  skin/classic/calendar/sun-calendar-event-dialog-toolbar.png	(/calendar/prototypes/themes/__THEME__/sun-calendar-event-dialog-toolbar.png)

"winstripe" in the lines below should be replaced with __THEME__ like the line above. That's what the #expand uses to find/replace __THEME__ with pinstripe/winstripe where appropriate.  Be sure to also commit these graphics to both winstripe and pinstripe themes.

>+#expand  skin/classic/calendar/TimeZone_0h.png	(/calendar/prototypes/themes/winstripe/TimeZone_0h.png)
>+#expand  skin/classic/calendar/TimeZone_1h.png	(/calendar/prototypes/themes/winstripe/TimeZone_1h.png)
>+#expand  skin/classic/calendar/TimeZone_2h.png	(/calendar/prototypes/themes/winstripe/TimeZone_2h.png)
>+#expand  skin/classic/calendar/TimeZone_3h30.png	(/calendar/prototypes/themes/winstripe/TimeZone_3h30.png)
>+#expand  skin/classic/calendar/TimeZone_3h.png	(/calendar/prototypes/themes/winstripe/TimeZone_3h.png)
>+#expand  skin/classic/calendar/TimeZone_4h30.png	(/calendar/prototypes/themes/winstripe/TimeZone_4h30.png)
>+#expand  skin/classic/calendar/TimeZone_4h.png	(/calendar/prototypes/themes/winstripe/TimeZone_4h.png)
>+#expand  skin/classic/calendar/TimeZone_5h30.png	(/calendar/prototypes/themes/winstripe/TimeZone_5h30.png)
>+#expand  skin/classic/calendar/TimeZone_5h45.png	(/calendar/prototypes/themes/winstripe/TimeZone_5h45.png)
>+#expand  skin/classic/calendar/TimeZone_5h.png	(/calendar/prototypes/themes/winstripe/TimeZone_5h.png)
>+#expand  skin/classic/calendar/TimeZone_6h30.png	(/calendar/prototypes/themes/winstripe/TimeZone_6h30.png)
>+#expand  skin/classic/calendar/TimeZone_6h.png	(/calendar/prototypes/themes/winstripe/TimeZone_6h.png)
>+#expand  skin/classic/calendar/TimeZone_7h.png	(/calendar/prototypes/themes/winstripe/TimeZone_7h.png)
>+#expand  skin/classic/calendar/TimeZone_8h.png	(/calendar/prototypes/themes/winstripe/TimeZone_8h.png)
>+#expand  skin/classic/calendar/TimeZone_9h30.png	(/calendar/prototypes/themes/winstripe/TimeZone_9h30.png)
>+#expand  skin/classic/calendar/TimeZone_9h.png	(/calendar/prototypes/themes/winstripe/TimeZone_9h.png)
>+#expand  skin/classic/calendar/TimeZone_10h.png	(/calendar/prototypes/themes/winstripe/TimeZone_10h.png)
>+#expand  skin/classic/calendar/TimeZone_11h.png	(/calendar/prototypes/themes/winstripe/TimeZone_11h.png)
>+#expand  skin/classic/calendar/TimeZone_12h.png	(/calendar/prototypes/themes/winstripe/TimeZone_12h.png)
>+#expand  skin/classic/calendar/TimeZone_13h.png	(/calendar/prototypes/themes/winstripe/TimeZone_13h.png)
>+#expand  skin/classic/calendar/TimeZone_-1h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-1h.png)
>+#expand  skin/classic/calendar/TimeZone_-2h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-2h.png)
>+#expand  skin/classic/calendar/TimeZone_-3h30.png	(/calendar/prototypes/themes/winstripe/TimeZone_-3h30.png)
>+#expand  skin/classic/calendar/TimeZone_-3h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-3h.png)
>+#expand  skin/classic/calendar/TimeZone_-4h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-4h.png)
>+#expand  skin/classic/calendar/TimeZone_-5h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-5h.png)
>+#expand  skin/classic/calendar/TimeZone_-6h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-6h.png)
>+#expand  skin/classic/calendar/TimeZone_-7h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-7h.png)
>+#expand  skin/classic/calendar/TimeZone_-8h30.png	(/calendar/prototypes/themes/winstripe/TimeZone_-8h30.png)
>+#expand  skin/classic/calendar/TimeZone_-8h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-8h.png)
>+#expand  skin/classic/calendar/TimeZone_-9h30.png	(/calendar/prototypes/themes/winstripe/TimeZone_-9h30.png)
>+#expand  skin/classic/calendar/TimeZone_-9h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-9h.png)
>+#expand  skin/classic/calendar/TimeZone_-10h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-10h.png)
>+#expand  skin/classic/calendar/TimeZone_-11h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-11h.png)
>+#expand  skin/classic/calendar/TimeZone_-12h45.png	(/calendar/prototypes/themes/winstripe/TimeZone_-12h45.png)
>+#expand  skin/classic/calendar/TimeZone_-12h.png	(/calendar/prototypes/themes/winstripe/TimeZone_-12h.png)
>+#expand  skin/classic/calendar/TimeZone_map.png	(/calendar/prototypes/themes/winstripe/TimeZone_map.png)

I'd uncapitalize the filenames as well, since we generally either use CamelCase with a leading lowercase letter, or all lowercase with hyphens. Using the underscore in this case (since you need the hyphen for "minus x hours") seems fine with me.

It's kind of tough to review this since the referenced files aren't commited yet


So that's a lot of comments.  I'd like to see another rev before giving it r+.

Comment 31

[Michael Büttner (no reviews TFN)]

Attachment: prototypes patch v2

this patch implements the specification available at
http://wiki.mozilla.org/Calendar:SMB_Event_Dialog, just for reference purposes. this is a new version of the previously submitted patch with loads of bugfixes.

Comment 32

[Michael Büttner (no reviews TFN)]

Attachment: patch v2

this patch addresses all the previous comments.

> It's kind of tough to review this since the referenced files aren't commited
> yet
matt, all the referenced files are contained in the "prototypes patch v2", so just apply this patch to see the final result.

Comment 33

[Matthew (lilmatt) Willis]

(In reply to comment #31)
> Created an attachment (id=244091) [edit]
> prototypes patch v2

You need to cvs add the PNG images using -kb, as they're binary and CR/LF issues could screw them up pretty badly.

If you wanted to zip them up and attach them that way (since there's so many) that might work for helping me review the other patch.

Comment 34

[Matthew (lilmatt) Willis]

(In reply to comment #33)

Ya, I get this if I try to apply the prototypes patch v2:

patch: **** malformed patch at line 410: IHDR

You need to attach a zip file of the images

Comment 35

[Michael Büttner (no reviews TFN)]

Attachment: prototypes patch v3

same as previously submitted 'prototypes patch' but without binaries.

Comment 36

[Michael Büttner (no reviews TFN)]

Attachment: binaries v1

all png's contained in a zip-file. the content of this file already contains the correct folder structure.

Comment 37

[Matthew (lilmatt) Willis]

Comment on attachment 244092 [details] [diff] [review]
patch v2

> +#expand    skin/classic/calendar/timezone_0h.png
The PNGs in the zip file all are still named TimeZone_... You'll need to fix the case of those filenames before cvs adding them and checking them in.

One other note about this section: I neglected to mention last time that I _do_ try to place the ( at 50 chars (after preprocessing) if possible to increase readability, but since most of your filenames are so long anyway, it wouldn't matter, except in the timezone*.png lines.  50 chars after preprocessing = 50 chars + 7 chars for "#expand", so the ( should be at 57 chars for those lines if possible. (58 if you're looking at a diff with the leading space/plus/minus).  This is just a nit though.


> calendar-en-US.jar:   
> locale/en-US/calendar/preferences/views.dtd  (/calendar/locales/en-US/chrome/calendar/preferences/views.dtd)
   locale/en-US/calendar/sun-calendar-event-dialog.dtd	(/calendar/locales/en-US/chrome/prototypes/sun-calendar-event-dialog.dtd)
> +  locale/en-US/calendar/sun-calendar-event-dialog.properties  (/calendar/locales/en-US/chrome/prototypes/sun-calendar-event-dialog.properties)

While you're here, please remove the tab in the sun...event-dialog.dtd line.

r=lilmatt will those fixed

Comment 38

[Michael Büttner (no reviews TFN)]

Patch checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED