Closed
Bug 306692
Opened 19 years ago
Closed 8 years ago
Simplify file menu (New calendar vs. Subscribe to calendar)
Categories
(Calendar :: Dialogs, defect)
Calendar
Dialogs
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: lapsap7+mz, Unassigned)
References
Details
Attachments
(2 files, 4 obsolete files)
5.75 KB,
patch
|
jminta
:
first-review+
|
Details | Diff | Splinter Review |
2.41 KB,
patch
|
michael.buettner
:
review+
clarkbw
:
ui-review-
|
Details | Diff | Splinter Review |
* "File" > "Open Calendar file" has no reaction * "File" > "New Calendar file" has the same effect as "File" > "Subscribe to remote". These last two items should be merged as one.
Comment 1•19 years ago
|
||
Unless we have a good, clear label to give to the New/Subscribe menu-items that makes it clear to an average user what it does, I'm against combining them. A small, simple help might be to automatically select 'remote' when 'Subscribe' is chosen. 'Open calendar file' should definitely disappear.
Reporter | ||
Comment 2•19 years ago
|
||
If New... and Subscribe... aren't supposed to be the same, of course they shouldn't be merged. But they need to display different things, or people would think they're redundant.
What is the rationale behind eliminating the ability to easily browse to and open local .ics files? That seems like the natural thing to do when someone saves an ics file email attachment, or they download an ics file because their browser isn't set up to forward links to sunbird, --- in either case they want to look at the file, not import it. (The reason that New Local Calendar File and Open Local Calendar File are separate in 0.2 is because the operating system provides different file picker behavior depending on whether you're opening or creating a file. If you're creating a new file (save as), then you're allowed to pick an non-existing name, and if you pick an existing file, it warns you about overwriting. If you're opening a file, then you're not allowed to provide a non-existing filename, and you get no warning about overwriting when you pick an existing filename. So both are needed.) Maybe open calendar file could be combined with subscribe, however, as they are both about adding existing files. (Commands to opening local and remote files were separate in 0.2 because local files can use a file picker and urls cannot, and that distinction is familiar from Firefox where there is both Open Location (url) and Open File (local) in the File menu.)
Comment 4•19 years ago
|
||
*** Bug 310051 has been marked as a duplicate of this bug. ***
Comment 5•19 years ago
|
||
*** Bug 314563 has been marked as a duplicate of this bug. ***
Comment 6•19 years ago
|
||
*** Bug 319606 has been marked as a duplicate of this bug. ***
Comment 7•19 years ago
|
||
*** Bug 320176 has been marked as a duplicate of this bug. ***
Comment 8•19 years ago
|
||
Please could the severity of this bug be increased to at least Major? The 4 duplicates are all rated either normal or major but this one is only minor; it seems rather sneaky to close a major bug by marking it a duplicate of a minor one. Also the bug is present on the Linux version too.
Comment 9•19 years ago
|
||
(In reply to comment #8) > Please could the severity of this bug be increased to at least Major? The 4 > duplicates are all rated either normal or major but this one is only minor; it > seems rather sneaky to close a major bug by marking it a duplicate of a minor > one. There are fairly simple workarounds for all of the problems listed here, which means that the severity is correctly set to minor. Adding P1, though, since the level of duplicates alone indicates that this is a very high-profile problem. If no one takes this bug in the next week or so, I can probably find some cycles for it after calConnect, but that of course depends on what other priorities come up between now and then.
Assignee: mostafah → nobody
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Comment 10•19 years ago
|
||
(In reply to comment #9) > If no one takes this bug in the next week or so, I can probably find some > cycles for it after calConnect, but that of course depends on what other > priorities come up between now and then. > What do we really want done here? Remove 'open calendar file'?
Comment 11•19 years ago
|
||
(In reply to comment #10) > What do we really want done here? Remove 'open calendar file'? > I agree with gekacheka that the Open Calendar File... option has many common use cases. I think that needs to be more like the 0.2 behavior, where it opens a filepicker and adds the file picked to the list of calendar. With regards to the other two problems, I think the New Calendar Wizard needs to accept an additional argument that contains a function to run when the dialog is loaded. That way we can bypass the first screen and automatically select 'remote' when the user chooses 'Subscribe to Remote Calendar'.
Comment 12•19 years ago
|
||
(In reply to comment #9) >... > There are fairly simple workarounds for all of the problems listed here, which > means that the severity is correctly set to minor. Adding P1, though, since > the level of duplicates alone indicates that this is a very high-profile > problem. Please could you elaborate on the simple workaround, because I haven't managed to find it? I tried editing the properties of a calendar file to change its location to file:///blahblahblah/test.ics but it didn't work. Am I using the right URL format? I know that I can import a calendar, but that is not what I want to do, because I want the calendar to be visible to other users. Thanks
Comment 13•19 years ago
|
||
(In reply to comment #12) > Please could you elaborate on the simple workaround, because I haven't managed > to find it? I tried editing the properties of a calendar file to change its > location to > file:///blahblahblah/test.ics but it didn't work. Am I using the right URL > format? 1.) Choose File->New Calendar file. 2.) Choose 'Remote'. 3.) Choose 'Webdav'. 4.) Type in the address of the file (beginning with file://) 5.) Fill in extra details (name/color) 6.) Enjoy. You can test whether or not you're using the right URL format by trying to open the file in firefox. The address in the addressbar in firefox should be the same as the address you type into the Location box in Sunbird. Please use Mozillazine forums for support questions in the future.
Comment 14•19 years ago
|
||
(In reply to comment #13) Thanks for the hint, that works great. Going back to the matter of what the various menu items ought to do, my expectation (based on other applications) would be that "New Calendar" would only be used when creating a brand new empty calendar. "Open Calendar File" and "Subscribe to remote calendar" could possibly be merged, but I don't think it hurts to have both. Maybe they should execute the same dialogue but with different defaults. The dialogues should definitely be made more intuitive, but I imagine this is being worked on anyway. In particular if you select Local in the New Calendar dialogue it should give you the option of creating an ICAL file in an arbitrary location instead of the default hidden storage.sdb.
Comment 15•19 years ago
|
||
This makes 'Open Calendar' launch a filepicker.
Attachment #207626 -
Flags: first-review?(jminta)
Comment 16•19 years ago
|
||
Comment on attachment 207626 [details] [diff] [review] Make 'Open Calendar' work, V1 + var nsIFilePicker = Components.interfaces.nsIFilePicker; Should probably be a const, not a var. + fp.init(window, getStringBundle().GetStringFromName("Open"), nsIFilePicker.modeOpen); This only happens to work because we also include import-export.js (where getStringBundle() is defined) in calendar.xul. I'd rather this code didn't depend on that file. + fp.appendFilter(gCalendarBundle.getString( "filterCalendar" ), "*" + ".ics" ); I know calendar.js doesn't have very consistent styling, but let's at least be consistent within this function. (Don't put spaces around things in parens.) + var url = currentFile = fp.fileURL.spec; Triple initializations are difficult to read, and I don't see any place where currentFile gets used. + // Handle if the calendar is already added + try { + calMgr.registerCalendar(openCalendar); + } catch(ex) {} Failing silently here is going to confuse a lot of people. Either let the error be thrown, or pop-up a nice error-message. + var captures = url.match(fullPathRegex); This is a rather odd variable name to pick, why? + composite.addCalendar(openCalendar); Why is this necessary? I thought the composite registered an observer with the calMgr to listen for exactly these types of events.
Attachment #207626 -
Flags: first-review?(jminta) → first-review-
Comment 17•19 years ago
|
||
(In reply to comment #16) > (From update of attachment 207626 [details] [diff] [review] [edit]) > + var nsIFilePicker = Components.interfaces.nsIFilePicker; > Should probably be a const, not a var. > Fixed > + fp.init(window, getStringBundle().GetStringFromName("Open"), > nsIFilePicker.modeOpen); > > This only happens to work because we also include import-export.js (where > getStringBundle() is defined) in calendar.xul. I'd rather this code didn't > depend on that file. > Fixed > + fp.appendFilter(gCalendarBundle.getString( "filterCalendar" ), "*" + > ".ics" ); > I know calendar.js doesn't have very consistent styling, but let's at least be > consistent within this function. (Don't put spaces around things in parens.) > Fixed > + var url = currentFile = fp.fileURL.spec; > Triple initializations are difficult to read, and I don't see any place where > currentFile gets used. > My mistake, that got left over during the coding-process =) > + // Handle if the calendar is already added > + try { > + calMgr.registerCalendar(openCalendar); > + } catch(ex) {} > Failing silently here is going to confuse a lot of people. Either let the > error be thrown, or pop-up a nice error-message. > try/catch removed > + var captures = url.match(fullPathRegex); > This is a rather odd variable name to pick, why? > That's the original variable name from the funcion in calendarCreation.js, so I figured I'd leave it like that, I could change it though, but I'm not sure to what > + composite.addCalendar(openCalendar); > Why is this necessary? I thought the composite registered an observer with the > calMgr to listen for exactly these types of events. > I thought that was necessary (I had to use it when doing that holiday-calendar-stuff for the calendar to be activated)
Attachment #207626 -
Attachment is obsolete: true
Comment 18•19 years ago
|
||
Comment on attachment 207633 [details] [diff] [review] Make 'Open Calendar' work, V2 Forgot to ask for review, sorry for the bugspam
Attachment #207633 -
Flags: first-review?(jminta)
Comment 19•19 years ago
|
||
Comment on attachment 207633 [details] [diff] [review] Make 'Open Calendar' work, V2 + function srGetStringBundle() { + var strBundleService = + Components.classes["@mozilla.org/intl/stringbundle;1"] + .getService(Components.interfaces.nsIStringBundleService); + return strBundleService.createBundle("chrome://calendar/locale/calendar.properties"); + } This function is already defined, in calendar.js nonetheless. You shouldn't redeclare it here. + if (fp.show() == nsIFilePicker.returnOK) { Just a minor style nit, but I think it's better to reduce the amount of indenting you need to do when possible. This could be if (a != b) { return; } foo1(); foo2(); instead of if (a == b) { foo1(); foo2(); } + var captures = url.match(fullPathRegex); Call it prettyName or something more indicative of what it is, just to make Venkman happier.
Attachment #207633 -
Flags: first-review?(jminta) → first-review-
Comment 20•19 years ago
|
||
This should fix those issues
Attachment #207633 -
Attachment is obsolete: true
Attachment #207712 -
Flags: first-review?(jminta)
Comment 21•19 years ago
|
||
Just my two cents: + fp.appendFilter(gCalendarBundle.getString("filterCalendar"), "*" + ".ics"); Why "*" + ".ics"? Why not write "*.ics" without another string add? + if (prettyName && prettyName.length >= 1) { + var name = prettyName[1]; + } + + openCalendar.name = name; +} That code will fail if we do not hit the if-block. I think you either have to init variable 'name' first or move the 'openCalendar.name' assignment into the if-block.
Comment 22•19 years ago
|
||
(In reply to comment #21) ssitter mostly read my mind here. > + fp.appendFilter(gCalendarBundle.getString("filterCalendar"), "*" + > ".ics"); > > Why "*" + ".ics"? Why not write "*.ics" without another string add? I think an argument can be made that the current code is a bit easier to read, emphasizing the 'ics' part, but I'll leave that up to redrenius. > > + if (prettyName && prettyName.length >= 1) { > + var name = prettyName[1]; > + } > + > + openCalendar.name = name; > +} > > That code will fail if we do not hit the if-block. I think you either have to > init variable 'name' first or move the 'openCalendar.name' assignment into the > if-block. > Indeed. We should grab some sort of 'Untitled' string in an else block.
Comment 23•19 years ago
|
||
This patch makes calendars with empty filename use 'Untitled Calendar' as name (the name is localizable).
Assignee: nobody → robin.edrenius
Attachment #207712 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #207734 -
Flags: first-review?(jminta)
Attachment #207712 -
Flags: first-review?(jminta)
Comment 24•19 years ago
|
||
This patch changes "*" + ".ics" to "*.ics" as per discussions on irc.
Attachment #207734 -
Attachment is obsolete: true
Attachment #207735 -
Flags: first-review?(jminta)
Attachment #207734 -
Flags: first-review?(jminta)
Comment 25•19 years ago
|
||
Comment on attachment 207735 [details] [diff] [review] [checked in] Make 'Open Calendar' work, V5 Thanks for the patch! This helped me out immensely at calconnect. r=jminta
Attachment #207735 -
Flags: first-review?(jminta) → first-review+
Comment 26•19 years ago
|
||
Checked in the patch to make 'Open Calendar' work, leaving bug open to handle the other issues. Reducing priority, since those aren't nearly as high-profile. redrenius: If you're not planning to keep working on the other parts, please reassign this back to the default owner.
Priority: P1 → P3
Comment 27•19 years ago
|
||
(In reply to comment #26) > redrenius: If you're not planning to keep working on the other parts, please > reassign this back to the default owner. > Reassigning to default assignee.
Assignee: robin.edrenius → mostafah
Status: ASSIGNED → NEW
Comment 28•18 years ago
|
||
Update summary from "Three "File" menu items have problems" to "Simplify file menu (New calendar vs. Subscribe to calendar)" to reflect remaining issues.
Summary: Three "File" menu items have problems → Simplify file menu (New calendar vs. Subscribe to calendar)
Comment 29•18 years ago
|
||
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Updated•18 years ago
|
Target Milestone: --- → Sunbird 0.3
Comment 30•18 years ago
|
||
Not going to make the 0.3 train. ssitter: Do you want this one to go with your other Menubar fun?
Target Milestone: Sunbird 0.3 → Sunbird 0.4
Comment 32•17 years ago
|
||
We're at the string freeze. Bumping this to 0.7 and denying blocking-calendar0.5
Flags: blocking-calendar0.5? → blocking-calendar0.5-
Target Milestone: Sunbird 0.5 → Sunbird 0.7
Updated•17 years ago
|
Flags: wanted-calendar0.8?
Updated•17 years ago
|
Target Milestone: 0.7 → ---
Version: Trunk → unspecified
Updated•17 years ago
|
Attachment #207735 -
Attachment description: Make 'Open Calendar' work, V5 → [checked in] Make 'Open Calendar' work, V5
Comment 33•17 years ago
|
||
It would be good to have this 0.8
Flags: wanted-calendar0.8?
Flags: wanted-calendar0.8+
Flags: blocking-calendar0.5-
Comment 34•17 years ago
|
||
This patch takes care of this issue by simply removing the "Subscribe to remote Calendar" menuitem. Asking for UI-review from Christian to get a feedback on whether this is the right choice for this bug.
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #290094 -
Flags: ui-review?(christian.jansen)
Attachment #290094 -
Flags: review?(michael.buettner)
Comment 35•17 years ago
|
||
Sorry for the delay, I'll do the ui review as soon I can build on Leopard....
Comment 36•17 years ago
|
||
Comment on attachment 290094 [details] [diff] [review] Remove "subscribe to remote calendar" from Sunbird File menu r=mickey.
Attachment #290094 -
Flags: review?(michael.buettner) → review+
Comment 37•17 years ago
|
||
I'm not sure if we really want to remove "Subscribe to remote Calendar" item, now. I support the approach, but we should focus on redesigning the whole calendar creation respectively subscription process. Removing only the entry point would only confuse people who are using that specific menu item.... In stead of removing "Subscribe to remote Calendar" we should optimize the wizard: - skip the first wizard step, and - hide the iCaledar, CalDav option.
Comment 38•17 years ago
|
||
Christian, IMO we should do it right the first time. I seriously doubt that most fo our users do really distinguish between subscribing to an existing calendar and adding a new calendar. I believe, that for them it's simply "I want to add that cool holiday/football team/course schedule/etc. calendar on www.xyz.com" to my list of calendars. And this use-case is pretty well-covered by our "new calendar" menuitem. I believe what you want to improve is the problem with people choosing "CalDAV" instead of "ICS" or similar input errors. IMO this should be covered by adding appropriate calendar type autodetect code, not by adding/retaining additional menuitems.
Comment 39•17 years ago
|
||
What about renaming the new calendar item to "Add Calendar" ? This could mean both a new calendar and a subscription? Of course this would break the usual New-Open-Save-(Close) logic.
Comment 40•17 years ago
|
||
(In reply to comment #38) > Christian, IMO we should do it right the first time. > > I seriously doubt that most fo our users do really distinguish between > subscribing to an existing calendar and adding a new calendar. I believe, that > for them it's simply "I want to add that cool holiday/football team/course > schedule/etc. calendar on www.xyz.com" to my list of calendars. > Whats so wrong about differentiating between "New" (aka new calendar) and "Open" (aka subscribe to calendar). I do mentally make a difference between the two and most programs seem to offer these two options. I think people might be worried about overwriting existing calendars if they choose "New calendar" while what they want to do is open an existing calendar.
Comment 41•17 years ago
|
||
Philipp, I don't think that renaming "New Calendar" to "Add Calendar" will buy us much. And staying with the current logic has advantages all by itself. Sebastian, in Sunbird we already have a "Open Calendar..." menuitem, which allows to open local .ics files.
Comment 42•17 years ago
|
||
(In reply to comment #41) > Sebastian, in Sunbird we already have a "Open Calendar..." menuitem, which > allows to open local .ics files. Hmm, but thats limited to local files. My main message should have been: I think there should be difference between creating a calendar and subscribing to an existing calendar. Wether its local or remote and wether you call it "open" or "subscribe" does not matter so much wrt this point.
Comment 43•17 years ago
|
||
There is no difference between creating a new calendar file and subscribing to an existing file for a normal user. For him it's all the same thing, he adds a new calendar to his Sunbird/Lightning installation. The different semantics of creating a new calendar or subscribing to an existing calendar is something for computer-literate people like us, but nothing to molest normal users with. I recommend the KISS principle here.
Comment 44•17 years ago
|
||
With that reasoning, word processors don't need to distinguish between 'open' and 'new' either. Yet they do. Until we can do user-testing, I think we should stick to what other applications do.
Updated•17 years ago
|
Priority: P3 → --
Comment 45•16 years ago
|
||
(In reply to comment #3) > If you're creating a new file (save as), then > Note the problem here. If "create new file" really means "save as", then the wording of the interface is clearly not indicative of the action that will result. To add to that, I've been wracking my brains trying to figure out how to share a calendar on a networked file system. I finally stumbled across the mechanism on a simlarly misnamed path: 1. Choose "subscribe to calendar". The word "subscribe" clearly suggests an existing calendar, so I tried every option possible until finally reaching that one as a last resort. 2. The dialog box /now/ gives the information that you can create a calendar to share on either the network or the file system. I'm going to have to think more about the menu options really ought to be, but at the moment the choices are pretty clearly a bug in what otherwise is an exceptionally good interface and superb functionality. (I see myself using this particular app for a long, long time.)
Comment 46•16 years ago
|
||
(In reply to comment #41) > Philipp, I don't think that renaming "New Calendar" to "Add Calendar" will buy > us much. And staying with the current logic has advantages all by itself. > On the contrary. The operation of "new" is well defined by every editor in existence, so expectation as to its behavior is well established. If I select "new", I expect to create a brand new calendar--a blank slate with nothing in it. Until I read this particular message, I had no idea that it would do anything other than that. If the operation is to add an existing calender to the ones I'm viewing, then "Add" is a much better choice. At this point, I'm beginning to see that the SunBird is not a "calendar", so much as a "Calendar Viewer", or "Calendar Aggregator". I think that expectation needs to be set up front in the first web page that explains what SunBird is. (Again, until reading this message, I had no idea it did that.)
Comment 47•16 years ago
|
||
(In reply to comment #38) > > I seriously doubt that most fo our users do really distinguish between > subscribing to an existing calendar and adding a new calendar. > Reading through these messages has led me to reconceptualize SunBird/Lightning as a "Calendar Aggregator". With that paradigm, "subscribe" is way better than "add", and both are a million times better than "new" (which should be removed until it implements behavior that is consistent with every other app in existence).
Comment 49•16 years ago
|
||
Can't we just rename it to "New/Add Calendar"?
Comment 50•16 years ago
|
||
(In reply to comment #49) > Can't we just rename it to "New/Add Calendar"? > The first step is to identify the desired behaviors. The next is to give them meaningful names. The third is to see what people thing and respond to their feedback. I was astonished once again, today, when I chose "subscribe". I'm on my system at home, and the idea was to point to the calendar I made last night. Subscribe seemed like the right choice. Wrong! "Subscribe" doesn't give me any option at all to select an existing calendar. It /only/ lets me create one. Egad. (The "open" method is obviously the one I want. My mental model is improving.) So maybe at this point I can hazard a guess as to step 1: What behaviors are needed. Here's what I see so far: * Create a blank calendar, give it a name and a storage location * Open a calendar to edit it * Save an existing calendar under a new name * Share a calendar via publish/subscribe There are also seem to be multiple technologies: local file storage, WebDAV, and CalDAV (not familiar with that last one). My initial matrix of those combinations, along with menu names and behaviors, would then look something like this: NEW -- create a blank calendar location=network -- create it via WebDAV location=local -- create it in the file system OPEN -- edit a calendar location=network -- access it via WebDAV location=local -- access it from the file system SAVE AS -- save under a new name location=network -- via WebDAV location=local -- via the file system PUBLISH -- create a read-only version that others can watch location=network -- create/update via WebDAV (CalDAV?) location=local -- create .ics file SUBSCRIBE -- as with Publish Notes: * I'm still unclear on what export is supposed to do. But if it isn't converting to a new format, it should be named "Save As". Export and import are for conversions. * Not having a "Save" makes me nervous. I know. It really shouldn't be needed. I'm old school. I have hard time getting used to things that don't let Ctrl+S when I lean back and stop typing. If there were some way to allay my fears in the docs, a tooltip, or a daily tip, that would be great. :_)
Comment 51•16 years ago
|
||
It occurs to me that there is another behavior that is insufficiently telegraphed by the interface. The "current" calendar is the one that events are saved to. But I only learned that by reading the bug reports. So once I attached to an existing calendar, I was supposed to remove the default. Of course, I forgot to do that, so events stored from one location were not visible in the other location. The "surprising" behavior occurred there is nothing in the interface that tells me where an even is being saved. I like the idea that the app is a multi-calendar interface, but it seems to me that the logical extension of that behavior is that I might want to post an event to one of several calendars--one for my project, one for my home system, and one for an external group or activity, at a minimum. In those circumstances, I need an interface that does more than rely on me to click the calendars tab and know that the top calendar in the list is the one that the event will be saved to. (Assuming that is the behavior. Lacking docs, there is no way to know.) Some ways to improve the interface in this respect: * Preferences can have a setting "Currently saving to" * The title bar can display the save-target calendar * When creating an event, the dialog can have a drop down with a list of potential targets
Comment 52•16 years ago
|
||
Note: Did I mention that I really love this app? It also happens to be one I desperately need. Hence the extensive feedback. Apologies for excessive verbosity.
Comment 53•16 years ago
|
||
Eric, your comment 51 is handled in bug 366914.
Comment 54•16 years ago
|
||
as for the third point raised in comment 51: this dropdown already exists in the event-dialog for a single calendar.
Comment 55•16 years ago
|
||
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Updated•16 years ago
|
Flags: wanted-calendar0.8- → wanted-calendar0.9+
Comment 56•16 years ago
|
||
Comment on attachment 290094 [details] [diff] [review] Remove "subscribe to remote calendar" from Sunbird File menu Simon, is this patch still up for discussion, or obsolete?
Comment 57•16 years ago
|
||
This patch is still up for discussion, as I'm still waiting on a final decision here from Christian. He only commented once in this bug (comment 37), but never replied to my statement in comment 38. Unless I get a ui-review- or ui-review+ I consider this bug to be open.
Updated•16 years ago
|
Flags: wanted-calendar0.9+ → wanted-calendar1.0+
Comment 58•15 years ago
|
||
Comment on attachment 290094 [details] [diff] [review] Remove "subscribe to remote calendar" from Sunbird File menu Bryan, could you take a look at this, please? The use-case I'm trying Sunbird to optimize for is that most of our users do not distinguish between subscribing to an existing calendar and adding a new calendar. I believe, that for them it's simply "I want to add that cool holiday/ football team/ course schedule/etc. calendar on www.xyz.com" to my list of calendars. And this use-case is pretty well-covered by our "new calendar" menuitem. Thanks for your time.
Attachment #290094 -
Flags: ui-review?(chris.j.bugzilla) → ui-review?(clarkbw)
Comment 59•15 years ago
|
||
Comment on attachment 290094 [details] [diff] [review] Remove "subscribe to remote calendar" from Sunbird File menu I think what Philipp recommended in comment #39, "Add Calendar", sounds the best to me. This text description seems right on for a use case and I can't see how "New Calendar" would fit in there. > I believe, that for them it's simply "I want to add that cool > holiday/ football team/ course > schedule/etc. calendar on www.xyz.com" to my list of calendars. I agree that removing the "Subscribe" option is a win as well so I'd give a ui-r+ to remove subscribe and change the new to add. I didn't see many arguments against using "Add Calendar..." but I might have missed them. Also I think we should file a bug for Christian's concern in comment #37. The menuitem text is important but the rest of the experience is really lacking as well. minus for now until we have some discussion and reach agreement
Attachment #290094 -
Flags: ui-review?(clarkbw) → ui-review-
Comment 60•14 years ago
|
||
I'm not going to work on this in the foreseeable future.
Assignee: bugzilla → nobody
Status: ASSIGNED → NEW
Comment 61•8 years ago
|
||
Sunbird is discontinued and not actively developed anymore.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 62•8 years ago
|
||
True, Sunbird is dead. Let's move this to Thunderbird/Calendar and concentrate on it.
Status: RESOLVED → REOPENED
Component: Sunbird Only → Dialogs
Resolution: WONTFIX → ---
Comment 63•8 years ago
|
||
The reporzed issue isn't any im current TB. Please elaborate what's the TB issue here.
Flags: needinfo?(lapsap7+mz)
Whiteboard: [close me 2016-03-26]
Comment 64•8 years ago
|
||
Resolving incomplete. If you can provide the requested information, please feel free to reopen.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Flags: needinfo?(lapsap7+mz)
Resolution: --- → INCOMPLETE
Whiteboard: [close me 2016-03-26]
You need to log in
before you can comment on or make changes to this bug.
Description
•