[kadrian12]

This is quite cool. Makes me philosophical: isn't it odd, that this is like an Excel template? Like a "domain model" template? In this case, presented nicely in a TUI that makes basic CRUD workflows work.

Most SaaS companies are just that: 1) Curated domain model (stored in their cloud db) 2) Some way for users do to almost raw CRUD on the tables 3) Curated high-level domain specific workflows that do n CRUD calls underneath

So many of these SaaS apps could have been a simple Excel / domain model template like Micasa.

But it seems like we haven't "cracked" the perfect UI on top of relational DBs.

Excel: Good: raw CRUD. Bad: too many degrees of freedom + the possibility to edit the domain model itself. That's too much for most users.

TUI: Good: raw CRUD with some guardrails, limited possibility to adjust the domain model / not by accident. Keyboard shortcuts, for professionals. Bad: inaccessible for non-tech end users + hard to build good UX for high-level domain specific workflows.

Full Web UI: Good: accessible for all. Great for high-level domain-specific workflows. Bad: looks and works different every time. Raw CRUD possible, but always a compromise with editable data grid libraries.

[apsurd]

I've always stubbornly bemoaned how everyone seems to love to work in spreadsheets. Undeniably the world's power-tool.

I've never liked them, never learned to work with them, and instead spent 20 years learning to program and make my own db-backed crud interfaces.

Your points are spot on. But I'd like to defend a sliver of my stubbornness about it all; a product built for a specific use or domain exports the _education_ and information architecture of that domain. Sure it's all rows and columns in a db, and a spreadsheet is just that exposed to the user, but a "product" and its creator/company gets to design and prescribe a learning experience. And I think that's the magic and the value. That's what I'm holding onto!

[iguana_shine]

There was once a time when tools like Microsoft Access and FileMaker Pro were common. These were a database and custom GUI designed using a drag and drop editor. I don't know whether these apps ever had network server capability or if they were always offline or why they died out. It was a bit before my time

[tjohns]

FileMarker Pro had a dedicated server product (FileMaker Server) that you could use for multi-user access. Claris still sells it: https://www.claris.com/filemaker/

Microsoft Access was strictly file based. You could drop the .mdb/.accdb file on a SMB share and it would support basic concurrency via lock files. However, you could also swap out the internal database engine (Jet) with anything else via ODBC, so your Access database could connect to a remote Microsoft SQL Server instance - or even MySQL/Postgres.

Back in high school, I even wired up an Access database to give a graphical frontend to an accounting app running on an IBM AS/400 mainframe. ODBC made it easy, and Access itself didn't really care where the data lived.

[wpm]

I know a dude who runs his business off of FileMaker and even does work for his customers building them FileMaker stuff. He loves it.

I should probably give it a shot.

[moduspol]

How many names do you think they ruled out before they settled on "Filemaker"?

[CobrastanJorji]

I wonder what the state of workflow engines is these days. Back in the (distant, distant) past, everything seemed to use Lotus Notes. Today, there are oodles of workflow engines of all shapes and sizes, but asides from domain-specific stuff like Salesforce, I hardly hear anyone mention them.

[j45]

I helped a legacy Lotus Notes application reincarnate once, and it was impressive how reasonably solid it's ability was to be offline-first, and mobile first, and how fewer sychronization/replication errors there were than I expected.

[CobrastanJorji]

Lotus Notes was doing decentralized apps built with NoSQL databases before either of those things were cool. Mostly because "going online" was potentially quite an undertaking at the time.

[j45]

Agreed - Lotus Notes def is an example of a working NoSQL database that scales in relating data as well where other noSQL databases only dream of.

Being offline-first has it's advantages too.

[shakna]

Salesforce is used well beyond its domain, unfortunately. A lot of BAs love the drag 'n drop design features.

[harikb]

I’ve lived the Microsoft Access times. The downfall of those tools was the refusal to keep the interface simple. They kept layering on features and UI cruft until they became massive apps pretending to be databases

[designerarvid]

Yes, this is a spreadsheet-like model with crud. Most software is.

Users don't care whether a product is "just crud" or not. The value comes from what the spreadsheet-like model looks like, and how it and its associated crud operators map onto the real world, helping a real human being to get things done. It's never about "the technology".

Many developers dislike this fact about the world because they are more interested in technology than solving people's problems.

Developing that well-working model and ux takes time and effort. Without an associated business model you cannot spend thousands of man hours to do that. Hence software tend to be for-profit saas, and not open source TUI apps.

Many developers dislike this fact about the world because they wish they could work on technology and not have to care about economic reality.

[virgil_disgr4ce]

> Full Web UI: Good: accessible for all. Great for high-level domain-specific workflows. Bad: looks and works different every time. Raw CRUD possible, but always a compromise with editable data grid libraries.

I'm not a Notion booster, and I know there are many other solutions with similar tools/features.

But I'd argue that Notion databases are a very good balance of all of these things. It can be raw CRUD if you want it to be, but it's easy to create custom views that accomplish often exactly what you need.

Not exactly sure what you mean by "looks and works different every time" w.r.t. web apps.

In my experience this is a good example of where the UX details matter significantly. Yes, Airtable exists. But a Notion database row being its own first-class "Page" is a *massive* deal for me. (Again: I'm aware Notion is not the only thing)

[apsurd]

> Not exactly sure what you mean by "looks and works different every time" w.r.t. web apps.

Not the parent but I take it to mean _across_ web-apps from various services the UI looks and works differently, vs every spreadsheet is a spreadsheet and works like a spreadsheet.

[sgt]

Web UI's for power tools are generally not a good idea. A browser will always have limitations and not quite reach the level of e.g. a TUI. On the other hand, TUI's as you point out has some serious limitations on its own.

So the answer is native app - I think what the world need is a super fast native spreadsheet that is NOT Excel. Kinda like a combination of Excel, TUI, and MS Access in one. Fast like Numbers.app, not sluggish like Excel is.

I'd use that. But it needs to have a keyboard centric operation, and be faster and a very solid, near industrial design, no "the latest flavor of someone's Figma design". I'm having a tough time explaining this.

What do you guys think?

[misiek08]

Good to see (although I was more than sure there are) people thinking about this same thing.

I’m using Google Sheets for house and cars. Columns that should be easily grouped are using data validation and yes - few times deep into the experiment (because I’m sometimes lazy and miss some data - so experiment is good name) I’ve changed domain a little by adding columns. It meant empty values for existing rows - that I couldn’t fill in most cases, because a lot of time passed.

Reading many comments here I think we will create multiple frameworks/standards like always and some tools will be missing things others have :(

Funny thing is sheets works good and with scripts I can (still for free in terms of money) send notifications to selected channels or do some automated actions (like check disks status or order something automatically)

Edit: sheets have sync across devices too. Single SQLite for this specific case, having less nerdy people at home is an disadvantage.

[pjc50]

> A browser will always have limitations and not quite reach the level of e.g. a TUI

There's no reason you can't jam a TUI into a browser. Perhaps to the surprise of both kinds of user, but it's possible.

> I think what the world need is a super fast native spreadsheet that is NOT Excel.

> I'd use that. But it needs to have a keyboard centric operation

You should boot up an emulator and check out the OG: Lotus 1-2-3. Keyboard driven, extremely fast, all written in 16-bit assembler for the original IBM PC running at, what, 4MHz?

It's because of Lotus 1-2-3's use of F2 for "edit cell" that F2 is still "edit" or "rename" in most applications.

(you can then continue the tour with WordPerfect and Borland Turbo Pascal, if you like light blue)

[donatj]

Back at a job I had in ~2008 we built a library to convert an Excel spreadsheet into a fully functional web based configurator. I've talked about it here previously[1].

I have always thought that it was a missed opportunity that we'd never reused it nor turned it into any sort of SaaS. It seems to me like such an obvious and easy way to let your clients define their own business logic without having to maintain it yourself.

1. https://news.ycombinator.com/item?id=20793043

[StopDisinfo910]

Considering Cognite made a fortune in the oil and gas industry by basically allowing companies to toss them all their data, them automatically linking and contextualizing everything using a tunable knowledge graph and then giving access this domain model, I think you are onto something. A bit late to the party but yes, this party exists and LLM are useful there for once.

Amusingly most of this data then end up back into Excel or PowerBi but the unbundling and contextualizing itself is worth the price.

Semantic mapping was the answer all along. It just failed on the open web. The idea never died in the industrial world.

[astatine]

dBase was the gold standard for this back in the 80s, early 90s. Great tool. Both the "dev" part and how it could be made available to non developers. The freedom of spreadsheets when developing and the constraints of a TUI (or just UI in those days) for users.

[sabas_ge]

Our ERP is dBase+SQL server with Harbour executables, until I don't move all the database to SQL server it will be like that

[sgt]

Maybe we need a new dBase.