Bugzilla

(In reply to Thomas D. (:thomas8) from comment #7)
> (In reply to Henry Wilkes [:henry] from comment #6)
> > @thomas8 I think we'll have to think about this. Pressing Enter on an item, or double clicking an item, is understood as "activating" the item.
> 
> Yes. More precisely, **Enter or double-click performs the *default action* associated with an item (often `open`).**
> 
> I think we can agree that **the main purpose of an address book is managing contacts**, so the most typical **one-fits-all default action here should remain `Edit`** (as you say, View already happens on selection).
> 
> > But I'm not sure "activating" a contact item would necessarily be understood as editing it because a contact has a lot of non-editing functionality. I think "show contact details" would be more obvious, but we already show them on changing selection.
> 
> Exactly. The other actions `Write`, `Event`, `Search` are certainly useful, but not suitable as a default here:
> - `Write`: No need to promote and give high-value access to `Write` from AB because it probably makes more sense to just use `recipient autocomplete` or `Contacts Sidebar` for that (which has an incompletely realized default action of `Write`, because it lives in a composition context, where writing would appear the most likely action).
> - `Event`: Certainly very useful, but is it for everyone and could it be the *default action* for a contact in an address book?
> - `Search`: dito
> 
> Iow, those are more like *additional* actions which we offer for convenience (and we could certainly consider giving them dedicated shortcuts).
> 
> > Moreover, the old addressbook "edit" took place in a new window, but the layout is different now with both the view and the edit functionality in the side pane. Therefore, accidentally triggering an edit is more disruptive now.
> 
> Well, accidental double-clicks will always be disruptive in some way - that's not an argument against the double-click. Accidental `Enter` is unlikely. 

Whether or not it is unlikely or not is I think besides the point. 
a) this is reversing long standing behavior that results in efficiency for the user
b) if such accidental activity occurs 1) it is easily reversed by escape key 2) you would hope accidental triggering will eventually train the user to avoid the triggering behavior

> > However, a quick means to edit a contact could be made available via the context menu, which would seem to address your issue of moving the mouse a long way.
> 
> The context menu is needed, but it cannot replace or compete with the ultimate convenience and efficiency of just pressing Enter or double-clicking on a contact to edit it.

I agree, per above
 
> In theory, we could offer a pref and let the user choose his favorite default action, but imo that would be over-engineering, and I'd still argue that any default action other than `Edit` would be a very strange choice for an address book.

yes, that would be over engineering - prefs are to be avoided.

This is effectively a regression of UI.  And while I'm not against changing UI behavior to advance the greater good, I don't see the greater good here.

(In reply to Thomas D. (:thomas8) from comment #7)
> (In reply to Henry Wilkes [:henry] from comment #6)
> > @thomas8 I think we'll have to think about this. Pressing Enter on an item, or double clicking an item, is understood as "activating" the item.
> 
> Yes. More precisely, **Enter or double-click performs the *default action* associated with an item (often `open`).**
> 
> I think we can agree that **the main purpose of an address book is managing contacts**, so the most typical **one-fits-all default action here should remain `Edit`** (as you say, View already happens on selection).
> 
> > But I'm not sure "activating" a contact item would necessarily be understood as editing it because a contact has a lot of non-editing functionality. I think "show contact details" would be more obvious, but we already show them on changing selection.
> 
> Exactly. The other actions `Write`, `Event`, `Search` are certainly useful, but not suitable as a default here:
> - `Write`: No need to promote and give high-value access to `Write` from AB because it probably makes more sense to just use `recipient autocomplete` or `Contacts Sidebar` for that (which has an incompletely realized default action of `Write`, because it lives in a composition context, where writing would appear the most likely action).
> - `Event`: Certainly very useful, but is it for everyone and could it be the *default action* for a contact in an address book?
> - `Search`: dito
> 
> Iow, those are more like *additional* actions which we offer for convenience (and we could certainly consider giving them dedicated shortcuts).
> 
> > Moreover, the old addressbook "edit" took place in a new window, but the layout is different now with both the view and the edit functionality in the side pane. Therefore, accidentally triggering an edit is more disruptive now.
> 
> Well, accidental double-clicks will always be disruptive in some way - that's not an argument against the double-click. Accidental `Enter` is unlikely. 

Whether or not it (accidental double-clicks) is unlikely or not is I think besides the point. 
a) this is reversing long standing behavior that results in efficiency for the user
b) if such accidental activity occurs 1) it is easily reversed by escape key 2) you would hope accidental triggering will eventually train the user to avoid the triggering behavior

> > However, a quick means to edit a contact could be made available via the context menu, which would seem to address your issue of moving the mouse a long way.
> 
> The context menu is needed, but it cannot replace or compete with the ultimate convenience and efficiency of just pressing Enter or double-clicking on a contact to edit it.

I agree, per above
 
> In theory, we could offer a pref and let the user choose his favorite default action, but imo that would be over-engineering, and I'd still argue that any default action other than `Edit` would be a very strange choice for an address book.

yes, that would be over engineering - prefs are to be avoided.

This is effectively a regression of UI.  And while I'm not against changing UI behavior to advance the greater good, I don't see the greater good here.