675514 - folder name comparison when deciding whether to include account name should be case-insensitive?

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect)

Description

[Jonathan Kamens]

I like the new feature which appends the account name to the folder name in the "Favorite Folders" view if there's another favorite folder with the same name.

However, I wonder if the name comparison which drives this logic should perhaps be case-insensitive. For example, I have one account with a folder called "archive" and one with a folder called "Archive" and sometimes it takes me a while to remember which is which. The account name would help me remember more quickly, and it doesn't seem to hurt anything to add this additional information.

Comment 1

[Jonathan Kamens]

Attachment: patch to make folder name comparisons case-insensitive in favorites folder view

Comment 2

[David :Bienvenu]

Comment on attachment 549689 [details] [diff] [review]
patch to make folder name comparisons case-insensitive in favorites folder view

Blake wanted me to point out that the let line is not indented correctly:

         for each (let item in faves) {
+	  let name = item._folder.abbreviatedName.toLowerCase();

nor is this one:

+        for each (let item in faves) {
+	  let name = item._folder.abbreviatedName.toLowerCase();

we want two space indent everywhere.

Comment 3

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 549689 [details] [diff] [review]
patch to make folder name comparisons case-insensitive in favorites folder view

I agree that asking people to remember the difference between the case of folders in different accounts is unreasonable.

So ui-r=me for this patch!

Thanks,
Blake.

Comment 4

[Jonathan Kamens]

Attachment: same patch with indentation fixed and emacs mode line to prevent recurrence

Comment 5

[Jonathan Kamens]

Comment on attachment 550711 [details] [diff] [review]
same patch with indentation fixed and emacs mode line to prevent recurrence

Woops, that posted before I had a chance to add my comment. This is exactly the same patch but with the indentation fixed (sorry about that!) and an emacs mode line to prevent the problem from recurring for emacs users. I assume it doesn't need another UI review, but I didn't obsolete the prior patch because I didn't want to lose the record of the UI review having taken place; is that the right protocol to use here?

Comment 6

[David :Bienvenu]

Generally, we just carry forward the ui review + to the new patch, along with a comment.

Comment 7

[Jonathan Kamens]

So now I set checkin-needed in Keywords, right?

Comment 8

[Stefan Plewako [:stef]]

(In reply to Jonathan Kamens from comment #0)
> However, I wonder if the name comparison which drives this logic should
> perhaps be case-insensitive. For example, I have one account with a folder
> called "archive" and one with a folder called "Archive" and sometimes it
> takes me a while to remember which is which.

Perhaps treating Inbox, INBOX, inbox and inBOX as the same is not exactly solution for the presented case but this is how you implemented it.

> The account name would help me remember more quickly,

And then what? IMO the folder tooltip is quick enough…

Additionally I don't quite understand why the folder tooltip doesn't help in this case and helps with unique named folders.

> doesn't seem to hurt anything to add this additional information.

Not true - too much of additional garbage was the exact reason to create this.

Comment 9

[Jonathan Kamens]

(In reply to Stefan Plewako from comment #8)
> (In reply to Jonathan Kamens from comment #0)
> > However, I wonder if the name comparison which drives this logic should
> > perhaps be case-insensitive. For example, I have one account with a folder
> > called "archive" and one with a folder called "Archive" and sometimes it
> > takes me a while to remember which is which.
> 
> Perhaps treating Inbox, INBOX, inbox and inBOX as the same is not exactly
> solution for the presented case but this is how you implemented it.

That's an exceedingly contrived example, considering that (a) TB's name for the Inbox folder in particular is hard-coded and not dependent on the case of the actual folder and (b) it's unlikely that anybody is going to name a folder "inBOX".

In any case, the point is that I'm *not* treating folders with varying names like that "as the same," but rather than I'm treating them *as different folders*, but it's hard for users to remember which is which, hence the need to put the account name next to them.

> > The account name would help me remember more quickly,
> 
> And then what? IMO the folder tooltip is quick enough…

I disagree. Apparently Blake does too. I frankly didn't even *know* there were tooltips until I discovered it while working on this patch, and I'm sure there are many other users in the same boat. Even if I'd known, I want to be able to scan the list of folders with my eye and quickly click the one I want; I don't want to have to hover for a second or whatever it is over several folders to figure out which one is the right one. This change makes my workflow faster.

Furthermore, the tooltips don't pop up when you're doing a drag-and-drop, which is a significant use case for the problem my patch solves, because you can't just click on the various folders with the same name to find out which one is the one you want when you'rein the middle of a drag-and-drop.

> Additionally I don't quite understand why the folder tooltip doesn't help in
> this case and helps with unique named folders.

See above.

> > doesn't seem to hurt anything to add this additional information.
> 
> Not true - too much of additional garbage was the exact reason to create
> this.

Whether the account names I added are "additional garbage" is a matter of opinion, about which we apparently disagree.

Comment 10

[Stefan Plewako [:stef]]

(In reply to Jonathan Kamens from comment #9)
> That's an exceedingly contrived example, considering that (a) TB's name for
> the Inbox folder in particular is hard-coded and not dependent on the case
> of the actual folder and (b) it's unlikely that anybody is going to name a
> folder "inBOX".

How much unlikely? Like when someone will name some folders to be included in favorites with only one character case difference? (instead of having them named exactly the same or completely different)

> In any case, the point is that I'm *not* treating folders with varying names
> like that "as the same," but rather than I'm treating them *as different
> folders*, but it's hard for users to remember which is which, hence the need
> to put the account name next to them.

Users are in control of what will be displayed in favorites and in general have control over the names (with only few exceptions). What's the use case here? When users include such two barely distinguishable folders in favorites?

Comment 11

[Jonathan Kamens]

(In reply to Stefan Plewako from comment #10)
> How much unlikely?

Your contrived example is not nearly as likely as, e.g., someone having folders in two accounts whose names differ only in capitalization of the first letter and for whatever reason changing them is difficult. In context within All Folders there is no ambiguity, whereas when they are placed right next to each other in Favorites without context, there *is* ambiguity. Hence my patch.

This is a real world example, unlike yours. The reason why I created this patch is because *it applies to me* and I believe it will apply to others as well, which is why I created the patch.

> Users are in control of what will be displayed in favorites and in general
> have control over the names (with only few exceptions). What's the use case
> here? When users include such two barely distinguishable folders in
> favorites?

This argument applies equally well in the opposite direction. If a user doesn't like that the account name is appearing next to the folder name, he can change the folder name. So the argument that the user is in control of the folder name is irrelevant. All that is relevant is which behavior will be, overall, more intuitive and helpful to users.

Having said that, here are at least two use case from my personal experience:

1. I have folder names with different case in different accounts that I can't change because they are huge and if I change their names they will have to be backed up again under the new name and it'll cost me money and network bandwidth for those backups.

2. I have folders from other users' accounts liked to my IMAP account and I can't change their names.

Comment 12

[Jonathan Kamens]

By the way, saying that users should just change the names of their folders to solve this problem is essentially saying that the users should adapt their workflows to conform to the software. That is NEVER the right answer in UI design. The software should be designed to make it easier for users to do what they want to do, not to force users to change their work habits to make the software do the right thing.

Comment 13

[Stefan Plewako [:stef]]

(In reply to Jonathan Kamens from comment #11)
> Your contrived example is not nearly as likely as, e.g., someone having
> folders in two accounts whose names differ only in capitalization of the
> first letter 

I wonder if I would say a word if your patch would ignore only the case of the first letter… probably not.

> 2. I have folders from other users' accounts liked to my IMAP account and I
> can't change their names.

Finally… the very first reason as it seems.

For me this forms into a question about how often people use imap accounts with shared folders and how much we care about folder distinguishing by characters case.

Comment 14

[Stefan Plewako [:stef]]

(In reply to Jonathan Kamens from comment #12)
> By the way, saying that users should just change the names of their folders
> to solve this problem is essentially saying that the users should adapt
> their workflows to conform to the software. 

So, don't say that and stay on topic, please.

Comment 15

[Jonathan Kamens]

(In reply to Stefan Plewako from comment #14)
> (In reply to Jonathan Kamens from comment #12)
> > By the way, saying that users should just change the names of their folders
> > to solve this problem is essentially saying that the users should adapt
> > their workflows to conform to the software. 
> 
> So, don't say that and stay on topic, please.

I'm not the one who said it, you did.

In response to my claim that the software should behave a certain way in response to folders whose names differ only in case, you asked why the users couldn't just change the names of the folders so they either had the same case or had different names.

You suggested that the user make changes to cause the software to behave the way they wanted, not me.

I don't know why you've got such a chip on your shoulder about this, and I think it's clear to all the CC's reading this thread that you're unnecessarily copping a rather patronizing attitude about the whole thing. I've laid out the case for my change, and both David and Blake agree with me and have approved it, so as far as I can tell, unless they reverse themselves in response to your concerns, which I think is unlikely given that none of your concerns are actually substantively, the patch has been approved and should be checked in.

Comment 16

[Stefan Plewako [:stef]]

(In reply to Jonathan Kamens from comment #15)
> I'm not the one who said it, you did.
> 
> In response to my claim that the software should behave a certain way in
> response to folders whose names differ only in case, you asked why the users
> couldn't just change the names of the folders so they either had the same
> case or had different names.

That is simply not true and anyone could check this easily by reading my (four) comments above and I don't see a reason why I would waste my time any longer arguing with you.

Comment 17

[Justin Wood (:Callek)]

http://hg.mozilla.org/comm-central/rev/aa8e3dd28126