Hacker News Reader

Comment by brudgers | Hacker News Reader

  "What day do you want to travel?"
   >

NoGUI.

View on HN

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 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.

Reply on news.ycombinator.com