21–30 of 62 posts
This is interesting, very similar to a project I am working on, which is a cli asset manager for a small repair shop. Basically, mine keeps track of service tickets, customers and inventory while being query-able to help identify trends in problem products or recall records for warranty disputes, etc. It's just a silly little project I started in my spare time because I got fed up with having to open up three pieces…
The text-based software that would eat work management is one that embraces the incumbents rather than avoid them. I want a bidirectional SaaS YAML/JSON adapter. So that I can push and pull our CRM (and other SaaS utilities like project management) into a common (schematized) YAML format. The YAML then can be analyzed and modified using LLMs and/or stored in git. And then use the bidirectional sync to reconcile confl…
Getting people to use the terminal to do things instead of the bloatware produced by Google/Microsoft tools is almost impossible... I live in the terminal, but most people in my company, including developers rather stay away from it
To state the obvious (sorry): (1) Command lines lack the discoverability element of GUIs (and TUIs), where the available choices are typically laid out in front of you. Just look at the command "firm -c list contact" in the screenshot in the linked readme - no doubt it's sensible, but you wouldn't just type it in out of nowhere. You could argue that good docs fix this, but they'll never be a substitute. (Silly analog…
1. It tends to be bloated, with developers slapping framework upon framework, creating a mess of background wiring that is prone to a dictionary's worth of issues that will either frustrate the user or confound the person maintaining it.
2. UX Designers approach their jobs incorrectly; they assume they are smarter than the user. Interestingly, this might actually be true on paper in most cases, but the practical reality is that the user needs to do things the user's way, not the way the the developer wants them to.
If we could find ways to smooth those two glaring issues, I posit that we'd see a lot of problems with productivity and workflow melt away. Caveat; I'm not a software developer, so I'm sure anyone who is thinks I'm speaking out of school right now. Fact is, I've worked in a few different industries over 40 years, and one of the biggest thorns always seems to boil down to the software not being quite right for the team/application, so workarounds have to be invented, adding layers of complexity on what is already a decidedly fragile system.
Thinking about an LLM use case, not needing a query language should remove translation risk I'd assume?
Earlier quoted context omitted.
Yes I agree. My guess is that the console is a much better and natural UI because it goes in one direction and is less confusing and productive for humans. In the end we seems to move back to it through the chatbot paradigm, because it is in the end a console...
It's an interesting trend. With the push for chatbot-based interactions, CLIs and plain text representations are making a bit of a comeback, since LLMs interface with those more easily than UIs.
So I'd wager we will see the same with chatbot interfaces. I furthermore predict that we will get taylor-made AI applications with a GUI that triggers specific "prompts" on unspecified datasets. "Prompt engineering" will become just another skill of professionals that have to use general purpose tools to built specific purpose tools... again.
Getting people to use the terminal to do things instead of the bloatware produced by Google/Microsoft tools is almost impossible... I live in the terminal, but most people in my company, including developers rather stay away from it