Dropdowns Should Be the UI of Last Resort • Hacker News Board

Re: Dropdowns Should Be the UI of Last Resort

#201

Post by ocb » Mon, Jul 20, 2015, 9:25 PM UTC

err4nt wrote: post #132

epistasis wrote: post #126

Earlier quoted context omitted.

Screenshotting is something that almost nobody knows how to do. And even if everybody did know how to screenshot, it's so much slower and inefficient that it's a completely unacceptable replacement for the natural, and designed zoom interface.

> Screenshotting is something that almost nobody knows how to do I got a really good laugh at this one, a cursory glance of user-generated content online shows tons of people not only know how to screenshot their devices, but are quite adept at figuring out how to share those screenshots with each other and the world.

Looking at social media, it seems like lots more people know how to screenshot than directly download an image, leading to screenshots of images being shared. Strange phenomenon.

Re: Dropdowns Should Be the UI of Last Resort

#202

Post by err4nt » Mon, Jul 20, 2015, 9:33 PM UTC

function_seven wrote: post #165

err4nt wrote: post #111

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

> 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? They have that ability (at least on iOS. Don't know about Android, but I assume it has similar settings). It's under the Accessibility options. Why don't you allow users the ability to zoom your sites?

I do allow zoom when it's appropriate: usually when I'm either targeting desktop users and don't plan (or don't have budget) to specifically target mobile users with their own experience, or when user scaling of the viewport makes sense to the project.

It's FAR better to pan and zoom around a working desktop layout than to have a broken responsive layout, so I only disable user-scaling on sites with a specifically targeted mobile experience where I can deliver a better experience by disabling user scaling than leaving it on.

Here's an example where disabling user zoom vastly improves user experience: a tool I built for myself with the purpose of allowing me to test other websites responsively at different widths while using a device with a fixed-width screen.

I.E. this tool lets me test websites at different browser widths while on a phone with a fixed-width.

http://staticresource.com/speedtest.php

Now, if I were to have had user scaling enabled do you think the experience on that site would be better?

Clearly not! But on the other hand, here's a chart with all of the values in hexadecimal plotted in a grid so I can understand and visualize the relationships between values in hexadecimal colour notation (like #1166aa). This page is an illustration, and though I do have some crude responsive styles to help it fit on narrower screens, I intentionally left user-scaling on to make a better user-experience, until/unless I decide to go in and give it a better mobile-specific experience:

http://staticresource.com/misc/grid.html

Now, if I were to have had user scaling enabled do you think the experience on that site would be better?

Clearly not! There's no right or wrong answer for every. single. website. You have to look at how it will be used, who will use it, on which hardware, and what will provide the most value to them. That decision happens case-by-case and there's always a trade-off happening.

I wonder if the group of people that can't manage to browse with user-scaling turned off on their modern, high-end mobile phones are the same who can't seem to load any website posted to HN that uses JavaScript because not everybody uses a browser with JS enabled…

Re: Dropdowns Should Be the UI of Last Resort

#203

Post by coldtea » Mon, Jul 20, 2015, 9:47 PM UTC

vidarh wrote: post #93

coldtea wrote: post #38

Earlier quoted context omitted.

On the other hand, any list of "significant length" is best served by a dropdown. None of the options he shows in the article works well there.

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

Only if you know the options in advance as the sibling comment says.

And mostly for very significant length (e.g. "all my songs") E.g. for up to 20-30 items dropdown is still better, and you can select with one finger without much concetration.

Of course there's also the "searchable dropdown", or a dropdown where you can type the first letter(s) of an options to jump there.

Re: Dropdowns Should Be the UI of Last Resort

#204

Post by russgray » Mon, Jul 20, 2015, 9:49 PM UTC

brudgers wrote: post #181

simoncion wrote: post #167

Earlier quoted context omitted.

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

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 "wu…

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?

Re: Dropdowns Should Be the UI of Last Resort

#205

Post by Nadya » Mon, Jul 20, 2015, 9:50 PM UTC

err4nt wrote: post #202

function_seven wrote: post #165

Earlier quoted context omitted.

> 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? They have that ability (at least on iOS. Don't know about Android, but I assume it has similar settings). It's under the Accessibility options. Why don't you allow users the ability to zoom your sites?

I do allow zoom when it's appropriate: usually when I'm either targeting desktop users and don't plan (or don't have budget) to specifically target mobile users with their own experience, or when user scaling of the viewport makes sense to the project. It's FAR better to pan and zoom around a working desktop layout than to have a broken responsive layout, so I only disable user-scaling on sites with a specifically ta…

I can say for a fact that zooming on the grid would have been a better experience. As-is it is currently only usable if I use my phone as landscape rather than portrait as there is no space between each item. For most sites I don't bother rotating my phone - scrolling down is worse than zooming in/out. Especially when trying to read a grid or chart reliant on seeing all the information at once and not 4 rows at a time.

Re: Dropdowns Should Be the UI of Last Resort

#206

Post by Nadya » Mon, Jul 20, 2015, 9:50 PM UTC

err4nt wrote: post #202

function_seven wrote: post #165

Earlier quoted context omitted.

> 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? They have that ability (at least on iOS. Don't know about Android, but I assume it has similar settings). It's under the Accessibility options. Why don't you allow users the ability to zoom your sites?

I do allow zoom when it's appropriate: usually when I'm either targeting desktop users and don't plan (or don't have budget) to specifically target mobile users with their own experience, or when user scaling of the viewport makes sense to the project. It's FAR better to pan and zoom around a working desktop layout than to have a broken responsive layout, so I only disable user-scaling on sites with a specifically ta…

I can say for a fact that zooming on the grid would have been a better experience. As-is it is currently only usable if I use my phone as landscape rather than portrait as there is no space between each item. For most sites I don't bother rotating my phone - scrolling down is worse than zooming in/out. Especially when trying to read a grid or chart reliant on seeing all the information at once and not 4 rows at a time.

Re: Dropdowns Should Be the UI of Last Resort

#207

Post by simoncion » Mon, Jul 20, 2015, 10:15 PM UTC

russgray wrote: post #204

brudgers wrote: post #181

Earlier quoted context omitted.

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 "wu…

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

Re: Dropdowns Should Be the UI of Last Resort

#208

Post by function_seven » Mon, Jul 20, 2015, 10:19 PM UTC

err4nt wrote: post #202

function_seven wrote: post #165

Earlier quoted context omitted.

> 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? They have that ability (at least on iOS. Don't know about Android, but I assume it has similar settings). It's under the Accessibility options. Why don't you allow users the ability to zoom your sites?

I do allow zoom when it's appropriate: usually when I'm either targeting desktop users and don't plan (or don't have budget) to specifically target mobile users with their own experience, or when user scaling of the viewport makes sense to the project. It's FAR better to pan and zoom around a working desktop layout than to have a broken responsive layout, so I only disable user-scaling on sites with a specifically ta…

Yes, both of those sites benefit from zoomability. The first one, I just tested (by visiting "water.com" in your tool). When I tested #5 (500 x 477), the viewport disappears off the end of the right edge of my screen. I can't see the whole thing at once, no matter what I do. I have to scroll, and that's confusing because my scroll swipe will move the content inside the viewport before moving the site itself, and thus the viewport itself. If I could pinch out on it, I'd see the whole thing at once.

As an aside, the Android I used to test this allowed me to turn on Force Zoom, and that allowed me to use the site better.

The second site (grid.html) can appear very small. I think you intended to say it should be zoomable, as I was able to zoom in and out on that one.

My point is, even when you yourself cannot conceive of a reason a user would like to zoom the site, trust me, there probably is one. In another reply, you mentioned the 300ms delay that turning on zoom control introduces. I hadn't thought of that before, and that is a good point for disabling zoom control. Maybe Apple can follow Google's lead, and give their users the option to override it. That would allow the majority of your users the faster touch-responsiveness that you're trying to give them, while still letting the rest of us have the control we'd like over our browsers.

Re: Dropdowns Should Be the UI of Last Resort

#209

Post by brudgers » Mon, Jul 20, 2015, 10:22 PM UTC

russgray wrote: post #204

brudgers wrote: post #181

Earlier quoted context omitted.

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 "wu…

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.

Re: Dropdowns Should Be the UI of Last Resort

#210

Post by dragonwriter » Mon, Jul 20, 2015, 11:17 PM UTC

marcosdumay wrote: post #179

err4nt wrote: post #155

Earlier quoted context omitted.

I feel like a lot of these complaints are endemic to defining things in CSS using 'px' as units instead of more sensible (and repsonsive) modern techniques like defining type in 'pt' and widths in more complex units (percents, or mixed units). It's possible to avoid a lot of these pitfalls with better design. 1. User far from big screen: You can zoom much faster and easier with your forearm than a pinch gesture 2. Us…

> I feel like a lot of these complaints are endemic to defining things in CSS using 'px' as units instead of more sensible (and repsonsive) modern techniques like defining type in 'pt' and widths in more complex units (percents, or mixed units). What? Isn't px a fixed multiple of pt, with an actual size that varies by platform?

> What? Isn't px a fixed multiple of pt

CSS 3 defines pixels that way (1/96 inch, pt is 1/72 inch), but the previous definition was rather different, and had no fixed relation to either inches or ems.

But I thought the change in CSS 3 was because pretty much every actual implementation of CSS 2.1 had taken the definition, chucked it out the window, and used 1/96 inch anyway. So, I don't see how any problems could arise in practice from using px instead of pt.