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.
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!
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
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.
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.
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.
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.
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
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.
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.
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.
> 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)
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.
> 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)
> 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.
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.
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.
Funny enough, not exactly this, but when i review new apps - either desktop or mobile (but especially mobile!) - besides ensuring that the desired features are present and will do the trick...i try to see if i can understand where/how the files are saved...This started years ago when i was interested in exporting stuff from proprietary apps...and now i've biased myself...so whenever i can not view/access/understand how or where files are stored for an app, then i almost immediately have a negative sentiment towards said app. Sadly, for mobile apps, the obfuscation of files and how/where they're stored is too much of a prevalent thing and for me so annoying.
This started out in my quest to be sure that i can not trapped by an app, and so i can safely export my data...but, nowadays, it has extended a little into the tinfoil hat thinking - fairly or not - where i ask myself: "why does this app not disclose where its files are stored, *what do they have to hide!?!*" ...which feels like the universe is nudging me more and more towards either text-centric methods, or the simplest, open source style apps, etc. :-)
Yes, exactly, stick to the facts! Read my comment again, I haven’t said anything about the last election.
If you check the latest polls, AfD surpassed CDU (not the union CDU/CSU!).
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!!
By the way, you are including a lot of useless files and binary files in your git repository.
(.egg folder, pycache, pyc files). They make your repo very heavy.
Take a look at this example .gitignore : https://github.com/github/gitignore/blob/main/Python.gitigno...
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.
I think this somewhat misses the point. The content is clearly there. When it fails to load javascript, instead of leaving the content there, it replaces the content with a message about requiring js
The "look-everyone-how-i-can-do-it" idea is likely part of the reason that sites like this use an "app" framework. There is nothing more technical or "cleverer" about simpler websites that do not use "app" frameworks.
The issue however is not the use of an Javascript app framework (I have no issue with their use), the issue is that people falsely pronounce Javascript to be "required" and users are shown a blank page or some other ungraceful failure when they turn JS off. Clearly, JS is not required to retrieve the information, as demonstrated above. The web developer is intentionally hostile to users retrieving the information with clients (user-agents) that do not cater to advertising.
Everyone knows how easy it is to detect whether the user has Javascript enabled or not. The question is what web developers say and do when they detect it is not enabled.
That line of thinking is why you need gigabytes of RAM just to check social media, all for a few kilobytes of text. HTML and CSS already give you all the visuals you'll ever need to display a little text.
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 think this is kind of backwards. Japanese just has a restrictive phonetic system that makes it awkward to borrow English words. It’s unlikely that if it were written differently they’d pronounce the words more like English.
English has an alphabet, but we still slaughter the pronunciation of harakiri, karaoke, and kamikaze because our phonology demands it. The one Japanese word we pronounce okay is "tsunami" which has a sound we don't have, lol!
Unlikely. English and Japanese have different phonetics. The writing system just reflects the spoken language.
Korean has this same problem. Ice cream becomes ah-ee-suh kr-ee-muh, etc. I don't know very much Japanese but I believe it's even worse for Korean in this regard.
interesting perspective, but more important reason in my opinion is that Japanese has so simple pronunciation (many vowels and fewer sounds all together), so Japanese people are not accustomed to making those difficult sounds that are in English.
None of this matters because the industry relies on docx (and it's a crusty, oldschool industry so good luck changing that).
A minimum for a novel writing tool is that one can actually send the novel out in a format where your agent and editor will read it. Otherwise you're not getting that novel published.
If we're being fair, docx (or rather, tools that write docx files) offers a lot of tooling out of the box that is useful for proofreaders, editors, and typesetters. Revision history, suggestions, and non-printing comments are all incredibly useful.
> A Song of Ice and Fire was not written with Word.
When startups haven't even started up yet but are worrying about how they can scale to billion-dollar unicorn level, a common refrain on Hacker News has been "you are not Google."
Allow me to give you the fiction writers' equivalent: you are not George R.R. Martin.
You're missing the point that people are trying to make here.
Yes, it's possible to convert Markdown to a Word file, with a variety of tools. You can use Pandoc to do this if you are the sort of person who is comfortable using tools like Pandoc. I can do that, along with all sorts of other things, because I am that sort of nerd.
However, most fiction writers and editors are not that sort of nerd. Most people don't want to use Markdown in the first place. Of the people who do want to use Markdown, not all of them are that sort of nerd, either. They want an "Export to > DOCX" command in their editor, not "save the Markdown file, open your terminal app, change to your documents directory, and type "pandoc -o my-novel.docx my-novel.md". (And that's assuming they're not doing something like, well, what NovelWriter does, saving individual chapters and perhaps even individual scenes as independent files.)
Look, I love Pandoc. It's great. But it's not a tool for everyone. If someone is trying to embrace the plain text lifestyle with a tool like NovelWriter but pointing out not being able to export to a Word file is a problem for them, asking "are you comfortable with Unix command line tools" and then telling them about Pandoc if they say yes might be a great idea -- but starting out with "obviously you hate the Unix way", maybe not so much.
> you can even convert it to WordStar....magic eh? Pandoc can do that.
> (And that's assuming they're not doing something like, well, what NovelWriter does, saving individual chapters and perhaps even individual scenes as independent files.)
This is totally unrelated to the gist of this thread, but I just wanted to point out that novelWriter's project builder outputs to a single file, which can be markdown, ODF, PDF, HTML, and others. Pandoc could then make a single DOCX file out of that.
Your point still stands that this is too complicated for the average user, but I just wanted to mention this since it might make a difference for technically minded writers considering novelWriter.
That makes sense (I figured novelWriter did that, since it looks an awful lot like an attempt at a Markdown-based answer to Scrivener and that's how Scrivener's "Compile" function works), and I suspect it won't be too difficult for novelWriter to add other file formats to its exporter. So not being able to output DOCX is probably not a long-term issue, unless the maintainers have a philosophical objection to it. :)
When you too can afford to pay your editors, proofreaders, and publishers to accommodate your unique file formats and the associated changes to their workflow, you too can write in WordStar.
Since you obvious don't know what unix philosophy is, it's a md writer..that's it, you want to convert it..take a converter like pandoc. If you really think every writing program should have it's own converters..well then you end up with less interchangeable stuff. One tool for Writing another one for conversion..is that so complicated?
Has nothing todo with programming, a real hammer is better as the backside of an axe. A Specialized Knife is better then a Swiss-Pocket Knife. One tool for one job but make that job perfect.
Ever see a framer’s axe? It’s one part axe, one part hammer. It’s perfect for framers - they love it. It’s one tool which lets them chop, modify, remove nails, hammer in nails, whatever they need to do, without having to carry 4-5 different tools.
The idea that a specialized tool is always better than a multi-tasking tool is simply not true. One must only look at the popularity and utility of leatherman multi-tools to see this to be true.
Even in programming circles, one needs only to look at how many options there are for ‘ls’ to see that “one tool for one purpose” is not always the best thing.
If you have an editor, you need two way communication -- they are going to make changes in your word document, using track changes, so you also need to be able to convert back.
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.
reply