Hacker News Reader

Comment by epistasis | Hacker News Reader

This is reminding me of the whole "Worse is better" essay and debate:

https://news.ycombinator.com/item?id=27916370

The author wants the "worse" sort, one based on ASCII/Unicode codepoints, without any intelligence for numbers that 99% of GUI users want.

For their purposes, they've assumed something about the implementation, to the point that a convenience feature is actually a misfeature for them. But the author here is probably a developer, or close to one, so they do not represent the needs of most people using computers.

Understanding the target audience for your product results in very different design decisions. Better is better might be great for products, but worse is better is probably better for systems that need to grow and evolve.

View on HN

It's an issue of mental models. As a developer, his mental model is one of how naive software would sort items with mixed numbers in them. Most people, of course, naturally sort 10 after 9 -- their mental model doesn't contain software developer assumptions.

> The author wants the "worse" sort, one based on ASCII/Unicode codepoints, without any intelligence for numbers that 99% of GUI users want.

I want the author's opinion on how caplital and lowercase letters should be sorted. Do they follow strict ASCII/Unicode codepoints, or do they normalize into actual alphabetical order and sort upper/lower within each letter?

Asciibetical sorting

And where do you sort the letter ä? (After a is correct in German, but I think Swedish does it differently.)

This feels like the right moment to mention "ch", which is considered a letter in orthodox Czech, sorted between "h" and "i". The problem is, you can't reliably distinguish between "ch"-the-letter and "ch" as just "c" and "h" combined, which are present in loan words but also some original Czech compound words.

So if you're doing it "properly", sorting strings in Czech involves understanding the etymology of every word.

What a headache! I'm glad that the relevant standard ČSN 97 6030 does not demand analysis of compounds or knowledge of etymology.

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?

The sorting order is only defined between strings of the same locale, not between strings of different locales.

You can specify the sorting order per command like

LC_COLLATE="tr_TR.utf8" ls

if it differs from your system or user locale.

An alternative is to first transliterate the strings to ASCII and then sort them (but this does not preserve the sorting order of non-latin scripts).

I'm multi-lingual but try to separate business stuff for example (multi-lingual) from private stuff (mostly one language), so clashes between languages rarely happen.

But if it gets complicated I'll usually resort to Perl scripts to take care of pesky details. Sorting an associative array where the key is a string in unified form and the value is the multi-lingual target is rather easy in a script language which one is fluent in.

You could alias cd to a shell script that sets the env based on the location.

> export LC_TIME=en_US.UTF-8

Why would you do this to yourself?

Why? For example to not have diacritics in month names? Take them as examples as you can easily add them to a shell script to make in work the way you want.

But you get

* 12h time

* Sunday start of week

* Silly pyramid mm/dd/yyyy

> I want the author's opinion on how caplital and lowercase letters should be sorted. Do they follow strict ASCII/Unicode codepoints, or do they normalize into actual alphabetical order and sort upper/lower within each letter?

I prefer the strict ASCII / Unicode sorting (all capitals first, then all lowercase).

> most people using computers

> the target audience

Which is it? Those should be different groups.

"Most people" have incoherent ideas that can't even be used. So instead a designer cherry-picks some ideas - setting the agenda - and declares that they're popular. That doesn't make them good ideas. Also, "most people" are easily influenced and will like the terrible things that they've been told to like.

>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/20 rule? Most features will be used by only a small slice of users, that doesn't mean they're out of scope.

Sorry, I'm just kind of exhausted of software not being able to do the most obvious things because it didn't align to some perfect vision of how the user should be.

> 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 not get started on how we're wasting time adding things that they don't personally need, and therefore no one could possibly need, ever. No, clearly by adding this sorting method, we must have directly stolen development time from the feature they want, which is a personal attack directed at them and every member of their family going three generations back.

It is best to not engage with these demons.

KDE welcomes configurable complexity, Gnome deemphasises it. I am glad that broad user choice exists.

> 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.

Reply on news.ycombinator.com