Hacker News Reader

Comment by Sean1708 | Hacker News Reader

> but he still drastically oversimplifies the space of GUI use-cases and ignores some of the key benefits of mouse-based interaction.

I think you've still missed the point. He's not saying that keyboards should be used most of the time, he's saying that keyboards are better for structured interfaces while mice are better for unstructured interfaces and a lot of what we consider to be unstructured interfaces are actually structured (e.g. twitter).

While I don't think he's 100% correct, I do think he raises a lot of interesting points if you can look past his rather unhelpful delivery.

View on HN

> While I don't think he's 100% correct, I do think he raises a lot of interesting points

One of the things I got from this was that maybe we should do more to design structured interfaces instead of counting the number of clicks needed to transition to the page you're looking for.

Many enterprise applications (especially web based ones) are horrible to navigate, and some people spend most of their working days in them. It's terrible.

Nothing makes me feel stupider than SAP Concur. I miss our old SAP "native GUI" travel reporting.

Really? I hated S/3 with a passion. Nothing that describes itself and totally bad laid out applications.

I also thought I disliked it. Then we switched to Concur.

Concur is an impressive example of how you can make a really simple thing really, really painful.

It has to be complicated so they can justify the expense. If it were as simple as it needed to be, even execs would wonder where the money is being spent; and they don't even use the app!

I was once waiting in a doctor's office about ~4-5 years ago, and sitting close to me was an older lady, perhaps around 60.

A commercial came on the TV in the waiting room for SAP, and this lady started cursing about what a piece of trash it was. I was really shocked. She was not someone I expected to even know what SAP was, but I guess she was an unfortunate user stuck with having to use it in an office somewhere.

'enterprise users are too dumb to use the keyboard' is what i heard a lot and it's blatantly untrue.

'look at what the iphone does with just one button' is a useless thing to say in an enterprise app.

etc.

it just shows that enterprise app developers don't use the software they make.

Neither do the buyers. No one cares about the ergonomics of enterprise applications, because the users are forced to use it.

100% agree. I manage two teams of developers - one builds the infrastructure for a back-office (power user) interface - the other builds the infrastructure for an end-user (casual user) interface. While both are web apps, the usage patterns are VERY different.

The power users know all the special shortcuts. Keyboard mappings, tab order, and also app-specific shortcuts (forcing look-ups to behave certain ways, quick key combos to access forms, etc). They value speed of data entry above almost everything.

The casual users know none of these things, don't care, won't remember them if we try to teach them, and place a much higher value on easy navigation and discovery via visual cues and mouse.

I've yet to see a graphical enterprise app that approaches 1/10 of the interface speed of a mainframe terminal app.

All app developers should be required to sit and watch an expert user interact with a mainframe interface for at least 30 minutes before they're allowed to make arch decisions.

Lots of business programs of the sort where people spend much of their day in them should probably look and act more or less like "bad" old DOS keyboard-focused business programs. Instant responses to input, shortcut-driven. You watch someone use one of those who's been at it for even a few weeks, man, they're fast.

A very good touchscreen interface would probably be as good or better for cases in which typing isn't required, except that most touchscreen interfaces are terrible (janky, frequent missed presses, laggy enough that it's often unclear whether a press has been missed or it's just being slow, confusing navigation—see those new McDonalds ordering kiosks for all of the above) so that doesn't seem to be a realistic option unless you put some kind of UX dictator with great taste in charge of the project.

Years ago I had occasion to visit my mother at work. In her department most of the worker's time was spent in a custom Windows app that was developed specifically for them... as in exclusively for that department of that company.

The app was modal and took up the entire screen. Except is was clear that the developers had larger displays than the workers because in order to view and use the entire page the workers had to scroll around both X and Y using the scroll bars. Well, that and the fact that tabbing around didn't go around in a logical order.

I walked out and returned with a slightly LCD display that I bought in a local big box store and nearly started a riot. They had all been using that crappy app for years like that and the worst pain point for it was due to the fact that the devs had assumed that everyone in the company had the same size displays while their employer had refused to buy those larger displays for the 45 people that had to use it.

Different budgets probably - I've seen people kicking up an almighty fuss on a ~£40 million pound project about buying ~200 large monitors for one screen in the application (the application screen really did need to be huge due to various constraints).

One of our meetings probably cost ten times the cost of 200 monitors!

Those are some huge (or long) meetings.

Back of the envelope:

$400 * 200 = $80000 for the monitors.

You need to have $80000 / ($100000/12/21/8) = 1600 person/hour of meeting time to equal the cost. 100 people can meet for two days!

I feel like something is off with that calculation, but I cannot find it...

It was a big project - so easily 30-40 people at meetings (usually in multiple concurrent sessions). People flying in from all over the world and staying in decent hotels...

I remember seeing the bill for breakfast for one set of meetings - was nearly $5000.

Yeah - I was off with the "ten times"... but not by a huge amount ;-)

Ah, yeah, you can rapidly run up the cost if you fly to your meetings. I was thinking about an all-in-one-office situation. Good point, thanks :)

The Danish government had a program developer in the 90' for the job centers (the job centers are suppose to help unemployed people return to the job marked, they're just very good at it). Somewhere in the specs. the was a limit on how long the loading time for a window could be.

To get around this load time restriction the developer simply put less information and features into window. So rather than spending 10 seconds loading one large form and fill it out, users would have to click though X number of windows, filling out part of the form in window.

I'm not sure where I'm going with this, but your comment reminded me of this case.

>a lot of what we consider to be unstructured interfaces are actually structured

But only IF you know the structure otherwise it's effectively unstructured. The issue with structured interfaces is that the barrier to entry is high and the discoverability of how to do things is low. That works if you are able to force people to use it but fails when you depend on people organically wanting to join.

Also, they are very fragile in a move-fast-break-things world. If you are going to be structured, and have people depend on your structure, then you have to commit to it and support that structure. Sometimes for far, far longer than you ever expected.

Reply on news.ycombinator.com