UI is a function of your organization
blog.jim-nielsen.com
blog.jim-nielsen.com
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.
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.
More businesses should just use paper.
draft_document.pdf document.pdf final_document.pdf final_final_document.pdf document_final.pdf document_v2.pdf final_final_document_v3.pdf
Which one do I use?
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.
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.
File -> Save As "file-snapshot.doc"
(you're now editing file-snapshot.doc)
File -> Open "file.doc"
File -> Save current as copy "file-snapshot.doc"
(you continue to edit file.doc)
… 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.
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.
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.
Then again we should always ask ourselves if a drug dealer would ever recommend someone stop doing drugs.
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.
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.
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.
The thing that matters is that it is unstructured.
MediaWiki won't scale to support billions of records in a database, but for small to medium sized things imo it's perfect.
I can't find the discussion can you share the link
The world is highly cursed. The information system which accommodates this is highly blessed.
the rest is just scale.
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...
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.
Sometimes, analog is best.
After hearing the outbound version of this truism, I discovered that the inbound version is also true; ie "you buy your org chart."
Anyone selling to v large organizations, corporate or government, will know what I mean. Bloated and dysfunctional orgs with eternal sales cycles buy from bloated and dysfunctional orgs that can survive eternal sales cycles, and which are willing to sell bloated and dysfunctional products to satisfy arbitrary criteria.
This is one of many reasons why startups have a hard time selling to very large orgs.
[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin E. Conway, How Do Committees Invent?
Consider an organization that designs broom handles. They have an industrial design department that selects the shape and material, and a market research department that selects the color and packaging to fit current trends. If the market research is purely downstream from the industrial design, their feedback can never affect the tactile properties of the product, thus limiting the range of possible designs.
Replace the physical product with an abstract system, and the same design dependency issues apply.
1. For any two software systems to interact, they must use some sort of agreed API or protocol.
2. In order to have that agreed API or protocol, the teams building those two systems must communicate in some way (even if it's just one-way communation where one team documents an API and the other consumes it).
3. Therefore, the communication structures of the software system will reflect the communication structures of the organization. So the software architecture mirrors the org chart.
They have long departed from quality and functionality; Jobs has a no nonsense approach where form followed functionality. If it functioned properly, the form was intuitive. Apple UI interfaces from the Jobs years were incredible. Nowadays, under forced yearly redesign policy, we’re reversed so far things are just hidden and awkward.
Kinda funny: you force it and it sucks.
The way I see it is that Apple excels at designing and building UI patterns and systems (I don't think anyone comes close), but they're terrible when it comes to the UI of actual software products.
I'm thinking the word in that last sentence should be “excelled” (past tense).
System Preferences I could pretty intuitively find anything I was looking for. The newer System Settings is basically unusable outside of search
The UI that you're referring to is malpractice.
The new one is not much better I agree. But the old one was objectively not great in terms of UX Design.
The main problem with the new one in my opinion is that they're shoehorning a mobile experience on the Mac. Something Apple does more and more (and not just Apple, gnome does it too)
A cost effectiveness measure over a well-thought out one, methinks
Anybody would would make a critical productivity feature a hidden hover should be canned from a UX team. This choice was defended by Alan Dye.
EDIT: Oh, is this it? [0]. I can't say I ever noticed that before (when it still existed)
0: https://osxdaily.com/2014/08/20/open-files-new-app-proxy-ico...
Its under System Settings → Accessibility → Display → Show window title icons
This is the sort of integrated functionality you get when the OS, the application framework and the core applications that come with the OS are all written with each other in mind.
Heh. There was a time when you had to upgrade your OS by ... first going into iTunes. Maybe this is still the case.
I don't eat there often, but when I have, the Pizza sits in QA for about 10 minutes, then is "out for delivery for about 15, despite the fact I could literally walk to the place in 15 minutes, and they sure as heck and walking my pizza to me.
Then there's the fact that they outright lie by saying it has been delivered, then turning up about 10 minutes later.
Between the fact it's not the best pizza and this dodgy behaviour, they pretty much make sure I don't eat from there more often than about quarterly.
It's the same reason that when you buy from McDonald's, the order shows on the screen as "ready for collection" then "collected", then disappears from the screen well before the food has hit the counter at all.
The staff are incentivised to just press everything through the system asap regardless of the actual status of the food. They're presumably performance-measured against targets and aren't punished for just checking that everything went through quickly regardless of the reality.
Domino's are particularly bad (or noticeably bad) for it.
It's an important lesson about remote top down control and a failure mode of JIT systems. I've long wanted to prepare a proper blog post about this exact phenomenon using Domino's and McDonald's as examples, but I haven't put in the effort to collect the right evidence to fully understand the negative effects of IT systems misrepresenting reality.
It's a funny feeling, watching the machine at work
But in my area they now do table delivery so I tend to use that.
Ps: it's really funny to see McDonald's proudly advertising table service as if it's some cool new thing they invented :)
It will cause a real problem if, for example, operations engineers try to make optimisations based on the data.
For a toy example, you could imagine someone might analyze the wait times and determine that the burger frying is on the critical path. Kitchens could be instructed to add an additional person to frying burgers while reducing the headcount at the drinks station. ( You can probably tell I haven't worked in a McDonald's kitchen, but bare with the example. )
However there is a hidden reality given the data was complete fiction, and it could be that the drinks were in reality on the critical path, and this intervention which a computer model predicts will boost throughput will actually harm it.
Of course the reality of operations research will be a lot more nuanced and subtle than that, but the conclusion that fake data will lead to expensive incorrect interventions and suboptimal optimisers stands.
There is also reputation to consider. If McDonald's gets a reputation as somewhere people avoid because they are put off by the broken system, then they should be proactively working out why.
It may well already show up in satisfaction surveys that people are put off by "the computer system", but it may be misattributed to the ordering UX rather than the complete package that includes the broken tracking system, fundamentally broken by misaligned incentives.
>The staff are incentivised to just press everything through the system asap regardless of the actual status of the food. They're presumably performance-measured against targets and aren't punished for just checking that everything went through quickly regardless of the reality.
But at the end they are still required to deliver the food or else there will be worse consequences. It is just not realistic to expect perfection in a noisy system where you can't exactly predict how many people will come during a busy hour. Mcdonalds is trying to improve with their massive data collection operations. Things such as reading your license plates in the drive through are not only just a profit making scheme: they help predict analytics on what you may order and the goal is to improve wait times during busy hours.
As soon as the order comes in, it pops up on their screen. Is the restaurant busy? That would affect the time.
From there, the person assembles it (you can usually see this from the order counter) and then he pops it into the oven with the constantly moving rack.
This part is limited by the speed of the rack so there is a lower time bound where you cannot go under or your pizza is uncocked. Asked for well done? Well it goes back into the oven after coming out.
If you are there you eliminate the time from when the pizza comes out and it waits for the delivery driver to pick it up and deliver it. He could be out delivering something else or there could be traffic on the way to you.
You can walk in, place the order, and pay..then watch the order process begin in front of you and get the best possible pizza.
I know it's just a little thought exercise, but I see enough of that reflected in the real world to pause and consider. I would wager that in majority of cases, organizational structure does indeed remain static, at least in orgs that live on long enough timescales.
In companies that go through frequent reorgs, you'll often see a lot of "scar tissue," where you can tell that one set of services date back to a particular epoch. For example, these services are from a different time when the company tried to enter a new market, and here's a bunch of messy microservices from when the company added a bunch of developers after the Series C and the engineering processes failed to keep up. And along the way, you'll see a bunch of half-finished migrations that require both the old and new systems to be maintained simultaneously.
In your example, if that org is adapted to frequently shifting team boundaries with some central top-down architectural authority (CTO, architect, committee, whatever), then Conway's law would predict exactly the kind of modular architecture with a "shared design approach" that you describe.
It is correlation vs causality question. Conway law may actually be the former rather than the latter.
Among the reasons I refer to myself, tongue in cheek, as a software anthropologist, is what I'd recognised from that software: it bears the marks of the major platforms it evolved through: IBM mainframes, VMS, Unix, MS Windows, and ultimately an Apple Macintosh variant (though principally the tool now seems to be PC-oriented).
Similarly, on Unix, one can often identify applications' origins based on their toolkits and widgets: Athena Xaw widgets, Motif, VUE, KDE, GNOME, etc. Though often criticised for the lack of consistency, I'm aware that different tools reveal their affordances by the toolkits (and GUI presentation and behaviour) they reveal. Similarly BSD vs. GNU command-line tools, and various other command origins. Particularly notably, the 'dd' command, which comes from, and borrows syntax from, IBM TCL, a mainframe environment.
Digging deeper, Unix's origins in Multics, the B programming language, etc., are also apparent.
Again, this is somewhat confounding tools and teams, though I'd suggest that the principles are similar and related. The upshot is that past decisions get layered into software, with the oldest layers typically closest to the core.
Casey Muratori has some great examples in his video on the subject: https://www.youtube.com/watch?v=5IUj1EZwpJY
tl;dr:
Stevesi (Technical Assistant to BillG): Mgmt forced Exchange to use NT Directory (followed by glowing description of the NT directory)
DonH (Exchange Directory dev lead/ later Active Directory dev lead): No, NT was late, and eventually canceled NT Directory. Exchange wrote and shipped our own Directory and then moved the code to NT to use as the base for Active Directory.
Stevesi prevaricating about high-level executive view of the interaction of NT vs Exchange directory.
DonH: No, that's wrong. NT provided nothing. Exchange created an email-specific directory. I used that to make Active Directory. Water flowed uphill not downhill.
from https://hardcoresoftware.learningbyshipping.com/p/021-expand...:
"That proved to be a defining moment because deploying a directory was hugely complex and there was no way EMS could do it twice. In one of the rare times an architectural choice was pushed to a team, using the directory from NT became a requirement for EMS. Many others supported this, including the Server leadership. It was to them as natural as pushing Excel to use Windows—the directory was that core to NT Server—while sharing files and printers was the baseline scenario, it was the directory that brought deep enterprise value to customers. For the better part of the following year or more, EMS would not speak well of using the NT Directory, and conversely the NT team felt that EMS was trying to use the Directory in ways it was not designed to be used. This sounded to me a lot like getting Excel to work on Windows, and it played out exactly that way. Had EMS not used NT Directory, it is likely Directory never would have achieved critical mass as the defining app for the client-server era (and remained the cloud anchor for today’s Office 365). And conversely, had the NT team not met the needs of EMS, then the NT Directory would have likely been sidelined by the rising importance of the email directory in EMS. Forcing this issue, while it might be an exception, only proved the strength of a strategic bet when it is made and executed. Still, it was painful."
Comment from DonH Apr 22, 2021, at end of blog entry:
"Speaking as the dev lead for the Exchange Directory (1991-1996) and later on Active Directory (1996-2005), there's a lot wrong with this chapter. NT's approach to functional directory services in the early 90's was "wait for Cairo. they're building one", which meant that we in Exchange had to build our own directory service. When Cairo collapsed (late 1995) Exchange and NT struck a deal so that once Exchange 4.0 shipped (April 1996) one of my developers and I brought a copy of the Exchange Directory source code over to Windows, and we built Active Directory out of that. Exchange in no way "bet on" the NT Directory; we essentially built the replacement for it in order to get the features we needed. Ask me if you need details.
However, the part about endless repeated pressure to build everything (specifically including the directory) on top of SQL is entirely accurate.
I'm only moderately annoyed that I had to pay ten bucks to post this correction."
Second comment from DonH:
"You're missing the point that there was no NT Directory. The strategy given to us was "use the NT directory, which is the Cairo directory. Sorry that doesn't exist yet, so Exchange might need to cobble something together for its first release." I built that something, and later went on to use it to fill the directory service shaped hole in Windows.
Presenting this as Exchange leveraging the NT Directory might be polite, but it is definitely not accurate.
And although I remain eternally grateful to LDAP for saving me from COM I completely agree about omitting it from the history."
The article is centered around the pizza tracker, but I thought that tracker was fake.
Just for illustrative purposes.
Is it not?
https://www.the-sun.com/money/6927297/dominos-pizza-tracker-...
I've always thought the tracker was real, at least here in Spain (it looks different than the US one in the article pictures), as it always seems to have changed at different intervals. Could also be just randomized a bit I guess. Long time ago I ordered from Domino anyways.
Yikes, I wouldn't put that info online. What's the point?
This could be super useful when considering the next place of employment for example; the organizational dysfunctions and idiosyncrasies only become apparent once you've jumped in with both feet.
Microsoft also seems to have generational UI revamps. There's a funny bathtub curve where Win32 has outlived many of its replacements.
Might be a UI/Organization mismatch, as described in this article.
Or maybe it's the staff intentionally marking things done early, to game metrics expectations from management.
I can show you anything in a UI - only good orgs can develop valuable products from those UIs.
I don't know, it seem to me the 90s had a very dystopian view of future Pizza Hut.
« The Deliverator stands tall, your pie in thirty minutes or you can have it free, shoot the driver, take his car, file a class-action suit. The Deliverator has been working this job for six months, a rich and lengthy tenure by his standards, and has never delivered a pizza in more than twenty-one minutes. [..] Pizza delivery is a major industry. A managed industry. People went to CosaNostra Pizza University four years just to learn it. Came in its doors unable to write an English sentence, from Abkhazia, Rwanda, Guanajuato, South Jersey, and came out knowing more about pizza than a Bedouin knows about sand. And they had studied this problem. Graphed the frequency of doorway delivery-time disputes. Wired the early Deliverators to record, then analyze, the debating tactics, the voice-stress histograms, the distinctive grammatical structures employed by white middle-class Type A Burbclave occupants who against all logic had decided that this was the place to take their personal Custerian stand against all that was stale and deadening in their lives: they were going to lie, or delude themselves, about the time of their phone call and get themselves a free pizza; no, they deserved a free pizza along with their life, liberty, and pursuit of whatever, it was fucking inalienable. »
The post makes this point explicitly. It doesn’t sound like you read the whole thing.
and the fact that the same tropes are recapitulated over and over again without any reference to prior art. Alan Kay is correct; computing is a pop culture.
Then don't lie. Instead of the status, just say outright that it takes up to 5 minutes for the pizza to get in the oven. And show a timer.