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.
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.
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.
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?
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.
I'm thinking out loud. A problem I am interested in has a much stronger assumption of a GUI than something like airline search. It is hard and to think about the solution space without that assumption and productive because it moves the underlying class of problems to a higher level of abstraction that offers the possibility of substantial innovation. GUI's are the conventional wisdom. But maybe it is worth asking if forty year old assumptions about computer users are worth revisiting.
After perusing brudgers' comment history, it's clear to me that the comments I was replying to were just extremely unusually disjointed or scattered. Mea culpa.
I still believe that I was being trolled, but it is now quite clear to me that brudgers appears to be completely capable of having entirely reasonable, insightful conversations. Sorry for any offence. :(
However, -for future reference- when speaking of obviously, chronically disjointed and confused commenters -say, a more polite Terry Davis- what is an HN-acceptable way to structure the sentiment in my comment?
This is a serious, non-confrontational question. :)
Your not understanding something isn't necessarily a sign that it is incorrect. It's not necessarily a sign that you're being trolled either. Obviously a position that one does not understand is probably a suboptimal starting point for developing a coherent counter-argument due to the risk that one's comment be seen as constructing a strawman.
One of the things I've learned on HN is that, just asking someone to clarify their idea before responding is surprisingly useful. It disarms the troll because it breaks the pattern. It allows an earnest person to attempt to clarify their thoughts or will be ignored by someone with low interest in further discussion. It's also a good way for me to express genuine curiosity.
Accusing me of trolling you for a third time on this page and focusing on "any offense" rather than your behavior isn't an apology...even ignoring the comparison to a schizophrenic individual. Other than the delete link, there isn't an HN appropriate way to express the sort of sentiments you're interested in expressing.
It is now clear that in the third paragraph of my response, I chose my words poorly. I had thought that the previous two 'graphs would make my new knowledge vis a vis my grave error in judgement clear. It is obvious that I was incorrect.
For a third time, I apologise for the hasty, completely unfounded, and obviously incorrect assertion regarding your mental capacity.
> One of the things I've learned on HN is that, just asking someone to clarify their idea before responding is surprisingly useful. It disarms the troll because it breaks the pattern.
Frankly, I have rarely found this strategy to be of use. In my experience, the troller typically continues full steam ahead.
Note that in our conversations, I did exactly as you suggest. Twice. Indeed, please kindly go back and look at our conversations with fresh eyes.
You open with:
"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..."
I counter with a question, anecdote, and a book recommendation:
"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."
You reply:
"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".]"
In another thread:
You (replying to the comment "[brudgers] (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."
Me, attempting to establish what exactly it is that you consider to be a 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?"
You:
"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."
Can you see how a reasonable person might see your replies as extreme obliqueness and refusal to engage in productive conversation? I directly asked you for your opinion, twice in an effort to both steer the conversation in a productive direction and help me to understand your position, as I was having great difficulty determining it[0] from your comments up to that point.
[0] I mean, anything more nuanced than "NoGUI!". :)
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)
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.
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.
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.