(In reply to Deven Corzine from comment #43) > How does such an obvious bug get filed and debated for year (2013), after > year (2012), after year (2011), after year (2010), after year (2009), after > year (2008), after year (2007), after year (2006)... but never actually > fixed?
Deven, thanks for your feedback. I appreciate the frustration, as I've often felt it myself (being an active volunteer TB QA/UX contributor since 2007). However, we need to face the fact that TB has a track record of unresolved bugs for a variety of reasons. Where this bug is just one out of many, and the choice of "important" bugs to start from is pretty vast. TB is now maintained almost exclusively by volunteers, so getting this bug fixed requires a volunteer who is a) able, b) willing, and c) has the time to actually fix this, and d) an agreement about the exact goal of this bug, the desired UX how it should be fixed. a) and c) are the hard parts, whereas I'd consider d) a non-issue in this case (although looking at the entirety of comment 0, to which comment 12 responds, I suspect misunderstandings about d) also contributed to the long latency of this bug). > This worked in Thunderbird 2, which means it's a regression bug, not an > enhancement. Deven (and others before), thanks for pointing that out. Understanding the nature of a bug and documenting that as precisely as possible in the bug report is crucial. Indeed, this looks like a bug because it violates the very purpose of the nickname design, which is a 1 on 1 relationship between the (ideally unique) nick and the card, to allow user to retrieve and distinguish that card efficiently and consistently from all other cards. (As a caveat, note that TB is not enforcing uniqueness of nicks!). As has often been said in this bug, users correctly expect from the intrinsic purpose of nickname design, that nicks should have absolute priority in searches, which includes priority over frecency. Frecency is a way of automatically establishing dynamic nicks, but certainly nicks that have been purposefully and explicitly defined by user must take precedence over that (why should I add "wil" as a nick to my uncle's card if I don't want "wil" to find that very card?). Users who want the frecency algorithm to take highest precedence probably wouldn't (and shouldn't) define explicit nicks. Due to violation of these imo correct, established, and widely-evidenced user expectations, this is a bug in terms of UX error prevention where users can easily inadvertently send the msg to the wrong recipient(s), which is a major violation of their privacy. As such, this bug also undermines UX trust in TB as an application, as repeatedly stated here in line of comment 0 and comment 43: > You may not think this is important, but anything that causes mail to get > sent to > the wrong user inadvertantly is just about he worst possible problem a mailer > can have. > There has been ample evidence that this seemingly-minor issue > is a major source of frustration to many users, even to the point of > abandoning Thunderbird entirely. It may be a little thing, but that doesn't > mean it doesn't matter. > > Instead of debating the best algorithm for years, why not at least add a > special-case check for an exact match of a unique nickname, before going > into the current algorithm? That would satisfy the critical use case, > making most of the frustrated users happy. A special-case should be trivial > to add, for anyone who knows the code, so why hasn't that much been done > after nearly 8 years of this ticket being marked as NEW? See my remarks further up in this comment. Getting bugs fixed in TB is often less trivial than it looks, for a variety of reasons... FTR: I agree that the obvious solution to this bug (as required by the intrinsic principles of "nicks" design concept) is to list fullstring matches on nicks at the very top of the recipient autocomplete dropdown, so that they take highest precedence (even before frecency if we implement that). Btw FF works the same way for keywords: Keywords (not tags, nor frecency) take absolute highest priority over any other matches. Think of keywords and nicks as an ALIAS for the real thing. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address Status in Mozilla Thunderbird Mail and News: Confirmed Status in “thunderbird” package in Ubuntu: New Bug description: From what I have read in the support forum the nickname should take priority in the search for an email address in the to: field. It does not appear to work any more. Example: One friend's address is Mark<m...@yyyy.com>. The other is James<james.m...@xxxx.com>. Both are in my address book with Mark entered as the nickname of m...@yyyy.com and James as nickname for james.m...@xxxx.com. If I type james in the To: field I get james.mark as a first entry in the list of available addresses. If I type mark I get the same address again, when I would prefer the first optional address to be m...@yyyy.com Reason it is needed: I am trying to avoid sending emails meant for m...@yyyy.com to James.mark because I do not notice in time that I have defaulted to the first entry in the list of available addresses. ProblemType: Bug DistroRelease: Ubuntu 11.10 Package: thunderbird 10.0.2+build1-0ubuntu0.11.10.1 ProcVersionSignature: Ubuntu 3.0.0-16.29-generic-pae 3.0.20 Uname: Linux 3.0.0-16-generic-pae i686 ApportVersion: 1.23-0ubuntu4 Architecture: i386 BuildID: 20120216123548 Date: Fri Mar 16 00:31:06 2012 InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012) SourcePackage: thunderbird UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
