348028 - Re-evaluate New Calendar->Remote choices

Status: VERIFIED FIXED

(Calendar :: Internal Components, defect)

Description

[Joey Minta]

The choice between 'WebDAV' and 'CalDAV', without any context whatsoever, is one that users are constantly struggling with.  It is one of the top, if not the top, problems in the support forums.  For 0.3 we need to find a minimal solution to make it clear that the WebDAV option is what users want.

dmose has already suggested that we should just auto-detect that type of server available.  That's an ideal solution, but I don't think we have the resources to get that in for 0.3.  Suggestions for alternative, less drastic changes are welcome.

At a minimum, i'd suggest changing WebDAV to iCalendar (ics), since really that will work with http, ftp, and file urls, and not all of those can have WebDAV.

Comment 1

[Stefan Sitter [:ssitter]]

I'm very much in favor of changing the description for Sunbird/Lightning 0.3.

New text actually could be similar to our Bugzilla component names, e.g
(*) iCalendar, ICS, WebDAV
( ) CalDAV server

Comment 2

[Joey Minta]

Attachment: Local/Shared with options

Patch unifies the first 2 pages of the calendar-wizard.  We offer Local calendars, and Shared calendars now, with different available formats for the shared calendars.  We also autopopulate the url field to point to your profile (for easy creation of local ics files) and provide an example holiday file for remote files, and to encourage holiday discovery.

Comment 3

[Joey Minta]

Attachment: screenshot

Screenshot of the tweaked dialog

Comment 4

[Matthew (lilmatt) Willis]

Comment on attachment 233610 [details] [diff] [review]
Local/Shared with options

(In reply to comment #3)
> Created an attachment (id=233611) [edit]
> Screenshot of the tweaked dialog

I'm glad to remove extra steps. Simple is better.

However, I have the following comments on the dialog as shown/patched that I'd like the cal-ui-review crew to consider...

1. The "Format:" label seems extraneous. We have a bit of descriptive text above. We should be able to ask whatever we need to ask of the user in that text. Let's remove "Format:" altogether.

2. The "descriptive text" currently in place, "Choose your calendar type",
 could use a little tweaking. Perhaps something like "Select the type of calendar:". beltzner or Lucy are probably better for this piece. I just think there are too many Cs in that dialog, and replacing "Choose" with "Select" would help cut that down.

3. SQLite appears to be the correct capitalization, although I'm not sure if we need/want to confuse the user with that information. Simply using "Local disk" or something might be better there.

4. When the location textbox appears, it is far too narrow. URLs for calendars are often very long. Let's try to show as much of the URL as we can to the user, since we have lots of vertical space available. Perhaps we could include some example URLs under the textbox? "(example: http://www.server.com/MyCalendar.ics, webcal://calendar.server.com/GroupCalendar.ics)"

5. Your "Other.." label has two periods? Unless we're opening another dialog because of you selecting "Other", it should not have an ellipsis.

6. Please give the (currently) commented out menuseparator an id, so it can be used by overlays to insert additional locations.

7. Why are we adding commented out stuff to the .xul?

Comment 5

[Joey Minta]

(In reply to comment #4)
> 
> 1. The "Format:" label seems extraneous. We have a bit of descriptive text
> above. We should be able to ask whatever we need to ask of the user in that
> text. Let's remove "Format:" altogether.
Note that we need something here to prevent the 'Location' label from looking silly.
> 3. SQLite appears to be the correct capitalization, although I'm not sure if we
> need/want to confuse the user with that information. Simply using "Local disk"
> or something might be better there.
The idea was that users who want to use 'poor-mans-sync' should know that they need to pick the ICS option, not the 'local' one.

> 
> 4. When the location textbox appears, it is far too narrow. URLs for calendars
> are often very long. Let's try to show as much of the URL as we can to the
> user, since we have lots of vertical space available. Perhaps we could include
> some example URLs under the textbox? "(example:
> http://www.server.com/MyCalendar.ics,
> webcal://calendar.server.com/GroupCalendar.ics)"
I did include 1 example.  I also made the textbox bigger.  Are you not seeing that?

> 
> 5. Your "Other.." label has two periods? Unless we're opening another dialog
> because of you selecting "Other", it should not have an ellipsis.
It'll send you to a webpage, so it should have ellipsis.

> 
> 6. Please give the (currently) commented out menuseparator an id, so it can be
> used by overlays to insert additional locations.
Commented out code can't be used for overlays :)

> 
> 7. Why are we adding commented out stuff to the .xul?
> 
Not 100% sure, but it seems to be the trend in this file. (http://lxr.mozilla.org/mozilla/source/calendar/resources/content/calendarCreation.xul#98)

Comment 6

[Matthew (lilmatt) Willis]

(In reply to comment #5)
> (In reply to comment #4)
> > 
> > 1. The "Format:" label seems extraneous. We have a bit of descriptive text
> > above. We should be able to ask whatever we need to ask of the user in that
> > text. Let's remove "Format:" altogether.
> Note that we need something here to prevent the 'Location' label from looking
> silly.
Since "Location:" is a child of "Shared", it should be indented slightly.
Here's a suggestion:

-------------------------------------------------------------
|                                                           |
|                                                    ###### |
|  Create a new calendar                             ###### |
|                                                    ###### |
|                                                           |
|    Select which type of calendar you wish to create:      |
|                                                           |
|    ( ) Local (not shared, stored locally)                 |
|    (*) Shared: [iCalendar       |v]                       |
|         Location: [                                  ]    |
|         Example: http://www.example.com/myCalendar.ics    |
|                                                           |
|                                                           |
|                                                           |
-------------------------------------------------------------


> > 3. SQLite appears to be the correct capitalization, although I'm not sure if we
> > need/want to confuse the user with that information. Simply using "Local disk"
> > or something might be better there.
> The idea was that users who want to use 'poor-mans-sync' should know that they
> need to pick the ICS option, not the 'local' one.
Agreed. I'm not sure "sqlite" helps that at all. It may in fact make it worse. ("SQL... isn't that a database server?")

> > 4. When the location textbox appears, it is far too narrow. URLs for calendars
> > are often very long. Let's try to show as much of the URL as we can to the
> > user, since we have lots of vertical space available. Perhaps we could include
> > some example URLs under the textbox? "(example:
> > http://www.server.com/MyCalendar.ics,
> > webcal://calendar.server.com/GroupCalendar.ics)"
> I did include 1 example.  I also made the textbox bigger.  Are you not seeing
> that?
No, I wasn't. The patch didn't apply cleanly for some reason. After hand-merging it, I see the example.

> > 5. Your "Other.." label has two periods? Unless we're opening another dialog
> > because of you selecting "Other", it should not have an ellipsis.
> It'll send you to a webpage, so it should have ellipsis.
Cool. Fix that.

> > 6. Please give the (currently) commented out menuseparator an id, so it can be
> > used by overlays to insert additional locations.
> Commented out code can't be used for overlays :)
Right, but we could uncomment it and collapse it. :)

> > 7. Why are we adding commented out stuff to the .xul?
> Not 100% sure, but it seems to be the trend in this file.
Let's stop the insanity. 

Comment 7

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

Local / Shared is not a good set of options. They are not mutually exclusive. A calendar can be local (on the local network!) but still be shared. Better would be Private / Shared. But then, an ics file on my private ftp file is still private. Nobody has access to it...
Maybe trying to cut down the options to 2 just doesn't do it...

Comment 8

[Joey Minta]

(In reply to comment #7)
> Local / Shared is not a good set of options. They are not mutually exclusive. A
> calendar can be local (on the local network!) but still be shared. Better would
> be Private / Shared. But then, an ics file on my private ftp file is still
> private. Nobody has access to it...
> Maybe trying to cut down the options to 2 just doesn't do it...
> 
I think (a) including the format helps clarify the issue here.  I also think that the case of 'shared on a local network' is reasonably edge-case (local-network doesn't seem that local to me).  In any case, let's not let perfect be the enemy of good.  The current options clearly aren't working for users.  If people are confused by these too, then we can re-evaluate.

Comment 9

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

Sure, we don't need to be perfect. But i don't even think the new options are much of an improvement.
My point is simply that 'local' and 'shared' are not opposites. It's not a set. We need 'local'/'remote' (which didn't work), or 'private'/'shared'.
But those options are not good either. I think the biggest problem is the word 'local'. Users are likely to have no clue as what it means. It is not the language they use.

We need to go back to use-cases. For storage calendar, the option would then be something like 'For private use, stored on my own computer'. For webdav, the option would be 'Stored on a server, might be shared with others'.
At least I think that those words avoid using terms that are too technical.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

In the interest of getting 0.3 out without entraining a bunch of UI discussion about the changes in the patch, we'd like to land something more minimal for 0.3.  In particular, we'd like to see a patch that leaves the UI infrastructure the way it is, and merely improves the strings.  In particular,

Local -> On My Computer
Remote -> On the Network

WebDAV -> iCalendar (ICS)

Comment 11

[Joey Minta]

(In reply to comment #10)
> Local -> On My Computer
> Remote -> On the Network
I'll say that I don't really agree with the Remote choice here.  One of things we've been taking a bit of flak for is an inability to easily create a local ics calendar for syncing.  These calendars are 'On my computer', but once the user picks that option, they have no way to get to ICS.

Comment 12

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

the suggested wording is better for most cases. If we want to do better for all cases, we need a complete redesign of how the wizard works. That is not doable in the 0.3 timeframe. So lets go for this simple wording change for now, and do better later.

Comment 13

[Matthew (lilmatt) Willis]

Attachment: rev0 - just string changes

Just the string changes requested: 
Local -> On My Computer
Remote -> On the Network
WebDAV -> iCalendar (ICS)

Comment 14

[Simon Paquet [:sipaq]]

Comment on attachment 236950 [details] [diff] [review]
rev0 - just string changes

>-<!ENTITY calendarproperties.webdav.label   "WebDAV">
>+<!ENTITY calendarproperties.webdav.label   "iCalendar (ICS)">

[...]
>-<!ENTITY initialpage.local.label    "Local" >
>-<!ENTITY initialpage.remote.label   "Remote" >
>+<!ENTITY initialpage.local.label  "On My Computer">
>+<!ENTITY initialpage.remote.label  "On the Network">

Please rename the entity, so that localizers are made aware of the string change.

Comment 15

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

Ehm, please don't. We don't want to change entity names for every string change. We have bonsai for that.

Comment 16

[Simon Paquet [:sipaq]]

(In reply to comment #15)
> Ehm, please don't. We don't want to change entity names for every string
> change. We have bonsai for that.

mvl, http://developer.mozilla.org/en/docs/Writing_localizable_code says that you should change the entity key, if you change the semantics of a localized string. At least for the second change

>-<!ENTITY initialpage.local.label    "Local" >
>-<!ENTITY initialpage.remote.label   "Remote" >
>+<!ENTITY initialpage.local.label  "On My Computer">
>+<!ENTITY initialpage.remote.label  "On the Network">

this seems to be the case here.

Comment 17

[Matthew (lilmatt) Willis]

Attachment: rev1 - changes key

Changes the key

Comment 18

[Simon Paquet [:sipaq]]

Comment on attachment 236971 [details] [diff] [review]
rev1 - changes key

Sorry for being unclear here. With "second change" I meant the second block of changes in the original patch.

So please also change initialpage.local.lable to something like initialpage.computer.label

Again, sorry for my unclear statement. r=sipaq with that fixed.

Comment 19

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 236971 [details] [diff] [review]
rev1 - changes key

r=dmose with the change sipaq requested.

Comment 20

[Matthew (lilmatt) Willis]

Patch (w/ nit) checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED

Comment 21

[Miguel]

Verified.
Sunbird 2006100207/windows.

Long term solution in bug 306495 - autodetect remote calendar type so user doesn't need to pick

Comment 22

[cmtalbert]

Marking as verified, according to Miguel's testing.