Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dropdowns Should Be the UI of Last Resort

lukew.com

Post reply on HN
Print view View original

211–220 of 241 posts

Re: Dropdowns Should Be the UI of Last Resort

#211

Post by csallen »

brudgers wrote: post #108
Trufa wrote: post #58

Earlier quoted context omitted.

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.

"What day do you want to travel?" > NoGUI.

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.

Re: Dropdowns Should Be the UI of Last Resort

#212

Post by Elepsis »

brudgers wrote: post #209
russgray wrote: post #204

Earlier quoted context omitted.

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.

Re: Dropdowns Should Be the UI of Last Resort

#213

Post by simoncion »

Elepsis wrote: post #212
brudgers wrote: post #209

Earlier quoted context omitted.

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 pl…

Your points are good.

I'm pretty sure brudgers is either trolling or dysfunctional in some way.

Re: Dropdowns Should Be the UI of Last Resort

#214

Post by brudgers »

Elepsis wrote: post #212
brudgers wrote: post #209

Earlier quoted context omitted.

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 pl…

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.

Re: Dropdowns Should Be the UI of Last Resort

#215

Post by brudgers »

csallen wrote: post #211
brudgers wrote: post #108

Earlier quoted context omitted.

"What day do you want to travel?" > NoGUI.

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.

Re: Dropdowns Should Be the UI of Last Resort

#216

Post by brudgers »

simoncion wrote: post #213
Elepsis wrote: post #212

Earlier quoted context omitted.

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 pl…

Your points are good. I'm pretty sure brudgers is either trolling or dysfunctional in some way.

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.

Re: Dropdowns Should Be the UI of Last Resort

#217

Post by JupiterMoon »

err4nt wrote: post #189
tajen wrote: post #143

Earlier quoted context omitted.

Please stop disabling zoom, period. You mention you are properly trained. Who trained you, so we can fix them too ;) ? (joking)

My training was in graphic design, and the web training we got in college was behind where I was self-taught in web before getting to college, they only covered the basics. By leaving the User Scaling on, the browser slows down all of your taps 300ms to wait and see if your single-tap is really a double-tap to scale the page. By disabling User Scaling, your interactions are read as soon as you make them, leaving you…

> My training was in graphic design

So mainly paper based graphics right?

> and the web training we got in college was behind where I was self-taught in web before getting to college, they only covered the basics.

As I thought so no formal training in design for screens.

Screens are not paper. Please be responsive yourself, be a life long learner and stop disabling zoom. Can google analytics or somesuch look for failed pinch to zoom events followed by someone leaving your website?

P.S. responsive means that the website responds to the screen size and looks fine on a 40" wide screen or on a 4" smart phone. It does not mean anything about speed of response (which is a nice thing to have obviously but not at the expense of basic function).

P.P.S. there are two responses to a non-zooming website: 1. That of someone that knows what the web-designer did: "Why on earth did the * web developer disable zooming. I'm closing the tab." 2. Non-techy people: "Grunt aaahhh why is this * website not working. I'm closing the tab and never coming back".

Re: Dropdowns Should Be the UI of Last Resort

#218

Post by dang »

simoncion wrote: post #213
Elepsis wrote: post #212

Earlier quoted context omitted.

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 pl…

Your points are good. I'm pretty sure brudgers is either trolling or dysfunctional in some way.

> I'm pretty sure brudgers is either trolling or dysfunctional in some way.

Whoa, that's not nice. Please don't make personal slights in HN comments.

Re: Dropdowns Should Be the UI of Last Resort

#219

Post by vidarh »

simoncion wrote: post #162
vidarh wrote: post #93

Earlier quoted context omitted.

A list of significant length is often best served by search .

Unless -of course- you don't have a good idea of what it is that you want to search for! This happens to me far more frequently than I would like. :)

At which point a search with instant feedback is still often far better than trying to scan a huge list.

Re: Dropdowns Should Be the UI of Last Resort

#220

Post by vidarh »

err4nt wrote: post #111
vidarh wrote: post #91

Earlier quoted context omitted.

If I try to zoom, it is already a demonstration that your design does not work for me on my device. I would not prefer to pan - if I resort to it, it's because I have to because the site design is broken. At that point you better not have disabled zoom too, if you want me to come back to your site.

> If I try to zoom, it is already a demonstration that your design does not work for me on my device. THIS! This is how I feel exactly! When you load up a site I do it is as well designed as a mobile app. Surely people don't complain about the inability to zoom in their iOS settings app, or in the clocks app. Why would my site be any different?

> THIS! This is how I feel exactly! When you load up a site I do it is as well designed as a mobile app.

You appear to have missed my entire point, which is that if I try to zoom, there is no reason to prevent me from doing so, as the fact that I have tried to zoom is proof your attempt at design to meet my needs failed, and zoom might make it better, and certainly won't make it worse, while denying me will make me annoyed or angry and potentially mean I can't use your site.

I can tell you with 100% certainty that you are unable to find a font-size, for example, that will satisfy everyone, as e.g. what is comfortable for me is too small to be readable for a lot of people.

Arguably, disabling zoom might even violate disabilities protections in some jurisdictions. E.g. in the UK you are required to take reasonable steps to make your site available to people with disabilities. Disabling zoom does the opposite, by making it harder to access your site for weak sighted people.

> Surely people don't complain about the inability to zoom in their iOS settings app, or in the clocks app. Why would my site be any different?

Why do you think people won't complain if they can't zoom? The first screen magnifying application I saw was ca. 1986. And that was on a home computer where font sizes etc. could be freely adjusted up to very large sizes. People still wanted the ability to zoom to make their usage easier.

I don't know about iOS, but on Android you can turn on "magnification gestures" and zoom any app everywhere by triple-tapping the screen. At least in my version.

But for e.g. the browser, assuming you've done your job properly, then zooming in a way that allows re-layout would save a lot of weak-sighted people a lot of panning that they are forced to do if they use the built in magnification since the latter doesn't have any knowledge of the page structure.

Post reply on HN