Hacker News Reader

Comment by brudgers | Hacker News Reader

GUI's embody micromanagement as a virtue. GUI's in general should be a last resort. Computers are supposed to do our work automatically. Barring that, by delegation. Making rounded corners and gradients is easier than making something useful. that's why it gets so much attention.

NoGUI.

View on HN

While I agree with your point that computers should do the most they can to take the work out of things for the user, the flight search example used in the article is exactly the sort of thing that at some point you're likely to need to input. It's a plan that the user has that they want to action. While you could use voice recognition or call a person to do the same, some people are probably going to want to type it into a flight search or calendar app or similar, so the GUI for that is necessary.

"Making rounded corners and gradients is easier than making something useful. that's why it gets so much attention"

It's not about it being easier, it's about making it obvious that the user can use it. Following established design conventions for buttons by gradating backgrounds or rounding borders, however right or wrong they may be, can help a user to know the intention behind something without needing to think about it.

Look at the last frame, "Title Your Guide". The website/app doesn't provide it's own keyboard wudgut. Why the fuck does it have 3 wudguts to enter a date?

NoGUI.

This would be the perfect use case for SIRI (or alternatives), but we're still a little far from that.

"I want to fly from X to Y in the first week of september"

I don't think it's a matter of last resort, rather correct use.

GUIs are inevitable.

You basically should only ask from the user what a computer can't possibly know, for example what date you want to travel for your holidays and how many units of that product do you want.

I firmly believe that in a short time computers will predict all of those little things really well. Let's see.

What things? One seems highly unlikely, the other might be impossible.

In on would have to be able to read complex human thought, in the other we would basically would have to predict the future.

My phone already suggests where I might want to go for dinner tonight. It's getting pretty good at it. Holiday suggestions don't seem that far beyond our capabilities.

Yes, but you are free to disregard the suggestion and do something else, so UI still has to be built for that case.

There will always be cases when the computer predicts wrong and the user will need a way to edit/correct the result.

That seems orthogonal to NoGUI.

  "What day do you want to travel?"
   >

NoGUI.

I get the simplicity, but I really disagree that visual aspects of a website/program are not "something useful".

I would bet that a well designed and clean GUI would be easier to use for a large percent of the population than text alone..

Why can I use a cookie rather than a GUI to log into HackerNews? Why can I use Oauth to log into StackOverflow? Would it be better if we all had to use a keyboard wudgut?

The idea that GUI's are great was good forty years ago when men worried about catching typing-pool-koodies from keyboards; college students would hire typists to turn longhand drafts into print on a page; and the only form of search was query and that query happened over a circuit based network on a mainframe running a non-relational database. Now we've all got a Cray in our pocket yet the industry is breeding faster horses.

You suggest that we use CLIs for pretty much every task?

I -happily- spend most of my day in one CLI or another, but there are many, many things for which interactive graphical display of information is just the best choice.

If you never have done so, find a copy of Edward Tufte's "The Visual Display of Quantitative Information". You really need to find a professionally-printed dead-tree version; computer screens still can't do the book justice.

Oh:

> "koodies"

That word is spelt "cooties". ;)

I bought my copy of Tufte almost 25 years ago (11th printing 1991). I see the $34.00 price sticker is still on the rear of the dust jacket and living within is the Graphics Press advertising collateral. Tufte is a good starting point, remove what is unnecessary. One "7/19/15" is a better user experience than three wudguts with 12-31 items each.

["Koodies" alliterates better with "keyboard" more Carrollingean like "wudguts".]

7/19/15 is immediately and irredeemably ugly to me, because I'm not in the U.S. Quick, someone from Europe types in 9/10/15, do they want to travel in September or October?

Yep. ISO 8601 exists for a reason. :)

This isn't an overnight batch process on a paper tape: It's the 21st century not 1962. Return both sets of results and let The user choose. Search is better than query.

If your solution to ambiguity of date input on a flight search website is to return flight options for either date, you will have a shocking number of customers inadvertently booking flights for the wrong dates, because they're already overwhelmed with a long list of options (airlines, times of day, prices, connecting points, etc.) If you added the randomizing variable of multiple entirely different dates being in play, all bets would be off.

If GUI's were not inherently ambiguous, the article would not have been written and we could all use hamburgers or ribbons or live tiles or material design and call it a day. But GUI's are and users have to deal with arbitary assumptions that are orthogonal to the business context.

If finding flights is a case of search, then we can look at Google. It uses text to maximize expressiveness. It uses progressive refinement rather than precise query to produce better results, e.g. maps results based on partial addresses. Google is understands that search has intrinsic ambiguity and that natural language is the best tool we have for dealing with it...and the hieroglyphs are not.

User: I want to travel the last week of august.

So, your program needs to calculate what date that is, or the user is will need to look at an external calendar (Windows GUI) to determine which date that is.

So, your program needs to calculate what date that is

Yes it does, Qnd that is harder for the programmer and easier for the user. Calendar wudguts suck for:

   > last week of august next year.

Twenty years ago parsing user input and calculating a date was resource constrained and ambiguity was expensive because the query was hitting Sabre on some mainframe. Today we've got gigahertz and gigabytes in our pockets and we're wired up at megabit speeds to caches and CDN's and search tools with autocompletion (Windows Intellisense)

And yet we still have to manually query every combination of departure and return dates to find reasonable airfare.

That's less a fault of our interface devices, and more that the airlines are not in the business of giving us the cheaper fares. ;) I'm sure they'd be happiest to suggest fares that were cheaper than competitors, yet 3x the price of a different day's fare for the same trip.

Not on Adioso, which is why I use them. You can choose a city (with multiple airports) for the departure location and something like "about X weeks/months" for the travel duration. And then drill down, since they display a range of dates.

That is a user interface, one that (1) requires the user to enter many keystrokes instead of click a mouse a few times, (2) requires the user to guess at the formats your program can accept, and (3) doesn't provide any supplementary hints about which calendar days correspond to which days of the week.

It's not a GUI [1]. While in the abstract a machine could just click a mouse a few times, a human has a read, interpret, click, wait cycle attached to each click. GUI's require users to work in whatever some designer thought was a good language.

There's friction against changing such languages because GUI elements have spatial dependencies that are unrelated to the user's needs (e.g. the size of the screen, the length of labels, etc.). Adding an option can require adjusting unrelated items. It's no accident Google has focused their user interface on developing better "intellisense" - they can improve the code and let the interface remain familiar.

[1] A counter example supporting the evitability of GUI's.

I disagree. These are some great examples of interfaces that make gathering user input more intuitive. You couldn't possibly delegate this information automatically, i.e. travel dates.

Also there is no mention of gradients... The article is exclusively about reducing the number of interactions to get the desired user input by using features other than default dropdowns.

This is a far cry from an article touting that they increased conversion rates by 300% by changing the color of the sign up button, and in fact it is changes to GUI's like this that separate "something useful" from being used, or being completely ignored.

...as he (probably) posts to HN through a web GUI

I used a browser and a keyboard to hit the address bar and enter the URI and type my comment. Logging into HN did not required HTTPS, not GUI.

Did you know that even Lynx is properly considered a GUI? It's a text-mode GUI, but a GUI nonetheless.

Edit: To figure out where you're coming from: do you consider text editors like vim, nano, and pico to be GUIs or CLIs? Why do you hold this opinion?

Ed is a visual line editor, and if that's a GUI then we can stop talking about PARC and just agree that Brainfuck is as good as Python via Turing Completeness while we're at it.

If it's the turtles all the way down, any blinking light becomes a GUI, for what is a pixel?

I never brought up ed. You're not a good troll, you try too hard.

He gets the content using wget and then posts directly using POST...

Reply on news.ycombinator.com