Open Bug 1133652 Opened 9 years ago Updated 2 years ago

Hiding "Address book" column in single-AB views hides it for cross-AB views/search results, too, and vice versa - should allow independent toggling for both types of views

Categories

(MailNews Core :: Address Book, enhancement, P5)

enhancement

Tracking

(Not tracked)

People

(Reporter: thomas8, Unassigned)

References

(Blocks 2 open bugs, )

Details

(Whiteboard: [GS][ux-papercut])

+++ This bug was initially created as a clone of Bug #170270 +++

(In reply to Thomas D. from Bug 170270 comment #143)
> (In reply to Suyash Agarwal (:sshagarwal) from Bug 170270 comment #139)
> > (In reply to Thomas D. from Bug 170270 comment #133)
> > > Here's another issue seen in last try-build of Bug 170270 comment 112:
> > > 
> > > 1) Main AB view, select "PAB" (or any single AB)
> > > 2) deselect "Address Book" column
> > > 3) select "All ABs" and observe columns shown
> > > 
> > > Actual result
> > > 
> > > "Address Book" column is gone for global search results, too, after being
> > > disabled in any single AB (where the column might be optionally useful, but
> > > not generally required).
> > > 
> > > Expected result
> > > 
> > > "Address Book" column in global search results must be toggled independently
> > > from other views.
> > No. It was implemented this way but it didn't pass the review and a few bug
> > reports
> > want it to be present in all ABs.
> 
> No, it was never implemented exactly the way I suggested, and nobody ever
> suggested hiding/showing the column in single-AB views should also hide/show
> it for global search results (where the hiding case is the bigger ux
> problem). Pls list the bug reports.
> 
> > Also, it seems confusing/annoying that you
> > just hid the AB column
> > and it again shows up.
> 
> I'm yet to see the latest patch in action, but let's be clear about the
> "Address book" column:
> 
> - "Address book" column is important information for all *cross-AB* views or
> search results (All ABs, Local ABs, Remote ABs etc.), because results can
> come from various sources so it matters to know the source.
>   -> for search results, it must be *shown* by default; but if user decides
> he doesn't need it in search results, he should still be free to disable it
> *for cross-AB search results*
> 
> - "Address book" column is optional/redundant information for all
> *single-AB* views or searches because the source Address book can quite
> easily be seen from the AB selected in the list of ABs, and all contacts in
> such views always have the same source.
>   -> for single ABs, it must be *hidden* by default because for many/most
> users it'll just waste space; but we could (imo should) still allow users to
> show that column if they so wish because they might find it useful anyway
> (clearer in-situ indication of source AB in multi-AB environments, to avoid
> errors in fast address management).
> 
> So definitely the sane defaults are:
> - Show "Address book" column for *cross*-AB views / search results (but
> allow hiding the column anyway)
> - Hide "Address book" column for *single*-AB views / search results (but
> allow showing the column anyway)
> 
> So definitely we cannot/should not force user to see redundant "Address
> book" column in all of his single-AB views just to preserve it for cross-AB
> views; that would be really odd and our users hate that sort of wasting
> their screen real estate without reason.
> So that requires that we cannot handle hiding/showing of that column the
> same way for single vs. cross-AB views. Hiding the column for single-AB
> views does not imply I want to hide it for cross-AB views / search results
> and vice versa, showing the column for cross-AB views does not mean I want
> to see it on single ABs too, where the source is always the same for all
> contacts seen, and known.
> 
> > > Way forward (to speed up delivery):
> > > 
> > > If it's too hard to get independent column sets, pls restore the old
> > > behaviour where "address book" column is only available to global search
> > > results.
> > It isn't hard its just confusing. If you still think this is necessary,
> > please file
> > a follow up bug.
> 
> Please accept that cross-AB views and single-AB views are different animals
> with different needs, so there's nothing confusing about showing the
> "Address book" where it's needed but hiding it where it's generally not
> needed because it's redundant information. (But, if we can do it without too
> much effort, we could still allow deliberate redundancy if the user so
> wishes as long as we don't force that upon everyone by default).
> 
> For comparison wrt ux-consistency, please look at "Location" column in
> - main message list
> VS
> - global message search results, list-style ("Open as list")
> 
> User can freely hide/show location column in both types of views
> independently of each other, and the choices will be preserved.
> That's exactly what I suggested the different types of AB views, which are
> exactly the same scenario, so we should be ux-consistent.
> 
> Whether it's done in a new bug or here I don't care (to land the feature and
> strings and do all the rest later), but a corrected version (at least
> allowing to show the column for cross-AB views only) should land with the
> first release of the feature.
Depends on: 1136792
No longer depends on: 1136792
This enhancement requires a pref to be added. So, I think, we should get a ui-r and r for this idea.

Thanks.
Blocks: 1167798
(In reply to Suyash Agarwal (:sshagarwal) (away till 19th of May) from comment #2)
> This enhancement requires a pref to be added. So, I think, we should get a
> ui-r and r for this idea.

I'm not sure why this would require a pref? A pref for what exactly?

Just memorizing the status quo of columns independently for "all abs" vs. "any other real ab" imo does NOT require a pref, iirc this can even be memorized using something like XUL persist attributes (not sure about the exact usage), perhaps with different instances of the tree view?

I think this is pretty straight-forward in terms of the desired UX. Avoiding clutter of generally undesired AB column in single ABs is self-evident, as is the need for AB column in cross-AB searches. We also have a very good precedent in message lists where we'll even remember different column sets for *each* folder (and we want the same for ABs in the long run: bug 1167798, with which this bug 1133652 is intersecting or perhaps a subset). And by default, location column gets shown for cross-folder search results and not shown for single folders. Nothing surprising here, just common sense (and based on user feedback).
For users who want the same set of columns for every AB, they are free to have it remembered like that.
To make that more efficient, message list has an option to apply the current-folder column set to all other folders. So we could do the same for ABs after/with bug 1167798.
Summary: Hiding "Address book" column in single-AB views hides it for cross-AB views/search results, too - should allow independent toggling for both types of views → Hiding "Address book" column in single-AB views hides it for cross-AB views/search results, too, and vice versa - should allow independent toggling for both types of views
Priority: P2 → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.