>Understanding the target audience for your product results in very different design decisions This is an excuse. Just add an option to sort both ways. It isn't hard. There is no target audience in this planet that benefits from less options or less features. Even if you had the features under an "advanced mode" UI that's still a better software than not having the feature in first place. Have people forgotten the 80…
> There is no target audience in this planet that benefits from less options or less features. I'm currently involved in UI design and, to my frustration, adding more options or features seems to send a vocal minority of the user base into a foaming-at-the-mouth violent rage. It's like any change resets the entire contents of their brain, and it's our fault we're making things so confusing for everyone... And let's n…
> any change resets the entire contents of their brain
That's because it does. Consistency is incredibly important.
The problem isn't that you're adding a feature, the problem is that you're adding a feature in an obtrusive way. Add as many features as you like (while preserving performance), but keep the day-to-day UI as stable as you possibly can. Place entry points (buttons) for new features in menus first, and make sure they're both used frequently and by many users before moving them to a crowded toolbar (and then give good thought about where it belongs on said toolbar/menu). Don't remove features unless they're truly problematic, and don't change UI.
> And they choose the interpretation that (per their reasoning, and possibly some actual data) seems most likely to correspond to what the user wants. Yes, that make sense, but the problem is that this interpretation changed in the last 10 (15? 20?) years. It used to be that "by name" meant "by name, il alphabetical / lexicographical order" in pretty much every file manager.
That's why we have all this LC_* stuff in Linux, which you can configure to your needs: export LC_MEASUREMENT="de_DE" export LC_MONETARY="de_DE" export LC_PAPER="de_DE" export LC_CTYPE=de_DE.UTF-8 export LC_MESSAGES="en_US.UTF-8" export LC_RESPONSE="en_US.UTF-8" export LC_TIME=en_US.UTF-8 Mix in your Swedish or Swaheli, maybe even the Vatican State: e.g. de_DE, sw_TZ, it_VA (not guaranteed ;-).
How does this work if you're a multi-lingual person and you have files with names in different languages?
You could alias cd to a shell script that sets the env based on the location.
I agree with Microsoft/Google/KDE's order. The author's situation is extremely rare, and the situation where someone wants "10" to be before "9" is far more common. Moreover, desktops don't label this sorting "alphabetical" (E: and it would really be "lexicographic"*), they label it "by name" (an informal criteria), so technically they're not lying. > I miss the time when computers did what you told them to, instead…
I will add that I'm plenty "smart" enough to understand that "10" comes before "9" in a strictly alphabetical sense, and I still want my file managers to sort "9" before "10". I don't want to put leading zeroes before every all the single digit numbers in my file names. (And then potentially go come back later and add even more leading zeroes once the maximum number reaches three digits.) --- I split all of my audiob…
> This works, but it looks kind of ugly
Maybe I'm weird but I prefer the way zero padding looks :)
I personally think the misalignment of lines where the numbers have different lengths looks (a lot) uglier than having zero padding. Sometimes it even throws _me_ off because the numbers have different lengths and ... well it just doesn't look sorted to me! :)
So the bonus of zero padding is that it'll be sorted correctly even if the file manager tries to be "smart" and sort incorrectly.
> Treat any consecutive sequence of digits as a number when sorting. Based on this description, I have no idea how the following would be sorted: • photo.jpg • photo1.jpg • photo01.jpg • photos.jpg
Does it matter? There's a user expectation that photo20.jpg comes after photo3.jpg. There's no user expectation around whether photo1.jpg or photo01.jpg comes first. Just like there's no user expectation around whether photo1.jpg or Photo1.jpg comes first. Users also don't have the slightest idea about what order punctuation gets sorted in. Just sort the things that matter in the way users expect (natural sort order)…
> There's a user expectation that photo20.jpg comes after photo3.jpg
I expect photo20.jpg to come first.
> There's no user expectation around whether photo1.jpg or photo01.jpg comes first.
Clearly photo01.jpg comes first.
> Just like there's no user expectation around whether photo1.jpg or Photo1.jpg comes first.
Of course Photo1.jpg comes first because uppercase comes before lowercase.
It really sounds like you're using the word "user" to mean "dumb" and I wonder, what got you to the point that you started considering yourself an expert on "dumb" and feeling the need to defend "dumb" ?
I'm sorry but it all comes off so condescending, like "users" are a different+lower species or something.
> Does it matter? Yes. An algorithm must be unambiguosly specified for all possible inputs.
> An algorithm must be unambiguosly specified for all possible inputs. And it is. It's just that some outputs may not match what the user expects. TFA's preferred algorithm (simple lexicographic sorting) matches user expectations 90% of the time. The algorithm actually in use on most OSs (simple lexicographic sorting + treat consecutive digits as combined numbers) matches expectations 99% of the time. An algorithm th…
I get your point but I still disagree (also about the percentages btw). Can you also get _my_ point?
Well-designed machines quite _often_ operate against "user" expectations when those expectations are wrong.
For instance say if I charge my phone for an hour, it'll last for a day. How long will it last when I charge it for two hours? Because in practice the answer is either "also a day" or it is "the battery catches on fire", this machine acts _against_ user expectations and stops charging the phone after an hour.
Maybe an even better example: coins! I dunno about coins in the US but but get this: the 5 eurocent coin is _bigger_ than the 10 eurocent coin! I dunno why, or if there even is a good reason for that, but it doesn't seem to bother "users" of money (e.g. everybody) when they have to sort out cash.
Anyway my point is that even if _some_ (but definitely not all!) people may expect numerical sorting, doesn't mean that they're right ... and it's not like lexicographic sorting is rocket science and zero padding .. well I think you said you don't like the way it looks, but I actually think it looks very neat because things line up and it's actually easier to read for me, as well :)
It's dumbing things down, in a bad way. It's like hiding the inner workings of stuff, and it's a mistake to think that even if somebody is not familiar with computers that they are _stupid_. People might even get curious and figure out that numbers come before uppercase and those come before lowercase. And maybe one day someone comes along and says "you know that's because of ASCII?" and they learn a thing! Which is cool.
Instead it's like you're painting people scratching their heads wondering "why number not go up?"
Many commentors are positing the "clever" sort is what 99% of the user's want, but I really doubt it has been properly checked beyond the original PO's hunch and at most some user panel with pre-sampled data. Most of these decisions are early default behaviors that stay there as long as users aren't clamoring for change, and TBH I can't imagine most users to have a self emerging strong opinion on how alphabetical sor…
This case is really the opposite, though. Sorting strictly by character value was the default for decades because it was the quickest and easiest to implement. Only with computers hitting the really big mainstream, and millions of complaints from users who don't know the ASCII table by heart, or have ever heard of ASCII, did tools start to implement the kind of ordering logic that any user who isn't a developer would expect.
ls sorts filenames strictly lexicographically, comparing character by character, so e.g. "055436307" is compared as the characters "0", "5", "5", etc. so it sorts before "121134" because "0" is less than "1". if all compared characters match and one string ends, the shorter one comes first. Symbols like _ are just more characters, and their position relative to digits depends on the locale’s collation table. Google D…
It feels like this algorithm could be improved though. If a number has leading zeros you probably don't want to sort it numerically. That said the author's situation where it's numerical and different lengths seems likely rare enough that it probably isn't worth complicating things.
for me the takeaway here isn't that sorting should use some smarter/better mechanism for inferring semantic intent from filenames, but rather that sorting should not try to infer semantic intent from filenames in the first place
Nothing new about lexicographic order versus natural sort order. However, for people like me who love "creeping featurism", the UI and UX could be improved. First, both lexicographic order and natural sort order are not absolute, they are relative to an underlying character order, itself relying on character grouping algorithm (it is not the same thing to say a byte is a character and to group bytes to have an utf8 character or an utf32LE character). So far, the UI is just an "arrow" upward or downward next to Name column or things like that: easy as pie, one or two clicks next to a column name and you have the chosen order. But if you copy what is available in ERP with web apps like an ERP done with Django or another framework, you can:
- sort on many columns, each column sort being one element of a bigger lexicographic order on the chosen columns,
- propose many distinct sorts for the same column: most UIs stop at "increasing/decreasing" order, but with a modal, or one or more selects, you can propose to chose your wanted sort with more than two possible values. For example, if dealing with strings, most UIs only propose increasing/decreasing natural sort order grouping with UTF8 characters (GNU/Linux) or UTF16 characters (Windows) and default system collation. But instead you could treat any string as a sequence of bytes and select your character grouping algorithm (including a cascade : try to group as UTF8, if fails, try as UTF32LE, etc., if all fails use each byte as a character (not an ASCII one, UTF8 would have worked, an ISO-8859 for example, see collation after) ... you can start laughing ;) XD I'm still serious but I also know it is quite funny :) ), then select your collation, then select your sort between lexicographic and natural.
This is usually not needed, but would give full control to the user. And I love "creeping featurism" and giving full control to the user :). Typically, if one day an AI can code a variant of Gnome and Nautilus in a matter of hours, then with this kind of knowledge, if you know how to ask, you could have such a complex and juicy UI that is functional in a matter of hours :). Maybe one day we will all have custom-made OSs instead of ready-made OSs, and people with knowledge and a taste for complexity will have options mere mortals never thought of :). To return on the current ground, distinct sorts is common in ERPs with "type" or "status" columns: imagine you have an ERP with a webpage for today deliveries, and in some office someone needs the list of today deliveries with those that are already delivered at the top, in another office someone else needs those that are still currently in delivery at the top, and again someone else needs those that have an anomaly at the top, 3 distinct orders at least. I made up this example, and it is simple enough to think that a filter could replace an order, since I only talked about the top. But I can tell you such things do exist in real world applications.
I generally agree with your points (and love TDE) but > I don't use autosave either. I don't want the computer to assume when I want to save a file. The computer is too stupid to know that. That’s why, with auto save systems, you flag/name a version as your canonical save point. Rather like a video game, I’d rather have the autosaves and not need them, because I generally save the game myself, than not have them at a…
> with auto save systems, you flag/name a version as your canonical save point. You mean each saved version is stored separately, like a version control system? A system like that would be fine (in fact I use version control all the time for this kind of thing). But that's often not how auto save is implemented; the auto save just clobbers the last version you saved. That's the kind I don't use.
I’ve never used an autosave system for general software like that, overwriting the file but keeping no history, before. Which one behaves like that?