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 conflicts and push.
So I can do work processes on the console, and still collaborate with people who want the native web UI.
Thinking of Terraform, you have data blocks that can grab data from an external source. Still trying to grok what would be a convenient way of doing something like this - whether that gets generated to DSL, or if data pulled in dynamically as you build the org graph...
Having your plain-text workspace as a unified structural source where you pull in data from external systems would be potentially powerful.
Looking at the points you made and examples, I would cobble a similar tool with Django, writing only CLI commands with no HTTP endpoints. And most LLMs are already fluent in Django.
- Schemas and relationships live in models.py, actual data is persisted in Sqlite
- I can dump to JSON or XML with Django utils for LLMs
- Query engine can simplify reuse Django syntax, like `Firm.objects.get(owner_name__like="john", date__gt=2015)`, fetch related names, aggregate subqueries
- Format as tables
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 of software with clunky UIs and frequent crashes to accomplish what should be fairly simple and straight-forward tracking and analysis. My biggest hurdle was getting it to export to a nice looking PDF that could be emailed or printed later.
While mine is functional, yours looks A LOT more refined, so I think I will play around with it and see if I can't adapt it to my needs.
I try to work in the terminal as much as I can since that's where I'm most comfortable, but when it comes to business software like CRMs, HRMs or ERPs, especially geared toward smaller shops, the selection for terminal-based options is severely lacking.
(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 analogy: imagine if your toaster had buttons just labelled "1", "2", "3" and you had to refer to the manual for which meant toast, defrost, extra browning.)
(2) Command lines lack the visual persistence of the data you're operating on (like a list of files in a directory, or project/people data like in this program). If you rename a file and you then re-run ls and now everything appears in a slightly different place on the screen (because the previous listing had shifted up when you ran "mv") it's visually jarring in a way that just operating directly on the data isn't. Not-silly analogy: it's like how no-one today would dream of operating on a text file using a pure line editor like ed. (Even command-based editors like vim persist the file data in the main visual area.)
Command lines are much better than GUIs/TUIs for some applications, for example when called from a script, or where you might need to compose a complex command and then tweak and re-run it (in fairness, that might apply to OP's project). But I think techies sometimes get a bit carried away. GUIs are sometimes a legitimately better choice.
I don't disagree with you at all, but my biggest hangup with GUI-based software is twofold:
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.
Many people forget the main reason why Windows, Mobile, Webapps succeeded is because of convenience. The more easy to use the more better. Convenience is also the reason why Meta Glasses will be successful.
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.
We saw this in the early days of chat tools like Slack, too. /remind anybody? Today you, at least, get a floating help text if not a mini-GUI within the channel once you begin to invoke.
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.
I think that's fair. I'm personally happy with a text editor + CLI, but can acknowledge that is not enough for broader adoption.
The project is structured as libraries such that you could build an editor separately, but it's not something that has taken priority for me (as the only user, so far).
Healthy skepticism. I think firm differs from ops as code in the sense that it focuses on the structural aspects and representing the people-ops side in a way that machines can interact with too.
To be clear, I'm trialing this out in my own small business. Whether it's ergonomic enough to add value and whether it's scalable, I don't know yet. So far, so good, though.
The age of LLMs is shifting the predominant modality of data towards plaintext. For people like us, it's easier to grok, and it allows all of the poweruser use cases. I think this is a great idea.
I love the idea. More power to text-based tools, more power to the CLI.
But ... why invent a new file format?
Why not just make in JSON, so it is easier to integrate in other toolchains (e.g. having a python script add customers based on external APIs without having to write your own output generator)?
I’ve tried JSON, YAML, and TOML for storing data. Last time, I ended up with an 8,000-line JSON file. And I had to write an editor for it, because text-based editing caused more syntax errors than I expected (what a surprise :).
But each of formats seemed nice at first.
So I understand that sometimes it’s easier to invent a new format. But compatibility with other formats can definitely be a problem lately.
My question is: how does the proposed system handle multiple editors working on the same text file?
I'm curious to see if the advent of LLM assistants will result in a resurgence of "headless" systems
CLI is cool but this won't work in real life, focus your energy building something else.
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 conflicts and push.
So I can do work processes on the console, and still collaborate with people who want the native web UI.
Agreed, this is on my mind as well.
Thinking of Terraform, you have data blocks that can grab data from an external source. Still trying to grok what would be a convenient way of doing something like this - whether that gets generated to DSL, or if data pulled in dynamically as you build the org graph...
Having your plain-text workspace as a unified structural source where you pull in data from external systems would be potentially powerful.
I would like the native web UI when I am being too lazy, and terminal when I am in the zone..
Looking at the points you made and examples, I would cobble a similar tool with Django, writing only CLI commands with no HTTP endpoints. And most LLMs are already fluent in Django.
- Schemas and relationships live in models.py, actual data is persisted in Sqlite - I can dump to JSON or XML with Django utils for LLMs - Query engine can simplify reuse Django syntax, like `Firm.objects.get(owner_name__like="john", date__gt=2015)`, fetch related names, aggregate subqueries - Format as tables
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 of software with clunky UIs and frequent crashes to accomplish what should be fairly simple and straight-forward tracking and analysis. My biggest hurdle was getting it to export to a nice looking PDF that could be emailed or printed later.
While mine is functional, yours looks A LOT more refined, so I think I will play around with it and see if I can't adapt it to my needs.
I try to work in the terminal as much as I can since that's where I'm most comfortable, but when it comes to business software like CRMs, HRMs or ERPs, especially geared toward smaller shops, the selection for terminal-based options is severely lacking.
Can you share the github link to your cli asset manager project?
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 analogy: imagine if your toaster had buttons just labelled "1", "2", "3" and you had to refer to the manual for which meant toast, defrost, extra browning.)
(2) Command lines lack the visual persistence of the data you're operating on (like a list of files in a directory, or project/people data like in this program). If you rename a file and you then re-run ls and now everything appears in a slightly different place on the screen (because the previous listing had shifted up when you ran "mv") it's visually jarring in a way that just operating directly on the data isn't. Not-silly analogy: it's like how no-one today would dream of operating on a text file using a pure line editor like ed. (Even command-based editors like vim persist the file data in the main visual area.)
Command lines are much better than GUIs/TUIs for some applications, for example when called from a script, or where you might need to compose a complex command and then tweak and re-run it (in fairness, that might apply to OP's project). But I think techies sometimes get a bit carried away. GUIs are sometimes a legitimately better choice.
I don't disagree with you at all, but my biggest hangup with GUI-based software is twofold:
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.
Many people forget the main reason why Windows, Mobile, Webapps succeeded is because of convenience. The more easy to use the more better. Convenience is also the reason why Meta Glasses will be successful.
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.
We saw this in the early days of chat tools like Slack, too. /remind anybody? Today you, at least, get a floating help text if not a mini-GUI within the channel once you begin to invoke.
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.
Spent ages building my own work management system only to realise I was just taking the scenic route to eMacs.
I was thinking the same thing: why is everyone reinventing emacs?
gnu and emacs already have a long history of cli and text friendly solutions that LLM dev agents can easily use and are trained on.
Or for structured data, just use a database. Dev agents can work with SQL just fine.
The simplicity of text files is appealing - did you consider using a database at all or was it pure text from the start?
Thinking about an LLM use case, not needing a query language should remove translation risk I'd assume?
I’d be interested in defining my business using a DSL but then ultimately I’d want that to be translated into a UI.
I’d love to simply map all the relationships between stock, assets, tools like invoicing, APIs all in a place like this.
But I have to agree I think CLI alone would result in it being usable by only me.
EDIT: just wanted to add I’m interested in where this project goes.
I think that's fair. I'm personally happy with a text editor + CLI, but can acknowledge that is not enough for broader adoption.
The project is structured as libraries such that you could build an editor separately, but it's not something that has taken priority for me (as the only user, so far).
Makes me think of recutils
https://www.gnu.org/software/recutils/
Looks ambitious but previous attempts at “Ops as Code” haven’t been promising.
Healthy skepticism. I think firm differs from ops as code in the sense that it focuses on the structural aspects and representing the people-ops side in a way that machines can interact with too.
To be clear, I'm trialing this out in my own small business. Whether it's ergonomic enough to add value and whether it's scalable, I don't know yet. So far, so good, though.
It's good to experiment, and your boldness should be commended.
Ehm, SAP ERP?
The age of LLMs is shifting the predominant modality of data towards plaintext. For people like us, it's easier to grok, and it allows all of the poweruser use cases. I think this is a great idea.
I love the idea. More power to text-based tools, more power to the CLI.
But ... why invent a new file format? Why not just make in JSON, so it is easier to integrate in other toolchains (e.g. having a python script add customers based on external APIs without having to write your own output generator)?
I’ve tried JSON, YAML, and TOML for storing data. Last time, I ended up with an 8,000-line JSON file. And I had to write an editor for it, because text-based editing caused more syntax errors than I expected (what a surprise :).
But each of formats seemed nice at first.
So I understand that sometimes it’s easier to invent a new format. But compatibility with other formats can definitely be a problem lately.
My question is: how does the proposed system handle multiple editors working on the same text file?