Olaf's New Menu Item
blog.plover.com
blog.plover.com
Someone had build this a operational report that listed people to contact—hundreds of them. Users would copy-paste the person ID and search for their phone number in another internal database. Then they would type that number. One of them had this hack where they typed it into a software phone that made the bulky physical phone attached ring. All that felt suboptimal to me.
That other database had standard URL structure so I knew that I could turn the id into a link by appending `https:\\admin.company.com\users?id=` That way, they could click and be in the right page without searching. But the reporting system had relevant personal information, so I could instead add a SQL JOIN and include the phone number right there. So I did, and I was showered with praises.
That’s when I thought: why not also have a link? There is this rarely used protocol `tel:`, the phone equivalent of `html:`. It never really made sense, until your phone turned into a computer… I had seen work a while ago. Lo-and-behold! It worked!
So I turned two painstainking ten-digit copying and look-ups into a single-click. I think that hack doubled that team’s productivity.
But the idea has gone way overboard. Everything that could be a phone number, address, or calendar date is now automatically made into a link in many web pages, apps, and instant messengers, such that you have to be very precise with your mouse or finger to be able to copy-paste without accidentally clicking the link. And in some apps they've made it literally impossible to copy-paste the data that they've turned into a link. You have to resort to using developer tools or copy the data by hand.
There needs to be some general UI convention that allows you the option to copy-paste as plain text. There are lots of situations where I don't want a link but just the data.
Modern software is so hard to learn -- though browsers are old.
Some years ago, my team created a web-based portal for a local ad agency. Long-running actions that triggered ajax calls would display this hideous, too large, black spinning wheel. Probably there was a bug that caused the spinning wheel to sometimes remain on the screen until you refreshed.
At one point a user contacted us and asked how long the "black sun" as she called it was supposed to be there? We shrugged our shoulders and thought, "maybe a few seconds?". She said she had been working in the app, navigating and clicking right under the spinning wheel, for two whole days before contacting us!
Also, consider what the default scenario might be for someone at a job like Olaf: How likely is he to be able to affect change when some part of a process is inefficient? When I was at my first job, the general mood was that one should keep their head down and just do as instructed, since going above and beyond was not encouraged.
But seriously, how hard should I be expected to think when something seems medically 'off'? My left wrist has been a little 'off' for a few weeks, but WebMD says it shouldn't be carpal tunnel. Instead of seeing a doctor, I'll just google some more and see what I can do myself.
[0] Where applicable
The other side of this is that doctors in america lean heavy towards interventionism. If you go see a doctor, they will do something. Useful or not.
An american doctor will never, for example, say “Hey maybe your chair is too low compared to your desk and you’re putting too much pressure on your wrist” or suggest a series of stretching exercises to do 3x/day for a few weeks until the discomfort goes away. The best you can expect from a doctor is “eh it’s not bad enough for surgery yet, come back in a few years. Take advil or something idk”
I remember going in for a persistent cough. After 5 minutes the doctor decided “this is post nasal drip” (my nose drains into my throat instead of making me sniffly) and prescribed some medicine to take. And I’m like … yo this problem isn’t bad enough to need fixing, I just wanted to know what’s up. Too much intervention can easily make things worse.
When you have an acute problem that’s when american healthcare shines. Chronic and minor stuff, not so much.
A (good) chiropractor will do the first, and a physical therapist will do the second.
You're right about regular MDs though.
Not my experience. I've had doctors that recommended I do stretch exercises for a certain condition I had.
The few times I've been to a doctor in America (I'm not from USA) I got excellent care. They explained the whole thing, told me about options I could take etc. I was very satisfied with the doctors.
Yes it's more expensive than it should be, but that's a different matter.
(Not affiliated with this movement and I don't even use it, just think it's a great idea.)
To be blunt, most users have been not been conditioned to expect anyone to listen to them. The software comes down from on high with a dictum that says "this is the way things work". Even if there is a way to provide feedback in the app, which often there isn't, it tends to goes straight into the void.
Users need to feel empowered to request changes by being involved in the development process. There are also often larger organizational issues that prevent users from feeling they have a say in how their workplace operates.
If I had to hunt down "support" somewhere under "about" in the menu or if I was presented with a very generic form, I'd be that user because I'd dread the braindead support conversations I have learned to expect (Seriously, just today a hoster told me to send them a screenshot of the HTTP 504 response their customer UI receives for a javascript request to their ticketing system.... to support@....)
Let me tell you, it has helped sometimes. It also regularly gets duped to threads with a few hundred complaints and product people saying it's intentional behavior.
I think this is also the kind of magic that happens when a business is operating well and it's employees have empathy for each other.
If Engineering and Product are well aligned it should be a matter of habit to be looking for and executing on regular projects like Olaf's new menu item or the auto fill of a new account form mentioned here.
As engineers and engineering management we can make sure there is room in our schedules for these kinds of small projects.
And if we develop well our relationships with our product managers we can make those conversations like the one about the form auto filler easier to happen: "this is three hours of work tomorrow that will save this team 10s of hours each week until we get the new system built, it's worth an afternoon one sprint for a developer".
But also what I think is best displayed in this report is empathy :). Organizations that show empathy for their users are ones that tend to be the best to work for because they actually care about people who are using their products and the people who are making their products. And in general, over time, I think empathy builds better customer and employment relationships which then builds better businesses.
All in all it was a fun little system to work on, and I enjoyed it a lot. What made it worth doing, even though it was a giant corporation's call center, was that my (shared) office was right next to the actual team actually working with the tool. I smoked cigarettes at the time, so it was not uncommon for me to take little smoke breaks with the actual users. At first they were hesitant to try and push "work questions" on me during my break, but I assured them that it was fine.
They'd bring up those tiny little things that never get fixed in systems like this. NDA prevents me from going into any kind of detail, but it was little stuff like Olaf's New Menu Item. Working that closely with the Actual Users was very liberating, and I think it alleviated a lot of their frustrations to have developer access, too.
That said, this team was maybe 50 people. When this "preemptive logistics issue team" model was rolled out world-wide, I had already left the organization for entirely unrelated reasons, and I don't think I would have given all those people direct access to me on my breaks like that.
It works well, at certain scales, though!
This is only true in a narrow time context. If you broaden the context, then you can see where it falls down. The missing element is that people who can solve high-ROI problems are not willing to be cut off from work like this. If you don't let good people help their co-workers, then they'll leave and find a more hospitable environment. When that high-ROI problem comes along, that really would pay off quickly, then there won't be anybody like Olaf around to tackle it.
Think about a non-technical example. You probably have insurance of some kind, on your house, car, or life. In a narrow perspective, this just costs you money. A tree doesn't fall on your house, nobody rear ends your car, and you don't get hit by lightening. But in the long term, one of these sorts of things is bound to happen. The care and feeding of talented engineers who "lean in" is like an insurance policy for when a high-ROI opportunity presents itself.
You might believe that, but I don't think you know for sure, and I doubt you could prove it. I would not know what evidence of that claim would look like, or how to evaluate it.
What I would like, though, is to unask the question completely. Maybe Olaf's menu item saved the company money in the long term, or maybe it cost the company money in the long term. Why is that so important? Why should that be the primary consideration (or only consideration) when we judge whether the project was worth doing?
I would like a framework for evaluating these sorts of choices starting from a different place.
Something that has been on my mind a long time is the idea of persuading local merchants to pay someone to pick up trash on their street. In the USA, the argument would look like this: "If you chip in a small amount of money to pay for street sweeping, that cost will be more than offset by the revenues stemming from increased foot traffic to your business.”
This to me seems deeply insane. Everything is measured in dollars. To Americans, not living in a pile of filth has no intrinsic value apart from increased business returns. The argument “even if the cost isn't offset by increased revenues, at least you won't have to walk through piles of trash every day” does not carry any weight.
I would like to live in a world where Olaf's menu item was sufficiently justified by its obvious benefit to Olaf, and the presumption was that it was worth doing on that basis alone.
I know it's fun to shit on Americans, but this is simply not true. You yourself begin the idea with "the idea of persuading local merchants to pay someone to pick up trash on their street". You have chosen to frame it economically, so it should come as no surprise that anyone you talk to about it evaluates it on economic grounds.
It's like asking someone if they want a 500 calorie cake and then complaining that no one focuses on the taste.
We live in a society heavily dominated by corporations and where many people struggle to afford a dignified, stable life. I don't think people want to be in a hustle mindset all the time, but if you're forced to live in the desert, you're going to spend a lot of time thinking about water whether you like it or not.
I have tried for years to find a rule to balance these types of projects. But in the end, I have just come to believe that both are essential, and that alternating between high-level and low-level somewhat randomly is the only solution.
This type of situation can be multiplied a millionfold across organisations and businesses, and I honestly don't know what the general solution is. Creators of software can't anticipate every need, and similarly you can't exactly publish a data model and give users a SQL prompt and expect that to end well. The best we can do is shrink the gap between developers and users so that the very low-hanging obvious fruit is implemented at least.
This is one of the reasons why software development is so expensive. You really have to find those small little "business processes" and translate them into clear rules a computer can work with and keep a usable user interface. Without domain knowledge this is really hard.
This also is why the world runs in Excel. Somebody smart in the business unit starts with collecting all info in Excel and slowly builds more and more complex macros into it whenever they have a need. The larger the distance between the business and development the harder it is to capture all those small edges.
People don’t want to expose a schema and API, especially for programs like that, because at that instant all their decisions become frozen and turn into technical debt. Any change to the schema would break all the unknown little hacks written by customers.
I don’t think there’s a good long term fix
In this case we were using a couple of third party GUI components, and importantly we were using them precisely as we should, and they interacted with other user customization code we had written in an unexpected but totally appropriate way.
Manual things can create mistakes.
This particular number from Olaf might not be critical if it is off by a few countsother workflows are.
For the first one, I work in servicenow all day and it has an “insert and stay” menu option for basically any record, something I use incredibly often, so to whoever added that feature, I love you!
Maybe his product people were unreliable and unsympathetic to the users - he suggests so in the first anecdote. Maybe all product people are, I dunno. But I have been on projects where engineers were allowed (usually de facto rather than by policy) to unilaterally add features they thought were important. The results are not always as positive as they are in this article.
Much more likely, I'd guess, is that either nobody was responsible or the person ostensibly responsible had other things to focus on. The way these systems are usually supported is no official resourcing, but rather "grab Mark's time when he's in the office."
This speaks to my soul. I have never read such a clear description of how I choose what to work on.
I recently went on a "copy to clipboard" campaign, adding all sorts of places to click and copy information to the clipboard. Nobody asked for it but I've gotten lots of love from folks where it has saved them a ton of time / hassle.
Meanwhile I've got high priority requests to remove a thing that "they don't need" and I know the moment I remove it ... I'll get a request to add it back.
This is why I love running a side project. It’s great to be able to talk to users and find out what they actually want. There’s no need to track their every move or measure clicks, just ask them directly.
> It was not doing its job, and to pick up the slack, Olaf, a sentient being, was having to pretend to be a machine.