Closed Bug 93772 Opened 23 years ago Closed 16 years ago

The arrow indicating sort direction is reversed

Categories

(Toolkit :: Themes, defect)

Product:
Toolkit
Component:
Themes
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.2a1

People

(Reporter: bryanck, Assigned: mstange)

References

(
URL
)

Details

(Keywords: polish, verified1.9.1, Whiteboard: [polish-easy] [polish-visual][polish-p3])

Attachments

(2 files, 1 obsolete file)

Examples
20.96 KB, image/gif
Details
updated "patch"
179 bytes, patch
faaborg
: ui-review+
beltzner
: approval1.9.1+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080110 When sorting messages by clicking on the list header of the column you want to sort by, the arrow indicating sort direction seems to be reversed. For instance, sorting by ascending order is indicated by a "down" arrow, while sorting by descending order is indicated by an "up" arrow. This is the opposite of Windows programs (e.g. Windows Explorer, Outlook, Outlook Express, etc.), though I think (?) it is consistent w/ Netscape 4.x. Reproducible: Always Steps to Reproduce: 1. Click on a list header to sort by that column. 2. Click on it again to switch the sort direction (ascending, descending) Actual Results: The arrow points up for descending and down for ascending. Expected Results: The arrow should point up for ascending and down for descending.
QA Contact: esther → laurel
Arrow indication are correct on linux. Reporter: Are you still seeing this bug? If so: Does it apply to both classic and modern theme?
I still see it - arrow points up for descending, opposite of how other Windows apps behave, in both the Modern and Classic themes.
I need some clarification here.. What i see - and expect - is this: when arrow points up: Newest message lists first when arrow points down: Oldest message lists first The arrow indicates in which end of the list the newest message is found. This is also how Netscape 4* indicate sorting. If that is what you also see, this bug is invalid since it works as designed.
If this is the expected behavior, then it works as designed. I was comparing this feature to other apps (Microsoft products, Perforce, WinZip, CodeWarrior, etc.).
if they point "forward" to the oldest file, that seems a little odd to me. Well. Resolving as invalid. You may of course file an RFE on the matter, but there will probably be discussion: The arrows in for instance Nautilus (filemanager) on Linux also point in direction of the "newest" file's location. Down=bottom / Up=top
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
I don't have Windows Interface Guidelines handy, but I believe that the other way around (arrow points up when the data is sorted from top to bottom in alphabetical, numerical or chronological order) is the Windows platform standard - which we should obey. Somebody can probably check this out? MacOS X does it the Windows way, too. The current Mozilla behaviour is only consistent with Netscape 4.x, Nautilus and Konqueror. Reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
- Marking new - Changing the component to Browser (this bug concerns all Mozilla components) - Changing Platform/OS to All/All (since there's no "Windows & Mac" option :-)
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → User Interface Design
Ever confirmed: true
OS: Windows 2000 → All
Product: MailNews → Browser
Hardware: PC → All
Found it: "You can also include a graphic image with a text label to illustrate information about column item attributes. When you do, make sure they properly communicate the current state of the column items. For example, a downward pointing arrow graphic used to indicate sort order should indicate descending sort order. When sorting by date on U.S. system configurations, this means that the contents of the column should be sorted with the most recent item first." http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch08c.asp
Adding polish keyword - this should be easy enough to fix. But we still need to decide whether or not to "fix" it on platforms other than Windows and MacOS.
Keywords: polish
This is not 4xp and Windows95 Explorer's does not even use arrows to indicate sorting order. Whatever outcome: This should not be broken on Linux.
> This is not 4xp and Windows95 Explorer's does not even use arrows to indicate > sorting order. Yes, Windows Explorer has sorting arrows starting with Win2k (maybe ME too, dunno).
*** Bug 137915 has been marked as a duplicate of this bug. ***
I assume folks at MS were drinking turpentine and had a language mixup, and everyone blindly followed ;)
uid is being phased out.
Assignee: sspitzer → varga
Component: User Interface Design → XP Toolkit/Widgets: Trees
QA Contact: laurel → shrir
*** Bug 182416 has been marked as a duplicate of this bug. ***
Windows and Mac have the right idea here. "Up" means "ascending order", "down" means "descending order". That's logical and obvious. As far as Linux is concerned, Evolution and OpenOffice are consistent with the Windows and Mac file managers. Fixing this will be good for Linux, too. GTK2 follows what Mozilla currently does. I believe that's a design error, and I intend to raise this issue on the GNOME usability list next week. I would be surprised if the developers of any of this software had spent more money on usability testing than Microsoft and Apple. If the weight of the convention they've established here isn't sufficient to warrant a fix, the obvious logic of "up"->"ascending" and "down"->"descending" certainly should be. This should be trivial to fix; so if this is just waiting around for someone to care about it enough, I'll be That Guy.
Keywords: ui
Looks like fixing this should be as simple as swapping the image file names. That is, sort-asc.gif -> sort-dsc.gif, and sort-dsc.gif -> sort-asc.gif.
This change just involves renaming some binary files; so there are no diffs. themes/classic/global/tree/sort-asc.gif -> sort-dsc.gif themes/classic/global/tree/sort-dsc.gif -> sort-asc.gif themes/modern/global/tree/sort-asc.gif -> sort-dsc.gif themes/modern/global/tree/sort-dsc.gif -> sort-asc.gif toolkit/skin/win/tree/sort-asc.gif -> sort-dsc.gif toolkit/skin/win/tree/sort-dsc.gif -> sort-asc.gif
adding Jennifer Glick to cc list. Jen could you comment about this? Right now the sort arrows are the reverse of what it says in the msoft ui guidelines, but that seems counterintuitive. Which way should they be?
Attached image Examples —
Some examples of Mail applications on Windows. Down for decending seems more common and the MS UI Guidelines quote from comment #8 is correct. Honestly, I don't think one is inherently better than the other. Just like the comments in this bug, I've had some people tell me they prefer one method and other say they prefer the other. Its all what you're used to I suppose. As long as clicking on the column header results in a visible change that is apparent to users (and we are consistent), I think either is ok.
If we are considering keeping the current behavior, someone should explain the rationale behind the assertion that "up arrow" -> "descending sort" is intuitive. As evidence that the converse should be more intuitive: 1. "up" has a natural association with "ascending". 2. The big part of the arrow is at the bottom of the graphic, and the "biggest" items in the list occur at the end. If intuition is irrelevant, and this is simply a matter of what one is accustomed to seeing, then we still have the issue that both Microsoft and Apple follow the "up" -> "ascending" convention; and that inevitably sways the preconceptions of users.
Braden, read the description of Windows-guideline arrow direction in comment 6 (the "arrow points up when the data is sorted from top to bottom" part). There's no point in arguing about whether thinking in sequences (ascending) or directions (up) is more intuitive or natural, based on introspection of individuals... My random guess is that people pay more attention to the order of the list rows they want sorted than the darn arrow anyhow :) ...as such, following each platform's conventions would be ideal of course
Tuuka: "top to bottom" is a frame of reference; not a sort order by itself. "top to bottom alphabetical" order is the same as "ascending alphabetical" order, and would have an arrow pointing up. That is consistent with my position on this. In my estimation, only Windows and Mac could really be considered to have a convention. On Un*x, OpenOffice and Evolution follow the "up" -> "ascending" convention, while GTK2 and Qt do things as Mozilla currently does. It would be constructive for Mozilla to promote a convention on Un*x that is consistent with the one already present on other widely-used platforms. (I intend to promote a change in GTK2's behavior on this, but I think it's best to see this bug through to resolution first.)
Braden, you missed my main point completely -- I guess I didn't make it well... Lemme try to explain in my own words my understanding of these, even though the description and motivation of the opposed ways of thinking is completely OT... which is the point I was trying to make, ironically :( * The arrow/order relation that the current behaviour follows is based on - a static_natural/default_order (ascending) combined with - a changeable direction (up/down like an axis on a graph, portrayed by the sort arrow) that the natural order can be aligned to. * The other arrow/order relation is based on - a static natural/default direction of a list (down), and - a changeable value order of the items (ascending/descending) Note that the words "ascending" and "descending" don't usefully describe the choices in the first thinking as that parameter is fixed; similarly the words "up" and "down" don't describe the choices in the second case, as that parameter is fixed. Sorry about my contribution to bad snr :( As for the *nix convention, one could argue that OOo and Evolution are MS app clones and as such couldn't be so much considered to establish platform guidelines -- GTK and Qt on the other hand are the mainstream toolkits, so they might be expected to cover most of the core user experience
Tuukka: I have no idea what you're saying there. "static natural"? "default order"? Plain language, please. "As for the *nix convention, one could argue that OOo and Evolution are MS app clones and as such couldn't be so much considered to establish platform guidelines...." That's quite a non sequitur.
Attached patch Proposed fix (obsolete) — — Splinter Review
This change just involves renaming some binary files; so there are no diffs.
Attachment #112040 - Flags: review?(braden)
Attachment #112040 - Flags: review?(braden) → review?(varga)
> This change just involves renaming some binary files; so there are no diffs. > themes/modern/global/tree/sort-asc.gif -> sort-dsc.gif > themes/modern/global/tree/sort-dsc.gif -> sort-asc.gif Confirmed. Braden has probably done this already, but I could not see that it had been documented. I wanted to check for sure to see if the bug was in the Mozilla code or in the skins. This is important because fixing the bug in wrong place would make it look right on-screen but it would not be correct and could lead to problems later on. The file "sort-asc.gif", i.e. "the Sort Ascending icon" contains an image of a downwards-pointing arrow(!) The file "sort-dsc.gif", i.e. "the Sort Descending icon" contains an image of a upwards-pointing arrow(!) When the rows displayed are (by inspection) in ascending order, the downwards-pointing arrow is displayed, indicating the the Mozilla code has correctly selected the "sort-asc.gif" icon. So the actual Mozilla code is correct. The bug is in the icons in the standard skins. Since the correct icon is available in the oppositely named file, renaming the files would have the effect of putting the right image in place.
Jag, do you agree with this change ?
Attachment #112040 - Flags: superreview?(jaggernaut)
Attachment #112040 - Flags: review?(varga) → review?(dean_tessman)
Comment on attachment 112040 [details] [diff] [review] Proposed fix I don't know how I can give r=me to a non-existent patch, but this is definitely the right thing to do. We're the only app that has it wrong.
braden: the way it currently is feels natural to me, since the arrow points from smallest to biggest: a | v z For reverse: z ^ | a There is something to be said for platform parity though. I don't believe however that Microsoft's (and Apple's) way are inherently "right", so I don't want to push this on unix platforms if the majority there does it the way we're currently doing. Let me talk to our designers to see what their thinking was behind the current association between sort order and arrow direction.
Keywords: nsbeta1
yes, we do it diff than a lot of other apps. but not all apps. We don't think people notice the direction of the arrow as long as they know where to click to change the sort order and the user is more likely focused on the content than the arrows. People notice the data re-sorting, not the little arrow. I don't think it's worth the time and effort to review/approve the patch when we have so many other broken things to focus on.
Jag: Why do you think it's "natural" for the arrow to point from smallest to biggest? Whatever. What's important is consistency between apps. Mozilla needs to follow what the overwhelming majority of the GUI design design community (comprising designers who target Microsoft and Apple platforms) has decided to do. Un*x is, as usual, a hodgepodge of different mindsets. Since you certainly aren't going to change Microsoft and Apple design conventions, Mozilla would do well to contribute to making Un*x consistent with convention common to those platforms.
> People notice the data re-sorting, not the little arrow. If that statement had any basis in reality, this bug would not be here. > I don't think it's worth the time and effort to review/approve the patch > when we have so many other broken things to focus on. If it's not worth *your time*, don't waste *my* time sharing that. I don't care. The fix has been completely articulated. It has been checked by other folks to confirm that it fixes things the right way. This bug has module owner approval from Dean Tessman. I can find folks who'll check it in. AFAICT, little energy is needed for this issue to be resolved. A lot more energy could be spent on leaving it unresolved.
As far as I know Dean can't give module owner approval.
Whoa, let's slow down people! I'm definitely far from being able to give module owner approval. But I do agree that the way we're doing it currently is plain wrong. Lori: Can you give an example of an app that we don't do this differently than, besides AOL? Also, the arrows are there to give a visual indication of the sort order when the window is first opened. You say that the arrow doesn't really provide any indication at all, so why don't we just remove it all together? Jag: The arrow is meant to indicate the sort order. Pointing up indicates ascending and pointing down indicates descending. That is how all Windows apps do it, and it makes a lot of sense. I don't see how an arrow pointing up tells me that I'm viewing the newest message first.
Dean, Jag: Sorry for the confusion about Dean's authority. I was misinformed.
Dean, braden: to clarify, I understand how MS's (and Apple's) arrows indicate the current sort order. "Arrow pointing up" means the values are going "up" as you're going down the column (ascending), "arrow pointing down" means the values are going "down" as you're going down the column (descending). I've tried (and I suspect failed) to explain to braden on irc how the direction of the arrows currently make sense to me: essentially the arrow goes with the flow, if one takes the flow to go from "smallest" to "largest" value, or put differently, the arrow indicates in which direction I need to read the column to read the values in ascending order (though I hardly ever sort in descending order, if I need that I just go the bottom and read up). Whew, now that I've spelled it out, I understand comment 24. Regardless, the question is whether to preserve the way things are in NS 4.x to NS 7.x, and Mozilla 1.X (X < 3final), or to make this change so we're on par with MS and Apple. For now I'm going to err on the side of keeping things the way they are.
I suspect if you took a survey on the target Mozilla user population on the applications that they use on a daily basis, then you would find "up arrow = ascending" being the most familiar interpretation. This is based on the assumption that there is more Windows than anything else. My guess is that nearly all users will go with one of the skins supplied with the Mozilla binary package. At the minute, Mozilla effectively places a requirement upon the majority (Windows) user population to mentally special-case Mozilla and interpret the symbols differently to all their other applications, whilst providing the minority population a comfortable symbol set. The user could possibly change their skin, but why put the majority of users in that position? Surely it would be better to please the majority of users out-of-the-box. There will be a minority that want it the other way round, and that set will probably have some correlation with the set of more technical users who are willing and able to install a different skin or alter the skin they have to suit their particular wishes. Consider how the world would be if the arrows had been the other way round to what they are now to begin with. There would undoubtedly be some user popping up saying that the arrows were the wrong way round. Discussion would ensue. The outcome would probably be that the user was in the minority and that if they really wanted the arrows the other way round, that they could just change their skin. The bug would be resolved as invalid. ("argument ad absurdum"?)
Jag: Exactly what is the rationale for leaving it as it is? "Inertia" is a silly reason; there have been *lots* of bugs fixed in Mozilla that were "features" in Netscape 4.x. The compelling reason to change has been articulated thoroughly: Mozilla is inconsistent with established convention. What is the compelling reason to leave this as-is?
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 202793 has been marked as a duplicate of this bug. ***
I'm interested in renaming these files. How do I repack the files back into a .jar file (on WinXP) once I'm done renaming them?
These jars are actually zips, you can use for example WinZIP or infozip.
*** Bug 166491 has been marked as a duplicate of this bug. ***
Only for information: we have a discussion in OOo concerning this point, too: <http://www.openoffice.org/project/www/issues/show_bug.cgi?id=17776> I believe the WINDOWS way to handle it is not intuitive: For me the "natural" sort order for Numbers is 1,2,3,4,5, and the arrow should show the direction of this natural sort order (also: #30): -----> 1,2,3 or <---- 3,2,1 I would vote for "don't change", but most users think different and follow arguments of the reporter. any Idea to where <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch08c.asp> has moved? Rainer
*** Bug 214988 has been marked as a duplicate of this bug. ***
Comment on attachment 112040 [details] [diff] [review] Proposed fix I agree with comment 39. It's more important to be consistent with the rest of the platform's apps than with out-of-date apps like NS and Moz < 1.3. r=me. That being said, I can only review. Jag has the ultimate decision with the sr.
Attachment #112040 - Flags: review?(dean_tessman) → review+
The changes described in attachment 112040 [details] [diff] [review] would introduce platform inconsistency wrt gnome. See <http://ftp.gnome.org/pub/GNOME/teams/marketing/en/2004/two-six-screenshots/html/index.html> for examples. Evolution is now also in line with the gnome convention.
I think it may be that having it only work one way may not be the best solution. The windows/mac/commercial-head types will always claim that "up arrow" = "ascending order", and the unix/gnome/geek-head types will always claim that "up arrow" = "descending order". Perhaps it would be best if it used the behaviour which was the best match to the environment it was running under. The implementation would be in the code rather than the skin. That way skins would be designed one way, and then the target platform would determine whether or not to use the icons in reverse sense. It may also be a good idea to tuck in a tick box (= "check box") in the preferences page to reverse the sense of the arrows, in something gets screwed up, or the user just happens to prefer it the other way round. That way should make the majority of people happy by default; the remainder only have to find the tick box. Bill
There are compelling reasons GNOME should change the way it does this (consistency with OpenOffice, familiarity for users coming from Windows, etc.). Having Mozilla change to be consistent with other platforms will add another compelling reason. Better for Mozilla to be inconsistent with one out of three platforms rather than two out of three platforms as it is now.
Attachment #112040 - Flags: superreview?(jag) → superreview?(neil.parkwaycc.co.uk)
*** Bug 264036 has been marked as a duplicate of this bug. ***
If one can't get this problem fixed in the official Mozilla sources, then one could always create a forked version with this bug fixed. This problem no longer affects me for Mozilla Mail, but I am considering using Thunderbird, which suffers from the same bug. The bug seems to be in the visual design of the icons used. So the fix (for me) would be to change the icons in the default skin. This shouldn't require any compiling of the actual application. The tricky bit would be the creation of the self-extracting, self-installing executable. Oftentimes the creation of such things requires a commercial product like InstallShield. I could go away and dig around in the sources, but does anyone know off the top of their head what system Thunderbird uses?
*** Bug 278088 has been marked as a duplicate of this bug. ***
*** Bug 290767 has been marked as a duplicate of this bug. ***
*** Bug 295696 has been marked as a duplicate of this bug. ***
Why is the bug still there after three years?
(In reply to comment #56) > Why is the bug still there after three years? Probably because the way things are working at the moment, is not the most common way. I consider this to be a bug too. In almost all programs i've seen (i'm not talking about email progs exclusivelly), a down-pointing arrow means descending order (greater - newer thing at the top, smaller - older thing at the bottom). IMHO, this is the correct way and since it's more widelly user, again IMHO, it would be nice if TB worked this way too. If noone wishes to change that, perhaps a checkbox should be added in the preferences dialog: "use up arrow to denote ascending order in list-sorting".
*** Bug 301577 has been marked as a duplicate of this bug. ***
2 > 1 every mathematician and programmer will read that: "two greater one" of course it is a bug!
I totaly agree to braden's comment #21: > 1. "up" has a natural association with "ascending". > 2. The big part of the arrow is at the bottom of the graphic, and the > "biggest" items in the list occur at the end. This bug also affects Firefox 1.5.0.9.
Sorry for the dupe (Bug 374009). I searched for something like this first, and didn't find anything. And there I was, thinking I had found something that no one else had noticed yet! :-) Well, at least I'm in good company. Except this bug's been open for 6 1/2 years? I guess it has as much chance of getting fixed as my other long-standing favorite, Bug 84128, which has been opened slightly longer...
It looks like everything has already been said - an interesting debate! Without taking sides, I would like to present my own perspective: The Windows standard (Windows Explorer and all other Windows applications) is clearly the opposite to Thunderbird. The narrow side of the arrow always indicates the 'smaller' value or earlier date. It never crossed my mind that the behavior in Thunderbird could be any different. This will definitely confuse Windows users that have no experience with Linux - which is most of them. I actually came here to report the bug, only to find that it was already under discussion. Oh well...
Of all the bugs reported that are related to this issue, I couldn't find the one with the latest update, so I put my comment in one of the issues (bug 301792 comment #10). In general, we should just allow the users to select their own interpretation of the arrow/triangle/pyramid in the Users Preferences to settle this 7-year discussion.
(In reply to comment #45) > For me the "natural" sort order for Numbers is 1,2,3,4,5, and the arrow should > show the direction of this natural sort order (also: #30): > > -----> 1,2,3 > or > <---- 3,2,1 One additional point regarding the "natural" order of things: it depends on the context, so there is no consensus. 1,2,3 is counting up (-->) for people who write left-to-right and counting down (<--) for people who write right-to-left. Similar argument can be made for 3,2,1. The point is, you don't know the current context in which to define what "natural" order is. Some people read newest email first, while others begin with the oldest unread email. Using the triangle as a pointer to indicate the direction of the "natural" order is misleading and inconsistent. Magnitude (i.e. Sort State) on the other hand is always consistent: 1 is always less than (<) 2 and so is 19700101 < 20080423.
(In reply to comment #66) > 1,2,3 is counting up (-->) for people who write left-to-right But the arrows don't indicate a horizontal direction but a vertical direction. Where I am from it's natural to read a text from the line on the top to the line on the bottom of the page. Are there also countries where you read from the line on the bottom upwards till you reach the line on the top of the page or maybe even from the bottom upwards (a vertical line) till you reach the end of the line which is on the top of the page? (In reply to comment #66) > In general, we should just allow the users to select their own interpretation of the arrow/triangle/pyramid in the Users Preferences to settle this 7-year discussion. Agreed. I also think that this would be the most reasonable solution.
I think decision must be platform-depended. If Thunderbird and other Mozilla apps compiled for Windows or Mac-os, there are must be TRIANGLE, large part of which describe side with biggest values in list, and thin side of which describe smaller values position. It's like in Explorer and other platform-related apps. If Mozilla appc compiled for any unix - there are must be an simplified ARROW from natural number axe, that represent direction from zero (and other lowest values) to positive infinity (and other biggest values). P.S. I very-very want to have in my Windows installation of the Thunderbird sorting TRIANGLE in the column's headers.
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets
I'm reversing the arrow on Mac OS X in bug 465402.
Attached patch updated "patch" — — Splinter Review
This is what has to be done for Winstripe.
Attachment #112040 - Attachment is obsolete: true
Attachment #112040 - Flags: superreview?(neil)
Attachment #350401 - Flags: ui-review?(faaborg)
Attachment #350401 - Flags: review?(dao)
Assignee: Jan.Varga → nobody
URL: http://weblogs.mozillazine.org/gerv/a...
Component: XUL → Themes
Product: Core → Toolkit
QA Contact: xptoolkit.widgets → themes
Attachment #350401 - Flags: review?(dao)
Comment on attachment 350401 [details] [diff] [review] updated "patch" If you're doing this, you should update the images in pinstripe as well, as they are still packaged there. Other than that, this only needs ui-review.
Wow, it's not every day that I get to ui-review a 7 year old bug. The short version is that we should try to be as close to both the behavior and appearance on each different platform as possible, for external consistency with other applications on that platform. The long version is that this gets a little complicated when you look at the three different platforms, and how they interpret the meaning of the arrow for each type of data (alphabetical, size, date, type). In the following list "small" is the pointy part of the triangle, and "large" is the wide base part. So if "A" = small and "Z" = large, then when "A" is at the top of the list the arrow is pointing up, and when "A" is at the bottom of the list the arrow is pointing down. Windows: Folders and files are grouped separately from each other in every sort. group of all folders=small, group of all files=large Alphabetical: a=small, z=large Date: old=small, new=large Size: small=small, large=large Type: alphabetical where a=small, z=large xp: group of all folders=small, group of all files=large vista: folders are always grouped first, either way. This is possibly a bug, and not worth matching. OS X: Folders are interspersed with files in every sort. Alphabetical: a=small z=large Date: old=small new=large Size: small=small large=large Type: alphabetical where a=small, z=large, "Folder" is under "F" Gnome: Folders and files are grouped separately from each other in every sort. group of all folders=large, group of all files=small Alphabetical: a=large, z=small Date: old=large new=small Size: small=large large=small Type: alphabetical where a=large, z=small
Comment on attachment 350401 [details] [diff] [review] updated "patch" I'm not sure what the best way is to handle file names, but right now on Windows are behavior is exactly backwards, so this patch will fix that.
Attachment #350401 - Flags: ui-review?(faaborg) → ui-review+
Two follow up bugs: Use native sort arrows for different OS themes (toolkit): bug 467844 Correctly group folders when sorting columns on Windows and Linux (Firefox): bug 467848
pushed: http://hg.mozilla.org/mozilla-central/rev/171f4a715e42
Status: NEW → RESOLVED
Closed: 23 years ago → 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Attachment #350401 - Flags: approval1.9.1?
Blocks: 301792
Comment on attachment 350401 [details] [diff] [review] updated "patch" a191=beltzner
Attachment #350401 - Flags: approval1.9.1? → approval1.9.1+
Markus: you're not going to forget about that a191, are you?
Assignee: nobody → mstange
I'm not :)
Verified. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090127 Shiretoko/3.1b3pre
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Whiteboard: [polish-easy] [polish-visual]
All I have to say is that anyone who prefers up=descending must have really had enormous trouble learning the greater than and less than symbols in 3rd grade. For review: the point on the < or > points to the smaller item. Any ideas on when this 7 year old bug is likely to be fixed in Tbird?
No one's explicitly verified this on windows tbird, but looking at http://scr3.golem.de/?d=0902/Thunderbird_3_Beta_2&a=65570&s=9 it seems to have had an effect. This is fixed on 1.9.1 and trunk, which for thunderbird means version 3 onward. As for your conclusion, it's pretty silly.
Tuukka, Ah yes, the last resort of one who has no legitimate aruments left: insults. Well, perhaps I'm "silly", but so far, the eight people in the up=descending camp (the same eight who have held up this fix for almost 8 years) have not come up with any sort of logical reasoning why up=descending makes any sense. All I keep hearing are mystical arguments such as "well, if you draw an arrow from the smallest thing to the largest thing...". And yet, those who make these arguments never can fully explain why an arrow should go that way and not the other. If that's the best you can do, please, never become a lawyer, because you will lose every case you are assigned to. The argument for up=ascending is logical, mnemonic, and at least a billion times more sensible than the alternative. Those in my camp have come up with a vast amount of ammo against the up=descending camp: 1) Windows standard. (overwhelming majority of tbird users are on windows). 2) Web standard. (see sorting on wikipedia.org among others). 3) up=ascending. You can not get more sensible than that. 4) If the LARGER end of the triangle is at the top, then the larger data is at the top. Again, way more sensible than the mystical hand-waving "arrow" arguments of the up=descending camp. 5) <> greater than / less than signs... the "point" points in the direction of the smaller data. So, feel free to keep calling me silly and to continue your mystical hand-waving. Based on how much you probably get laid, I'm sure that's not the only thing you are doing with that hand. All I know is that the MAJORITY windows users have had to put up with illogical arrows for 7 years just because the MINORITY *nix users have resisted simple fixes for 7 freakin years. Pretty ridiculous if you ask me. The entire open source community should be embarrassed about this one. "Oooooh, look at my arrow ... it is sooooo big and so long, and I've got it pointed towards the larger data. See how logical my argument is?????? Ummm. No? Well, um, did I mention my arrow is pointy?" Great argument. Wow.
2 MrMe: Please stop flame and just read https://bugzilla.mozilla.org/show_bug.cgi?id=93772#c68 and around
2 MrMe: P.S.: To change unix-world GUI traditions You can try talk in some unix GUI forums, but Mozilla must just correctly follow it.
<a> you guys must have had enormous problems in 3rd grade <b> that's a silly thing to say <a> silly? that's so insulting! [a bunch of insults] How sweet of you :)
note: this was accidentally regressed by Bug 467844, fix will be in bug 495595.
This bug's priority relative to the set of other polish bugs is: P3 - Polish issue that is in a secondary interface, occasionally encountered, or is not easily identifiable. This effected a number of places in secondary interfaces, but you really had to think about it figure out that the arrow was backwards (I personally didn't notice until seeing the bug).
Whiteboard: [polish-easy] [polish-visual] → [polish-easy] [polish-visual][polish-p3]
Still not fixed here,fedora/gnome. us english. The logic is simple: 1<9 1 ^ 9 9>1 9 v 1 simply rotate the globally-accepted-as-true expression "1<9" and you see, the vertical orientation (90deg) of the arrow is wrong in the UI.
I'm sympathetic; but the underlying problem there is the current GNOME HIG. I encourage you to voice your support for https://bugzilla.gnome.org/show_bug.cgi?id=305277
Instead of speaking of A-Z order, let's consider about size ordering. Assume that you sort by size indicated by "v" arrow. Now let's analyze its purely graphical meaning, which is the starting point of all the icons: There's a "big" line on the top, "small" tip at the bottom. Isn't it natural enough to think that large files should be shown on the top and small files on the bottom? Thunderbird in Ubuntu behaves in exactly the opposite way, which is why I agree with Braden. I'm not talking about the majority population thing, I believe MS and Apple didn't come up with just a random decision about this. There is a good reason for that, as can be seen in the above example. Somebody mentioned about the meaning of arrows before. However, there's a big difference between "triangle" and "arrow", even if it looks trivial. Arrow has a "tail" that indicates "flow" whereas "triangle" does not. It is not sufficient enough to convey the meaning of flow. In other words, it is "static". Thus, I can't say anything else but to conclude that the triangle icon should be interpreted as: "v"=descending, "^"=ascending.
I can't believe that it is still not fixed...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: