Paid hosting sign ups are closed there. Which is too bad, I don’t really want to self host this since it only works with postgres, and I have no other reason to setup/run/maintain postgres.
That does tend to be annoying, but my experience with maintaining postgres for my email setup so far has been to 1) set it up, 2) configure backups &c and 3) forget about it. So if you’re willing to put in the up-front work it’s probably pretty painless.
I’d never heard of this but just installed it, it’s cool. Light in resources, Debian package repo, clear installation instructions and it feels faster than ttrss. I’ve been using and advocating ttrss for years, but this might be my switch moment. The content parsing is better and it does not require an app on mobile. With ttrss I cannot subscribe to a feed in the ios app…
The only thing that keeps me from ditching ttrss is that miniflux seems to have no ability to adjust the sorting. I prefer to have the newest articles on top on the first page.
I’ve asked this the last time, but does anyone know why “rewritten in rust” and “overuse of colour and emojis” correlate? I have no need to switch from coreutils, but as someone who disables colours in my terminal sessions, I wouldn’t even want to (with the exception of ripgrep, where I get the technical advantage over rgrep).
I kind of think that “overuse of color and emojis” is a bit of an oversimplification, but I take your meaning. Or at least, I might say, “more thought and care given toward the overall user experience.” However, you might disagree with that, since you might think that colors and emojis actually make the user experience worse. (Although, to be honest, I’m not sure how much these tools use emojis.) With that said, I think it’s at least reasonable to say that many of the “new” tools (and not just Rust) are at least paying more attention to improving the overall user experience, even if they don’t actually improve it for every user. For example, I know for ripgrep at least, not everyone likes its “smart” filtering default, and that is absolutely a totally reasonable position to have. There’s a reason why I always include smart filtering in every short description of ripgrep; if you aren’t expecting it, it is not only surprising but frightening, because it violates your assumptions of what’s being searched. It’s a disorienting feeling. I know it all too well.
As for why this is happening, I’m not sure. If we wanted to get hand wavy about it, my personal take is that it’s some combination of lower barriers to entry to writing these kinds of tools and simultaneously providing more head space to even think about this stuff. So that means that you not only have more people entering the space of writing CLI tools, but you also have more breathing room to pay attention to the finer details of UX. This isn’t altogether surprising or unprecedented. Computing history is littered with building new and better abstractions on top of abstractions. As you move higher up the abstraction ladder, depending on the quality of said abstractions, you get more freedom to think about other things. This is, after all, one of the points of abstraction in the first place. And Rust is definitely an example of this IMO. And it’s not just about freeing yourself from worry about undefined behavior (something that I almost never have to do with Rust), but also about easy code reuse. Code reuse is a double edged sword, but many of these applications shared a lot of code in common that handle a lot of the tricky (or perhaps, “tedious” is a better word) details of writing a CLI application that conforms to common conventions that folks expect.
I also don’t think it is the only phenomenon occurring either. I think building these kinds of tools also requires tapping into a substantial audience that no longer cares (or cares enough) about POSIX. POSIX is a straight jacket for tools like this, and it really inhibits one’s ability to innovate holistically on the user experience. The only way you can really innovate in this space is if you’re not only willing to use tools that aren’t POSIX compatible, but build them as well. My pet theory is that the pool of these people has increased substantially over the past couple decades as our industry has centralized on fewer platforms. That is, my perception is that the straight jacket of POSIX isn’t providing as much bang for its buck as it once did. That isn’t to say that we don’t care about portability. We do. There’s been a lot of effort in the Rust ecosystem to make everything work smoothly on Linux, macOS and Windows. (And POSIX is a big part of that for Unix, but even among Unixes, not everything is perfectly compatible. And even then, POSIX often doesn’t provide enough to be useful. Even something as simple as directory traversal requires platform specific code. And then there’s Windows.) But beyond that, things drop off a fair bit. So there’s a lot of effort spent toward portability, but to a much more limited set of platforms than in the older days. I think the reason for that is a nearly universal move to commodity hardware and a subsequent drop in market share among any platform that isn’t Windows, macOS or Linux.
Sorry I got a bit rambly. And again, these are just some casual opinions and I didn’t try to caveat everything perfectly. So there’s a lot of room to disagree in the details. :-)
Just to provide feedback as a user of ripgrep, xsv, bat, broot. I have experienced no annoyance with respect to colourization or emojification of my terminal emulator. If I had to hypothesize, I think easy Unicode support in Rust allows people to embed emojis so they do.
The key is overuse. Some colour can sometimes be very helpful! Most most of these tools paint the screen like a hyperactive toddler instead of taking the time to think of what would improve the user’s experience.
taking the time to think of what would improve the user’s experience
I addressed this. Maybe they have taken the time to think about this and you just disagree with their choices? I don’t understand why people keep trying to criticize things that are border-line unknowable. How do you know how much the authors of these tools have thought about what would actually improve the user experience? How do you know they aren’t responding to real user feedback that asks for more color in places?
We don’t all have to agree about the appropriate amount of color, but for crying out loud, stop insinuating that we aren’t taking the appropriate amount of time to even think about these things.
“How much colour is too much colour” is kind of an empirical question; while design is certainly some matter of taste and trade-offs, generally speaking human brains all work roughly the same, so there is one (or a small range of) “perfect” designs. It seems quite a different problem than Ripgrep’s smart filtering you mentioned in your previous comment, which has more to do with personal preference and expectations.
See for example these Attention management and Color and Popout pages; the context here is very different (flight control systems), but it’s essentially the same problem as colour usage in CLI programs. I don’t know if there’s more research on this (been meaning to search for this for a while, haven’t gotten around to it yet).
Have some authors spent a long time thinking about this kind of stuff? Certainly. But it’s my observation based on various GitHub discussions and the like that a lot of the time it really does get added willy-nilly because it’s fashionable, so to speak. Not everything that is fashionable is also good; see the thin grey text on website fashion for example (which thankfully died down a wee bit now) which empirically makes things harder to read for many.
When I worked on vim-go people would submit patches to the syntax highlighting all the time by adding something for some specific thing. Did that improve readability for some? Maybe, I don’t know. For a while most of these patches were accepted because “why not?” and because refusing patches is kind of draining, but all of the maintainers agreed that this added colouring didn’t really improve vim-go’s syntax highlighting and were superfluous at best. There certainly wasn’t a lot of thought put in to this on our part to be honest, and when we started putting thought in to it, it was too late and we didn’t want to remove anything and break people’s stuff.
“How much colour is too much colour” is kind of an empirical question; while design is certainly some matter of taste and trade-offs, generally speaking human brains all work roughly the same, so there is one (or a small range of) “perfect” designs. It seems quite a different problem than Ripgrep’s smart filtering you mentioned in your previous comment, which has more to do with personal preference and expectations.
While I agree that it’s a quantifiable question, there’s 2 classic problems here.
All quantifications in user design are “70% of users find this useful” for statement A, and “60 % don’t find it useful” for statement B. The often committed mistake is then assuming that you should implement “A & ^B”, ignoring that you now need to analyse the overlap.
The second is that good quantification are a lot of work and need tons of background knowledge, with standard books on color and interface perception doubling as effective close combat weapons.
A classic answer to the above problem is that good UI uses at least two channels, potentially configurable. So if if the group that doesn’t find B useful isn’t having problems with it, having both is a good option. Your cited Color and Popout page is a very good example of that. And it gracefully degrades for people that do e.g. not see color well. And especially emoji based CLI programs do that very well: Emoji don’t take up a lot of space, are easily differentiable, are accessible to screen readers while still keeping their symbolic character - the line afterwards is the thing for people that need the details.
While I agree with your fashion argument, but see it in a much more positive light: user interface trends have the benefit of making good basics the default - if they are successful. This is community practice learning - I would say that the phase of gray text made the design community realise that readability is not optional when reading text. This may seem trivial, but it isn’t unsurprising that this trend came up when visual splendor was much easier available in websites and the current focus of that time.
For a practical summary of research and reading, I can highly recommend “Information Visualization: Perception for Design” by Colin Ware. Take care, though, it was updated for the 4th Edition this year and many vendors still try to sell you the 3rd. For a book of around 70$, I’d hate if you fell into that trap ;). It’s the book I learned from in University courses and found it very accessible, practical, but also scientifically rigorous. It also spends a lot of time on when visual encoding should be applied, when not and especially has clarity and accessibility as its biggest goals.
Also, even scientific research isn’t protected of the fads you describe: for a long time, with enough computational power available, everyone tried to make visualisations 3 dimensional. That’s generally seen as a mistake today, because either you just add fake depth to you bar diagram while it still remains essentially 2D (wasting the channel), or you run into problems of perspective and occlusion, which make it hard to judge distances and relationships making you turn the image all the time, because 3D data is still projected on 2D. Reading 3D data is a special skill.
What are some examples? Curious what makes you think that the authors did not consider user experience when implementing nonstandard features specifically in pursuit of user experience? No doubt their efforts may not land well with some of the users. I just think it’s a bit dismissive to assume that the authors didn’t put thought into their open source projects, and pretty rude to characterize the fruits of their labor as a “hyperactive toddler”.
As a personal data point: I use fd, ripgrep, and hexyl, and they’re fine. However, I tried exa (a replacement for ls) and exa -l colors absolutely everything, which I find overwhelming compared to ls -l (which for me colors just the file/directories/symlinks). To me it seems like exa developers pushed it a bit too far :-)
Cool. It definitely seems that exa in particular colorizes a lot of things by default. My initial thought is “wouldn’t it be nice if I could customize this” and it turns out you totally can via the EXA_COLORS variable (see man exa).
I think the ideal colorized tool would roughly do the following: it would make coloring configurable, ship with reasonable defaults, and then some presets for users with disabilities, colorblindnesses, or those who prefer no color at all.
compared to ls -l (which for me colors just the file/directories/symlinks).
This is likely local configuration, whether you’re aware of it or not. GNU ls will happily color more or fewer things, in different ways, based on the LS_COLORS environment variable and/or configuration files like ~/.dir_colors. See also the dircolors utility.
Interesting, TIL. I don’t have a ~/.dir_colors but LS_COLORS is indeed full of stuff (probably added by fish?). In any case, exa was a bit much, the permissions columns are very very colorful. Maybe it’s to incentivize me to use stricter permissions 😂
If we wanted to get hand wavy about it, my personal take is that it’s some combination of lower barriers to entry to writing these kinds of tools and simultaneously providing more head space to even think about this stuff
It seems plausible, adding colours or UI extensions sounds like a good “first patch” for people learning Rust and wanting to contribute to “real world” projects.
That’s not exactly what I had in mind. The syntax highlighting that bat does, for example, is one of its central features AFAIK. I don’t know exactly how much integration work it took, but surely a decent chunk of the heavy lifting is being done by syntect. That’s what I mean by headspace and lower barriers to entry.
why “rewritten in rust” and “overuse of colour and emojis” correlate?
JS community does the same. I think it’s not specific to Rust, but specific to “modern” rewrites in general (modern for better or worse).
I see a similar thing in C/C++ rewrites of old C software – htop and ncmpcpp both use colours while top and ncmpc did not. Newer languages, newer eyecandy.
JS community does the same. I think it’s not specific to Rust, but specific to “modern” rewrites in general (modern for better or worse).
The phrase “modern” is a particular pet peeve of mine. It’s thrown around a lot and doesn’t seem to add anything to most descriptions. It is evocative without being specific. It is criticism without insight. Tell me what makes it “modern” and why that is good. The term by itself means almost nothing which means it can be used anywhere.
AIUI “modern” as it relates to TUIs means “written since the ascendence of TERM=xterm-256color and Unicode support, and probably requires a compiler from the last 10 years to build.” Design wise it’s the opposite of “retro”
I don’t see how it’s a criticism (what’s it criticizing?), Or why every word needs to be somehow insightful, It’s just a statement that it’s a departure from tradition. It’s like putting a NEW sticker on a product. It doesn’t mean anything more than “takes more current design trends into account than last year’s model”
I think a “new” sticker on a product tells you more than sticking “modern” in a software project page. At least you know it isn’t used/refurbished. What constitutes modern is a moving target. It may be helpful if you had knowledge of the domain in which it’s being used, but otherwise it’s just fluff.
Worse, I think it doesn’t present a nuanced view of the design choices that go into the product. In my mind it subtlety indicates that old is bad and new is good. That thinking discourages you from learning from the past or considering the trade offs being made.
Moreover I think it bugs me because I work in a NodeJS shop. When I ask people what’s great about a package they tell me it’s modern. It’s just modern this or modern that. It barely means anything. So maybe take this with a grain of salt.
Huh. I think this must be a cultural difference. Working with C and C++ packages, ‘modern’ has a bit more meaning because of the significant changes that have happened in the languages themselves in a reasonably recent fraction of their existence. (For example, “modern” C++ generally avoids raw pointers, “modern” C generally doesn’t bother with weird corner cases on machines that aren’t 32 or 64 bit architectures I can currently buy)
It’s even true to a lesser extent in python, “modern” usually refers to async/generators/iterators as much as possible, while I agree that “modern” definitely does lack nuance, it fits in an apt package description and means roughly “architected after 2010,” and I think this is a reasonable use of 6characters.
You make a library. It’s nice and new and modern. You put up a website that tells people that your package is modern. The website is good, the package is good. It’s a solved problem so you don’t work on it any more. Ten years pass and your website is still claiming that it is modern. Is it? Are there other ways that you could have described your project that would still be valid in ten years? In twenty years?
The definition of modern exists in flux and is tied to a community, to established practices, and, critically, a place in time. It is not very descriptive in and of itself. It’s a nod, a wink, and a nudge nudge to other people in the community that share the relevant context.
I definitely see your point, but I’d also argue that if I put something on the internet and left it alone for 10 years, it would be obvious that it’s “modern” (if it’s still up at all) is that of another age. If you’d done this 10 years ago, you’d likely be hosted by sourceforge, which these days is pretty indicative of inactivity. It also doesn’t change that your package is appreciably different than the ones serving a similar purpose that are older.
There are buildings almost 100 years old that count as “modern” (also, there are ‘modern’ buildings made after ‘postmodern’ ones. Wat?) It’s a deliberately vague term for roughly “minimal ornament, eschewing tradition, and being upfront about embracing the materials and techniques of the time” what “the time” is is usually obvious due to this (and IMO it is in software as well). The operative part isn’t that it’s literally new, more that it’s a departure from what was current. and when a modern thing gets old, it doesn’t stop being modern, it just gets sidelined by things labelled modern that embrace the tools and techniques of a later time. Architects and artists don’t have an issue with this, why should we?
Libuv is I think a good example IMO. I’d call it “modern”, but it’s not new. That said, it doesn’t claim to be.
Honestly, given how tricky it is for me to pin this down I feel like I should agree with you that it’s cruft, but I just… Don’t… I think it’s cause there’s such a strong precedent in art and architecture. Last time I was there, Half of the museum of modern art was items from before the Beatles.
Honestly, given how tricky it is for me to pin this down I feel like I should agree with you that it’s cruft, but I just… Don’t… I think it’s cause there’s such a strong precedent in art and architecture. Last time I was there, Half of the museum of modern art was items from before the Beatles.
Haha, well, I think we’ll have to agree to disagree then.
Ultimately, I’m being a bit of hardliner. There is value in short hand and to be effective we need to understand things in their context. I think being explicit allows you to reach a wider audience, but it is more work and sometimes we don’t have the extra energy to spread around. I’d rather have the package exist with imprecise language than have no package at all.
I don’t blame you – I haven’t been taking JS software seriously either ;) Whenever I see an interesting project with a package.json in it I go “ugh, maybe next time”. Rust rewrites at least don’t contribute to the trend of making the software run slower more rapidly than the computers are getting faster.
But seriously: I don’t think so many tools and projects would be putting the effort into looking the way they do, if nobody wanted it. I just think that colour is better used sparingly, so that issues that really need your attention are easier to spot.
I suspect that the pool of tool users has expanded to incorporate people with different learning styles, and also that as times change, the aesthetic preferences of new users track aesthetic changes in culture as a whole (like slang usage and music tastes).
Personally, I find color extremely useful in output as it helps me focus quickly on important portions of the output first, and then lets me read the rest of the output in leisure. I’ve been using *nix since I was a kid, and watching tools evolve to have color output has been a joy. I do find certain tools to be overly colorful, and certain new tools to not fit my personal workflow or philosophy of tooling (bat isn’t my cup of tea, for example). That said not all “modern” rewrites feature color, choose being the example that comes up for me immediately.
(On emojis I’m not really sure, and I haven’t really seen much emoji use outside of READMEs and such. I do appreciate using the checkmark Unicode character instead of the ASCII [x] for example, but otherwise I’m not sure.)
I wrote this blog post as an answer to this article. I am also wondering why this “overuse of color” is so popular among “rewritten in rust” kind of tools.
I think this is generally true of CLI tools written since Unicode support in terminals and languages is commonplace. I don’t have any examples but I’ve gotten a similar impression from the go.community. I think emojis and colors in terminals are kind of in Vogue right now, as is rewriting things in rust, so… Yeah, that’s my hypothesis on the correlation.
Aside, as someone with rather bad visual acuity and no nostalgia for the 80s, I like it.
I implemented this in Go a while ago: https://codeberg.org/rumpelsepp/ni
I use https://neo-layout.org/. Perfect for German and English und coding.
Should be it.
One more argument to move to miniflux.
Paid hosting sign ups are closed there. Which is too bad, I don’t really want to self host this since it only works with postgres, and I have no other reason to setup/run/maintain postgres.
That does tend to be annoying, but my experience with maintaining postgres for my email setup so far has been to 1) set it up, 2) configure backups &c and 3) forget about it. So if you’re willing to put in the up-front work it’s probably pretty painless.
Postgres has a pretty easy-to-use docker container, which would probably be adequate for this use.
Except when trying to migrate to another major postgres release, which isn’t all that easy with those containers.
In that case and for this use I’d probably just do a dump and restore. There’s no downtime limitation, so that seems like it should be adequate.
I’d never heard of this but just installed it, it’s cool. Light in resources, Debian package repo, clear installation instructions and it feels faster than ttrss. I’ve been using and advocating ttrss for years, but this might be my switch moment. The content parsing is better and it does not require an app on mobile. With ttrss I cannot subscribe to a feed in the ios app…
Thank you!
The only thing that keeps me from ditching ttrss is that miniflux seems to have no ability to adjust the sorting. I prefer to have the newest articles on top on the first page.
Under Settings there seems to be a sort option. I also want newest on top: https://i.postimg.cc/bN85Jvwn/Selectie-0988.png
Nice thanks!
I’ve asked this the last time, but does anyone know why “rewritten in rust” and “overuse of colour and emojis” correlate? I have no need to switch from coreutils, but as someone who disables colours in my terminal sessions, I wouldn’t even want to (with the exception of ripgrep, where I get the technical advantage over rgrep).
I kind of think that “overuse of color and emojis” is a bit of an oversimplification, but I take your meaning. Or at least, I might say, “more thought and care given toward the overall user experience.” However, you might disagree with that, since you might think that colors and emojis actually make the user experience worse. (Although, to be honest, I’m not sure how much these tools use emojis.) With that said, I think it’s at least reasonable to say that many of the “new” tools (and not just Rust) are at least paying more attention to improving the overall user experience, even if they don’t actually improve it for every user. For example, I know for ripgrep at least, not everyone likes its “smart” filtering default, and that is absolutely a totally reasonable position to have. There’s a reason why I always include smart filtering in every short description of ripgrep; if you aren’t expecting it, it is not only surprising but frightening, because it violates your assumptions of what’s being searched. It’s a disorienting feeling. I know it all too well.
As for why this is happening, I’m not sure. If we wanted to get hand wavy about it, my personal take is that it’s some combination of lower barriers to entry to writing these kinds of tools and simultaneously providing more head space to even think about this stuff. So that means that you not only have more people entering the space of writing CLI tools, but you also have more breathing room to pay attention to the finer details of UX. This isn’t altogether surprising or unprecedented. Computing history is littered with building new and better abstractions on top of abstractions. As you move higher up the abstraction ladder, depending on the quality of said abstractions, you get more freedom to think about other things. This is, after all, one of the points of abstraction in the first place. And Rust is definitely an example of this IMO. And it’s not just about freeing yourself from worry about undefined behavior (something that I almost never have to do with Rust), but also about easy code reuse. Code reuse is a double edged sword, but many of these applications shared a lot of code in common that handle a lot of the tricky (or perhaps, “tedious” is a better word) details of writing a CLI application that conforms to common conventions that folks expect.
I also don’t think it is the only phenomenon occurring either. I think building these kinds of tools also requires tapping into a substantial audience that no longer cares (or cares enough) about POSIX. POSIX is a straight jacket for tools like this, and it really inhibits one’s ability to innovate holistically on the user experience. The only way you can really innovate in this space is if you’re not only willing to use tools that aren’t POSIX compatible, but build them as well. My pet theory is that the pool of these people has increased substantially over the past couple decades as our industry has centralized on fewer platforms. That is, my perception is that the straight jacket of POSIX isn’t providing as much bang for its buck as it once did. That isn’t to say that we don’t care about portability. We do. There’s been a lot of effort in the Rust ecosystem to make everything work smoothly on Linux, macOS and Windows. (And POSIX is a big part of that for Unix, but even among Unixes, not everything is perfectly compatible. And even then, POSIX often doesn’t provide enough to be useful. Even something as simple as directory traversal requires platform specific code. And then there’s Windows.) But beyond that, things drop off a fair bit. So there’s a lot of effort spent toward portability, but to a much more limited set of platforms than in the older days. I think the reason for that is a nearly universal move to commodity hardware and a subsequent drop in market share among any platform that isn’t Windows, macOS or Linux.
Sorry I got a bit rambly. And again, these are just some casual opinions and I didn’t try to caveat everything perfectly. So there’s a lot of room to disagree in the details. :-)
Just to provide feedback as a user of
ripgrep,xsv,bat,broot. I have experienced no annoyance with respect to colourization or emojification of my terminal emulator. If I had to hypothesize, I think easy Unicode support in Rust allows people to embed emojis so they do.The key is overuse. Some colour can sometimes be very helpful! Most most of these tools paint the screen like a hyperactive toddler instead of taking the time to think of what would improve the user’s experience.
I addressed this. Maybe they have taken the time to think about this and you just disagree with their choices? I don’t understand why people keep trying to criticize things that are border-line unknowable. How do you know how much the authors of these tools have thought about what would actually improve the user experience? How do you know they aren’t responding to real user feedback that asks for more color in places?
We don’t all have to agree about the appropriate amount of color, but for crying out loud, stop insinuating that we aren’t taking the appropriate amount of time to even think about these things.
“How much colour is too much colour” is kind of an empirical question; while design is certainly some matter of taste and trade-offs, generally speaking human brains all work roughly the same, so there is one (or a small range of) “perfect” designs. It seems quite a different problem than Ripgrep’s smart filtering you mentioned in your previous comment, which has more to do with personal preference and expectations.
See for example these Attention management and Color and Popout pages; the context here is very different (flight control systems), but it’s essentially the same problem as colour usage in CLI programs. I don’t know if there’s more research on this (been meaning to search for this for a while, haven’t gotten around to it yet).
Have some authors spent a long time thinking about this kind of stuff? Certainly. But it’s my observation based on various GitHub discussions and the like that a lot of the time it really does get added willy-nilly because it’s fashionable, so to speak. Not everything that is fashionable is also good; see the thin grey text on website fashion for example (which thankfully died down a wee bit now) which empirically makes things harder to read for many.
When I worked on vim-go people would submit patches to the syntax highlighting all the time by adding something for some specific thing. Did that improve readability for some? Maybe, I don’t know. For a while most of these patches were accepted because “why not?” and because refusing patches is kind of draining, but all of the maintainers agreed that this added colouring didn’t really improve vim-go’s syntax highlighting and were superfluous at best. There certainly wasn’t a lot of thought put in to this on our part to be honest, and when we started putting thought in to it, it was too late and we didn’t want to remove anything and break people’s stuff.
While I agree that it’s a quantifiable question, there’s 2 classic problems here.
All quantifications in user design are “70% of users find this useful” for statement A, and “60 % don’t find it useful” for statement B. The often committed mistake is then assuming that you should implement “A & ^B”, ignoring that you now need to analyse the overlap.
The second is that good quantification are a lot of work and need tons of background knowledge, with standard books on color and interface perception doubling as effective close combat weapons.
A classic answer to the above problem is that good UI uses at least two channels, potentially configurable. So if if the group that doesn’t find B useful isn’t having problems with it, having both is a good option. Your cited Color and Popout page is a very good example of that. And it gracefully degrades for people that do e.g. not see color well. And especially emoji based CLI programs do that very well: Emoji don’t take up a lot of space, are easily differentiable, are accessible to screen readers while still keeping their symbolic character - the line afterwards is the thing for people that need the details.
While I agree with your fashion argument, but see it in a much more positive light: user interface trends have the benefit of making good basics the default - if they are successful. This is community practice learning - I would say that the phase of gray text made the design community realise that readability is not optional when reading text. This may seem trivial, but it isn’t unsurprising that this trend came up when visual splendor was much easier available in websites and the current focus of that time.
For a practical summary of research and reading, I can highly recommend “Information Visualization: Perception for Design” by Colin Ware. Take care, though, it was updated for the 4th Edition this year and many vendors still try to sell you the 3rd. For a book of around 70$, I’d hate if you fell into that trap ;). It’s the book I learned from in University courses and found it very accessible, practical, but also scientifically rigorous. It also spends a lot of time on when visual encoding should be applied, when not and especially has clarity and accessibility as its biggest goals.
Also, even scientific research isn’t protected of the fads you describe: for a long time, with enough computational power available, everyone tried to make visualisations 3 dimensional. That’s generally seen as a mistake today, because either you just add fake depth to you bar diagram while it still remains essentially 2D (wasting the channel), or you run into problems of perspective and occlusion, which make it hard to judge distances and relationships making you turn the image all the time, because 3D data is still projected on 2D. Reading 3D data is a special skill.
What are some examples? Curious what makes you think that the authors did not consider user experience when implementing nonstandard features specifically in pursuit of user experience? No doubt their efforts may not land well with some of the users. I just think it’s a bit dismissive to assume that the authors didn’t put thought into their open source projects, and pretty rude to characterize the fruits of their labor as a “hyperactive toddler”.
As a personal data point: I use fd, ripgrep, and hexyl, and they’re fine. However, I tried
exa(a replacement forls) andexa -lcolors absolutely everything, which I find overwhelming compared tols -l(which for me colors just the file/directories/symlinks). To me it seems likeexadevelopers pushed it a bit too far :-)Cool. It definitely seems that exa in particular colorizes a lot of things by default. My initial thought is “wouldn’t it be nice if I could customize this” and it turns out you totally can via the
EXA_COLORSvariable (seeman exa).I think the ideal colorized tool would roughly do the following: it would make coloring configurable, ship with reasonable defaults, and then some presets for users with disabilities, colorblindnesses, or those who prefer no color at all.
exa -lgh --color=neverseems flag heavy but that’s just me and there’s probably more than one way to do it
Flag heaviness doesn’t matter much in this case though, since it can be trivially aliased in shell configuration.
This is likely local configuration, whether you’re aware of it or not. GNU
lswill happily color more or fewer things, in different ways, based on theLS_COLORSenvironment variable and/or configuration files like~/.dir_colors. See also thedircolorsutility.Interesting, TIL. I don’t have a
~/.dir_colorsbutLS_COLORSis indeed full of stuff (probably added by fish?). In any case,exawas a bit much, the permissions columns are very very colorful. Maybe it’s to incentivize me to use stricter permissions 😂Agree. Most people’s shell prompts are essentially rainbow unicorn vomit.
It seems plausible, adding colours or UI extensions sounds like a good “first patch” for people learning Rust and wanting to contribute to “real world” projects.
That’s not exactly what I had in mind. The syntax highlighting that bat does, for example, is one of its central features AFAIK. I don’t know exactly how much integration work it took, but surely a decent chunk of the heavy lifting is being done by syntect. That’s what I mean by headspace and lower barriers to entry.
JS community does the same. I think it’s not specific to Rust, but specific to “modern” rewrites in general (modern for better or worse).
I see a similar thing in C/C++ rewrites of old C software – htop and ncmpcpp both use colours while top and ncmpc did not. Newer languages, newer eyecandy.
The phrase “modern” is a particular pet peeve of mine. It’s thrown around a lot and doesn’t seem to add anything to most descriptions. It is evocative without being specific. It is criticism without insight. Tell me what makes it “modern” and why that is good. The term by itself means almost nothing which means it can be used anywhere.
AIUI “modern” as it relates to TUIs means “written since the ascendence of TERM=xterm-256color and Unicode support, and probably requires a compiler from the last 10 years to build.” Design wise it’s the opposite of “retro”
I don’t see how it’s a criticism (what’s it criticizing?), Or why every word needs to be somehow insightful, It’s just a statement that it’s a departure from tradition. It’s like putting a NEW sticker on a product. It doesn’t mean anything more than “takes more current design trends into account than last year’s model”
I think a “new” sticker on a product tells you more than sticking “modern” in a software project page. At least you know it isn’t used/refurbished. What constitutes modern is a moving target. It may be helpful if you had knowledge of the domain in which it’s being used, but otherwise it’s just fluff.
Worse, I think it doesn’t present a nuanced view of the design choices that go into the product. In my mind it subtlety indicates that old is bad and new is good. That thinking discourages you from learning from the past or considering the trade offs being made.
Moreover I think it bugs me because I work in a NodeJS shop. When I ask people what’s great about a package they tell me it’s modern. It’s just modern this or modern that. It barely means anything. So maybe take this with a grain of salt.
Huh. I think this must be a cultural difference. Working with C and C++ packages, ‘modern’ has a bit more meaning because of the significant changes that have happened in the languages themselves in a reasonably recent fraction of their existence. (For example, “modern” C++ generally avoids raw pointers, “modern” C generally doesn’t bother with weird corner cases on machines that aren’t 32 or 64 bit architectures I can currently buy)
It’s even true to a lesser extent in python, “modern” usually refers to async/generators/iterators as much as possible, while I agree that “modern” definitely does lack nuance, it fits in an apt package description and means roughly “architected after 2010,” and I think this is a reasonable use of 6characters.
Here’s another way of looking at it:
You make a library. It’s nice and new and modern. You put up a website that tells people that your package is modern. The website is good, the package is good. It’s a solved problem so you don’t work on it any more. Ten years pass and your website is still claiming that it is modern. Is it? Are there other ways that you could have described your project that would still be valid in ten years? In twenty years?
The definition of modern exists in flux and is tied to a community, to established practices, and, critically, a place in time. It is not very descriptive in and of itself. It’s a nod, a wink, and a nudge nudge to other people in the community that share the relevant context.
I definitely see your point, but I’d also argue that if I put something on the internet and left it alone for 10 years, it would be obvious that it’s “modern” (if it’s still up at all) is that of another age. If you’d done this 10 years ago, you’d likely be hosted by sourceforge, which these days is pretty indicative of inactivity. It also doesn’t change that your package is appreciably different than the ones serving a similar purpose that are older.
There are buildings almost 100 years old that count as “modern” (also, there are ‘modern’ buildings made after ‘postmodern’ ones. Wat?) It’s a deliberately vague term for roughly “minimal ornament, eschewing tradition, and being upfront about embracing the materials and techniques of the time” what “the time” is is usually obvious due to this (and IMO it is in software as well). The operative part isn’t that it’s literally new, more that it’s a departure from what was current. and when a modern thing gets old, it doesn’t stop being modern, it just gets sidelined by things labelled modern that embrace the tools and techniques of a later time. Architects and artists don’t have an issue with this, why should we?
Libuv is I think a good example IMO. I’d call it “modern”, but it’s not new. That said, it doesn’t claim to be.
Honestly, given how tricky it is for me to pin this down I feel like I should agree with you that it’s cruft, but I just… Don’t… I think it’s cause there’s such a strong precedent in art and architecture. Last time I was there, Half of the museum of modern art was items from before the Beatles.
I do think it sounds a bit presumptuous
Haha, well, I think we’ll have to agree to disagree then.
Ultimately, I’m being a bit of hardliner. There is value in short hand and to be effective we need to understand things in their context. I think being explicit allows you to reach a wider audience, but it is more work and sometimes we don’t have the extra energy to spread around. I’d rather have the package exist with imprecise language than have no package at all.
That’s a fair point, I guess I have just been noticing more Rust rewrites, or haven’t been taking JS CLI-software seriously?
I don’t blame you – I haven’t been taking JS software seriously either ;) Whenever I see an interesting project with a package.json in it I go “ugh, maybe next time”. Rust rewrites at least don’t contribute to the trend of making the software run slower more rapidly than the computers are getting faster.
As someone who appreciates colors in the terminal, I’m pretty into it. I think it’s just a personal preference.
Wrong, but ok ;)
But seriously: I don’t think so many tools and projects would be putting the effort into looking the way they do, if nobody wanted it. I just think that colour is better used sparingly, so that issues that really need your attention are easier to spot.
Because it’s easy in Rust. It has first-class Unicode support, and convenient access to cross-platform terminal-coloring crates.
I suspect that the pool of tool users has expanded to incorporate people with different learning styles, and also that as times change, the aesthetic preferences of new users track aesthetic changes in culture as a whole (like slang usage and music tastes).
Personally, I find color extremely useful in output as it helps me focus quickly on important portions of the output first, and then lets me read the rest of the output in leisure. I’ve been using *nix since I was a kid, and watching tools evolve to have color output has been a joy. I do find certain tools to be overly colorful, and certain new tools to not fit my personal workflow or philosophy of tooling (
batisn’t my cup of tea, for example). That said not all “modern” rewrites feature color,choosebeing the example that comes up for me immediately.(On emojis I’m not really sure, and I haven’t really seen much emoji use outside of READMEs and such. I do appreciate using the checkmark Unicode character instead of the ASCII
[x]for example, but otherwise I’m not sure.)I think it is more of a new tool trend than new language trend. I see similar issue in other new tools not written in Rust.
Perhaps it’s simply that Rust has empowered a lot of young people, and young people like colors and emojis?
I wrote this blog post as an answer to this article. I am also wondering why this “overuse of color” is so popular among “rewritten in rust” kind of tools.
I think this is generally true of CLI tools written since Unicode support in terminals and languages is commonplace. I don’t have any examples but I’ve gotten a similar impression from the go.community. I think emojis and colors in terminals are kind of in Vogue right now, as is rewriting things in rust, so… Yeah, that’s my hypothesis on the correlation.
Aside, as someone with rather bad visual acuity and no nostalgia for the 80s, I like it.