kadrian12

This is cool. Yet it reminds me of a recent insight, after hours of conversation with Home Assistant geeks:

Software is not their issue. Display hardware is (but they'd never admit that).

They've usually got all their data in their Home Assistant, tracked by often > 400 individual devices & sensors, visualized in several dashboards. But rarely does anyone actually put that data into their physical spaces, because there's no obvious choice for small-sized screens, long-lasting batteries, cheap, customizable. Something like Trmnl comes close, but is too expensive for most.

So their data stays in the Home Assistant app, mostly accessible through their & their partner's phones and maybe tablets.

If someone manages to build & sell cheap, easily customizable e-ink displays in various sizes, that would enable so much more creativity with custom dashboarding. Imagine every small concern gets their own screen AND their own physical place.

Am I missing some obvious, great solutions to this?

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.

My professor once said: the only thing that we'll still have in 80 years is the file system. Always bet on the file system.

Not true. CDU/CSU was the strongest party in the last election. Stick to the facts, please.

Wow nice, that works, thank you!! This will be so useful, I can't wait to try this for a real case soon

Wow, this is really great! I've got this case very often when I need non-technical people to send me data in a JSON format, but trying to teach them what JSON is and how to edit it is impossible / takes way too much time.

This is SO close to the solution I need. If I could configure this form using typescript and then send them a link where they can't see or edit the typescript, but just fill out the form and send me the JSON, that would be incredible!!

Nice. Would be cool to have shortcuts numbers next to the links to navigate to linked articles.

Really? Of course you can always do things in a cleverer, more technical, less visual, better performing, "look-everyone-how-i-can-do-it" kind of way.

But I really don't get the point of your comment. It's 2022. If some people publish work that visualizes information for all of us, I'm glad they have Javascript helping them do it.

Katakana, to me, is such a trouble. I really wonder whether I'm the only one who believes that Katakana is a big part of the reason, why it's very hard for native Japanese speakers to learn English.

In a Japan of today, you grow up with a plentitude of words taken from English and written + pronounced in Katakana. So you learn to pronounce "san-do-i-chi" for sandwich, "de-za-i-na" for "designer", "su-ma-ho" for smartphone, "ca-re-n-da" for calendar. And since you use and pronounce them wrongly on a daily basis you reinforce the Japanesified pronunciations. Then, actually pronouncing "calendar" in an English way becomes tricky.

So to me, the alphabets are a great example of a "historically grown" system, that's ripe for a "refactoring".

I applaud the author for keeping everything text file based.

In general, I think we should strive for non-proprietary, standard file formats.

Isn't docx far too one-sided and controlled in that regard? I wonder if anyone has some info on the "state of affairs" for the "document format race".