Closed Bug 301792 Opened 19 years ago Closed 16 years ago

The arrow indicating sort direction is reversed, should follow convention of each platform

Categories

(Toolkit :: UI Widgets, defect)

Product:
Toolkit
Component:
UI Widgets
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: deanis74, Unassigned)

References

Details

Compare the column sort arrow in Manage Bookmarks with that in Windows Explorer. They point in opposite directions on I'm trying the approach of a new bug. It doesn't seem like anyone wants to fix bug 93772 for the app suite, but we should fix it for at least Toolkit on Windows and, as far as I can tell, Mac. Let's leav *nix alone, as that was one of the contentions in 93772. The other contention was that this is how it was done in NN4. We're now so far away from NN4 that I don't think that's an argument anymore. We should be consistent with the platform we're running on. Please don't just quickly dupe this against 93772. I'd like to ignore that bug and start fresh here.
Kevin, any thoughts on this?
xref bug 227455 comment 8. I think that following the native scheme is the best way to go, even tho I think Mozilla has it right and Windows/Mac has it wrong. I wouldn't think a preference would be called for, but it would be nice (for me) if the default could be easily overridden in userChrome.css.
*** Bug 313824 has been marked as a duplicate of this bug. ***
Following the OS pref is a really bad idea for people who use Thunderbird on more than one OS. This is different from e.g. OK/Cancel button placement because with that you can see the switch at a glance. With this, it would be very easy to get confused. Gerv
The number of people using Thunderbird on more than one OS is far fewer than the number of people using Windows Explorer and Thunderbird on the same OS.
It's a common practice that ascending sort is shown as pyramid and descending sort as reversed pyramid. For me is very strange to see the reversed pyramid as the sign of ascending sort. It should be redone!
(In reply to comment #6) > It's a common practice that ascending sort is shown as pyramid and descending > sort as reversed pyramid. For me is very strange to see the reversed pyramid as > the sign of ascending sort. It should be redone! > Yes, it is common. But not intuitive for me. Intuition is a per person concept. It cannot be treated as universal. I am an advanced Windows user and I love the Windows GUI (don't blame me for this). For me, when I see an arrow I think in "look in this direction". It can be up, down, right or left. If up is "ascending", what could be a right arrow? No one can tell that "direction thinking" is not intuitive. What is the normal sorting? When someone tells that some list is ordered, what should I think? It "grows" as I read it! And I always read from top to bottom. This is the "normal" expected. So a down arrow tells me that I can read a normally ordered list (from top to bottom or down direction). When I see a top arrow I think it is "reversed" because I don't read from bottom to top. The right and left arrows directions also make sense. Right direction is normal for a Portuguese speaker but left direction is normal form Arabic speakers. Ascending and descending does not apply in this case. So please, if you (somebody) will change based in democracy (majority rules!!) it is OK. And that is the only reason for me. Cheers.
(In reply to comment #7) > For me, when I see an arrow I think in "look in this direction". It can be up, > down, right or left. If up is "ascending", what could be a right arrow? No one > can tell that "direction thinking" is not intuitive. It's not an arrow! It's a pyramid. So, the thicker end of the pyramid shows (in Windows) the more recent records or corresponds to a bigger number in 1,2,3,4,5.... sequence.
(In reply to comment #8) > It's not an arrow! It's a pyramid. So, the thicker end of the pyramid shows (in > Windows) the more recent records or corresponds to a bigger number in > 1,2,3,4,5.... sequence. > If you want to be straight it is a triangle figure. Some persons see arrows (and some few programs actually use arrows), some persons see pyramids and others (me) don´t even look at it (just look to the ordered list to decide to reverse or not). This is NOT intuitive for everyone. But a decision MUST be taken. Finally, my vote is for an arrow point of view.
Here's a different take/question for this issue (as brought up in other comments): Why isn't there an agreement to just add an improvement for a user selectable preference regarding the interpretation of the triangle/arrow/pyramid? If there is, we should link this and all related issues to it and call it settled. Obviously, there are two camps and changing or keeping the current behavior will irritate one or the other. We are dealing with the interpretation of the "arrow" here and there's no right or wrong answer. Some see it as a "pointing" icon that tells you the direction to read (comment #7) while some view it as a "state" icon that gives you the sort state of the list (ascending/descending). Personally, I believe the "pointing" interpretation is subjective because not everyone will agree to what exactly the "arrow" is pointing to: Newest item? Oldest item? The direction to read? The end/start of the list? The "state/magnitude" interpretation, however, has a more general consensus that the pointed end is less than the wide end: 20080423 > 19700101, A(0x0041) < Z(0x005A). Thus ^ means a list in a state where smallest (i.e. oldest time) is at the top. Then again, as long as people don't agree to one interpretation the best solution is to let people choose their preferences.
I agree with Dave, for me it seems obvious that up arrow/pyramid = ascending, but if we can't decide one way or the other then it should be a user preferfence.
BTW, Bug #93772 was opened back in 2001, 4 full years before this one. It's filed against "Core" instead of "Toolkit" (like this one), but as a novice I don't see the difference. I don't care if there is a user preference for this, but I'm completely baffled by some of the comments. In both Mac OS and Windows, the GUI standard for ascending order is an arrow pointing up. The fact that Thunderbird does it "backwards" simply does not make sense. I don't buy the argument about different languages being read in different directions - this is about the order of discrete "lines" in a GUI - they are either alphabetically increasing or decreasing (or increasing/decreasing in a date/time sense) as you go "down" the page. That's what the arrow/pyramid says to mean - "smallest" items are at the top, largest items are at the bottom. I'd like to encourage the Mozilla folks to do the right thing, and have their GUI elements conform to the rest of the major GUI design standards.
(In reply to comment #12) > BTW, Bug #93772 was opened back in 2001, 4 full years before this one. It's > filed against "Core" instead of "Toolkit" (like this one), but as a novice I > don't see the difference. Dean mentions in the original description that he's refiling the bug because #93772 has been neglected for so long. > In both Mac OS and Windows, the GUI standard for > ascending order is an arrow pointing up. The fact that Thunderbird does it > "backwards" simply does not make sense. I've always thought of the icon as an arrow, I don't understand the pyramid thinking at all. How do "smallest" and "largest" map to a timestamp? Nonetheless, even if both positions are well argued, the problem with choosing one way or the other is that there's prior art either way. Yes, the Windows/Mac standard is the opposite of the way it is now, but GTK2 does it the same way Mozilla does. Rather than this bug getting bogged down in the same discussion over the "right way" to do it like #93772 did, which inevitably leads to nothing happening, there should just be a preference for it.
So all in all, is there a bug/request created to implement the user selectable preference? If so which issue is it? If not, how do I go about creating the request (is it any different from creating a bug)? Or should the user preference be implemented under this issue? Based on reading the comments in this and other issues, the "fix" is simple, and thus I'm assuming that inserting an user preference check will not be difficult.
I can see the GTK+ sort arrow documentation, as you described: http://library.gnome.org/devel/gtk/2.12/GtkSettings.html#GtkSettings--gtk-alternative-sort-arrows Note, though, that GTK+ does provide an "alternative" sort arrow that would match what this bug is asking for. If that's trivial to do here, great! But, if getting a new user preference is nearly as difficult as getting a new dialog box / warning (see bug #84128), then we'll be opening a 3rd bug in a couple years, because this one will be abandoned too. I'd like to stick w/ Dean's original request - let's "fix" this to be consistent w/ the host platform.
let's resummarize explicitly to match comment 0 then. the pref thing is something that at most solves bugzilla traffic to some extent if even much of that, not something that would ever touch anywhere near a double-digit percentage of users in any positive way in the products regardless of the default, so it should probably be discussed somewhere else. fwiw I don't think gerv's concern in comment 4 would be a big problem, I expect people pay more attention to the data being sorted than the sort indicator anyway, this is more something that might nag you if you happen to notice it ...icbw of course :)
Summary: The arrow indicating sort direction is reversed → The arrow indicating sort direction is reversed, should follow convention of each platform
(In reply to comment #16) > I expect people pay more > attention to the data being sorted than the sort indicator anyway Based on this logic, many things could be left in a somewhat dysfunctional or ugly state because people probably pay more attention to how pages are rendered than to appearance of UI elements.
fixed by Bug 93772?
yes, http://hg.mozilla.org/mozilla-central/rev/171f4a715e42 "Bug 93772 - Reverse sort arrow direction in tree header cells on Windows. On OS X this has already been fixed in bug 465402 and on Linux the current behaviour is correct. ui-r=faaborg"
Status: NEW → RESOLVED
Closed: 16 years ago
Depends on: 93772, 465402
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.