You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The CLI has become a central tool in the Herbs developer experience.
The current CLI has two problems in my opinion: the first is technical, with low test coverage and with many responsibilities, making it difficult to evolve. The second is a DX (developer experience) which is ok, but not amazing.
But the CLI, like the website, is where developers perceive the quality of the project. In addition, differentiated DX can have a real impact on the developer's daily life and performance.
With that in mind, I'd like to bring the teaser to the contributors: the CLI should be AWESOME!
This means:
Beautiful, nice and innovative UI
UX focused on the developers' job to be done
use the best practices
stay close to market trends
extract as much of the possibilities that the terminal allows
The developer using this CLI should feel like using something completely new, as well as feeling empowered to extract the maximum value from the tool. In short: developers need to love the CLI!
This could also be an opportunity to think about a new architecture that not only supports the evolution of the tool, but also brings concepts such as plugins, templates, etc.
I've been researching and doing some benchmarks and would like to share some here:
UI
When I look at projects like Ink and Textualize, I see that there are still a lot of UI possibilities in the terminal that we are not exploring.
These tools open up a world of possibility from the point of view of usability and new aesthetics.
The aforementioned tools can greatly improve the usability of the CLI. In addition, we can apply best practices from other established CLIs that are loved by developers.
For example, what would it be like to bring herbsshelf to the CLI? Or what would a new experience for Aloe on the CLI look like?
Documentation:
The DX for documentation can be raised to the tenth power, be it the doc from the CLI, from Herbs and of course from the project itself using Herbs.
Architecture
A new CLI is the opportunity to rethink the successes and mistakes of the past.
Responsibilities:
Currently there are responsibilities in the CLI that do not necessarily need to be in the CLI. Ex: Aloe test runner, complex and specialized file generation logics, etc.
What would an architecture that could be more modularized look like?
Tests:
By modularizing the CLI, it would be an opportunity to create more specific and decoupled tests, which could run in milliseconds, without file system dependency, for example.
Conclusion
For now I'm just putting everything in my head in terms of possibilities here. I believe that CLI can have a very high impact on the project and therefore deserves our attention and affection.
As next steps, the brainstorm is open to contributors. I intend to bring some ideas based on the content I brought here as well.
The text was updated successfully, but these errors were encountered:
The CLI has become a central tool in the Herbs developer experience.
The current CLI has two problems in my opinion: the first is technical, with low test coverage and with many responsibilities, making it difficult to evolve. The second is a DX (developer experience) which is ok, but not amazing.
But the CLI, like the website, is where developers perceive the quality of the project. In addition, differentiated DX can have a real impact on the developer's daily life and performance.
With that in mind, I'd like to bring the teaser to the contributors: the CLI should be AWESOME!
This means:
The developer using this CLI should feel like using something completely new, as well as feeling empowered to extract the maximum value from the tool. In short: developers need to love the CLI!
This could also be an opportunity to think about a new architecture that not only supports the evolution of the tool, but also brings concepts such as plugins, templates, etc.
I've been researching and doing some benchmarks and would like to share some here:
UI
When I look at projects like Ink and Textualize, I see that there are still a lot of UI possibilities in the terminal that we are not exploring.
These tools open up a world of possibility from the point of view of usability and new aesthetics.
The possibilities are many!
https://github.com/Textualize/textual
https://github.com/projectwallace/wallace-cli
https://github.com/maticzav/emma-cli
https://github.com/GitGud-org/GitGud
https://github.com/kraanzu/gupshup
https://github.com/aristocratos/btop
https://github.com/jarun/googler
https://github.com/helix-editor/helix
https://github.com/chubin/wttr.in
https://github.com/rastapasta/mapscii
https://betterprogramming.pub/designing-beautiful-command-line-applications-with-python-72bd2f972ea
Let's not forget about images and animations!
https://www.youtube.com/watch?v=ZjN6L_btw0Q
https://asciiart.club/
https://ascii.co.uk/animated
https://www.deviantart.com/zonedev/art/Logotypes-zoNE-ASCII-3D-Animation-GIF-913308765
DX
The aforementioned tools can greatly improve the usability of the CLI. In addition, we can apply best practices from other established CLIs that are loved by developers.
12 Factor CLI Apps
https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46
10 design principles for delightful CLIs
https://blog.developer.atlassian.com/10-design-principles-for-delightful-clis/
CLI Style Guide
https://devcenter.heroku.com/articles/cli-style-guide
Command Line UX in 2020
https://puppet.com/blog/command-line-ux-in-2020/
New DXs:
For example, what would it be like to bring herbsshelf to the CLI? Or what would a new experience for Aloe on the CLI look like?
Documentation:
The DX for documentation can be raised to the tenth power, be it the doc from the CLI, from Herbs and of course from the project itself using Herbs.
Architecture
A new CLI is the opportunity to rethink the successes and mistakes of the past.
Responsibilities:
Currently there are responsibilities in the CLI that do not necessarily need to be in the CLI. Ex: Aloe test runner, complex and specialized file generation logics, etc.
What would an architecture that could be more modularized look like?
Tests:
By modularizing the CLI, it would be an opportunity to create more specific and decoupled tests, which could run in milliseconds, without file system dependency, for example.
Conclusion
For now I'm just putting everything in my head in terms of possibilities here. I believe that CLI can have a very high impact on the project and therefore deserves our attention and affection.
As next steps, the brainstorm is open to contributors. I intend to bring some ideas based on the content I brought here as well.
The text was updated successfully, but these errors were encountered: