If you have a list with a refresh button on the bottom you have to scroll to see that button on a small screen. But if you use the standard pull to refresh control, you don’t even need the button.
If you use these smart hamburger menu overlay or scroll controls, they look bad on untested devices. Don’t use hamburger menus.
Most of the screenshots in this article are from iOS apps that show Google Material Design. It’s not too surprising this doesn’t work properly on Apple devices, the design doesn’t fit and you can’t implement it using the toolkit Apple designed, built and tested to work on all their devices.
Edit:
By the way you don’t even need to get a tiny phone to test this because most of the problems also show up when you increase the operating system font size which you’re also supposed to test.
There are some apps that use standard buttons that I recognize but far too many want to be fancy and roll their own making the app practically unusable unless you guess correct or press all buttons to see what they do.
But you are correct in that if everyone followed the guidelines, used the standard UI elements and images etc it would be much better. I could even forgo button labels if that happens :)
Why else would you need a special ‘discover these precious diamonds’ button in the toolbar, with the useful paths hidden in the hamburger menu and then patched over with parallel navigation from the ‘quick action’ buttons on the ‘dashboard’ (of which half is dedicated to ‘Offers & Promos’ and ‘Lifestyle’)
It’s almost as if the app has a fixed position ad that floats over half the screen and the article is complaining the useful information is so hard to see because they didn’t test on small iPhones.
It's so much worse on mobile without tooltips as well, maybe we need to standardise a long press giving a description or something similar
In desktop applications, you can over over a toolbar button and you get the label underneath. Why can't I long press a button in a mobile app and get a toast that says what it does? (I see the sibling says this should work, but I don't remember the last time I wasn't disappointed by trying this and failing.) You're making me miss the useless-90%-of-the-time question mark button at the top of every window in Windows!
I don't remember exactly where I've seen it, but for example in Android you can press-hold some buttons without labels and you see a toaster-style popup indicating its function.
I can't help but feel a bit of schadenfreude after visiting many websites clearly designed on - and for - Apple devices. Those gossamer-thin font weights are unreadable on anything else.
Also unrelated, amazing how the tables turn: I remember back in the day when small iPhones where considered to be "the ideal phone size" but the technorati, there even was a doctored graphic to go with it that showed how a thumb would reach the very top of an iPhone screen. It was doctored because the phones were not to scale, in favor of the iPhone - and this was before Apple had a larger phone.
The Apple Shortcuts (which by the way is an acquired app that was not originally designed by Apple) problem indeed is a bug in the way the sheet works, probably because of the custom keyboard like icon picker at the bottom, which is really poorly designed anyway. If you have an iOS device, here’s a riddle:
If your device has a larger screen than the one in the article and you try to recreate it (on ‘My shortcuts’ navigate back, then tap the add folder button), you can choose from a larger set of icons. Someone with an even larger device than yours would see a palette with even more icons. But on your device you can get to these icons as well, try to find out how!
They just want their designs to look good, but give no though to how they feel, especially when trying to use them one handed or with disabilities.
If I use the following SwiftUI code, I get a button that's 24.5 x 22.5.
Button(action: {}, label: {
Image(systemName: "magnifyingglass")
.imageScale(.large)
})
What is a good alternative to a hamburger menu? I can't think of anything that wouldn't have the similar issues.
Use the settings app for settings, so they don’t clutter your app. Have the user tap an ‘account’ control to do account related things like logout or change passwords.
The problem is (oversimplified) these developers start with 20 things they want to show, and then they pick 4 things they can cram in the toolbar and the rest is tucked away in the hamburger menu. It’s a lot easier of course but it also looks like the lazy alternative to thoughtful design.
or you have to localize in German.
Words don't translate 1:1 into another language. Sometimes labels are much longer in other languages.
But this doesnt make any sense. Often you need guidelines.
Typical Apple problem.
Last week I defended the move by Apple to remove that "crab house" app because they're the custodians of their walled garden and get to enforce arbitrary standards of quality and safety on the behalf of their customers who bought into the ecosystem. With this same mindset I can only blame Apple here for failing to maintain the quality standard on some of their phone lineup.
So basically I'd frame this as "Apple failing to enforce the guidelines" instead.
Even trying to find specific app from a specific vendor, while being sure to not get some lookalike evil clone from J. Random Hacker can be challenging.
Apps should follow some basic accessibility rules and be functional, but yij can in earnest say that you think that all games for example should follow the Apple design guidelines, can you?
At least in the case depicted, you should be able to get it to show just the map by tapping once in the map area.
(If you’re interested in more about this, https://www.justinobeirne.com has some excellent long-form content analysing all the major maps products, how they’ve changed over time, &c. https://www.justinobeirne.com/google-maps-new-app-icon and https://www.justinobeirne.com/what-happened-to-google-maps are good brief starting points.)
Heaven help you if you open a popular live feed. The wall of random teenage stream-of-thought noise streaming down across the video is just unspeakably crass. Why was this added, you ask? Because some overpaid manager at Google saw that Facebook was doing more video, so turning a video streaming service into a social network seemed like a brilliant idea. I mean why not? Why wouldn't people watching NASA feeds want snotty little kids spaming swearwords on their television?
PS: products slowly morphing to become nigh unrecognisable is a pre-Internet issue. The MTV channel used to show just music videos!
Facebook and YouTube then borrowed that feature when they added livestreaming.
Too often I've been unable to decipher what's being shown in the last ~15 seconds of the video because of the end-of-video annotations and recommendations.
It’s not uniformly worse than it was a decade ago; there are some areas like highlighting business districts and such where in the last decade they’ve— uh— caught up with paper maps. But if Google Maps presented me with a “show maps like they were ten years ago” option, I’d enable it in an instant, because the cons of the last decade have been far greater than the pros for how I, all my family and most of my friends use it.
When using it you kind of feel how a once pioneering piece of tech and UX initially built by a small team got taken over by corporate Google which knows best what their users need...
They absolutely don't support that use case anymore :(
And all this was just blown up, they did not have to cram in a lot of infos they just increased the size of every UI element, made fonts bigger and bolt. It was really poor design, it felt like a phone for the elderly. Also one feature was gone that the old Music app had which would've helped here: hold down on a song to get the overlay of the whole name...
In general classical music is really poorly supported by many music services and apps but this was such a huge annoyance that I had to switch to a third party app and delete that shitty Music app.
For an example there's an application I use to put money on my washing card, and also book washing machines in my building, and that doesn't work on my iPhone SE, even though that application is mostly a webview.
It could be nice if Apple could detect these issues in the review process.
This was one of the key factors for me to switch to the iPhone 12 Mini. And even though some apps still have issues, they just don't test bellow the regular 12 size.
The worst recurring bug across apps that still happen on the mini is not having enough UI spacing to accommodate scrolling bellow the keyboard. I very often have apps that won't show the "submit" or whatever button to confirm a form.
I somewhat regret this, as I miss the Touch ID. Rumors are the 13 models will have a Touch ID under the screen, which will be great, but, I don't know they'll have a 'mini' version either. Apparently the 12 mini is being discontinued? I can't tell if that rumor is true, or production is just being reduced in favor of the larger models. Either way, the "small form factor" just seems to be an afterthought.
Was reading a few viewpoints on this (perhaps it was even on HN?) some time ago, and ... one of the attractions of 'big screens' is that, for most people, that phone may be their only or primary internet access device. For me, I'm on laptops and large screens all day - I want small and conven ient and mobility in a phone, not large screens. If I want a large screen... I go to a large screen. I don't try to wrestle with getting a 7" device in to pockets to carry around with me. But people wanting 5" phones are apparently in a minority.
(Of course, in practice people made a hash of it (as they always do) and it often became mobile-only design, with users of larger screens getting a comically bad experience that was manifestly designed for tiny screens; but that’s not the idea of mobile-first.)
I’d say it’s generally a sound philosophy, even though at larger sizes you may desire to recompose the UI quite substantially. It’s generally easier and/or safer to design for small screens and reformat or add extras for larger screens, rather than to design for large screens and reformat or remove for smaller screens.
But people definitely regularly don’t go small enough in their idea of “mobile”. I decided some years ago that I would target 300px as my baseline width, and I feel that’s served me well. (And if convenient, I make it work past 260px.) 300px is a bit smaller than anything mainstream, and is thus pretty safe. (I haven’t often done much that needs a baseline height, but I’d use 300px and/or 450px there, considering both portrait and landscape usage as necessary or applicable.)
I used to use a square-screened BlackBerry 10 device, and the number of websites that didn't do this was infuriating, and I made frequent use of a "Kill Sticky" bookmarklet. But everyone runs into this issue at some point just by turning their phone to landscape mode, which most web developers evidently don't test with.
But sticky headers are the bane of my existence.
Negative space is good. It's good for readability and accessibility. Nowadays, most apps are designed to be scrollable, which means that cramping as much information as possible is probably not helpful.
>There’s too much padding on the navigation bar. For me it’s too much for my small phone and big thumb.
So… You want less space to tap with your big thumb?
Google maps is about the results list, not the map.
Other comments are just straight opinions about what he likes ("too much padding there and there"). Okay? That's just prescriptive feedback and don't bring anything valuable to the conversation.
It's also interesting to see that people in this thread have many design opinions, and almost systematically someone has the opposite feeling in their replies. It's proof that design is not just following a guideline. It's about choices, trade-offs and context.
Yeah, no. There's spacing, and there's useless void - negative space is usually being the latter.
Websites becoming ridiculous on computers, because everyone keeps designing for fat greasy fingers, and this trend is absolutely horrible.
Of course there are cases where it's taken too far. Not arguing that there isn't bad design out there. But again, negative space is good. It's proven better for comprehension and accessibility
Thanks. This attutude of respect on the UI side is why I'm tempted by the Apple platform. Unfortunately it looks like it's not as perfect as hoped initially and there's a lot of disrespect on other ends.
But even before that it had UI issues. While I had no problems with it, a friend of mine, a seasoned UI and web specialist and Apple fanboy no less, couldn't for the life of him figure out how to set a basic alarm until I hinted "you need to press 'edit alarm' at the top"; he just didn't notice that option being there.
The numeric keypad taking up the entire bottom half of the screen is what they’re expecting you to use. Providing that is why they switched to the new design. Dragging in the time box is just for some backward consistency; it’s not the intended interaction.
My favourite bit of alarm related UX is that the “dismiss” button for alarms and timers are in opposite places.
Is it really that hard to test against them? Android developers would love to have it so easy I’m sure.
https://hacknicity.medium.com/how-ios-apps-adapt-to-the-vari...
It absolutely boggles my mind, especially when you can attribute a "this is how much these users spend" amount to it (an ecom store, for instance). Most of the time it's not much extra effort to make it work properly (or even if you remove features, just keep it tidy), and absolutely worth it it real money terms.
It also happens the other way around, they break it for odd-sized devices and then they go look at their numbers: "It's less than 1% of our revenue", WELL OF COURSE IT IS! It's broken!
This was some of the same 'thinking' back in the 'designed for netscape / IE' wars of the late 90s. I would routinely hear that "we get more sales from IE users". And me saying "it's because we didn't test on netscape and the form submission is broken" didn't seem to register with anyone.
I actually worked with one client who 'got it', and they were very particular that we tested with all major browsers of the day - they had multiple millions of dollars riding on orders coming in every month, and even small delays meant big ramifications down the line. It was almost all Netscape/IE, but we had to deal with multiple versions, and test accordingly, which wasn't trivial because they were trying to also add new JS functionality. We had a lot of user-agent testing at that time. :)
I strongly disagree - with smaller devices you might be talking about an entirely different layout, and maybe a separate set of assets. More time for designers, more time for developers, and a whole category of tests for QA to verify during regression tests. You're talking about widening the entire development pipeline.
Our UI code has multiple ifs at this point where we have handle smaller screens explicitly.
As iOS developers stuck into this position we have grown to despise having to deal with smaller screens. It just feels like we can't win.
It is just mediocre design.
There are many advantages to it. If it looks good on the SE, we can be reasonably sure it will look good on everything else (though this was affected by the introduction of the notch). Also, flagship iPhones can easily handle badly designed apps but my phone will show lag and artifacts while scrolling through an infinite scrolling screen.
But... in general, yeah, the size/space/perf issues are more easily spotted on a device like an SE. I re-optimized some JS - reduced memory, speed improvements - was far more noticeable on the SE than the newer flagship devices.
For many apps, I have no idea what to click on because no one follows the autolayout.
Some (see Evernote) are so bad that I can’t even click the sign in button because the touch target seems to be on the text and the button only shows 2 letters.
¿Should I be outraged? So it goes...
I used it anyway because 1024x768 on a 14" CRT was unreadable with regular fonts.
Many of the examples have nothing to do with screen size (e.g. cutting off the bottom of letters or "so much white space"), or are intended ("Dang I can barely see the map" -- well yeah that's because the primary data is the list of results). Many other comments here are listing that many of the supposed issues are the same on large screens too.
I used the original SE and then upgraded to the SE2 and none of this has been any kind of problem.
In fact, almost all of these are great examples of responsive design. Even if you have to scroll a little or some ellipses are shown... they seem to all work.
If this is the worst the author can find of small screens not working... then they seem to have proved the opposite point, that small screens are actually working great.
Clubhouse - maybe it's an issue that the UI on the right isn't disappearing completely, but maybe that's by design. Anyway, nothing is clipped/truncated
Spotify - the "now plating" bar's height isn't added to the scrollview's content inset. Not a small screen issue since it's on the vertical axis and content is scrollable.
Globe Telecom - yes, this could count as one (with the tabbar).
CloudMd - that's just probably hardcoding the status bar's height, nothing is truncated/out of view.
Foodpanda - that side menu is actually scrollable. y letter is cut off, ok. Nothing you can't access.
Google Maps - this is a design decision, same ratio of map/list height on my iPhone XS. You can either view the map or the list in full screen
Headspace - navigation/status bar issue, just bad coding local bank - yes, this counts as well
Lalamove - yes, 2 textfields are too much
Shortcuts - scroll up?
I do agree that small screen devices aren't getting enough focus on this regard.
edit: formatting
That's a pity. I still think that 3.5" is the best smartphone size and I would pay good money to buy modern smartphone with good internals. But it does not make sense, even if some Android manufacturer would create it, apps and websites will ruin it.
There were two phones I owned which I loved from every possible perspective: an Ericsson T29s[^1], and the HTC Desire[^2]. This latter had a 3.7" screen, physical buttons, and an optical tracball, and it was glorious as a phone. Oh, and it actually fit in a hand, or a pocket.
Everything else I had since then - Nexus 4, Galaxy S4, Nomu S10, Moto E5 - are all way too big, but nobody seems to be doing any decent phones ~4" any more, which is a shame.
Current "phones" used to be called phablets in 2012.
If you’ve been rocking the original SE you’d know even better. Such a shame, it’s the best size phone I’ve had.
Likewise. It seems we will never see a comparable size flagship ever again though. I bought two new sealed box original SE's on eBay last year when they announced that the new SE would be larger, in the hopes they will last me for a while. I literally cannot imagine ever wanting another phone. It's without a doubt the best product Apple has ever designed.
Habit shapes creation.
I use an SE and naturally design & build for it. (Plug: https://mro.name/ShaarliOS)
But when a former 500K ipa (objc) becomes a ~70MB upload (swift) that makes >300MB traffic submitting, you clearly know the culture behind it is not sustainable and has no future.
Apple doesn't care about the low end. Not in developer tools, not in OS (weekly big sur updates in the GBs) and so that's what designers get used to. Apple sells hardware. Software and services is the bait.
Those who do care are a few opinionated geeks. Not the mainstream, not where the money is.
It's not a culture shift, it's a technology shift. Systemwide shared-libraries are going away because they involve all-manner of versioning difficulties (DLL-Hell, etc). Simultaneously, computers have enough physical memory such that processes don't need to share libraries in-memory to keep usage low, and the security advantages of single-upgrades to shared libraries are wiped-out by programs breaking due to unexpected changes in their dependencies, and writing software is now accepted as a treadmill: ship regular updates (monthly? weekly?) where the only change is updating to the latest dependencies and ensuring tests pass - these 3 things combined lead to portable, self-contained software that can run on minimal platforms. Other examples include Go's single-executable statically-linked compilation. And so on.
But this is progress. I do expect eventually we'll have entirely dependency-free software where every redistributable is effectively its own self-contained computer system (basically, a VM): that has tremendous implications for long-term application support. Apple (rightfully) gets a LOT of stick for their lack of backwards-compatibility support, but if all software for Apple's platforms eventually becomes more like a VM image then we'll be able to run those VM images on Apple's future phones - and even non-Apple phones - and non-phones, decades from now - which is a refreshing change from where we are today where we can't even run games from only 2-3 years ago.
That's IMO software explosion and bloat as Niklaus Wirth ranted on decades ago.
https://medium.com/front-end-weekly/dominos-pizza-and-web-ac...
https://www.cnbc.com/2019/10/07/dominos-supreme-court.html
For all of your web projects...
90+ score in Lighthouse is a good bar to aim for.
And look for any errors in Wave or Axe -- these should be part of your requirements (starting with requirements to the design team around contrast and colors they can use, as well as requirements to the devs), and part of your QA process. Call out issues you see. Compliance with WCAG (2.1, AA for most businesses https://www.w3.org/TR/WCAG21) is the de facto law of the land.
Regarding web design, I always set the iPhone 5/SE view as the baseline. I think it's a lot easier to go from there to a bigger device than the other way around. Also, the worst that can happen is that there's some empty spaces on the sides or some card gets wide. However, when you start from a big device and then try to fit the UI to smaller ones it's a lot harder.
Another problem is the rendering engines. I once had to help a friend with a problem that was only happening in my iPhone, but when I used Chrome (in my laptop) with the mobile view it worked ok. I could then reproduce the bug using Safari (in my laptop) with the mobile view active, so I guess it was because of the small size + rendering engine. Those things are also hard to debug and catch.
1. The fact that some designers ignore other devices than their own is definitely true. That is why I created a Figma plugin to broaden the perspective. https://www.figma.com/community/plugin/732240841094697441/Vi... But developers do the very same thing and as often as designers. Just further down the pipeline.
2. Not supporting the smallest possible devices like the original SE is a reasonable business decision. It is not even making it into the charts at all the products I'm currently working on. It is simply not worth the effort (since the effort is not as insignificant as people here say).
3. Supporting the smallest devices is definitely not free. And it has a real monetary, technological and UX cost. It costs a lot of money to properly test, report, design, and implement every possible edge case for every possible viewports. Developers HATE creating special layouts or cases for specific devices (speaking about native mobile development) and if I recall correctly, Apple might even prohibit it. And lastly, design is about making the best possible solution, for the biggest amount of people. Quite often you will find yourself in a situation where you have to decide whether you will vastly improve the experience for the 99% of people and make the experience not ideal for the 1% or vice versa. Which is the better call?
4. Blaming it all on designers is just too harsh. Yes, not everyone is perfect, and designers often miss it, but more often than not it is a simple business decisions. Designers can decide to ditch a certain viewport because it can benefit the majority, the same way developers decide to drop certain OS support.
Edit: I was wrong about the mini being smaller; it's somewhat larger than the 8/SE
This isn’t about physical size, though; it’s about screen resolution and aspect ratio.
> iPhone 12 mini: 2340×1080 @ 476dpi
> iPhone SE 2020: 1334×750 @ 326dpi
Yes, the 12 mini’s screen is 5.4” while the SE’s screen is 4.7”, but if the SE had the 12 mini’s DPI, it’d have a workable, modern-ish resolution. (Note how the OP never complained about how these apps look on the 12 mini. They look fine on the 12 mini.) The SE 2020 only ended up at the “outdated” resolution of 750p because its pixel density didn’t keep up with the times; not because it’s small per se.
But I completely agree that the iPhone 6. 7, 8, SE viewport should serve as the baseline for most, since the market share is quite significant (it takes the third spot worldwide).
The result is UI regularly covered by the keyboard. Text clipping and text overflows. The tiny map problem mentioned in the article.
As much as I want a smaller phone I fear that it would be unusable with the default UI and certainly if I chose to use increased text size.
But banks, drug stores, and things like Spotify should be paying attention to these things. Many businesses may out-source app development to people who just don't care about anything but "meeting the spec" but Spotify should know better.
The walled garden has for a long time failed to actually keep the quality up.
It often doesn't show the button to enable biometric unlock, so I'm constantly having to type the full password
It's so counter-intuitive and ironic that the biggest applications with the biggest headcounts in their small percentage userbases spend the least amount of effort trying to accomodate them.
Hasn’t happened with the iPhone 12 mini yet, but, it is a markedly larger phone with a significantly larger screen.
The Google Maps example is probably because most people want to see the list of results when you search for a category of businesses - the map is secondary. If you do want to see more map, you can just pull down on that handle at the top of the list or press the "View Larger Map" button.
Many of the other examples seem somewhat nitpicky, so I don't really think this supports the argument that nobody is designing for small devices.
Maybe the real question should be, why is software broken so badly?
Granted I don't load it onto that phone often, but I checked that it worked as expected, and the layout behaved reasonably.
An iPhone SE (not 2020) will set you back less than $100.
Anything that teenagers use (e.g. Spotify) you have to assume it'll be run across all kinds of budget devices.
So I switched to a Samsung Flip, and I've learned that a device that has a large display and fits in my pocket is a reasonable compromise. Now they just need to be a reasonable price.
One thing that really annoyed me was doing an accidental shake gesture while typing something. The blocking Undo dialog’s buttons are covered by the keyboard and you cannot do anything but restart the app.
I have people in my family rocking the original iphone se because THAT is small enough for them.
Best to check your hypotheses before writing them down as facts.
"This is losing is a LOT of money, but it would be a nice thing to do" is not realistic.
In fact, I think I'll upload it somewhere for this author to add to the list.
Scaling designs up to an X class device is much easier than trying to scale down.
Mobile-first was an approach to fix this but pragmatism usually dictates otherwise.
If it is really only 1% of the people with iphones that you are messing up... that is a gamble I would take.
This app will look good for 99% of the wallets who own this phone, the other 1% of the wallets have the cheap phone. By having the smaller device it implies (no matter if this is true or not) your spend will/could be less.
To me IOS is such a closed inbred ecosystem apps SHOULD look good on all of the devices.
And for that matter so do iPhone 6 and 6S, which are still current as of iOS 14.
iPhone 7 and up are still going to support iOS 15, so these devices will be with us for a while.
Most of these are either by design or just UI bugs or poor design.
The alternative is to really have a "one size fits all" design, but this will likely mean making compromises on larger screens.
Mobile development is expensive, and there's already enough to deal with to support backwards compatibility, and localization. It's just not economical to support small phones which almost nobody is using.
Why design for vision, hearing, motor, cognitive impairments, older browsers, feature phones, 2g connections, motion sensitivity, unusual input devices, smart watches, tvs, game consoles, low-powered devices, languages other than English?
I don't mean to sound harsh, but I'm very tired of hearing this argument. It's not that hard to accomodate people, especially on Apple devices, they give you all the tools to do this.
Don't be shocked if X group is a small fraction of your users if your design has made it clear they're not welcome.
It's a very entitled view to assume that every product has a duty to accommodate you. Yes it feels bad to be left out of something, but that doesn't mean it's owed to you.
pride in worksmanship, perhaps...
because 1% is still quite a few users for whom the experience sucks...
or perhaps just plain old empathy...
because not every customer can just replace their device...
or... i dunno... just avoiding someone posting embarrassing screenshots of one's app looking like shit on hacker news?
Mobile first often made the experience suck for desktops.
Tiny screen first just makes the experience suck for everyone.
The author says: Also, I don’t care if the statistics for small devices is less than 1%, it’s just pure respect for those users.
But that's a false dichotomy.
The horror!
My mom will for sure delete her local bank’s app if she sees the post showing that the padding is a few pixels off on a phone she doesn’t own.
Judging by the screenshots in the article this really isn’t true. Devs just need to bother to test with these small devices, they’d see the padding and offset issues immediately and it would be an easy fix.