The native applications lost the battle.
Windows is not able to offer a consistent native UI over a decade.

The UI inconsistency in Linux was created by design.

MacOS is no longer the safe heaven where designers can work peacefully.

Electron Apps have , but they also lack off visual consistency and keyboard-driven workflows.

Some restartet from scratch with Dart and Flutter UI to replace Android legacy things. Google gave up because they needed a monopoly or a large enough market to succeed.

Zed did the same thing in Rust: they designed their own cross-platform GPU-renderer library. It lacks integration with the host OS on itself though.

On the contrary, TUIs are fast, easy to automate and work reasonably well in different operating systems.

The post lists practices to improve user-experience of command-line interface.

Problematic patterns

1. Borders in TUIs should always be drawn with characters specifically intended for textual interfaces (e.g., boxdraw characters).
2. Borders should be used sparingly, as they end up causing issues when the window is re-sized
3. Decorative content in CLI output should be limited, since the output of CLI utilities can be piped through other programs.
4. Nearly all animated spinners are extremely problematic for screenreaders. A simple progress meter and/or numeric percentage combined with flags to enable/disable them is preferable.
5. Excessive animation and color can harm users with attention and/or vestibular disorders, and some on the autism spectrum. Tools should respect the NO_COLOR environment variable.

Accessibility

6. Does the tool is usable once sended in espeak-ng?
7. Have a look to the WCAG
8. Avoid ASCII-art
9. Keep it boring to other common utilities to reduce the learning curve.
10. Follow convention: POSIX-like options
11. Be predictable with the options. The command only do one thing well.

Documentation

12. Write man pages. If your utility has a config file with special syntax or vocabulary, write a dedicated man page for it in section 5 and mention it in a “SEE ALSO” section.
13. Ennsure whatis and apropos work as intended after installing your man pages.
14. Try adding shell completions for your program, so users can tab-complete options.
15. Use a well-understood -h. It helps to generate shell completions. See https://www.busybox.net/ as example

Miscellaneous

1. Delegate output wrapping or detect the number of columns and format output to fit
2. Be safe. Addd a --dry-run or equivalent option.
3. Disable the colors when the tool is not a TTY, or when the user explicitly enables them.
4. Check the binary name or the packages first. It can already be used. dnf can help.

Opinionated

1. --help should be blazingly fast as user can be stressed using it
2. Include example usage in the man page and accompanying documentation.
3. Send example usages to the tldr pages project if the tool gets popular.
4. Include an extended list of example command invocations and expected output. Make that document double as a test suite.
5. Make your man pages as similar to other man pages on the target OS as possible. Many programs parse man pages, and expect them to follow a predictable structure. w3mman handles hyperlinks; editer like vim support looking up man pages; Pandoc can convert man pages to a variety of different formats.
6. Conform to tools that share a similar niche. If you’re using Rust to make a fast alternative to popular coreutils. ripgrep or fd for Rust, go vet for Go are good examples.
7. Make the output readable to both humans and machines
8. Consider splitting related functionality between many executables (the UNIX way) or subcommands (like Git). See https://www.lucasfcosta.com/blog/ux-patterns-cli-tools#consistent-commands-trees for more
9. Don’t conflate CLIs and TUIs. A CLI should be non-interactive; a TUI should be interactive.

Gowall started as a tool to convert an image ( specifically a wallpaper ) to any color-scheme / palette you like! It has now evolved to a swiss army knife of image prosessing offering (OCR,Image upsacling,image compression and a lot more)

More efficient but this is typically the tool that should be used when needed :)

A normalised way to handle CLI arguments and password handling via a set of available options.
Input are treated as streams.
Report progress via SIGINFO and spit out some statistic or diagnostic message.
My tools generally produce line-based output on stdout, as you would expect. If the output consists of multiple fields, it is either space- or comma separated; or JSON because the processing is easy with jq.

Temporary files can be used, but securely: https://www.netmeister.org/blog/mktemp.html

That's very interesting to get insights: hotspots, churn, coupledPairs, couplingRankings, codeAge, ownership, communication

Script a demo in a demo.tape file and generate a gif for it.

""Listen for Siri" (and Apple Intelligence) can still detect audio"

Cut the microphone of the mac, for real.

A feedback after 10 years of usage: https://sgoel.dev/posts/10-years-of-personal-finances-in-plain-text-files/

Fast, flexible mock API server powered by JSON configuration and a lightweight scripting language (rjscript).

The devlog
https://plok.sh/harmoneer/taman

Taman is a TUI Pomodoro productivity app where your focus sessions literally grow plants!

• 1password
• direnv to load envs only in specific directories