[HN Gopher] Nobody designs for small iPhone devices anymore
___________________________________________________________________
Nobody designs for small iPhone devices anymore
Author : dirtylowprofile
Score : 429 points
Date : 2021-03-20 11:19 UTC (11 hours ago)
(HTM) web link (lwgmnz.me)
(TXT) w3m dump (lwgmnz.me)
| weejewel wrote:
| If you think this is bad, try the first iPhone SE.
| fouc wrote:
| I'm still using the iPhone SE (2016) as my daily driver. I find
| overall it's fine, only occasionally does a button get cut off
| by the screen size with no recourse.
| whitebread wrote:
| Same here, my iPhone SE (2016) is still going strong and I
| can't remember the last time I stumbled upon an app that gave
| me enough sizing issues to become frustrating. What I
| would've given for the 2020 SE to be the same size as the
| 2016, being able to do everything on my phone one-handed is
| such a nice perk.
| dijit wrote:
| Just a few times a button has been unreachable because of
| this.
|
| Hasn't happened with the iPhone 12 mini yet, but, it is a
| markedly larger phone with a significantly larger screen.
| endemic wrote:
| I've been confused by the "share" window where the screen
| dimensions cut content off perfectly, and there is no scroll
| indicator, so you don't realize there's more to the UI.
| SilasX wrote:
| Or Facebook photo preview where it cuts off the bottom
| until you open it to full, and no indicator it's cut off
| except your own experience with crappy cutoffs. That often
| changes the meaning of pictures/memes.
| formerly_proven wrote:
| GDPR "consent" popups are sometimes not usable on the first
| gen SE, because some of them position: absolute with a
| fixed size that's larger than the screen. Coincidentally,
| the "Accept all" button is always reachable, with the
| "Settings" or "Deny most" button conveniently located below
| the unreachable fold.
| captn3m0 wrote:
| I just read most stuff on Firefox Reader mode. No way to
| click those popupas cleanly on my phone.
| vbezhenar wrote:
| That was the case when I owned iPhone 4S. I think that around iOS
| 9 it was poorly usable partially because developers ignored its
| dimensions.
|
| 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.
| aphextron wrote:
| There's the new Palm phone[0], which is absolutely perfect in
| every way except for the fact that it runs Android. I would
| give anything for an iOS phone like this.
|
| [0] https://palm.com/pages/product
| vbezhenar wrote:
| Thanks, that's really interesting product!
| pmlnr wrote:
| > I still think that 3.5" is the best smartphone size
|
| 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.
|
| [^1]: https://www.gsmarena.com/ericsson_t29s-225.php
|
| [^2]: https://www.gsmarena.com/htc_desire-3077.php
| tambourine_man wrote:
| > Well, if you've been rocking the iPhone SE 2020 you would know
|
| 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.
| TrueGeek wrote:
| Have you tried the new Mini? I switched from the Pro and love
| it.
| tambourine_man wrote:
| I haven't yet, mine is still pretty fine. But I'll buy it
| when this one eventually dies or is not supported anymore.
| layer8 wrote:
| I have, and it is noticeably heavier and less "thumbable"
| than the SE1 (and the screen scratches much more easily). The
| mini size is better than the 6/SE2, plus the return to flat
| edges, but it's still a compromise in usability compared to
| the 5/SE1.
| mgkimsal wrote:
| Amen. I'm sticking with my 12 mini for now, but just left
| the original SE. they're close in size, but more screen
| means more reaching/stretching for my small hands. SE2 was
| bigger, but because the screen is smaller, I'm wondering if
| that may have been the better option? I miss the Touch ID
| too..
| layer8 wrote:
| I had an iPhone 6 (same size as SE2) for a year after the
| 5, and then reverted to the SE1 because the 6 was just
| too slippery with its round edges, and just a tad bit too
| wide to grip it naturally, and I had to use the
| Reachability feature quite often. So while it may work
| for you, I can't personally recommend it over the 12
| mini.
| mgkimsal wrote:
| I'd meant I considered an SE2, but didn't get it, because
| of the physical size.
| aphextron wrote:
| >"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.
| izerik wrote:
| A lot of these aren't "small screen" problems, just bad/hacky
| coding, not doing things like apple recommends or not handling
| some edge cases, so they're simply just bugs.
|
| 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
| chrismorgan wrote:
| The Google Maps thing isn't entirely about screen size (though I
| would hope it wouldn't be quite so bad on larger screens--but I'm
| only familiar with how it looks on a small-by-modern-standards
| Android phone, where it's about the same as on the iPhone
| depicted in this article, or even a little less); it's about the
| product's overarching philosophy, which has changed over the past
| decade (in a direction I strongly dislike). It used to be about,
| y'know, _maps_ , but maps are now incidental, a means to a
| _different_ end, ably demonstrated by their icon change a year
| ago from a map to a location pin. It's all about the destinations
| now, and mapping has progressively deteriorated and been
| deemphasised.
|
| 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.)
| shorts_theory wrote:
| That website is incredible. I had no idea I would be so
| engrossed in reading about the size and shape of map labels and
| the shape of building in a phone map application.
| sfvisser wrote:
| Google Maps is not much better on larger screens unfortunately.
| It's almost as if it _wants_ to obscure the map area, no matter
| what you try.
|
| 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...
| ramraj07 wrote:
| I have followed the brilliance of google maps from an ux
| perspective for decades now, and don't fault them that much for
| their new changes: it has become much more common now that I
| actually don't care much about where a place is, more only
| about if I found the right place, and how do I get there. If I
| use public transit then the map becomes even more irrelevant.
| Given how good Googles places info is, the only time the map
| becomes relevant is once I start turn by turn directions, at
| which point it again shows one of the best UIs out there for
| that purpose.
| chrismorgan wrote:
| Meanwhile, I get frustrated by the changes in their
| cartography style almost every time I use Google Maps. Most
| of the time I _do_ want an actual map, and even when I'm not
| so fussed about that, the old style conveyed more useful
| details for the sorts of things I was doing. If you want to
| _explore_ an area geographically, the changes have been
| terrible.
|
| 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.
| iggldiggl wrote:
| Absolutely, which is why I definitively prefer OSM for that
| purpose.
| asiachick wrote:
| Maps does what I want in this instance. The display shows
| results for what I searched for. If I want the map I tap the
| map. If I want to see more search results I scroll down. I'm
| not seeing any problem. I want those search results when I
| search. Where would you suggest they put them. The screen is
| already small, putting them just on the map would make it hard
| to provide any details to help you find the thing you were
| searching for
| kuschku wrote:
| The big issue is having them on the map, without reloading
| the search results when the map is zoomed/panned, without the
| map obscured.
|
| They absolutely don't support that use case anymore :(
| jiggawatts wrote:
| While we're on the topic: YouTube, which is inherently a video
| content viewing service, goes out of its way to obscure the
| video content. The TV app, the mobile app, and the browser app
| all _insist_ on overlaying the content with random garbage that
| no sane human being could possibly be more interested in that
| the content that they launched with the intention of watching!
|
| 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!
| spideymans wrote:
| >While we're on the topic: YouTube, which is inherently a
| video content viewing service, goes out of its way to obscure
| the video content. The TV app, the mobile app, and the
| browser app all insist on overlaying the content with random
| garbage that no sane human being could possibly be more
| interested in that the content that they launched with the
| intention of watching!
|
| 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.
| smileybarry wrote:
| YouTube added live chat not because of Facebook, but because
| of Twitch which popularized this live-video-with-
| synchronized-chat. (except on Twitch it's about 1-10s of
| delay where on YouTube it's 30+ minimum)
|
| Facebook and YouTube then borrowed that feature when they
| added livestreaming.
| the_jeremy wrote:
| Things[0][1] I've looked at says Twitch's delay is much
| longer than 1s.
|
| [0]: https://www.fairlyoddstreamers.com/post/twitch-stream-
| delay [1]: https://onetwostream.com/blog/twitch-delay/
| anonymousab wrote:
| The delay depends on a lot of things, from configurable
| settings for the streamer (both on twitch and on their
| machine) and for the viewer (low-latency mode, and
| sometimes, explicitly not! using it), as well as things
| outside of their control - in Twitch's infra and just
| general internet latency.
|
| It's not uncommon for streamers to display their chat in
| a sidebar on the stream, or overlaid on the content
| itself. From this, I've observed delays as low as (or
| maybe a bit lower than) a second, and as high as 30s -
| though I haven't seen anything nearly that high in a long
| time.
|
| I suspect bigger or more successful streamers are
| prioritized on Twitch's backend. But I think the
| threshold for "successful" is actually rather low -
| someone consistently getting just hundreds of viewers is
| probably there already, in that top percentile.
| deadmutex wrote:
| Understatement
| alisonkisk wrote:
| You can turn off chat
| jiggawatts wrote:
| What are you talking about? I just clicked through the
| "Settings" menu, and there's no such option!
|
| Oh, you mean _individually_ , on a per-video basis, using
| the tiny button that's thoroughly hidden as part of the
| dark pattern to drive user engagement?
| rozab wrote:
| I hate those scrolling chat feeds, and I don't understand how
| anyone's able to read them? I can barely read a 5 word
| message when it's juddering up the screen at a million miles
| an hour. Why hasn't twitch et al replaced it with a widget
| that just draws new messages above the old, scanning top to
| bottom?
| illwrks wrote:
| The main reason I had to get a new phone was because of apps not
| scaling correctly. And website visible areas being severely
| reduced due to ads and cookie notices etc...
| andybak wrote:
| Really surprised this isn't caught in the App Store review
| process. Seems like a very low quality bar to aim for.
| matsemann wrote:
| The only thing the review process is good for nowadays is to
| randomly ban apps by mistake, and make sure you're not taking
| payments without giving Apple their cut.
|
| The walled garden has for a long time failed to actually keep
| the quality up.
| gcb0 wrote:
| "oh buy i gladly pay the apple tax and subject myself to a single
| apple store with draconian rules for quality products in the
| entire ecosystem"
| sdfhbdf wrote:
| Is iPhone 12 mini considered small? I rock it and i can't seem to
| share the annoyances that the author mentions.
| dep_b wrote:
| Because the mini has the same amount of pt's as the iPhone X.
| Take a good look: everything's smaller.
| mattgreenrocks wrote:
| I sometimes see stuff like this on my 12 mini. Ridiculous.
| Almost always it's a website though.
| daviddavis wrote:
| I was considering upgrading to an iPhone 12 mini. Does it have
| these issues too?
| tomger wrote:
| No
| gridder wrote:
| It does but a lot less. Go for it, it's a great phone.
| crazygringo wrote:
| This feels... silly.
|
| 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.
| Adrig wrote:
| Without even debating the pertinence and aggressiveness of this
| article's title, some of these examples are just ridiculous.
|
| 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.
| pmlnr wrote:
| > Negative space is good
|
| 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.
| Daho0n wrote:
| You just proved his point though.
| Adrig wrote:
| You know that a proper website is designed differently at
| different breakpoints right? What you see on a computer
| screen is not designed based on fingers taps.
|
| 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
| [deleted]
| sharkjacobs wrote:
| Gosh, if only there was some kind of curated App Store run by
| Apple which only sold apps which had been reviewed and vetted by
| human beings who could check for this kind of thing.
| Daho0n wrote:
| Since many comments here says how Apple's own apps have the
| same problems, that wouldn't do any difference even if the app
| store was actually curated for quality and not control.
| skohan wrote:
| Why would you? There are a tiny share of small screen size phones
| out there, and often you need a substantially different design
| for a small screen. Basically you are doubling the layout effort
| on your designers and app developers (or let's say 1.3 times
| modifier at least), and those designs have to be maintained as
| well.
|
| 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.
| forgotmypw17 wrote:
| why?
|
| 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?
| mattmanser wrote:
| And then you make it suck for everyone else.
|
| 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.
| afavour wrote:
| > Tiny screen first just makes the experience suck for
| everyone.
|
| No it doesn't. iOS's UI toolkit has numerous tools to allow
| a design to adapt to screen size. There's no reason an
| adjustment for a smaller screen would have any effect on a
| larger one.
| skohan wrote:
| I'm quite sure all the screenshots in the article are the
| result of adaptive designs being broken due to edge
| cases. Constraint-based adaptive designs are great, but
| they have their limits. Unless you have a _very_ simple
| design it is not going to work on every form factor.
| forgotmypw17 wrote:
| >And then you make it suck for everyone else.
|
| In Russian, there is a saying: To a poor dancer, their own
| butt gets in the way...
| bradley_taunt wrote:
| > Mobile first often made the experience suck for desktops.
|
| I'd have to argue that poor design work in general is the
| cause for this. "Mobile first" never meant to neglect the
| desktop experience - designers who do that are just poor
| designers to begin with.
| paulcole wrote:
| > someone posting embarrassing screenshots of one's app
| looking like shit on hacker news
|
| 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.
| forgotmypw17 wrote:
| I don't know about you, but I would be ashamed if something
| I wrote showed up in this article...
| oneeyedpigeon wrote:
| There are more readers of hacker news besides your mom.
| kcmastrpc wrote:
| none of these reasons negate the cost of implementing layouts
| for _literally every device on the planet_. it's not
| practical, nor do the bean counters really care because the
| loss in revenue is very much less than the cost of
| implementation.
| konjin wrote:
| How does any of that make money?
| forgotmypw17 wrote:
| I don't recall claiming that it does...
|
| Although I would think that this type of experience would
| steer one away from using the software or recommending it,
| this eventually reducing the revenue.
|
| But more importantly, it would weigh on my conscience as a
| developer and reduce the quality of my sleep, which to me
| is more important than money by a long shot.
| burntoutfire wrote:
| Wasn't that the original value proposution of the Apple
| products under Jobs? That the overall craftsmanship was
| high and they just didn't feel crappy like their
| competitors'?
| forgotmypw17 wrote:
| it certainly seemed that way to me at the time... i miss
| ios 3.
| skohan wrote:
| When iOS3 was a thing, there was exactly one screen size
| to support at one resolution, and when you went to the
| home screen the app closed so you could count on a
| predictable state every time the app opened. We used to
| measure design elements in number of pixels back then. It
| was a much simpler time.
| Wowfunhappy wrote:
| Important note: the author is actually talking about the 2020
| iPhone SE. There has got to be tons of those + iPhone 8/7/6S's
| still in use.
| skohan wrote:
| Ok I missed that detail - I think it's reasonable to support
| iOS8 size screens given the market share. But the logic holds
| with iPhone 5 and below size screens for example.
| afavour wrote:
| > Basically you are doubling the layout effort on your
| designers and app developers (or let's say 1.3 times modifier
| at least), and those designs have to be maintained as well.
|
| 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.
| kergonath wrote:
| Most of the time, just using the OS-provided controls would
| save these problems before they even happen.
| danielheath wrote:
| Y'all are getting multiple test devices?
| afavour wrote:
| You can't use simulators?
| shadowfaxRodeo wrote:
| Everybody fits into a 1%.
|
| 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.
| skohan wrote:
| Maybe they aren't worth my time. What if I am running a
| bootstrapped startup, and supporting small screens is the
| difference between being able to out-compete my competitors
| on features or not? Just because these tools exist does not
| make it zero effort.
|
| 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.
| shadowfaxRodeo wrote:
| I'm talking from the perspective of the developers. It's
| not that difficult to accomodate people. Following
| principles on progressive enhancement is actually easier
| than not doing it.
|
| If you're looking for a way to out-compete your
| competitors, how about making an app that works for the
| people they've left out?
| skohan wrote:
| > If you're looking for a way to out-compete your
| competitors, how about making an app that works for the
| people they've left out?
|
| You're free to run this experiment, but my guess is that
| it will not be a meaningful differentiating factor
| Kye wrote:
| 1%s talk to other 1%s
| dbg31415 wrote:
| Seeing a lot of issues here that would also be violations of WCAG
| guidelines, and thus be something you could bring an ADA
| accessibility suit against the companies over.
|
| 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.
|
| https://wave.webaim.org/
|
| https://www.deque.com/axe/
| kps wrote:
| I'm no fan of ADA ambulance chasers, but if they start going
| after mobile and web 'designers' my schadenfreude will be
| unermesslich.
| dade_ wrote:
| For me it was Google Maps on my iPhone SE, but that was several
| years ago. The great GUI design for the display size is what made
| the classic iPhone size work. Essentially Apple decided to allow
| apps to be published that were terrible on smaller devices and I
| realized those horses weren't going to get back into the barn.
|
| 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.
| vertis wrote:
| I find it strange that these big companies aren't testing across
| a broad range of devices. I'm a solo freelancer, but the last app
| I built for a client, I actually went out and bought an iPhone
| SE, because that was the minimum spec.
|
| 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.
| cheeaun wrote:
| For Clubhouse app, it seems deliberate tho'. It looks cut-off on
| my iPhone 11 Pro too.
| alexlmiller wrote:
| Yep, this is definitely an intentional design decision, it
| renders that way on all iPhones
| iamben wrote:
| We've had this discussion on HN before and I'll make the same
| point, because this is very similar with responsive websites as
| well. All too often I see designs that don't think about odd size
| tablets, or (as here) phones less than 375 or 414, or whatever
| else.
|
| 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.
| furr wrote:
| X
| kawsper wrote:
| > 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).
|
| 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!
| mgkimsal wrote:
| EXACTLY! And for some businesses, you may never get me back
| to try a redesign. That can also be used as justification -
| "those people won't come back again anyway".
|
| 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. :)
| iamben wrote:
| Yeah, see that loads, very frustrating. "Desktop CVR is
| double that of a tablet, so we don't bother with tablets..."
| skohan wrote:
| > Most of the time it's not much extra effort to make it work
| properly
|
| 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.
| enlyth wrote:
| Most people on HN think UIs should be autogenerated from
| backend code and that peak UI was Windows 95. Anyone worth
| their salt doing some real UI work knows how difficult it is
| to accommodate every arbitrary resolution and aspect ratio.
| iamben wrote:
| To reply to you both - I'm specifically talking about the
| web. I have no experience building apps, so can't comment
| there. But for the web, I'm absolutely happy to argue it's
| not _that_ much more effort.
| ryandrake wrote:
| Whether it's the web or an "app," it should work sensibly
| at any reasonable resolution. It doesn't have to look
| good, or look like the pixel-perfect, happy-path
| Photoshop mocks the UX designer made, but it should
| function. Desktop developers have been doing at least an
| OK job of this for decades.
|
| Yet here we are, where it's a struggle to find an app
| that even sensibly supports landscape mode, or supports a
| user-configured font size.
| skohan wrote:
| Arguably most of the examples given in the post "work
| sensibly". They have some aesthetic issues but they
| should function
| greggturkington wrote:
| Developers that think we should support the iPhone 3 just to
| be nice have not worked on enterprise-level apps. They
| underestimate the cost of the things you describe--design,
| QA, support, etc. It's more than a media query.
| bluedino wrote:
| Here on HN, the username/score/logout links are triple stacked in
| the upper right and I've accidentally hit logout more times than
| I can count. iPhone 12 mini
| iamacyborg wrote:
| I think that depends on your score. I'm on the 12 mini as well
| and those links are spread over two lines for me.
| vulcan01 wrote:
| Problem is, they have one more digit in their karma than
| you...
| skohan wrote:
| Unintentional privilege-based UI ergonomics
| kergonath wrote:
| I always tap the poster's name when up- or down-voting a
| comment on my iPhone XR. HN's UI in general is not great for
| phones (though at least it is simple and effective, which is
| great).
| polyrand wrote:
| I use an iPhone 8 (more or less the same as the SE 2020) and I
| don't find this bugs often, but they are definitely there.
|
| 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.
| forgotmypw17 wrote:
| I bet some developers do, the ones who care about quality and
| user experience.
|
| 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.
| solarkraft wrote:
| > Also, I don't care if the statistics for small devices is less
| than 1%, it's just pure respect for those users.
|
| 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.
| formerly_proven wrote:
| Apple devices are full of dark patterns (to get you to enable
| "upload everything always to iCloud") and bad UX. Even super
| basic stuff like the alarm clock ("bedtime") has become a Rube
| Goldberg-esque nightmare, and good UX elements have been
| replaced with garbage in other places as well. For example,
| setting the time of an alarm requires you to drag in a 5x5 mm
| area for hour and minute, respectively. Not only is that a way
| too small area for a touch interface, but you are also not
| seeing what you are setting it to. Utter garbage.
| bambataa wrote:
| Yes, alarms are really fiddly.
|
| My favourite bit of alarm related UX is that the "dismiss"
| button for alarms and timers are in opposite places.
| tinus_hn wrote:
| Boo hoo. If it bothers you you can just type in the time, the
| large control got replaced by an enormous keyboard.
| ludwigschubert wrote:
| Come on, that's neither helpful nor kind. The controls were
| larger in previous OSes, and now look like they violate
| Apple's own 44pt minimum size target.
| tinus_hn wrote:
| The large control you are talking about was replaced by a
| keyboard. The small control is completely optional.
| aikinai wrote:
| Based on the downvotes flying around here, it looks like
| there are a lot of people who somehow haven't noticed the
| keyboard.
|
| Maybe Apple should have actually made the new tiny time
| display not scrollable so people would be forced to see
| the keyboard?
| wruza wrote:
| I am SO happy they did that. Choosing 4 digits by
| scrolling two pairs was a nice looking stupidest idea
| from the beginning. The fact that you had to wait for
| animation to complete didn't help. And if you didn't wait
| and hit "save", it silently used a former value. I was
| late at least once because of that. I also had few
| predefined alarms to not deal with that crap too often.
|
| I know many ways to improve an old control, and I believe
| Apple has a pile of folks smarter than me who did the
| same, but someone stubbornly retained that and that is a
| win that they finally gave up.
| gh-throw wrote:
| Not only that, the screen's super-ugly. It looks like
| part of some "kitchen sink" demo of UI elements.
|
| Glad it's not just me annoyed every time I open that and
| am reminded how crap it is now.
| kall wrote:
| The worst thing is they have a great wakeup time picker (not
| a generic time picker) for the "Bedtime/Wake Up" feature.
| That this feature, a completely separate alarm clock logic,
| even exists is insane.
| spaetzleesser wrote:
| I use it but it's really weird that there are two
| disconnected alarm clocks.
| e_proxus wrote:
| And the input for timers is yet another custom UI where
| you _can't_ enter the time with a numpad.
| aikinai wrote:
| > For example, setting the time of an alarm requires you to
| drag in a 5x5 mm area for hour and minute, respectively.
|
| 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.
| canuckintime wrote:
| Oh, I didn't even notice the UI change because for years
| I've been exclusively setting all my alarms with (Type to)
| Siri. If I add the Alarm shortcut to Control Center, would
| this numeric keyboard be faster? I wager it'd be more
| reliably/accurate than Siri
| [deleted]
| tannhaeuser wrote:
| Wow, just looked at the new alarm clock in 14.3; it's insane.
|
| 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.
| skohan wrote:
| What's the cutoff? If you have a single user who's running iOS
| 7 and you have to slow down feature development 50% to support
| them, do you have to do that out of respect?
| layer8 wrote:
| You should at least support what the latest devices support,
| e.g. iPhone 12 mini with Display Zoom turned on and large
| fonts. Incidentally, that will also mostly take care of the
| iPhone 5/5S/SE1 screen size.
|
| https://hacknicity.medium.com/how-ios-apps-adapt-to-the-
| vari...
| iagovar wrote:
| I am by myself, I have no money backing my sites, how much time
| spent catering to outliers do you think is reasonable?
| [deleted]
| Davidbrcz wrote:
| Now you can imagine my pain as someone who is visually impaired
| and who had to increase all the sizes to the max to be able to
| read anything....
| chrismorgan wrote:
| On the web, people came up with the concept of "mobile-first",
| meaning that you should first of all make sure everything can
| work with the smallest size, and then add whatever adjustments,
| improvements, extra functionality due to size, _& c._ for larger
| screens after that.
|
| (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.)
| frosted-flakes wrote:
| Something that I do that most people seem to miss is disable
| sticky headers below a certain height. It's super easy to do
| with a simple media query.
|
| 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.
| germ wrote:
| I came here to bring this up, I use a Key2 daily and have
| used a UniHertz Titan for a time. Many applications don't
| handle odd screen aspects very gracefully. (Like Instagram
| opting for zooming stories instead of lettering).
|
| But sticky headers are the bane of my existence.
| kawsper wrote:
| I have an original iPhone SE and I very rarely hit this, mostly
| by more amateurish applications, but it is still very frustrating
| when it happens.
|
| 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.
| RikNieu wrote:
| It's weird that they don't. Every time I push to the istore
| they review it will multiple devices.
| irae wrote:
| I held on to my original SE for as long as I could. I have
| dozens of screenshots similar to the ones on the article, and I
| was getting tired of reporting unusable or hard to use apps on
| small screens.
|
| 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.
| mgkimsal wrote:
| Similar here - I _just_ went up to a 12 mini because the SE I
| had was... well - still worked, but I wanted to 'forward
| proof' myself a bit. I suspect it may not go past iOS 14 (I
| just upgraded - was on 12 for a long time). For things like
| banking, etc, I wanted to know my device will work for the
| next few years, and this is the smallest I can get that still
| is in the ios/apple world.
|
| 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.
| lh7777 wrote:
| > But people wanting 5" phones are apparently in a
| minority.
|
| Let alone 4" phones! I'm still happy with my original SE,
| but the nuisances are starting to add up. I really prefer
| TouchID to FaceID and still use my headphone jack, so
| there's nothing in Apple's current lineup for me.
|
| Fingers crossed that the rumors are right about the return
| of TouchID and the rumors are wrong about the mini being
| discontinued. If they finally dump Lightning in favor of
| USB-C, that'd solve my headphone jack dilemma as I could
| just use USB-C headphones on all devices. I'm not
| optimistic that all of this will come together before Apple
| discontinues support of the original SE, though.
| mgkimsal wrote:
| the headphone jack is a nuisance, certainly. I've
| migrated to AirPods for a lot of stuff, but miss the jack
| and wired headphones. I _did_ just learn about this
| 'reachability' thing in iOS, where you can pull down the
| top half of the screen to the bottom. this makes up for
| some of the stretching I was needing to do, but yeah, in
| so many ways the SE was such a good combination of
| qualities - size, features, etc.
| mro_name wrote:
| I do.
|
| 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.
| DaiPlusPlus wrote:
| > you clearly know the culture behind it is not sustainable and
| has no future.
|
| 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.
| mro_name wrote:
| I'm a big fan of static builds. But cannot understand how a
| 15MB test IPA becomes a 70MB production IPA and takes 300MB
| to upload.
|
| That's IMO software explosion and bloat as Niklaus Wirth
| ranted on decades ago.
| DaiPlusPlus wrote:
| I'm guessing you're using SwiftUI? When you do that, it
| bundles the entire Swift UI library, including all the
| parts you're not using, in your package - I think that's
| because they support runtime-defined UIs which means your
| app _might_ use currently-unused Swift UI components in
| future...
|
| I assume you've also seen this article? https://developer.a
| pple.com/documentation/xcode/reducing_you...
| mro_name wrote:
| No SwiftUI, backwards compatible to iOS 9.0, check the
| source if interested https://github.com/mro/ShaarliOS
|
| Thanks for the link, I doubt it applies.
| ruph123 wrote:
| One thing that really annoyed me who always preferred the smaller
| iPhones like the SE: When Apple updated their Music app to make
| everything super big and bloated it basically got unusable.
| Especially for classical music where you could not see past the
| long name of the symphony to see which movement it was. And even
| while playing you had to wait for the running text to reach the
| important part.
|
| 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.
| bouke wrote:
| Yeah that's what bothering me as well. Seems to be happening
| everywhere though, reduced information density and increased
| whitespace and fonts. So as we're all buying something with
| bigger screens, we still keep loosing real estate.
| furr wrote:
| No one designs for IE6 anymore either. If it costs a lot more to
| support a platform that doesn't bring in money, it would be a
| terrible business decision.
|
| "This is losing is a LOT of money, but it would be a nice thing
| to do" is not realistic.
| hawos wrote:
| The iPhone SE 2020 is hardly comparable to IE6.
| Nailgun wrote:
| With all of the annoyances that Safari ios provides, I
| genuinely consider it the spiritual successor to IE.
| dreamer7 wrote:
| This is not true. We still use my iPhone SE with a 4" screen as
| the primary testing device for our iOS app -
| https://apps.apple.com/gb/app/vendi-buy-sell-verified-phones...
|
| 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.
| mgkimsal wrote:
| Just upgraded from SE to 12 mini, but was hitting issues with
| testing a web app on my SE. I'd also kept it on ios 12, and all
| new 'large' devices were auto upgraded to iOS 14... hilarity
| ensued. We hit weird bugs that only showed up on iOS 14.
|
| 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.
| jiofih wrote:
| Not true for you, true in general - "nobody" being just
| hyperbole.
| sebastien_b wrote:
| My favorite so far is my banking app asking a security question,
| with it being in a single-line field that truncates right at
| where it asks what information to provide.
|
| In fact, I think I'll upload it somewhere for this author to add
| to the list.
| rojcyk wrote:
| Wow, lots of assumptions or designer blaming in this thread. Not
| that it is unexpected, but it still hurts since it is not as
| black and white as people here draw it to be. Let me give you my
| perspective as a designer who spent quite a lot of time on this
| topic.
|
| 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.
| brundolf wrote:
| Not supporting people jumping to bad conclusions or being
| toxic, but it's worth pointing out the author said this is the
| _2020_ SE. Which is to say the body of an iPhone 8, not a 5.
| Which is to say roughly the same size as all iPhones before the
| X (and larger than the brand-new Mini!). That 's not <1% of
| iPhone users, especially considering how long iPhones last. My
| parents are still doing fine with their 6Ses.
|
| Edit: I was wrong about the mini being smaller; it's somewhat
| larger than the 8/SE
| rojcyk wrote:
| I know that the author is speaking about SE 2020, but the
| issues listed in the article (at least some of them) to me
| seemed like bugs rather then deliberate design decisions.
|
| 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).
| derefr wrote:
| > Which is to say roughly the same size as all iPhones before
| the X (and larger than the brand-new Mini!)
|
| This isn't about physical size, though; it's about screen
| resolution and aspect ratio.
|
| > iPhone 12 mini: 2340x1080 @ 476dpi
|
| > iPhone SE 2020: 1334x750 @ 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.
| brundolf wrote:
| My mistake; I made the assumption the Mini would be smaller
|
| Still, the point remains that lots of people are rocking an
| iPhone older than the XS (the 9 came out at the same time
| as the X) and would have these same problems
| derefr wrote:
| You're correct; I myself still have an iPhone 8. But I
| tend to think of problems I experience on my iPhone 8 as
| "being gradually left behind by an ecosystem that has
| moved on", rather than as "not being supported." (Like
| how it feels to try to use Windows 8.1 in 2021. It's not
| _technically_ End-of-Life'd... but do third-party devs
| even mention it on download-page compatibility lists any
| more?)
|
| With an iPhone 8, I know I'm the one "at fault" at this
| point for sticking with this device, stuck on the wrong
| side of an inflection point in screen size/resolution
| from the introduction of "edge" displays all across the
| ecosystem. I might expect Apple themselves to tune their
| first-party apps for my device for as long as they claim
| to support it; but I don't expect App Store devs to do
| so. They're shipping cross-platform designs on a tight
| schedule, for screens that are almost-exclusively twice
| as large and high-resolution as mine.
|
| The iPhone SE case is more concerning, because it's still
| for sale at the Apple Store. This means Apple is claiming
| it's fit-for-purpose for at least some use-cases. (Maybe
| that claim doesn't extend to "running apps from the App
| Store", though.)
|
| I feel like, at this point, the SE is almost the same as
| the iPod Touch--it's not a thing you get to take
| advantage of the Apple app ecosystem; it's more a thing
| you get to either use Apple's first-party apps for basic
| use-cases, or because it's a very cheap automated
| development smoke-test deploy target (roughly the iOS
| equivalent of a Mac Mini.)
| Kwpolska wrote:
| The iPhone SE 2020 and the iPhone 8 have the exact same
| screens. So it's not your fault, it's the lazy
| developers' who can't be bothered to sit down with the
| Simulator, click through the app, and fix at least the
| most basic glitches.
|
| > The iPhone SE case is more concerning, because it's
| still for sale at the Apple Store. This means Apple is
| claiming it's fit-for-purpose for at least some use-
| cases. (Maybe that claim doesn't extend to "running apps
| from the App Store", though.)
|
| Nah, Apple's marketing copy [0] says:
|
| > We put the brains of iPhone 11 Pro in the body of
| iPhone SE. Our A13 Bionic chip is built for speed. So
| everything feels fluid, whether you're launching apps,
| playing the latest games, or exploring new ways to work
| and play with augmented reality.
|
| (Also, a smartphone without third-party apps is quite
| useless for most users.)
|
| [0]: https://www.apple.com/iphone-se/
| Kwpolska wrote:
| It's not really useful to talk about DPI/PPI of the screen
| in an iPhone. The 12 mini uses 3x scaling, the new SE uses
| 2x. According to [0], the logical resolution is 360 x 780
| for the 12 mini and 375 x 667 for the SE. Sometimes, Apple
| used tricks such as running the OS at 3x and then
| downscaling it a little [1]. That said, since the SE is
| meant to be a hardware upgrade with the old size/form
| factor, some users would not be happy seeing smaller text
| on the new phone (compared to their old iPhone 6/7/8).
|
| [0] https://iosref.com/res [1]
| https://www.paintcodeapp.com/news/iphone-6-screens-
| demystifi...
| geniium wrote:
| Some are clearly mistakes from the builders, others are features.
| Come on stop bitching around and pick up some real apps.
| bondolo wrote:
| The same problem exists on Android. I chose one size larger
| system font because I like to be able to read the screen with my
| glasses off and _safely_ read the screen while I am driving.
|
| 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.
| some1else wrote:
| Switching the language to German also has interesting effects.
| FractalHQ wrote:
| I blame the CSS spec for not giving us responsive text sizes.
| It's 2021, the Internet was literally built on text, and we still
| can't have text that automatically grows and shrinks based on the
| size of its parent. We can go to Mars, but we can't have
| responsive text. Blows my mind.
| dep_b wrote:
| I used an iPhone SE 2016 until recently and I never really ran
| into situations where an app was unusable because of this. Also a
| lot of these design mistakes could be described as "reinventing
| UINavigationBar or UITabBar, crappy".
|
| 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.
| fortran77 wrote:
| I can understand Clubhouse. They don't care about people with old
| small phones--they're not influencers.
|
| 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.
| williesleg wrote:
| Fuck you, I do, I have tiny hands. This post is sizeist, you are
| hate speech against tiny hands
| brundolf wrote:
| Wait this is the _2020_ SE? I.e. an iPhone 8, not even the older
| one? I 'm even more surprised because the Mini exists now as a
| first-class citizen. Apple has historically been good about
| making sure all approved apps provide a good experience on all
| the devices that they should; I wonder why they've dropped the
| ball on this one
| HumblyTossed wrote:
| How do these apps get by Apple's highly regarded, industry
| leading, 30% worthy, approval process?
| PaulHoule wrote:
| The more I study UI systems the more I like Win95.
| tinus_hn wrote:
| A big part of the problem is people just not following the
| guidelines. If you have a toolbar with buttons that have labels,
| it's not going to fit. But if you're following the guidelines,
| you don't have labels and it fits.
|
| 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.
| simias wrote:
| You make good points but IMO that's an Apple problem first and
| foremost, not an application designer problem. If an
| application doesn't follow the guidelines and breaks on some of
| the phones supported by the app store, then Apple should tell
| the application makers to fix it lest the app be removed.
|
| 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.
| tinus_hn wrote:
| There's a point there but it is a difficult balancing act.
| Some of the largest third party apps, like Google Maps,
| feature the Google Material Design that is alien on iOS.
| There is no way to force Google to use an iOS design. Would
| it be a smart move from Apple to ban Google Maps from the
| iPhone?
| httpsterio wrote:
| Why? What if you're developing some app where you want to
| divert from the guidelines, you should be able to do that.
| Guidelines are just that, they're not rules.
|
| 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?
| simias wrote:
| If not following the guidelines makes your app hard to use
| or glitchy on some of Apple's lineup, I don't see why you
| wouldn't expect Apple to reject the app. This reflect
| poorly on Apple because it makes it look that some of their
| devices are 2nd class citizens within their ecosystem.
|
| They should follow the guidelines when not doing so causes
| usability issues. If your games is usable on all devices
| then obviously there's no problem.
| dmckeon wrote:
| Alternately, Apple could choose a different and non-binary
| way of curating apps. An app store with 4 or 5 scales of 0 to
| 9 scores: UX, privacy, cost/benefit, user reviews, etc. would
| be a lot more useful to me than a store with x00,000 apps all
| in an undifferentiated pile.
|
| 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.
| faitswulff wrote:
| I would find this a more compelling argument if some of the
| apps in question weren't from Apple themselves (Apple
| Shortcuts, Apple TV). If Apple can't get it right, then how can
| we expect anyone else to?
| tinus_hn wrote:
| The Apple TV example looks a bit disingenuous, the huge black
| space normally holds an image promoting one of the shows.
| That's why it has so much space. I don't know why in his
| situation the header is empty but that has nothing to do with
| layout on small screens. You could complain the promotional
| image is too large but it's really obvious you can scroll
| down to reveal the rest of the content and I don't think
| anyone is contesting the conclusion that yes, a small screen
| fits less content without scrolling.
|
| 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!
| djrogers wrote:
| > But on your device you can get to these icons as well,
| try to find out how!
|
| Uhh, I scrolled just like the emoji keyboard (which every
| iPhone user has figure out) and it worked? There are also
| partial icons at the edge hinting of more to the right.
| This wasn't/isn't exactly hidden.
| tinus_hn wrote:
| To me it was completely non obvious; I know that there
| are much more emoji than shown in the first view, there's
| category buttons that suggest there are more and the
| icons are layed out in such a way that most of the time
| you see half of an icon on the right, which suggests
| there's more to find.
|
| For this folder design where for the icon choice (which
| appears rather superfluous by the way) I have no idea how
| much icons there are supposed to be in the grab bag the
| developers provided, there's no categories and they are
| layed out as a vertically scrolling list with icons
| neatly arranged flush against the right edge.
| e_proxus wrote:
| Completely agree. If you change the category it doesn't
| even scroll to the new icons, it just instantly replaces
| the existing ones making it appear as if those are the
| only ones existing. It's only if you actually drag your
| finger over the icons that you get any indication there's
| more.
|
| It's even worse, tapping a category brings you to the
| first icons in that category. There's no way to find the
| default set (which seems to be somewhere in the middle of
| "objects" because that's where the folder icon is).
|
| And there's a bug too (at least on my 12 Pro). When you
| scroll past the category border the category button jumps
| back and forth between the two categories as if it can't
| decide which category you're viewing right now.
|
| The whole icon picker is very non-standard and feels very
| un-Apple.
| throw0101a wrote:
| > _If Apple can't get it right, then how can we expect anyone
| else to?_
|
| Just because a doctor smokes does not mean that them telling
| you that " _smoking is bad and that you should stop_ " is
| incorrect advice:
|
| * https://yourlogicalfallacyis.com/tu-quoque
|
| * https://en.wikipedia.org/wiki/Tu_quoque
| baxtr wrote:
| That's the core problem. Is there a specialized service you can
| submit your app to to test for guideline adherence?
| tyfon wrote:
| The custom buttons without labels are a pet peeve of mine
| actually. I can never guess what the buttons do when they only
| have pictures and each app use their own icon set.
|
| 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 :)
| tinus_hn wrote:
| But if you consider the app in the example, the 'Globe'
| carrier app, you'll almost immediately see that the problem
| is that it is a confusing navigational spaghetti that is
| designed to force users to explore an app littered with
| 'promotional offers'.
|
| 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.
| Nextgrid wrote:
| The main problem here isn't that apps/services don't follow
| the guidelines per-se but that more and more software is
| designed _not_ to solve a particular problem efficiently
| and get paid honest money for that effort but to waste as
| much of the user's time as possible showing them "offers".
| The industry calls this "engagement" and a large chunk of
| people's salaries and careers (including mine at the
| beginning) is based on that.
| tinus_hn wrote:
| This is kind of kicking an open door but the guideline
| explicitly is to design your app 'to solve a particular
| problem efficiently'
| mnahkies wrote:
| For software that you only occasionally use custom icons with
| no labeling is a real productivity killer.
|
| 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
| frosted-flakes wrote:
| Android already has that standard. Long press almost always
| brings up a tooltip.
| mnahkies wrote:
| I guess much like aria attributes it varies based on the
| quality of the product/motivation of the business.
|
| I just tried one of my banking apps and a Reddit client
| and found neither provided tooltips - perhaps they
| thought those particular icons are too self explanatory
| or perhaps they didn't bother/used a cross platform tech
| that didn't make it easy.
|
| Actually even on Google maps I don't seem to get tooltips
| for the fab icons for center map / directions.
|
| I do remember this being a thing but it feels like it's
| fallen out of fashion.
|
| Pixel 3a / android 11
| bartvk wrote:
| You say "even Google Maps", and something surprised me
| when I explored their SDK. So I don't know about Android,
| but the Google Maps SDK on iOS does not use the iOS
| widgets. They draw everything themselves. Integrating
| Google Maps is a pain, because standard layout techniques
| don't work (for example for labels on markers). The whole
| thing felt really ancient.
|
| It doesn't surprise me in the least that it didn't work
| as expected.
| chrismorgan wrote:
| On Android, by convention you can long-press icon-only
| toolbar buttons and the label will show as a tooltip. Non-
| native apps (fuzzy definition) lack this far too often, but
| it's always worth trying. Not sure if iOS has something like
| this.
| tinus_hn wrote:
| What is the advantage of this? If you can long press a
| toolbar button to get a label that states what the button
| is for, it's easier to just tap the button and see what it
| is for.
| jkaplowitz wrote:
| What if you're not sure if you want to trigger the effect
| of the button?
| e_proxus wrote:
| Unless I'm missing something we're talking about a tab
| bar? The worst thing that can happen is that you switch
| to that tab. Switching tabs should never be destructive.
| chrismorgan wrote:
| Toolbar, not tab bar. You will regularly get mutating
| actions there, though any mutating actions _should_
| either prompt or be undoable.
| tyfon wrote:
| Yeah I used to be on android, I had less issues there. This
| is my first iPhone (version 11) and I'm not sure if I will
| keep with apple. The tracking of google is bothering me big
| time though so I might just accept a worse user experience
| to avoid that.
| thegeomaster wrote:
| I have to pile on the rant - OK, maybe the screen real estate
| is precious and you don't have space for buttons - but allow
| me to somehow discover what they do!
|
| 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!
| gregoriol wrote:
| Hover is quick and natural on desktop, but why would you
| want to long press a tab bar button on mobile? That's long
| and unnatural. Just press it (quick and natural) and see
| what it does!
| spaetzleesser wrote:
| "Just press it (quick and natural) and see what it does!"
|
| And if it deletes something you wanted to keep you have
| learned a valuable and lasting lesson :)
| gregoriol wrote:
| If a button does that kind of critical action, it better
| have a better and much more visible explanation +
| confirmation than just a hidden hover tooltip
| tinus_hn wrote:
| At least it's supposed to be red
| mnahkies wrote:
| Hmm I wonder if this button sells all my shares at a
| steep loss, guess there's only one way to find out
| m-p-3 wrote:
| Some Android Material Design guidelines (which are often not
| followed..) specifies that you should be able to press-hold a
| button and have a popup label shows up to describe its
| function.
|
| 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.
| homero wrote:
| Ob Android, long holding a button usually tells you what it
| does
| hanniabu wrote:
| > If you use these smart hamburger menu overlay or scroll
| controls, they look bad on untested devices. Don't use
| hamburger menus.
|
| What is a good alternative to a hamburger menu? I can't think
| of anything that wouldn't have the similar issues.
| tinus_hn wrote:
| The alternative to hamburger menus is to design your app
| navigation so you don't need them.
|
| 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.
| atomicUpdate wrote:
| > Use the settings app for settings, so they don't clutter
| your app.
|
| I'm glad most app don't do this, except for where they have
| to for notifications, etc. It's really unintuitive to go to
| another app to adjust settings for an app you're already
| in.
| SiVal wrote:
| Exactly. Oh, you want to do something right here? Well,
| we could give you a menu right here of all the things
| that are relevant to this exact context--which was, you
| recall, the original "discoverability" advantage that was
| claimed to make a GUI better than a CLI. But, no, that
| would mean a hamburger menu, which "they say" is bad.
|
| Instead, superior designers will show very little and
| explain nothing so the screen can look fabulous. If Apple
| has taught us anything, it is that fashionable appearance
| matters most. Users will just have to figure out that
| they need to leave this app, go open another app,
| navigate a few screens into it, see if there is an entry
| for this app, enter it, and scroll around hoping to see
| something in the master list that looks like it might be
| relevant to what you needed in the context that other app
| was in.
| e_proxus wrote:
| You can actually hotlink directly to the Settings page
| for your app (e.g. Slack does this in their settings).
| [deleted]
| snarkyturtle wrote:
| Icons with labels are best practice for accessibility.
| tinus_hn wrote:
| No, for accessibility icons have titles that are not on
| screen yet are read out by the screen reader.
| frosted-flakes wrote:
| Accessibility is not just for people who use screen
| readers. It's for everyone, including you and me.
| silvestrov wrote:
| > you [...] have labels, it's not going to fit
|
| or you have to localize in German.
|
| Words don't translate 1:1 into another language. Sometimes
| labels are much longer in other languages.
| brundolf wrote:
| With how stringent Apple's review process and focus on user
| experience are, I'm surprised these apps got approved for the
| App Store at all in this state
| SebastianKra wrote:
| Out of those apps, only 2-3 use Material Design. MD seems to
| attract a lot of poor copies, misunderstandings and projects
| that pay lip service to it, but have only superficial
| similarities.
| sangnoir wrote:
| > 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[...]
|
| 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.
| valuearb wrote:
| Let's not get me started on tiny tap areas. Virtually every
| graphic designer I have ever worked with is ignorant of Apples
| 44 by 44 point recommendation.
|
| 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.
| bartvk wrote:
| What's funny is that Apple themselves are not helping.
|
| 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) })
|
| The .imageScale modifier is set to the largest! That button
| is abysmally small. You can use padding of course, and that's
| what I do. I suspect I'm missing something, but I can't see a
| reason why .large gives me an unusably small image.
| ryandrake wrote:
| Yep, too many UX professionals spend 95% of their energy on
| the look and maybe 5% on the feel.
| closeparen wrote:
| In my experience, designers work in Figma. Then they play
| with and give feedback on what the mobile engineers
| actually built, same as the rest of us. Their critiques
| become backlog items and it is ultimately up to the PM
| which of them to prioritize and whether they are launch
| blockers. They may very well be fanatical about feel, but
| at the end of the day there is a long line of people who
| want mobile engineers to change things and they will not
| always be able to skip to the front. With visuals, on the
| other hand, they provide the engineers with detailed
| layouts and assets, so their intentions are almost always
| carried out precisely.
| notSupplied wrote:
| I agree with this. I think design has a serious principle-
| agent problem.
|
| A beautiful design will live forever on your personal
| portfolio, but no one can directly experience usability
| there. So designers are fighting competing incentives to do
| what's right for this product, and what's right for their
| professional image. I think this is partly the cause for
| trend toward stylish-but-less-useable.
| ghaff wrote:
| Furthermore, many designers--at least those developing
| mobile apps etc.--are young people with good eyesight.
| There's also a general fashion element but I suspect this
| is one factor in the popularity of thin, small fonts
| today. (TBF, there's also a general trend towards simpler
| logos and the like which render well on mobile.)
| valuearb wrote:
| Don't get me started on font sizes. I'm older now and
| theee designs hurt my eyes.
|
| And on iOS if you use the system font and standard
| styles, text automatically adjusts to accessibility
| settings. So I always suggest that but every designer
| wants to "make their mark" with custom fonts that either
| font work with accessibility or require a bunch of extra
| coding that the product owner never gives time for.
| bajsejohannes wrote:
| I'm curious if even Apple follow the guidelines. It has been
| way too long since I read them, but I remember the minimum
| button size being quite large. A while ago, the pull up menu
| (with camera/light/volume/airplane mode/etc) was redesigned. As
| part of that the play/pause/skip buttons became so small that
| my iPhone SE frequently does something other than my intention.
| jonas21 wrote:
| In the first example (Clubhouse), it's a deliberate design
| decision to show the edge of the cards on the left as an
| affordance that you can swipe to get back to the main content.
|
| 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.
| riantogo wrote:
| I'm humbled by the effort required to create good UI that works
| well everywhere. That is why I decided to use stock bootstrap
| with minimal changes. The designer tried to customize it (causing
| flaws on certain screen sizes). I had them roll it all back to
| strict use of bootstrap classes. I'm okay with the limitations
| imposed. Atleast it is functional everywhere.
| tannhaeuser wrote:
| Unfortunately, that includes Apple's own apps on 6s/7/8 iPhones.
| For example, the new [double-swipes right] "app library" or "app
| mediathek" or what it's called in your language overflows into
| the bottom. Or in iMessage, the context menu on a photo.
| Black101 wrote:
| I was using my computer on a ~50in TV and sites were showing me
| their mobile version... there's a lot broken (it was not that low
| of a resolution).
|
| Maybe the real question should be, why is software broken so
| badly?
| jariel wrote:
| The author made the wrong conclusion.
|
| Most of these are either by design or just UI bugs or poor
| design.
| bambataa wrote:
| I get frustrated on my iPhone SE by apps that have me fill in a
| field but then no "done" button to close the keyboard. Between
| the keyboard and the app's overly large heading, there's barely
| any space to click anything else to close the keyboard without
| triggering something else. Cronometer is bad for this.
| aaronbrethorst wrote:
| I do all of my iOS development on an iPhone SE simulator. No, not
| the iPhone SE 2020, the _original_ one.
|
| Scaling designs up to an X class device is much easier than
| trying to scale down.
| jbverschoor wrote:
| Apple isn't checking apps anymore. They used to be pretty anal
| about many things. Unfortunately, even their own apps aren't
| checked completely anymore
| nottorp wrote:
| ... and i don't view the second iphone se as small even.
|
| I have people in my family rocking the original iphone se because
| THAT is small enough for them.
| jdmoreira wrote:
| I'm an iOS developer. The problem is multifaceted. Designers have
| completely disregarded these devices. They design for the latest
| and greatest in Figma and when we implement their design and
| eventually run it on an iPhone SE of course everything is super
| crammed, labels overflow into each other, you can't see some
| text, things just generally look bad, etc... etc...
|
| 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.
| ryandrake wrote:
| This is not a mobile device problem or an iOS problem. This is
| a competence problem with your designers. The role of a UX
| designer is not to produce a portrait-only, default-font-size-
| only pixel-perfect picture on three popular phone screen sizes,
| and throw it over the fence for developers to develop and not
| ask questions. Designers must ask, what if the user prefers
| landscape mode? What if their fonts need to be larger for
| accessibility reasons? What if they are on an odd sized phone,
| or even one we haven't even seen yet?
| daniellarusso wrote:
| Exactly.
|
| It is just mediocre design.
| tonetheman wrote:
| To take the opposite tack.
|
| 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.
| mucholove wrote:
| My font size is set to a fairly large size.
|
| 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...
| prox wrote:
| A peeve of mine is the constant need to throw popups when
| you've just installed an app. "Want notifications? Please like
| us! Follow us on X" and the list goes on... Whatever happened
| to "don't stop the proceedings" for user friendliness? If your
| app behaves like it has attachment issues, I don't want it.
| ectopod wrote:
| This isn't new. Back in 1992 you had two choices for DPI in
| Windows 3.1 but many applications couldn't cope with the larger
| setting.
|
| I used it anyway because 1024x768 on a 14" CRT was unreadable
| with regular fonts.
| alisonkisk wrote:
| iPhone and Android. So many apps have text they don't fit
| within their colored backgrounds, and overflow or get cut off.
| jbverschoor wrote:
| It's not just small screens. If you enable "Zoom", the aspect
| ratio changes, and most apps don't handle that properly. Same
| with following the global text-size settings
| StrangeOrange wrote:
| That Clubhouse UI is the way it is generally. It is that way on
| my iPhone 8+ anyway.
|
| Best to check your hypotheses before writing them down as facts.
| mabedan wrote:
| Try using apps with iPhone SE in German language. It's rare
| occasion to be able to see a label fully displayed in the ui
| brianzelip wrote:
| I start design at iPhone 5 (320px wide in portrait orientation).
| However, it will often work down to 300px or less.
| evolveyourmind wrote:
| The real problem is that designers usually focus on a single
| device without considering any other screen size
| BelleOfTheBall wrote:
| This is in part because it's assumed that everyone will get the
| cool new model once it's out and, in particular with iPhones,
| there's a marketing push to acquire newer models, lest yours
| feels outdated or stops being supported by the company.
| Xenoamorphous wrote:
| It's particularly painful in the EU and with a 2016 iPhone SE
| like me. I've come across too many GDPR dialogs where it's
| impossible to click any of the buttons.
| mouzogu wrote:
| There's too many devices and screens/orientations to handle. It's
| a hassle.
|
| Mobile-first was an approach to fix this but pragmatism usually
| dictates otherwise.
| ArkanExplorer wrote:
| iPhone 7, iPhone 8, iPhone SE 2020 all share the same screen size
| and resolution - so isn't this a problem on those other devices
| as well?
|
| 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.
___________________________________________________________________
(page generated 2021-03-20 23:01 UTC)