change counter in parent tab back to old style

[john12ik2]

In version 0.12.2011120101 you made this change:

Modified: The counter in a parent tab now reports the number of all tabs in the tree including itself.

I've used Tree Style Tab for years and having the counter change is very annoying. Please change it back to old style or make new style optional.

[piroor]

I think it is a matter of getting familiar with it. Actually I confused by the change, but now I've accepted the new behavior on my daily life.

Yes, I can make it optional, but, options generally introduce extra codes which are not run on most environment. So it costs to maintain. Generally I hope to reduce number of options. I think I should make a new behavior optional only if it can be critical issue (for example, some new features can break user data.) In other words, I think this counter issue is not a critical problem.

[john12ik2]

May i ask why you changed it to new style? Were a lot of people asking for new style? Why not just leave it as old style?

[piroor]

See discussions on #183.

Initially I implemented the counter, I didn't care either way - including the tab itself or not. However, on the moment the old style was easier to implement for me, so I decided to use the old style. Note, the decision is based on a negative reason - "easy to implement", not "better behavior as a GUI".

And, on #183, I got the first report saying "this seems to be a bug, and the counter should include the tab itself." I never got such a suggestion. So I went back to the starting point: which is better behavior? And, because it is not hard to include the number of the parent tab itself now (yes, I've grown as a programmer!), I decided to change the behavior.

[john12ik2]

Thank you for explanation.

I hope you consider making new counter optional because that was only 1 bug report after years of TST using old counter. So most people who use TST understand old counter and are used to old counter.

[PalulyHill]

I believe it's better to change counter in back to old style. The new style doesn't make any sense. You start with tab that has no number, then when you add child tab it jumps to "2". There is no "1" which makes no sense and is confusing and not something a person should "get familiar with"

[piroor]

I want to listen to Drugoy's opinion.

[piroor]

1. In horizontal tab bar, TST shows collapsed tree as stacked tabs. In this context, the counter clearly should include the parent tab itself. I strongly agreed to this point.
2. I believe that an UI should have just one role, one meaning. In old versions the counter was "the counter for the number of collapsed tabs in the tree". However, it is "the counter for the number of tabs in the tree" now. They are surely different.
3. I actually got a suggestion like: "please switch horizontal tab bar and vertical one by number of tabs - vertical for too many tabs, horizontal for little tabs".

By the reason 3, I have to take care of people who want to switch the position of the tab bar frequently. (However, this reason is weaker than others. Even if most people don't change the position of the tab bar, 2 and 1 are still important.) By the reason 2, I don't want to switch the role of the counter for horizontal and vertical tab bar. By the reason 1, leastwise the counter must count up the parent tab itself in horizontal tab bar.

On the other hand, of course, "changing" can confuse people. Actually, you noticed that the role of the counter was changed. I also know a lot of people dislike new UI introduced on Firefox 4 ("Tabs on Top", "Firefox button", "hidden status bar", and so on.) Changing is always painful for existing consumers.

We developers always have to choose one of them: existing users vs new comers. "Making old behavior optional" generally makes both consumers happy. However, note, there is the third person: the developer himself. Optional behaviors grow number of lines of source codes. I'm developing this addon Tree Style Tab just personally. This is very different point about TST and Firefox. I usually suffer from large codes, so I want to diet this addon. (Yes, as you know, in most cases I fail it - source codes of TST are growing on every releases - but I surely want to do it.) I don't want to introduce optional choices for non-critical issues anymore. To keep developing addons for future releases of Firefox, this is very important thing for personal projects.

And as a consumer of Firefox, I don't want to be locked in to a specific old version of Firefox. In old days I actually locked into Firefox 1.5 for a long time, because I locked into my old addon "Tabbrowser Extensions" depends on old Firefox. It was too huge to be updated for Firefox 2. So I had to use Firefox 1.5 until it became completely out of date. I don't want to repeat such a stupid thing.

[tyuicttycdl]

I came to post this bug and am disappointed to find that this was done on purpose.

For all the reasons already stated please change back to old way. New way is worse. You have to get "used to it" because it doesn't make sense. Old way didn't need getting used to.

New way should be optional for those people who want it.

[Knupsiul]

The numbering should be changed back. It's no good for vertical tabs. The new numbering should be optional or only applied for horizontal tabs.

[stevecx2]

I think the numbering should be changed back. More people want old style than new style, so why try force it on people?

[piroor]

Does anyone know another example similar to this counter, in another software? Then I'm ready for "back" to the old behavior for vertical tab bar, because it is important thing that we should copy the design of existing known UI when we design new UI.

Otherwise I think I can change the behavior irreversibly in some cases. (I told reasons to do it on #197 (comment) so I don't repeat it here. Read it please.) If there is no other software including UI like this, new comers won't be confused because the counter is not different to other existing known UI -- because it is unique.

[stevecx2]

Why are newcomers more important than the people who have been already using your software for years?

And in response to other software, any windows file manager such as built in windows explorer, Xplorer2, ExplorerXP, FreeCommander, etc will show the number of objects/items inside the folder [same as old style TST counter] when you select a folder. The counter is shown in status bar whereas in TST the counter is shown next to parent tab. So the only difference is location of counter, but they all use the counter to represent number of items inside and do not count parent folder/tab itself in the counter.

[piroor]

"New comers" means "myself in future" for me. Because I have very poor memory，I have to learn the UI every time if I use it after so long. This is the main reason why I think I should design my UI for new comers. (So, I don't like UI which requires learning like Vim - vimperator, Emacs - KeySnail, and so on. TST is designed for me at first.)

Okay, now we can move the discussion forward. Because no one pointed similar implementations, I couldn't believe that the old behavior is better than the current.

[stevecx2]

So will you change back to old behavior?

Also you make the extension Multiple Tab Handler. TST and Multiple Tab Handler both make tabs behave very similarly to a file manager. This similarity is what makes the extensions so useful because many people already are familiar to navigating windows explorer. Those file managers all use the counter to represent number of child items inside and do not include parent folder in the counter like you are doing with new behavior.

[CullenFan]

stevecx2 is right. The new TST counter is creating new UI which is causing the problem. I understand TST quickly because I'm used to using windows explorer but now TST is acting different than windows explorer causing confusion.

[piroor]

So will you change back to old behavior?

Maybe. It can be a reasonable solution that two modes for the counter - in vertical tab bar it should indicate count of descendants, in horizontal tab bar it should indicate count of all tabs in the tree. (One difference is that TST counts descendants but Windows Explorer counts just only children.) Remaining issue is how can I indicate difference of these two modes of the counter for people. (Color, font size, etc.)

BTW, I still disagree to such opinions "simply back to the old behavior anyway" but I can agree to "TST should respect existing similar implementations". This is the main reason why I obstinately disagreed to back to the old behavior against comments above. Not only about this topic, I hope that reporters post new "issue" with rational reasons which are different from personal habituation problems - sometimes I can't have time to determine the opinion is personal problem or rational problem.

[stevecx2]

 > BTW, I still disagree to such opinions "simply back to the old behavior anyway" but I can agree to "TST should respect existing similar implementations"

This comes down to opinion, but may i politely say that i strongly disagree with that statement. UI models should not just be about rational decisions, user experience matters just as much.

Simple example is english keyboard. It's well established that QWERTY is not the most optimal or rational layout for keys. Research has shown that there are more efficient layouts. If your statement is followed then computer manufacturers should just switch to "better" layout just like you just switched to new counter for TST. But no company will do that because being rational isn't the only thing, it also matters what people are used to.

[piroor]

You misunderstood my statement. QWERTY is not right for this case. If I was a designer of keyboards, I'll design products with QWERTY because it is well known existing design made by someone not me. I think I should respect existing design, it's one of my policies. And, it is also another my policy: I should break my old stupid design if it is not rational and there is no similar case.

In the analogy, after I switched positions of "0" and "1" keys, people just said "back to old positions anyway" and no one said that "the old position was same to an well known design QWERTY, so you should respect it". They are quite different. Before you clearly told there is similar UI in Windows Explorer, I didn't know whether it was same to existing major design or not. (Because I didn't think tabs are same to folders, I didn't look into the status bar. Yes, actually this was my fault that I didn't researched about similar features before I changed it. I apologize it.)

In other words, I hope that people report "issue"s with clear descriptions: steps to reproduce, actual result, expected result, and, "why" it should be so. The reason can be a W3C specification, an RFC, or an similar major implementation except TST itself. Because I cannot spent all my time for development, I want more help like easy-to-understand bug reports.

[piroor]

Now the counter of tabs have two roles for each mode: vertical tab bar and horizontal tab bar. Currently the role is changed silently (= without visual notification).
17c7280

[PalulyHill]

That's great news. Thank you for the change. I hope to use it in a release soon.

[piroor]

The change is now available in the latest release. I close this.