4 ms·

- Having seen enough of how different (and sometimes impossible to fix) it is to develop across even just Android and iOS, I am currently of the opinion that fu

by ceejay 10y ago

- Having seen enough of how different (and sometimes impossible to fix) it is to develop across even just Android and iOS, I am currently of the opinion that future web UI should be moving toward completely decoupling form fields from the native HTML Form Inputs. A few examples: - Alot of people will probably see the fancy animation in Angular Material 'placeholder' on text fields transition into a floating label when it receives focus as not having much functional purpose. On mobile, given space constraints, I feel it's a real innovation, not just sugar. - Because of the differences (and discrepancies in behavior) between the 'time' input field on both mobile web platforms I went out of my way to build an analog clock face to bring consistency between platforms and more reasonable behavior. Some of it is probably personal preference, but I think having an analog clock face is objectively better from the perspective that you can set time (at least how I designed mine) with 2 taps (and maybe one more to toggle the meridian). Compared to how iOS and Android HTML inputs work natively it may not be much of a difference in the eye of the user, but I think there is a lot of room for improvement in this space. - "tabbing" behavior between fields on a form are different, and because of a strange design decision on Apple's part, it's impossible to reconcile. There are 2 "tabbing" arrows on the iOS keyboard which send no events to the DOM. - I could probably go on but hopefully it paints a picture of how difficult it is to create a consistent experience easily across these platforms. Not to mention that I get the feeling the number of mobile browser / web-view options (and thus differences that may or may not be reconcilable) will just continue to grow. By decoupling the UI form input component from the native elements it will bring more consistency to the user. I don't know if Angular Material (or other material design libraries) have a goal currently to decouple from the native elements completely, but they feel like they're the furthest along in this respect.

eudes 10y ago
Thank you for your explanation, it actually brings up several points we didn't know about. That said, one of the main reasons to use native form controls is accessibility, which is one of our biggest priorities. Maintaining accessibility with non-semantic elements is feasible, but we would end up with bugs fully breaking it, as opposed to a slightly worse UX on some mobile devices. More importantly, we strongly believe that aiming for the exact same experience across all possible screen sizes is a mistake. If you are trying to write an application that feels natural on both desktops and mobiles, you will need to design two different interfaces, different patterns and probably different amounts of data displayed at once. Your time input example is very relevant: on desktops, you have easy access to a keyboard and a mouse, but sliding UI elements can be a drag. On phones, keyboards are painful to use, but swiping with your finger is extremely natural. Sticking to the native interface (or a customization of the native interface) in both cases will lead to an apparently "inconsistent" behavior, but a user experience that's more enjoyable on both sides. This is the choice we have made after quite a bit of research, and you can see it for instance on our responsive navigation patterns: we support 3 levels of navigation across the app on desktops, but we limit to 2 on mobiles.
- ceejay 10y ago
  Thanks for the feedback. I agree accessibility is an important priority. I generally allow for fallback to a native element in a user preference option if there's any question about that. Especially with custom components. I've always had to lean on ARIA, which I believe Angular Material components are compliant. As far as I know, since projects I work on generally don't have resources to employ specialists in accessibility. I am interested in this space, though, and would love to start seeing more individuals online blogging / sharing their experience with the current state of accessibility on the web so smaller teams can also learn to accommodate them in a more precise way. I agree it would probably be a major pain point to have to re-design the wheel. I'm hopeful the "componentization" of the web will help here. Apple and Google probably have little incentive to distill their platforms to normalize the development experience, so I see decoupling the components almost as the only way web developers will be able to overcome these things. I agree with the point about designing different experiences across screen sizes also. It definitely has to be considered on a case-by-case basis, but I've seen some interesting design choices which significantly reduce this pain point. I've almost convinced myself at this point that almost all cases (app types) can be handled by some clever flexbox manipulation and some reasonable media query break points.

by ceejay 10y ago

eudes 10y ago

Thank you for your explanation, it actually brings up several points we didn't know about. That said, one of the main reasons to use native form controls is accessibility, which is one of our biggest priorities. Maintaining accessibility with non-semantic elements is feasible, but we would end up with bugs fully breaking it, as opposed to a slightly worse UX on some mobile devices. More importantly, we strongly believe that aiming for the exact same experience across all possible screen sizes is a mistake. If you are trying to write an application that feels natural on both desktops and mobiles, you will need to design two different interfaces, different patterns and probably different amounts of data displayed at once. Your time input example is very relevant: on desktops, you have easy access to a keyboard and a mouse, but sliding UI elements can be a drag. On phones, keyboards are painful to use, but swiping with your finger is extremely natural. Sticking to the native interface (or a customization of the native interface) in both cases will lead to an apparently "inconsistent" behavior, but a user experience that's more enjoyable on both sides. This is the choice we have made after quite a bit of research, and you can see it for instance on our responsive navigation patterns: we support 3 levels of navigation across the app on desktops, but we limit to 2 on mobiles.

ceejay 10y ago
Thanks for the feedback. I agree accessibility is an important priority. I generally allow for fallback to a native element in a user preference option if there's any question about that. Especially with custom components. I've always had to lean on ARIA, which I believe Angular Material components are compliant. As far as I know, since projects I work on generally don't have resources to employ specialists in accessibility. I am interested in this space, though, and would love to start seeing more individuals online blogging / sharing their experience with the current state of accessibility on the web so smaller teams can also learn to accommodate them in a more precise way. I agree it would probably be a major pain point to have to re-design the wheel. I'm hopeful the "componentization" of the web will help here. Apple and Google probably have little incentive to distill their platforms to normalize the development experience, so I see decoupling the components almost as the only way web developers will be able to overcome these things. I agree with the point about designing different experiences across screen sizes also. It definitely has to be considered on a case-by-case basis, but I've seen some interesting design choices which significantly reduce this pain point. I've almost convinced myself at this point that almost all cases (app types) can be handled by some clever flexbox manipulation and some reasonable media query break points.