Open Bug 462279 Opened 16 years ago Updated 3 years ago

using a lock icon to indicate that a calendar is read-only seems confusing

Categories

(Calendar :: General, defect)

Product:
Calendar
Component:
General
Type:
defect

Tracking

(Not tracked)

People

(Reporter: dmosedale, Unassigned)

Details

Since much of the world is trained to think of locks being related to security and SSL. I'll leave it up to clarkbw to set the tb-integration flag appropriately.
Flags: tb-integration?
assigning to bryan to make sure it gets on his radar
Assignee: nobody → clarkbw
Definitely agree that we can't continue using the lock icon as it dilutes the meaning of the lock; which is supposed to mean some sense of 'secure'. I'm not entirely sure that we need an icon indicating read-only status from this area. We could try grouping read-only calendars under a new parent to show they are read-only; however I don't like how that would likely force us to have a "Read-Only" header.
I think it's going to be desirable to support arbitrary groups of calendars designated by the user (eg Work & Personal), so that may conflict to some degree with using grouping here.
For the read-only icon you could use a pencil with a red circle around it and a red line through it. If red is too loud you could use black.
Flags: tb-integration? → tb-integration+
To me grouping doesn't solve the problem, e.g. I'd like to see both read-only and writable "Work" calendars under the same group/category.
I can imagine that grayed out Calendar Name String would work appropriate. In addition the Status Bar, or a ToolTip could indicate the state of the currently selected Calendar. | +--------------------------------------- -- - | Calendar: Christian Jansen (Read Only) +---------------------------------------- -- -
Another idea that came up is to use a cursive font for read-only calendars and drop that icon.
I'm still a little unclear why we need to know (as shown in the list) which calendars are read-only. To me the information seems a little extraneous in this position. Changing or creating and event seems like the only time the read-only status effects the users course of action. Selecting calendars to view (the purpose of this list) doesn't seem particularly effected by read-only status. Perhaps we can just remove the icon and, as Christian said, add in a tooltip indicating the calendar is read-only?
BTW: iCal doesn't have read-only markers and pops up a modal dialog once I try to modify a read-only calendar. I don't like modal dialogs, but some feedback with assistance would be nice. I know from many users that they just don't care about calendar selection and usually just wonder why they can't drag new events.
I'd like to see some traction on this bug...
I chatted w/ Christian this week about this bug. Lets remove the lock icon from this list as it doesn't affect the users situation. Whether a calendar is read-only or not isn't a factor in viewing the calendar. The only situation that is affected is the edit / new calendar (or task) situation. There might be some related bugs where providers aren't setting the read-only flag properly. I"m seeing this especially with remote ics files. The resulting situation gives an error after trying to create an event or task on a calendar that doesn't allow writing. These bugs need to be addressed and fixed individually. Another separate possible issue is that the read-only checkbox isn't an available action for some calendar provides. Again in my situation with a remote ics file there is no way to make it writable. The checkbox should be checked and insensitive in this case.
> BTW: iCal doesn't have read-only markers and pops up a modal dialog once I try > to modify a read-only calendar. I don't like modal dialogs, but some feedback > with assistance would be nice. I know from many users that they just don't care > about calendar selection and usually just wonder why they can't drag new > events. Currently if a calendar is properly marked read-only you can't drag the event around at all. I think this is the correct thing to do. We don't offer any options to copy the event to a local calendar from the read-only event dialog, something that might be nice.
(In reply to comment #12) > > I know from many users that they just don't care > > about calendar selection and usually just wonder why they can't drag new > > events. > > Currently if a calendar is properly marked read-only you can't drag the event > around at all. I think this is the correct thing to do. The behavior that I think Daniel was referring to (and that I personally find aggravating) is that I'm used to creating events by holding down the mouse button and dragging, iCal-style. Most of the time I have a writable calendar selected, so this just works, but if a read-only calendar is selected, dragging causes nothing to happen with no particular feedback as to why the behavior is different.
I vote against removing the icon. For example I need it to quickly check what calendars are read-only. Without the icon I would be forced to check the calendar property dialog or the tooltip for each calendar separately. And I can't really understand the reasoning for removing it. We used it for a long time and nobody complained. For example Gnome and the Tango icon project seem to use a lock icon for read-only. For example Apple seems to use a lock icon for read-only (http://i13.tinypic.com/4kwm9au.jpg). And as far as I know Firefox 3 went away from using the lock icon as a security indicator.
> The behavior that I think Daniel was referring to (and that I personally find > aggravating) is that I'm used to creating events by holding down the mouse > button and dragging, iCal-style. Most of the time I have a writable calendar > selected, so this just works, but if a read-only calendar is selected, dragging > causes nothing to happen with no particular feedback as to why the behavior is > different. Curse you focus! When I tried creating an event (via double-clicking an empty area) with a read-only calendar selected and a read/write calendar available. A new event dialog appeared with the read/write calendar selected. Of course the dialog is a bit cluttered so the selected calendar isn't the most obvious thing, however that worked for me. Is this just an issue of the dragging behavior being different?
Double-clicking does the right thing, yes. Dragging-to-create is the problem.
(In reply to comment #16) > Double-clicking does the right thing, yes. Dragging-to-create is the problem. This is bug 453317.
> This is bug 453317. That is our real bug. Also ical providers should be marking calendars read-only correctly, not sure what bug that is... This change should be pretty easy.
I think we can start moving on this bug
Assignee: clarkbw → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.