That is true and I support you! I think that this must be changed in Gnome 3.0 and would be one step closer to seamless and more usable desktop.

When we wrote the guidelines, we did a straw poll specifically asking people which direction they thought represented 'increasing', and the majority said a downward pointing arrow, because that's the direction in which they read lists.

Personally, I'd be surprised if most people noticed or cared which way the arrow was facing, but we should certainly strive for consistency between the apps on our desktop.  I don't believe for a second that it will make the desktop "more usable" though-- people generally look at the list to see which way it's sorted, not the arrow.

But if it closes a bug, I'm happy to fix it the next time we're updating the HIG...

There is much good debate around this issue. Every time I look at a Gnome column that has a sort indicator my brain fogs over and I don't understand what it means. So I would like and am casting my verbal (er, typed) vote for changing the Gnome representation of sort order.

My brain thinks the pointy end of the arrow points at the little things and the big fat end of the arrow (I always think of it as a triangle) indicates the direction of bigger things.

Thanks for making space for my thoughts!!
Dale E. Moore

Can't believe the bug is still there.

(In reply to comment #2)
> When we wrote the guidelines, we did a straw poll specifically asking people
> which direction they thought represented 'increasing', and the majority said a
> downward pointing arrow, because that's the direction in which they read lists.

If that is how you formulated the question, then it is strongly biased, in that you are talking about "direction", thus almost implying the idea of an arrow.

In the "Mac/Windows" convention, these icons are NOT arrows! 

(In reply to comment #3)
> My brain thinks the pointy end of the arrow points at the little things and the
> big fat end of the arrow (I always think of it as a triangle) indicates the
> direction of bigger things.

Exactly, that's the meaning of the icons.

The only possible ambiguity is with dates (I think there has been some inconsistency in that among different email clients in windows), because in computers dates are numbers and hence old dates are small numbers, but it is rather intuitive to think of recent dates as "little time ago" and old dates as "much time ago".


The interpretation of arrows representing the direction in which the values _grow_ (i.e., up-arrow == [values grow if you read them from the bottom up] == descending) is ridiculous, beacuse if you think about it, you are choosing a direction which is subordinated to an implicit _increasing_ order... then you would need another arrow to choose whether the direction you chose is the direction of increasing or decreasing values... and so on.

Change it, that's an error.

Arrows, pictures, icons... semantics.  Imagine the "<>v^" as filled-in triangles if you like.
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,180deg) of the symbol is wrong in the UI.

Can't relate?
The wider end of, say, a (filled) "v" (arrow indicating down) is the top; wider, larger.  The bottom is narrower, smaller.  Logic says largest above, smaller below.  In mathematics and programming, this is also true.  The value above is larger than the value below.
Rotated, ">" - wider, larger on the left. narrower, smaller on the right.  Larger value on left, smaller value on left.  A running scale would be 9>8>7>6>5>4>3>2>1.  As you can see it is sorting largest to smallest.  Rotated version again:
9
v
8
v
7
v
6
v
5
v
4
v
3
v
2
v
1
Happens to be sorted largest to smallest. Arrow/symbol indicating downward.

I completely agree with changing the icons. My brain, when looking at the icon, is seeing the visual representation of how the things are sorted.

Smaller things on top, larger things on bottom:
            _
  /\       ___
 /  \     _____
/____\   _______


Larger things on top, smaller at the bottom:
______   _______
\    /    _____
 \  /      ___
  \/        _


So every time when I see GNOME icon which is "backwards", I have to stop and think for several seconds what it is actually representing: "pointing down means ... descending, ok, so that s like ... from larger to smaller ... hmm ... aha, it is larger at the top ...". It is just the opposite of what the icon is showing me.

We have to change this!

In the meantime, how can I change this on my own system?

"In the "Mac/Windows" convention, these icons are NOT arrows!"

If you ask most people to tell you what the symbols are (and I've asked quite a few in my time), whether or not they know what they are used for, they will describe them as "arrows". In some ways it would probably be better to use "non-pointy" symbols just to avoid all of this confusion, but that's the symbolic convention we're using for now.

"Smaller things on top, larger things on bottom"

That's fine for numbers. It's less obvious for letters or for dates, which have an order, but not a "size".  Or for columns of checkboxes, which have neither. That's why we felt it was more logical to associate the 'direction' of the 'arrow' with the 'natural direction' of the sort (low to high, first to last, earlier to later), rather than 'size'.

Anyway, there's no need for any more "me toos"... GNOME bugs don't get fixed based on how many people vote for them, they get fixed based on whether it's right to fix them. And we'll fix this one in the GNOME 3 HIG just as soon as we have a GNOME 3 HIG.

*** Bug 337700 has been marked as a duplicate of this bug. ***

*** Bug 533328 has been marked as a duplicate of this bug. ***

Just another vote to change this, coming from (for what it's worth) someone who has developed interfaces and worked in usability/user experience. People have come to accept that the "up arrow" means ascending order, and the "down arrow" means descending order. Sure, someone can click a column header and then look at the data to see how it's sorted, but that's an unnecessary step. Then what is the point of the arrow? Obviously it's to provide a quick at-a-glance reference on how the column is sorted.

This really ought to be fixed.

(In reply to comment #6)
> I completely agree with changing the icons. My brain, when looking at the icon,
> is seeing the visual representation of how the things are sorted.
> 
> Smaller things on top, larger things on bottom:
>             _
>   /\       ___
>  /  \     _____
> /____\   _______
> 
> 
> Larger things on top, smaller at the bottom:
> ______   _______
> \    /    _____
>  \  /      ___
>   \/        _
> 
> 

Exactly!  In System Monitor when I click the CPU column so that the indicator points downwards (big on top) I expect to see the largest processes - the ones using the most CPU - at the top of the list.  It's common sense.

Please fix this.

The fundamental problem comes from treating "arrow" and "triangle" as the same thing.
However, there's a big difference between the two, 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, following the triangle picture logic above (big lines on the top, small lines on the bottom), I can't say anything else but to conclude that the triangle icon should be interpreted as: "v"=descending, "^"=ascending.

I'm not speaking about the "majority of users" thing, I believe MS and Apple didn't come up with just a random decision about this. There is a good reason for that.

I can't believe this issue is still not solved. Please, fix this problem.

> The fundamental problem comes from treating "arrow" and "triangle" as the same
thing.

I'd rather say that the fundamental problem comes from treating column sort icons as if they were "arrows" while they are triangles.

An arrow could't ever be used, even if one wanted to, as an indicator of the sort order (ascending vs descending) because it would tell you nothing. An arrow indicates a direction (upwards/downwards), but you would still need to know whether it indicates the direction in which values grow or the direction in which values decrease.


> I can't believe this issue is still not solved. Please, fix this problem.

I can't either, especially after comment #7 of more than one year ago.

(In reply to comment #13)
> 
> I can't either, especially after comment #7 of more than one year ago.

That comment said it will be "fixed in the GNOME 3 HIG just as soon as we
have a GNOME 3 HIG". Since there is still no GNOME 3 HIG, there is still nowhere to fix it.

(There's no point fixing it in the GNOME 2 HIG, as nobody's going to retro-fix it in their GNOME 2 applications now.)

But there are certainly GNOME 3 applications.  So, where are GNOME 3 application developers looking for guidance on such issues?  It seems like that would be the appropriate place to address this in the near term in the absence of a GNOME 3 HIG.

While I have some sympathy with the "fat end of the arrow shows where the big things go" point of view, I'm honestly not convinced that it is worth us spending time on changing this:

 * We'd have to fix both GTK+ 2 and GTK+ 3. The former isn't really touched nowadays.
 * The arrow is fairly meaningless for names and dates - "ascending" and "descending" don't map to the arrow in a clear way.
 * For whatever confusion this causes, we also have to balance it against the confusion that would be caused by us switching the order.
 * Tree views are increasingly being phased out in favour of list boxes.

So, while the bug report might have some validity, I'm going to say wontfix, at least for now. If there's an opportunity to resolve it on the GTK+ side, then maybe we could do that in the future.

I can't believe I'm seeing a decision of this magnitude of stupidity being taken.

You have broken a basic UI and now you decide that it's going to stay in the broken way?


> * We'd have to fix both GTK+ 2 and GTK+ 3. The former isn't really touched
nowadays.

So what?

> * The arrow is fairly meaningless for names and dates - "ascending" and
"descending" don't map to the arrow in a clear way.

That only applies (questionably) to dates, not to names, which have a very clear increasing order from a to z, to begin with.
And what about other type of columns, such as numbers??

> * For whatever confusion this causes, we also have to balance it against the
confusion that would be caused by us switching the order.

Yeah, you have already done a terrible job in keeping it the wrong way all this time. Let's make it even worse.


> * Tree views are increasingly being phased out in favour of list boxes.

That has zero relevance unless tree views (assuming what you call a tree view is what exhibits the issue) are totally removed - which would be a very bad idea. Are you going to remove the option for the user to choose tree views?



If you're not willing to fix it, you should keep the bug report open, because that's its correct status. At least that would allow somebody wanting to provide a patch to do so.

Is this just a skin/glphs image file swap?  Surely there is one central location in the code than says "OK, draw this indicator" which's logic can be switched?

How are alphabetic names not capable of being sorted?  It's quite understood that A is first, Z is last, alpha-omega, and the progression should follow the direction of indication.  If you mean by Forename/Surname that's usually an option known to the user, and does not affect the expected order vs indication.  Which would still be incorrect.

Dates; personally I do not see any other meaning for order other than the face-value of the (ISO) date numerically sorted (1900-01-01 x is less than < 2000-01-01, 15:00:12 is greater than > 03:00:12), or if you please, sorted by epoch value in correct numeric order.  Unless you are thinking "age", but then that column should be called age, not date, and display age accordingly, no the actual date (1 day ago is less than < 20 days ago)

I also do not understand the relevance of bringing up treeview vs listbox

The current indication says the following:
1>9 (1 is bigger than 9)
Alpha>Zed (A comes after Z)

Those seriously look correct to you?

(In reply to comment #17)
> I can't believe I'm seeing a decision of this magnitude of stupidity being
> taken.
...

This, as well as other parts of your comment, is unacceptable behaviour. If you are unsure about what is acceptable, please check the code of conduct:

https://wiki.gnome.org/action/show/Foundation/CodeOfConduct?action=show&redirect=CodeOfConduct

...
> > * For whatever confusion this causes, we also have to balance it against the
> confusion that would be caused by us switching the order.
> 
> Yeah, you have already done a terrible job in keeping it the wrong way all this
> time. Let's make it even worse.

Changing an long-established convention will inevitably impact on users, and this has to be weighed up when deciding whether to make changes or not.

> > * Tree views are increasingly being phased out in favour of list boxes.
> 
> That has zero relevance unless tree views (assuming what you call a tree view
> is what exhibits the issue) are totally removed - which would be a very bad
> idea. Are you going to remove the option for the user to choose tree views?

It is relevant, considering the amount of work the change would require and the amount of benefit we would get.

> If you're not willing to fix it, you should keep the bug report open, because
> that's its correct status. At least that would allow somebody wanting to
> provide a patch to do so.

To change the behaviour, GTK+ would have to be patched. Any applications that have code that assumes the arrow behaviour would also have to be found and patched. In other words, it would require a coordinated effort across GNOME to make it happen.

I am not willing to change the Human Interface Guidelines independently of this happening, nor do I think that the amount of effort required to make the change would be worth it.

> Changing an long-established convention will inevitably impact on users,
> and this has to be weighed up when deciding whether to make changes or not.

Just to be clear, are you talking about the long-established convention that has  existed ever since UIs have had sortable columns and that still exists everywhere outside the GTK&Friends world (i.e., fatter end of the triangle = greater values), or about the contrary less-long-established convention that GTK has later implanted?


> considering the amount of work the change would require 
Isn't it just a matter of changing the default value of this setting from false to true?
https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-alternative-sort-arrows


FYI Ubuntu took the right decision
https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/901703/comments/11

Maybe you're right: perhaps it's not worth fixing it in GTK because hopefully, all applications using GTK will end up specifying the correct value instead of leaving the default.

(In reply to comment #16)
> While I have some sympathy with the "fat end of the arrow shows where the big
> things go" point of view, I'm honestly not convinced that it is worth us
> spending time on changing this:
> 
>  * We'd have to fix both GTK+ 2 and GTK+ 3. The former isn't really touched
> nowadays.

I agree it would be desirable to fix GTK+ 2.  I am not sure it is vital; but I'm mostly interested in bringing GNOME to parity with other popular UIs going forward.  Assuming GTK+ remains relevant, GTK+ 2 applications will, eventually, be phased out.

This is not a new bug.  It existed in other forms here well before this HIG bug was filed.  When this bug was filed, there was indication given that it could be fixed when the HIG was updated, presumably for GTK+ 3.

I might better understand resolving this WONTFIX if something about the surrounding landscape had changed: if, for instance, GNOME was less of a minority platform than when this bug was filed; or if competing platforms had come around to the GNOME way of doing things.  But the landscape seems to remain pretty much unchanged: GNOME is a minority platform doing things opposite to platforms with much greater user bases and visibility.  As such, the primary motivations for addressing this haven't changed.  WONTFIX does not seem appropriate.

>  * The arrow is fairly meaningless for names and dates - "ascending" and
> "descending" don't map to the arrow in a clear way.

I'm not sure how to respond to this.  You might happen to think that way; but computers and other persons have been applying ascending and descending orderings to names and dates for many, many years.

>  * For whatever confusion this causes, we also have to balance it against the
> confusion that would be caused by us switching the order.

That's fair, so let's do that calculus: Mac and Windows do this one way, GNOME does it the opposite way.  Should GNOME's position be forever entrenched and create dissonance for users coming to the platform from Mac or Windows, or should existing GNOME users adapt?

Are GNOME users accustomed to the existing way of doing things likely to leave the platform if it changes?

>  * Tree views are increasingly being phased out in favour of list boxes.

There are still plenty of opportunities for column-based sort in UIs.  This seems irrelevant.

> So, while the bug report might have some validity, I'm going to say wontfix, at
> least for now. If there's an opportunity to resolve it on the GTK+ side, then
> maybe we could do that in the future.

A catch-22.  Historically, the story from GNOME/GTK+ developers has been, "Fix the HIG before we'll entertain patches."  Now you say GTK+ must be fixed before the HIG can be fixed?

Seriously: what's a realistic path forward to fixing this?  This is a really confusing thing that GTK/GNOME does relative to other platforms and the mechanics of fixing it aren't *that* complicated.

> I might better understand resolving this WONTFIX if something about the
surrounding landscape had changed: if, for instance, GNOME was less of a
minority platform than when this bug was filed

If that had become the case, that would rather be one more reason to fix it than not to fix it, as it would mean the bug would be affecting more people.

> >  * The arrow is fairly meaningless for names and dates - "ascending" and
> > "descending" don't map to the arrow in a clear way.

> I'm not sure how to respond to this.

And it's not an arrow in the first place, it's a triangle. Confusing it with an arrow is mostly where the the bug comes from.

> That's fair, so let's do that calculus: Mac and Windows do this one way, GNOME
does it the opposite way. 

Not only Mac and Windows, also Unity under Linux, and almost(*) everything else except Gnome. Not only in OSes, but also in websites, etc.

(*)Almost, because sadly, Gnome is not completely alone. Launchpad is another example where the triangles are reversed.

This "bug", and the resistance to fixing it is a classic example of stubborn and pig-headed oligarchy that prevails in open source. Rather than changing things, some smug individual or group is holding onto the notion of importance in the face of the prevailing decline in popularity of GNOME, and its complete lack of influence on the future of desktop environments. More will benefit from correcting this mistake than won't. Those that care to maintain current behavior can configure it so. Let's get on with our lives. Fix it and get off your high horses.

Don't forget, even KDE and (some of?) its themes allow selecting correct or incorrect indication.

Reopening.

The rationale for closing this WONTFIX is inadequate as it has been presented here.

Ultimately, the question is: How can GNOME be brought to parity with the way nearly every other platform presents this bit of UI?

Historically, GNOME library/application developers have kicked the responsibility for this to HIG.  For HIG developers, *years* later, to kick this back to library/application developers is really inappropriate.

GNOME should be better than simply throwing up its hands and accepting a poor design choice in perpetuity out of sheer inertia.  While it *might* be reasonable to make the argument that fixing this *now* is impractical, it's not appropriate to make that argument without also presenting a plan for how and when it could be fixed.

And there needs to be a firmer commitment to that plan than Calum Benson's 2009 comment.

Ascending order should be indicated by UP arrow. This decision is used in most programs, systems and sites. It's intuitive and logical for me and many commenters over the web.

Guidelines and standards are good only if most things follow it. This is isn't that case. So, if the guideline could not be changed, it should be ignored this time. 

If you still refuse to change the default view, you should have an option for this. It may be even a hidden option set in config file - that's better than nothing.

> Ascending order should be indicated by UP arrow.

It is not a damn arrow in the first place, it is a TRIANGLE, but yes, ascending order should be a triangle with the tip on the top and the base on the bottom, or as you call it, an "up arrow".

> Guidelines and standards are good only if most things follow it.
> This is isn't that case.

You seem to imply that there's some sort of guideline or standard that encourages the (wrong) order used by Gnome?? I don't think it's the case. It's just Gnome (and very few others) that got it wrong all the time, against both prevailing convention and common sense, and I don't think it is in accordance to any standard.

(In reply to teo from comment #29)
> It is not a damn arrow in the first place, it is a TRIANGLE, but yes,
> ascending order should be a triangle with the tip on the top and the base on
> the bottom, or as you call it, an "up arrow".

That's really skin-dependent.  It's reasonable to represent this graphic using either an arrow or a triangle.  There's enough visual and semantic similarity between the two (as long as orientation is consistent).

> You seem to imply that there's some sort of guideline or standard that
> encourages the (wrong) order used by Gnome?? I don't think it's the case.

I sympathize with your frustration, but please read the bug you are commenting on.  This bug is about fixing the GNOME HIG, which is precisely that sort of guideline.  Specifically:

https://developer.gnome.org/hig-book/3.2/controls-lists.html.en#controls-lists-sortable

To restate what's already been articulated above, this HIG bug exists because GNOME developers have been resistant to bringing their applications and libraries to consistency with modern UI conventions on this point in the absence of support for the change in the HIG.

Obfuscating this debate is the fact that the HIG as it stands is poorly written on this point, using the term "natural" order, which is not well-defined anywhere that I can find.  There is a vague implication by way of examples that a "natural" order is usually, but not necessarily, an ascending order.

A look at the columns in the GNOME System Monitor demonstrates what a complete mess this has given us:

 * For CPU utilization, nice, memory footprint, and priority, an up arrow is
   used for an ascending order.
 * For process name, pid, and waiting channel, an up arrow is used for a
   descending order.

> I sympathize with your frustration, but please read the bug you are
> commenting on.  This bug is about fixing the GNOME HIG, which is precisely 
> that sort of guideline.  Specifically:
> 
> https://developer.gnome.org/hig-book/3.2/controls-lists.html.en#controls-lists-sortable

OMG sorry, I didn't realize, they even wrote a guideline, and it's totally retarded. That's hilarious. And they call it an "arrow" btw, that should be fixed too.



> There's enough visual and semantic similarity between the two 
> (as long as orientation is consistent).

There's a visual similarity, but semantically they don't have nothing to do with each other, and the orientation can never be "consistent", because if they are oriented in a way that physically/geomertically looks the same, they semantically mean the opposite (if the arrow means anything at all, because as I argued before, an arrow indicates a direction, but then again, you need to assume that the direction indicated by the arrow is that of increasing stuff)

The whole misconception at the very base of this bug is confusing a triangle with an arrow.

I came here from https://bugzilla.xfce.org/show_bug.cgi?id=13844

I add my vote, please fix this bug.
I could not find, above, the reason(s) why it is not to be fixed by changing the following default value:

gtk-alternative-sort-arrows = true

In fact, even on this very site here, the arrows are right. :)

See ID column where ▼ means descending sort order:

https://bugzilla.gnome.org/buglist.cgi?bug_id=305277%2C337700%2C533328&list_id=334938&order=bug_id%20DESC

Xfce Thunar bug moved to https://gitlab.xfce.org/xfce/thunar/-/issues/468

As, unfortunately, gtk-alternative-sort-arrows=true work around did not work (yet) for me.

I also vote for changing the default. While I recognize it is (1) a matter of convention, (2) a very small issue, and (3) easy to change locally with `gtk-alternative-sort-arrows = true`. I feel we might as well get it right. 

The arguments given above in the discussion https://notes.ericjiang.com/posts/456 summarize my position. Thank you.

GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-devel-docs/-/issues/

Thank you for your understanding and your help.

I have created this ticket in GitLab:

https://gitlab.gnome.org/GNOME/gnome-devel-docs/-/issues/26

I think we should maybe copy interesting comments over there too.

I wanted to make sure this important ticket was not put in the trash.
Braden, if you want to make a nice GitLab ticket on your own, I will cancel mine as duplicate.