Hacker News Reader

Comment by crispyambulance | Hacker News Reader

It looks like quite a normal UI from an "internal" government or enterprise application point of view.

In this case, the citizens of Hawaii paid for the bad system design with 48 minutes of existential horror.

But these kinds of mistakes happens ALL THE TIME with "enterprise applications." Oracle has similar horrendous UX for their EBS (Enterprise Business Suite), so does SAP, Siemens, etc. People regularly make costly mistakes in shipping and receiving, purchasing and manufacturing because they have to deal with shitty confusing applications that look just like that screenshot.

Totally not surprising that the internal application for public emergencies has the same awfulness as PTO request.

I expect the same employee in Hawaii fumbled the UI on their "time off request" for psychiatric counseling too.

View on HN

> People regularly make costly mistakes in shipping and receiving, purchasing and manufacturing because they have to deal with shitty confusing applications that look just like that screenshot.

Currently unscrewing one of those as my day job.

"Delete all production orders for period" - no confirmation, no ability to rollback (beyond me restoring from a backup) that kind of thing.

It's not that it isn't user friendly, it's that it is actively user hostile.

> "Delete all production orders for period"

Hah! I built one of those once! The (very abbreviated) conversation went something like this:

"I need a way to bulk delete orders."

"Umm... Are you sure? I can't think of a good reason to delete a bunch of orders in production."

"Yes. We absolutely need this."

"Ok..."

A short time later

"Why does it ask me to confirm? Just make it do it."

"Sure..."

A week later, after restoring from backup

"Remove the bulk delete function. I don't know why we even have that!"

Really demanding managers refuse to explain their XY problems... This one never did learn.

My boss is both understanding and willing to listen, after working with him for 6mths I really can't blame the system on him.

The out sourced developers however...very much yes I can.

Half the things do the wrong thing wrong, the other half is the wrong thing sorta working.

There was clearly no attempt to understand what the user wanted or any attempt to ask the simple questions like "Why do you want X, is X related to Y, would it be handy to pull in related Y for display X" beyond the terrible code quality (and database architecture, I wish I was kidding when I say it took 49 to 69s to search for a quote (I timed it on repeated runs), it now takes ~400-600ms and I still think that's too slow (and I search more things) there is just a complete lack of any thought/effort or consistency.

Even the tables aren't consistent across the system - sometimes click a row opens the related entity (with no indication that's what it does), sometimes there is a "view" button in the row on the right, sometimes on the left.

It's just pile after pile of UX disasters/architecture code disasters, no wonder the original lead dev came close to a nervous breakdown, I just don't think he was capable of dealing with a system of this complexity.

> There was clearly no attempt to understand what the user wanted or any attempt to ask the simple questions like "Why do you want X, is X related to Y, would it be handy to pull in related Y for display X"

Asking those questions is being obstructionist. Most end users don't understand the ramifications of what they are requesting. Explaining it all is an effort to bring them up to a level of education that would allow them to do your job. They pay _you_ to do your job and now you are just wasting everybody's time. Why do you have to make everything so complicated!? Why can't you just do what your told? Just add the button and stop asking questions!

It's so painful running into brick wall after brick wall of asking "Why do you want X and have you thought of the implications for Y, Z, and A-W?!", only to be met with sighs and eye rolls that we should just know and get it done. Blah. Bad day for me, I guess? I apologize.

A way to ask these questions that sometimes works better, is something like "can you explain the business value added by doing this, so that I can be sure my implementation achieves that?"

Asking "why X, why Y, why Z" can come off as challenging their knowledge, and questions like "would you also need W?" tend to get answered "yes, sounds good" so now you've just made more work for yourself.

> "can you explain the business value added by doing this, so that I can be sure my implementation achieves that?"

100% this - "Have you considered that our long lead times on inventory means we increase our holding costs?" is a good lead-in to exploring how to reduce that.

Borderline thread necro here but...

> "Have you considered that our long lead times on inventory means we increase our holding costs?"

What's frustrating about this is now we also have to understand the business overall, and that's kind of the problem in the first place: nobody has the patience to explain it.

So in addition to coming up to speed on whatever tech stack they have, we're going to have to find someone who understands and is capable of explaining the (sometimes completely foreign to us) business side of things and come up to speed on that too. That's a lot of ramp up time, especially when nobody wants to hand out raises and you're better off finding a new gig roughly every other year anyway.

I'm currently working somewhere with people that are great at explaining the business, and are willing to discuss at length the intricacies of how anything works at any time. The tech stack is abysmal, but being able to easily understand the business makes it worth dealing with the dumpster fire of a LoB app. I'd take it over the previous job, where we had greenfield project, bleeding edge tech, and money, but nobody could tell me how the hell the business worked...

I didn't wait for anyone to explain it to me, I went to the library and checked out a bunch of books they had on Supply Chain Management/Operations Management and Inventory Control and then read them.

That gave me enough of a grasp of the principles and more importantly the nomenclature that I could then talk to people in their language not mine.

To me it's a normalised series of tables to them it's WIP inventory.

One of the things DDD got right (if you remove the buzzword bingo/hype) was the idea of a 'common language'.

Unfortunately in my experience (couple of decades) most business people don't want a common language, they want you to understand theirs.

It is surprising how little theoretical knowledge people who work in a field use on a day to day basis.

> One of the things DDD got right (if you remove the buzzword bingo/hype) was the idea of a 'common language'.

> Unfortunately in my experience (couple of decades) most business people don't want a common language, they want you to understand theirs.

The “common language” of DDD was the language of the business domain, so that’s in line with DDD.

The practical problem is that the language of many business domains is often highly context dependent, making it unsuitable for direct use where ambiguity must be avoided even without context, and trying to namespace things to map to the specific relevant business contexts is often impractical.

Yep which comes back to 'no silver bullets'.

I've found it's easier to understand their domain and map it back to mine than it is to try to build a shared domain.

Also I find business stuff interesting, it's just a nice change of pace from fighting with code.

"Sure! Can you put that in an e-mail?"

Really underrated advice. If someone asks you for something you know is wrong make sure they get full credit.

I don't use email on my iphone. It's because I receive 400+ emails a day, mostly spam. I need a "delete all" button, as deleting them one at a time is untenable.

But there isn't a "delete all" button, presumably because people would use it and complain that they wiped out all their email.

The end result, however, is the iphone email is completely unusable for me.

Why can't you use an email filter?

I don't know. The interface could be better, but a different interface wouldn't necessarily stop someone who's confused from sending the wrong alert. How many times do you see a dialog box and click "yes" without even reading it? I do it all the time, and it's usually fine... except sometimes I think "wait, what did I just agree to!?" Someone under pressure to get that drill going can easily make the same mistakes, no matter what hoops you make them jump through. Someone who thinks they read the text but didn't comprehend it can easily click through just about anything.

In the end, the correct process is probably have two people activate the alert, so that two people have to independently not read the dialog boxes or whatever to send a false alarm. But maybe that doesn't work either, I haven't done any research to that effect and don't really know.

On some level, I like the interface. There is a list of possible alerts, and you click the one you want to send to send it. It's just that it doesn't account for the possibility that the user doesn't ACTUALLY want to send the one they clicked. The same problem exists with any powerful tool. Hammers don't check that you're hammering a nail and not your thumb. Cars don't ask "there appears to be a pedestrian, are you sure you meant 'accelerate' and not 'brake'?" With great power comes great responsibility.

    > a different interface wouldn't necessarily stop someone who's confused from sending the wrong alert.

No. Just. No. It is a horrific design. This one will likely end up in a future UX textbook as a case study. There is simply no excuse for jumbling together a list of options like that. The list items are not even semantically coherent.

Ultimately, however, the individual, his chain-of-command and the system designers have to be held accountable. The scary thing is that many people saw this and said nothing, almost certainly some people heard complaints about this and did nothing, somebody even signed off on this. It demonstrates an organizational problem, I think.

> How many times do you see a dialog box and click "yes" without even reading it?

A simple fix would be to use a tried and true method that's been effective for decades. Have different popups that read

Type "REAL WORLD" to send this alert.

and

Type "DRILL" to send this alert.

This would be good. Takes 15 min to code this in and you dont have to go redesign a bunch of stuff like some on here are suggesting. Obviously they dont care what it looks like. Fine. But safeguard for such a monumental action they should have had.

I've interacted with systems like that before. My brain looks for the quotes, I double-click to select the text, Control-c, Control-v, and it's done... completely on autopilot.

Trust me, if you get in your users way they will find some way to get rid of you.

this would probably be a bad design aswell. because if a real missle treat happens I would need to get out the warning as fast as possible. the best way would've been a second page with a big button and huge warnings.

You were modded down, but I agree. Contrary to popular opinion, "duck and cover" is not just psychological pacification. It will save lives if worst comes to worst. Literally every millisecond counts when issuing a warning of this nature.

So, yes, bring up a huge flashing red warning dialog with a single confirmation step. And make it easy to issue a retraction.

For everyone saying that people are so used to clicking yes on dialog boxes without reading them: Then change that paradigm for different levels of importance. For example, for a test alert, use an automatic countdown that will activate the alert unless canceled within N seconds. The ramifications of a test alert going out accidentally are a lot lower than a real alert going out accidentally. For more serious alerts like this most recent ballistic missile one, turn the entire screen red, have “THIS IS NOT A TEST” header, with an explicit acceptance required to send the alert. Two people may mitigate this existing problem but it still doesn’t get to the root of the issue.

Same thing with your hammer analogy. Everything shouldn’t look like a nail then! A real alert should look like a nail. A real ballistic missile alert should look like a railroad spike (aka really big nail). Test alerts should look like a screw. Etc.

I can think of two obvious mitigations that would have helped a lot.

1. Separate items intended to be tests from items intended to be live warnings. Draw a green (or yellow) box around the test items and a red box around the live items.

2. Require a confirmation before sending out a live item, and not just clicking a button. Put up a big red flashing warning that says, "You are about to send out a live warning, are you absolutely sure you want to do this?" and require the operator to type "YES".

Taking 1 a little farther, maybe have the first page be links to the test page or the emergency page then add some warnings to the top of the emergency page that make it damn clear that clicking any of the links, even accidentally, will send an actual emergency alert. Make everything red and scary. Hell, make it blink if you have to.

You don't even need confirmation boxes to make this better. Put the "test" options in a section all by itself, clearly labeled as test functionality. Put the real-world scary options in another section, labeled clearly, and perhaps colored red, or badged in such a way (red alert icon, or something) to indicate it's a real-world, serious action.

> With great power comes great responsibility.

Yes, and designers here have a lot of power and responsibility to design an interface that is difficult to use in the wrong way, and doesn't treat options with wildly different real-world consequences as equivalent.

> The interface could be better, but a different interface wouldn't necessarily stop someone who's confused from sending the wrong alert. How many times do you see a dialog box and click "yes" without even reading it?

How many times to I test the SMS delivery system? Not very often, so I am going to be more careful with any popups. Maybe you only use your computer once a month?

>It looks like quite a normal UI from an "internal" government or enterprise application point of view.

The "normal" for enterprise and especially government software is dogshit though.

It's because the people doing the procurement are not the people actually using the thing day to day. They treat UX and design as extravagances in the face of spec-sheets and slick marketing decks.

Or, more charitably, they're trying to balance a bunch of conflicting demands for requirements, budget, deadlines, etc.; the procurement process scares away the non-enterprise vendors; and they're not given enough budget to have in-house staff with enough expertise to meaningfully oversee it. If a big vendor says they'll handle it all and mount a huge PR push if anyone questions your decision, it's not hard to see why people opt to overpay.

Enterprise software is chosen by a manager who is told the feature list, but never uses the software. Usability is never considered because the manager never uses the software, and it's not really possible to evaluate usability on paper (they may say "this is really usable" and an application can still be really bad; if they say "it has feature X" and doesn't then you can sue them for breach of contract).

Consumer software is chosen by people that actually use the software. They can see that it is shit, give it bad reviews etc.

I used to work at a very large company who use Teamcity (think git for CAD), which was the worst POS I have ever used. A 90s Java mess that was so slow you could watch it redrawing GUI controls in slow motion. Everybody that used it hated it. At least some of the higher ups liked it, but they didn't actually have to use it.

Teamcity is the best CI that's available, far ahead of Jenkins.

The issue with these tools is the company that is too shit to run them. Put the smallest box they could salvage that's already running a hundred apps. Put the storage on a NAS in another datacenter because there was no more local disk space.

Sorry I meant Teamcentre. Teamcity is great!

I think this is the key here. Why do we keep trusting the one person who never uses the actual product to decide which product everyone should use?

I wish we could have a sane conversation about how UI's should be customizeable for the end user

>I wish we could have a sane conversation about how UI's should be customizeable for the end user

Depends a lot on context and the type of application, but a lot of end users get confused about where the line is between UI/UX and backend functionality.

A lot of things that might seem to be UI issues might actually have implications for things like resource consumption and application stability. It's a tough balance to strike.

Oh yeah, Im not saying it's easy, just that it leads to better workflows and efficiencies for end-users.

> But these kinds of mistakes happens ALL THE TIME with "enterprise applications."

Such misteackes in the cockpit of an airliner are deadly, which is why a great deal of effort is expended to prevent such mistakes. Unfortunately,

1. bad UI design is usually only obvious in hindsight

2. doing good UI design is expensive, and not always worth the effort

Of course, I face the same sorts of issues in designing a programming language (D), so this topic is of continuing interest for me.

> bad UI design is usually only obvious in hindsight

That's only true if you have little or no experience designing or even using interfaces. As someone who has been bitten by bad UI design in the past, I've noticed and called out a decent amount of bad design well before it actually has caused a problem.

> That's only true if you have little or no experience designing or even using interfaces.

I'm afraid the history of cockpit design in airplanes decisively shows otherwise.

I think we can agree that some elements of bad UI are obvious, and others are subtle.

Based on the photos of the screen shown in the article, this one's dead obvious.

> I expect the same employee in Hawaii fumbled the UI on their "time off request" for psychiatric counseling too.

That requires a paper form. The payroll system in the state has failed to be upgraded for some 20 years or so of promises. Staff are paid via checks which are sent direct to their banks because they can't even pay over the wire.

Here's a good article about it: http://khon2.com/2015/05/11/costly-consequences-of-outdated-...

Somewhat controversially, I wonder if that existential horror was really so bad. I can think of worse ways to spend 48 minutes that contemplating the reality of your mortality, the fact that you could very well be dead at any moment with no warning whatsoever. It makes you re-evaluate your priorities, maybe makes you stop putting off the life changes you were thinking about that seemed like they could wait until next year.

These 48 minutes may well have changed a whole bunch of people's lives for the better, in the long term.

Perhaps a bit of context might make it seem less like I’m being unempathetic. TL;DR: I was caught in the London tube bombings in 2005 and I believe it changed my life for the better.

http://swombat.com/2011/12/19/bomb-changed-my-life

I think that for anyone who has kids, those minutes could very well have been unimaginably awful.

I guess you can think of it like waterboarding. Waterboarding doesn't harm anyone, it forces one to contemplate mortality, but it is also something so terrible that one would not wish on anybody.

Or it will get them killed, once there is a real alarm and they sit down to meditate instead of seeking shelter ...

This is an un-empathetic thing to say, because you're ignoring the real emotional experiences of the people who lived through this. The terror experienced by people, especially but not limited to those with predisposition to anxiety, hypertension, panic attacks or suicidal thoughts, will have a real impact on their lives.

Or imagine someone who, convinced of an impending death, donates all of their saved wealth to charities online.

I haven't seen this comment yet, although I expected it. It is time for those who design internal government applications to take it as seriously as other engineers who work on systems that, when mistakes are made, result in people being hurt or killed. This system clearly has that potential, so people need to take it as seriously as someone designing interfaces for NASA or the military, along with serious consequences of shoddy work.

Reply on news.ycombinator.com