Sometimes, UIs are designed with unrealistic expectations and mismatches of how processes work in reality. This is maybe lost on today’s “native digital” generation, but anyone who worked at organizations a while back should understand this intuitively.
Back then, processes inside companies where paper-driven, a variation of “produce some kind of document, pass it along to another department, get a stamped copy/receipt to prove it’s been done”. I always use this example when designing architectures and UIs: if you couldn’t design the same process as paper being passed around, the design is missing something. You need to really grok the company structure and the domain to design something sensible.
Yes! And, the killer feature of paper that no digital UI has yet to fully capture is the margin.
If your business process doesn't have a form field for some data, but the person on the ground understands that it's valuable, it's naturally scribbled onto the margins, and then worked into the next version of the form.
If you're using nearly any digital UI, the feedback loop (if it exists at all) is a side channel.
> And, the killer feature of paper that no digital UI has yet to fully capture is the margin.
This is THE reason why, in the year of our LORD 2024, physicians still HATE electronic medical records. Margins, sticky notes, and red ink you can circle anywhere you d~~n well please, not organized data easily parsed during discovery.
With the recent discussion on here about using a massive single text file as a scheduling and planning tool and todo list, and some developers who still carry around a paper notebook to capture notes and ideas, you would think this desire by users of our applications would be better understood.
If only hospital systems didn’t force their physicians to use structured data. Administration loves structured data because it is an easy road to hoodwinking a jury into saying it’s professional negligence on part of a physician or plain bad luck on the patient’s part. It makes it easy for the losers who love to point out “see, it’s all right there in the medical record.”
You can support a structured way to add unstructured data. This can be useful a s a stopgap to understand where the structured data is inadequate, but I can become a hindrance if they don't use the structured data all.
This is precisely what MediaWiki tries to do, and it's why I love this software more than anything. You have templates and forms that the user can fill out, but the page is really a piece of paper - outside of the template you can write anything you want at all. With Cargo or Semantic MediaWiki you can even make a database out of the structured parts, and any record always includes the page from which that piece of data originated, so you can link to it to see the full context.
MediaWiki won't scale to support billions of records in a database, but for small to medium sized things imo it's perfect.
… or rather, digital processes shouldn’t throw away the benefits of paper.
E.g.: document databases instead of fixed-schema tabular (paper can accept more data than was anticipated), append-only databases instead of update-in-place (paper doesn’t forget). I’m a big fan of Datomic and similar databases because of that.
Problem is when businesses people want statistics and insights. Unstructured data allows not filling in some data but then data might be required to make analysis.
Agent taking free form notes might skip parts that are required for other means than job at hand and agent will optimize for work he thinks is important, some general statistics don’t bother him.
Problem is that user on the ground sometimes has to be forced into a scheme of bigger picture of processes.
On the other hand too much data is also being marked as required by business - where ad hoc note would do.
I see this with our customers where they ask us to implement bunch of fields as “must be filled in” just to start complaining that it takes too long to fill all required in - I did not make all of it mandatory on my own it was their business analysis.
And then people demanding free text fields be removed from various forms/b2b/market systems on the basis that they are rarely used… those easily contain all of the most valuable information in the system.
The world is highly cursed. The information system which accommodates this is highly blessed.
Discoverability. I can't count the number of times I've had to ask phone support people to please read the notes that the last agent took. If you have a paper form, someone marking in the margins is immediately apparent.
Hypermedia didn't go far enough, in the sense that it overlooks how people form relationships with specific documents. In case of margin notes, individuals take an instance of a document template and mark it up to customize it. They recognized that the shape of the form was not the only shape the document could take and they knew that the form was an extension of their authority. So if it didn't make sense they changed it.
You can't really reproduce that experience with hypertext because there's no concept of "this document doesn't apply to this situation let me, the individual user, change it to communicate something unique." And because humans aren't reviewing any of these documents, there's nobody there to interpret it correctly even if you could. Essentially the Internet and web form design and replacement of humans with machines has involved a great abdication of authority from the front-line employees who process these forms. I would argue that it's becoming the downfall of our modern society. If a programmer or analyst couldn't envision your situation, nobody works at the company who can do anything about it.
Working for a company that has mixed paper/electronic documentation. I can’t overstate how useful it is to highlight, circle, and/or cross-out sections of a form. Also to see /what/ was crossed out to know the history of the document.
You might say, “well we can add these formatting features and make the form elements removable and…”. But if you know you know. Asking “normal people” to do all this in markup is an insta-fail. Most of us are caterers, not programmers.
AI can handle the mixed form... Perhaps now with LLMs we can just scan all the stuff with crossed out words and cicled conditions and have the ai make it searchable.
Then again we should always ask ourselves if a drug dealer would ever recommend someone stop doing drugs.
LLMs certainly can cope with disordered notes scribbled into the metaphorical margins, and OCR can usually turn literal scribbles in literal margins into something approximating what was written, buuuuuuuuut the AI we currently have is just good enough to be dangerous if you tried using it this way.
On the other hand, the last 15 months have been "if you don't like the state of the art AI, wait a week", so I may be out of date with that assessment.
I think this is in big part because we got save functionality wrong. The interaction you typically need is to save a snapshot into a different file, and continue to work on the current one. That is, the operation:
File -> Save As "file-snapshot.doc"
(you're now editing file-snapshot.doc)
File -> Open "file.doc"
Should've been a single operation:
File -> Save current as copy "file-snapshot.doc"
(you continue to edit file.doc)
The software could even prepend the current date/time to the snapshot name by default, or something. Then, the simplest way of working would always keep "file.doc" as the most recent version, removing the need for the "_v2_final_really_final_final_final" suffixes.
This is why naively surfacing file systems to users is such a mistake. My gut feeling says that documents should always contain all of their revisions — with a time slider, and marginalia always enabled. However, organization of the documents seems like a critical issue. I can tell you, from my wife's/kiddos desktops, that organization means "one big pile". I strongly suspect that "one big pile" is the right answer, no matter how much it pains my programmer's heart.
Some people organize their entire lives into boxes and containers and labelled drawers. Some people have, basically, a big pile that they just shuffle through when they need something.
For example, I prefer a backpack that's one or two large compartments. Yet they sell backpacks with dozens of little slots. That's too much for me, but somebody thought people wanted it, so somebody must. Over organization doesn't work for me.
The old Word document format (*.doc) could, by accident, contain older versions of the document, as a side effect of how editing operations worked on the internal data structures (not purging all deleted content right away, to optimize editing speed, or something along those lines). This made for some embarrassing cases when third parties received documents with hidden content they weren’t supposed to know about.
And we all know of the numerous cases where text was blacked out in PDFs by adding black rectangles on top of it, but the text was still contained in the document.
The reason one big pile is the answer, at least for me, is that to do otherwise would be to bog myself down in minutiae of taxonomy. Being hierarchical worked when I was still in school (and somewhat works for work), but one large bucket with the ability to search by content—think iPhoto letting you search for text in photos—is how I run things now.
I often think about my partner's pregnancy journey, when she was pregnant she was given a folder which had all sorts of forms in. For every appointment she went to, she'd bring the folder in and the staff would read the existing pages, and add their own (results of scans etc...)
Due to some minor complications, her book ended up being quite full, and we went to lots of places, some hospitals, some GPs (which are private companies), and they could all read and add to this book.
In the UK, you can rock up to any hospital with maternity facilities when you're in labour, and have your baby there. You bring your folder with you, and they can read the notes from previous doctors. Once the baby is born, you hand the notes in, and they are collated together and put on your NHS record.
I often think about making a digital version of that. How difficult it'd be to build something that worked across all the systems that different healthcare providers use, is reliable, and secure.
> Back then, processes inside companies where paper-driven
Even today, the analogy I give for explaining APIs and integration sometimes involves tax-filing paperwork. The API for this system is that box 2 contains your full name, but the API for that system is a form where your last name in box 5A and your first name is in box 5B...
Back then, processes inside companies where paper-driven, a variation of “produce some kind of document, pass it along to another department, get a stamped copy/receipt to prove it’s been done”. I always use this example when designing architectures and UIs: if you couldn’t design the same process as paper being passed around, the design is missing something. You need to really grok the company structure and the domain to design something sensible.