Thomas D. (:thomas8) Reporter
	Description • 7 years ago

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

STR:

1) Compose one message, e.g. with subject "private msg1"
2) In contacts side bar, intentionally drill down to a message-specific AB, say "My private AB 1"
3) Save and close draft to continue later (perhaps without adding any recipients; or after adding some, but not all recipients as it's still work in progress).

4.1) Compose another message, e.g. with subject "business msg2"
4.2) In contacts side bar, intentionally drill down to a message-specific AB, say "My business AB 2"
4.3) Save and close draft to continue later.

5.1) Reopen "private msg1", with an intention of continuing to add recipients from where you left.

Optionally,
5.2) Re-select "My private AB"
5.3) Re-open "business msg 2"

Actual result

5.1) * When reopening "private msg1", TB presents "My business AB 2" in contacts side bar. The original context of "My private AB 1" is lost.
5.2) * When reopening "business msg2", TB presents "My private AB" in contacts side bar. The original context of "My business AB" is lost.
* I.e. we remember whichever AB was last chosen on a random and potentially unrelated message, and present that for reopenend drafts. Which is mostly not helpful because users may intentionally select a message-specific AB.

Expected result

* TB should present "My private AB" when re-opening the draft, as that's what I intentionally selected for this message before closing it.
* I.e. for when saving and reopening a draft msg, we should remember whichever AB was last shown in contacts sidebar with this specific draft, as we have no reason to assume that a random AB selected for another msg which happens to be the last edited msg is the better choice for this existing draft.
* More generally, when saving and reopening drafts, we should seek to preserve the status of the entire composition as exactly as possible as seen when closing

	Thomas D. (:thomas8) Reporter
	Comment 1 • 7 years ago

Proposed implementation:

When saving drafts, save the specific AB currently selected in contacts side bar into the x-mozilla-draft header where we already store other draft-specific information like attachment reminder status.
When opening drafts, restore the selected AB from the draft's x-mozilla-draft header.
Note that this applies to re-opening existing drafts only, not to starting new compositions.

The x-mozilla-draft part should be relatively easy to code in analogy to attachment reminder, as seen in bug 521158, attachment 825270 [details] [diff] [review].

	Thomas D. (:thomas8) Reporter
	Comment 2 • 7 years ago

Having to re-select a specific AB which I had already selected with this specific composition reduces ux-control and ux-efficiency.
Preserving composition state wrt the AB selected for a specific composition improves ux-control and ux-efficiency.
Existing feedback from users suggests that they are very sensitive about seeing an unexpected/unhelpful AB in their compositions.

Richard, does the idea of this bug sound good to you?

	Magnus Melin [:mkmelin]
	Comment 3 • 7 years ago

Sorry, but I really have to say, no, this is not something anyone should be spending time on.

Let's not over complicate things. Even if it would happen to be a different address book (which you don't know), it's just one click away.

	Thomas D. (:thomas8) Reporter
	Comment 4 • 7 years ago

(In reply to Magnus Melin from comment #3)
> Sorry, but I really have to say, no, this is not something anyone should be
> spending time on.
> 
> Let's not over complicate things. Even if it would happen to be a different
> address book (which you don't know), it's just one click away.

!!!???

I'm speechless, to say the least...

Of course, we are talking detail, but still... isn't ux-efficiency in the detail?

Anyway, I'll reserve my comment bc I've already painstakingly laid out my point above and anything I say from now on will probably be used against me...

Maybe users and user support representatives who have advocated for saving "just one click" in similar bug 1142705, bug 1236553 (which triggered my current round here), or similar bug 1177706 / bug 1308776, can add their perspective?
(Note that this applies only to re-opening existing drafts only, not to starting new compositions.)

Does this mean that ux-efficiency (here: reducing the number of clicks needed to get things done in basic scenarios) is no longer an accepted principle of TB UX?

What about ux-consistency... I remember we have a whole range of bugs filed for preserving the exact UI status of tabs? Why is NOT remembering the exact UI status of a given composition better than remembering?

What do others think?

	Thomas D. (:thomas8) Reporter
	Comment 5 • 7 years ago

So if it doesn't matter which AB is shown with a specific composition, why don't we just apply the last selected AB from contacts side bar of /any/ composition /immediately/ to all other open compositions? Interestingly, we currently allow the user to pick a specific AB for each open composition, and switching back and forth between compositions preserves that per-draft state of contacts side bar. Only after closing and reopening drafts, those per-draft choices get lost (this bug), and we open any existing composition on the last used AB from another message.

	Jorg K (CEST = GMT+2)
	Comment 6 • 7 years ago

Since the question was asked, personally I think that the X-Mozilla-Draft-Info should *not* be used to store the state of the UI when composing a message. This header is for representing user choices when sending the message, like DSN, return receipt, delivery format. OK, the attachment reminder information is also stored there.

Although contributors can of course choose the area of their contribution, I'd appreciate very much if some long-standing and rather puzzling problems got fixed, for example bug 1329295 or some of his friends from meta-bug 758969, or more recently bug 1352079, instead of investing contributors' and reviewers' time here.

	Charles
	Comment 7 • 7 years ago

(In reply to Jorg K (GMT+2) from comment #6)
> Although contributors can of course choose the area of their contribution,
> I'd appreciate very much if some long-standing and rather puzzling problems
> got fixed, for example bug 1329295 or some of his friends from meta-bug
> 758969, or more recently bug 1352079, instead of investing contributors' and
> reviewers' time here.

Magnus, and to a lesser extent Jorg, with all due respect, I'm more than a little put off by the comments regarding Thomas' work here.

Thomas has contributed a lot here in the bugzilla forums, and elsewhere, and he obviously feels strongly enough about this issue to work on it, and I think it is inappropriate for either of you, especially considering your new Council Memberships, to use this forum to publicly flog people working on what they choose to spend their time working on.

If you want to play bug shepherd, I think there are better ways and more appropriate places to do so.

What, or why do either of you care if Thomas' chooses to fix this??

	Magnus Melin [:mkmelin]
	Comment 8 • 7 years ago

Please try to look at the bigger picture, any time spent on this is time off from something else. If not from me, then from someone else. Someone to implement, someone to review, someone to work with the code complications it would cause, someone to handle whatever it happens to break now or in the future. These things add up significantly a lot over the years.

All for a feature of questionable usefulness, with likely wrong premises (that you'd enter addresses on more than one occasion, that you want the same addressbook instead of all) and wrong implementation idea (you'd store UI settings in a draft). 

Slightly unrelated but let's face it, the whole existence of different address books is driven by technical constraints, not user desires. The user just want to find their contact, they do not care which address book he/she's in.

We appreciate the time people spend on Thunderbird stuff, but I don't know where you got the idea of anything-goes. There need to be prioritization, and that's actually exactly our job to do. I closed this now, so there would be no complaints of stringing people along.

(In reply to Charles from comment #7)
> What, or why do either of you care if Thomas' chooses to fix this??

I hope the above makes that clear. Also, he didn't offer to fix it, this bug is just filed hoping someone else would.

	Thomas D. (:thomas8) Reporter
	Comment 9 • 7 years ago

(In reply to Jorg K (GMT+2) from comment #6)
> Since the question was asked, personally I think that the
> X-Mozilla-Draft-Info should *not* be used to store the state of the UI when
> composing a message. This header is for representing user choices when
> sending the message, like DSN, return receipt, delivery format. OK, the
> attachment reminder information is also stored there.

Out of general curiosity: Where would be the right place to store per-draft UI state information (i. e. UI information which potentially differs for each draft)? Especially considering IMAP where users expect that their per-message settings are synced across various email clients?

> Although contributors can of course choose the area of their contribution,

Indeed, thanks for acknowledging that...

> I'd appreciate very much if some long-standing and rather puzzling problems
> got fixed, for example bug 1329295 or some of his friends from meta-bug
> 758969, or more recently bug 1352079, instead of investing contributors' and
> reviewers' time here.

Fair enough. However, personally I would neither feel able nor interested to fix any of those bugs you mentioned. I also feel that the amount of time I'd have to spend to make any headway on those even if I tried would be entirely disproportionate to the net improvement, plus more experienced coders could achieve the same in significantly less time. So I believe my valuable time is much better spent on QA/UX rather than struggling with deep coding issues.


(In reply to Magnus Melin from comment #8)
> Please try to look at the bigger picture, any time spent on this is time off
> from something else. If not from me, then from someone else. Someone to
> implement, someone to review, someone to work with the code complications it
> would cause, someone to handle whatever it happens to break now or in the
> future. These things add up significantly a lot over the years.

Yes, any non-trivial improvement of application design and behaviour comes with implementation and maintenance costs, and for a big and sophisticated application like TB, it all adds up. I'm not so much fighting for this particular bug, but I'm worried about these commonplace statements which, if taken as an absolute, would make any non-trivial improvements of TB UX impossible.

> All for a feature of questionable usefulness,

It's all about principled UX design: If we offer a per-message choice of ABs in contacts side bar, which is persisted as long as compositions are open, it's inconsistent to loose those per-message UI states just because the draft is closed and re-opened. Preserving UI state looks like an important requirement of ux-consistency to me. Yes, we're talking details of UI/UX, but those details also add up...

> with likely wrong premises
> (that you'd enter addresses on more than one occasion, that you want the
> same addressbook instead of all)

I'm always surprised when others appear so confident of knowing quite exactly what our users are (not) doing in their workflows. Until proven otherwise, I'd tend to assume that a most workflows which are actually possible in the current design are likely to be used by someone. I'm also convinced that minority workflows matter, for several reasons:
Lots of minorities of a specific workflow can ultimately make up the entire userbase. If we neglect all workflows used by only 5% of our users, we might easily end up ignoring everyone's workflows, and shrink our userbase.

> and wrong implementation idea (you'd store
> UI settings in a draft).

See above, where else should this per-draft info be stored, also for IMAP?

> Slightly unrelated but let's face it, the whole existence of different
> address books is driven by technical constraints, not user desires. The user
> just want to find their contact, they do not care which address book
> he/she's in.

!? That's look like another totally untested hypothesis to me, and a misunderstanding between implementation level and UI. Yes, the underlying implementation of physical files for each AB and the way we store AB information is seriously flawed. However, why would changing the technical implementation (e.g. to a database where grouping of contacts is tag-based) automatically make the UI concept / metaphor of having various address books go away?
Even if we replace the notion of ABs with a notion of tagging, we'll still have distinct (albeit dynamical, intersecting) subsets of contacts, where choosing from a reduced subset is helpful and required for bigger datasets. John Doe in "private AB" can be a different person against "John Doe" from "2017 customers list" and there might be more pseudo-duplicates in other ABs or archives. Depending on individual/corporate workflows and data sets, starting out from limited data-subsets can be crucial. Searching "All Address Books" aka "the entire data pool" is not for everyone.
Yes, we've come to believe that we can "google" everything, but honestly speaking, there's still value in sorted and hierarchical data. Anecdotal evidence, I'm using global search (gloda) maybe a handful of times in a year, because targeted per-folder quick filtering usually finds my messages much more easily. Why search my private account when I'm looking for bugmail? By analogy, same for categorized addresses. Iirc, M$ Windows has changed the entire backend of their file management or search system, but we still have folders in the UI since time immemorial...

> We appreciate the time people spend on Thunderbird stuff, but I don't know
> where you got the idea of anything-goes. There need to be prioritization,
> and that's actually exactly our job to do.

I get your point, but I think there's a difference between prioritizing and shutting down ideas.

> I closed this now, so there would
> be no complaints of stringing people along.

That's appreciated, but maybe we can find some middle ground between shooting an idea down with a two-liner in comment 3 without any public discussion (in the first non-reporter comment), and coming late to the party at comment 100 to shoot things down after lots of cooperative work and brain has already been invested.

> (In reply to Charles from comment #7)
> > What, or why do either of you care if Thomas' chooses to fix this??

It's not about me, but same question goes for anybody who might be willing to fix this...

> I hope the above makes that clear. Also, he didn't offer to fix it, this bug
> is just filed hoping someone else would.

That's true.
I hope that this has been said without even a hint of blame, as describing and filing bugs and developing ideas is just as important as implementing them, even though Jörg tends to disagree. We can't create a better product without some degree of bug management, planning, and refining ideas before coding away.

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 10 • 7 years ago

(In reply to Magnus Melin from comment #8)
> Slightly unrelated but let's face it, the whole existence of different
> address books is driven by technical constraints, not user desires.
When it comes to 'Collected Addresses" vs. "Personal Addressbook", yes. Else if there are > ~30-40 contacts belonging to different scopes (e.g. family, friends, volunteering organizations and their members, institutions, companies), dumping them all in one addressbook creates a mess and makes it a drag to find and select someone e.g. in the contacts sidebar.

	Anje
	Comment 11 • 7 years ago

But how do you choose which address book to set if more than one has been used?
You cannot just auto have address books applied to compositions saved as draft.

Some people may have more complicated addressbooks than others.
Some keep it all in one place. Some people rename/delete address books or move contacts.
If a draft email had old AB info then should the default address book then take precedence upon opening?

What about those people who use drafts to create different versions maybe to send to different people who maybe in different address books, they may be forced to keep changing the already assigned address book. 

Then maybe you'd be wanting to have a separate AB choice menu button on the Composition Toolbar to select for each email or indeed you may not want one set at all and that should be the default selection.

Then you have to ask, if a default address book has been set, then it would need to have an override if another has been manually set when composing a message purely for that particular draft.

People use Address books in various ways, so just because some people want to set per draft message AB's, please remember there are those who would not want this, so the option to set an address book (assuming someone wants to do this) needs to be something the user has to choose manually, maybe like a tag.

Then people will be asking for address books to be set with individual Template emails or could the same be applied to both?
So maybe consider how this may end up being extended.

If I set a default address book to use in the Address Book or in Contacts Sidebar, then I do not want any email header overriding that preset choice whether I save as a draft or template. So, please consider not everyone wants or needs the requested option.

	Magnus Melin [:mkmelin]
	Comment 12 • 7 years ago

(In reply to Sebastian Hengst [:aryx][:archaeopteryx] (needinfo on intermittent or backout) from comment #10)
> When it comes to 'Collected Addresses" vs. "Personal Addressbook", yes. 

Different, but doesn't really warrant different address books. It's only about a tag.

Consider the real world case here, of a physical address book. You may want one for work and one for home, but in the end you do just want to find the persons address, and if someone happens to be in the wrong one that's just inconvenient. If you could look in both in at the same time, with no time difference, that's of course what you would do. Now you happen to be able to do that in the digital world.

	Magnus Melin [:mkmelin]
	Comment 13 • 7 years ago

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #9)
> Out of general curiosity: Where would be the right place to store per-draft
> UI state information (i. e. UI information which potentially differs for
> each draft)? Especially considering IMAP where users expect that their
> per-message settings are synced across various email clients?

Exactly, there's no way of even telling if the other machine has the same address books. The question has no good answer, except that we can conclude that UI settings should not be connected to a given message.

> application like TB, it all adds up. I'm not so much fighting for this
> particular bug, but I'm worried about these commonplace statements which, if
> taken as an absolute, would make any non-trivial improvements of TB UX
> impossible.

That's not my intent. Of course trivial improvements are welcome, as long as they add real value and are not overly complex compared to their added value.

> choosing from a reduced subset is helpful and required for bigger datasets.
> John Doe in "private AB" can be a different person against "John Doe" from
> "2017 customers list" and there might be more pseudo-duplicates in other ABs

While theoretically possible, if you really know more than one person with the same name, you better mark that up properly. Relying on which address book he happens to be in seems very error prone.

> I hope that this has been said without even a hint of blame, a

Yes, no blame intended. Just wanted to clarify.

	Jorg K (CEST = GMT+2)
	Comment 14 • 7 years ago

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #9)
> Fair enough. However, personally I would neither feel able nor interested to
> fix any of those bugs you mentioned. I also feel that the amount of time I'd
> have to spend to make any headway on those even if I tried would be entirely
> disproportionate to the net improvement, plus more experienced coders could
> achieve the same in significantly less time. So I believe my valuable time
> is much better spent on QA/UX rather than struggling with deep coding issues.
It's very nice of you to think the the rest of the developers are geniuses, but we're not. Kent likes to point out that he spends countless hours in the debugger to create three lines of code at the end: Bug 453196 comment #43. We spent many many hours debugging to finally come up with a small fix.

The address book bugs I mentioned perfectly match your modus operandi. The error is somewhere in JS code and you can just add prints to JS code in your flat debug setup. Yes, it's hard work, but it's also satisfying to deliver a solution to users by the end of the day. That's real service to the customer that we all strive for.

	Charles
	Comment 15 • 7 years ago

(In reply to Magnus Melin from comment #8)
> Slightly unrelated but let's face it, the whole existence of different
> address books is driven by technical constraints, not user desires. The user
> just want to find their contact, they do not care which address book
> he/she's in.

Please don't presume to speak for everyone, you will almost certainly often or even usually be wrong.

I for one (and many that I know) go to great pains to segregate my Contacts into different and appropriate Address Books.

That said, I would love to see it redesigned so that, instead of different physical Address Books, you could just organize Contacts using Tags (like Google Contacts).

Hmmm, I wonder if Cardbook does works that way? Gotta find time to play with it, but first have to recreate a new test profile (mine got trashed a while back)...

> We appreciate the time people spend on Thunderbird stuff, but I don't know
> where you got the idea of anything-goes. There need to be prioritization,
> and that's actually exactly our job to do. I closed this now, so there would
> be no complaints of stringing people along.

Well, as long as you don't close it for comments, anyone so inclined can at least continue discussing it and working out the best way forward should anyone step up to do the work.

> (In reply to Charles from comment #7)
> > What, or why do either of you care if Thomas' chooses to fix this??
> 
> I hope the above makes that clear. Also, he didn't offer to fix it, this bug
> is just filed hoping someone else would.

Well, a little more than that, he is trying to wrangle it to a conclusive direction, nothing wrong with that, and again, I fail to see why you care what he or anyone else does with their time in this regard.