There's a critical flaw in trying to erase boundaries here. The differences between mobile, tablet, desktop, etc. are not about screen size - that matters, but people resize a browser window, too. Make your stuff so it'll show on as wide a span of sizes as possible, and you'e golden.
No, it's mainly about input methods. Touch screen input is and will remain very distinct from mouse input, and a physical keyboard is a far different affair than a software keyboard on a touch screen. Touch screen input means no hovering, no cursor hinting, and far less precision in put, meaning far larger inputs are required - which will irritate a mouse user! No hardware keyboard means no key short cuts, no tab completion, none of the features we routinely use keys for - but software keyboards usually have predictive text, with varying accuracy, and built-in emoji capability, both of which their uses will expect to be able to use.
Then there's browsers and OS'es response to custom input types - looking at HTML inputs, the 'date' and 'time' inputs come to mind a great deal here. On Android, for instance, tapping an input field of type 'time' gives you a fancy clockface style dialog where you select a time. On a desktop Chrome, however, you just have an up and a down button to increment or decrement time. Meanwhile, 'date' inputs show, respectively, a nice calendar picker, and an ugly box that looked like it fell out of a 1990's accounting system. Consistency is, apparently, for chumps? But that's our problem now, as the developers.
From a UX perspective, there are huge differences between touchscreen devices and desktop devices. And I thank my lucky stars that the Windows 8 era hybrid devices haven't taken off more than they have, TBH.
I don't disagree about different input/output methods sometimes needing different design. However, sometimes this ends up meaning that certain capabilities are only available on one platform or another. For example, right-click type menus and searching within text are usually unavailable on touch interfaces (or at least not obvious). Providing or emphasizing those capabilities is a choice that developers or designers could make, in a way that's suitable to a given platform.
This is what I mean, though. It's a rare designer who can make all options available on both platform types. So it may be best to design the two apart, each focusing on making its best UX available.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There's a critical flaw in trying to erase boundaries here. The differences between mobile, tablet, desktop, etc. are not about screen size - that matters, but people resize a browser window, too. Make your stuff so it'll show on as wide a span of sizes as possible, and you'e golden.
No, it's mainly about input methods. Touch screen input is and will remain very distinct from mouse input, and a physical keyboard is a far different affair than a software keyboard on a touch screen. Touch screen input means no hovering, no cursor hinting, and far less precision in put, meaning far larger inputs are required - which will irritate a mouse user! No hardware keyboard means no key short cuts, no tab completion, none of the features we routinely use keys for - but software keyboards usually have predictive text, with varying accuracy, and built-in emoji capability, both of which their uses will expect to be able to use.
Then there's browsers and OS'es response to custom input types - looking at HTML inputs, the 'date' and 'time' inputs come to mind a great deal here. On Android, for instance, tapping an input field of type 'time' gives you a fancy clockface style dialog where you select a time. On a desktop Chrome, however, you just have an up and a down button to increment or decrement time. Meanwhile, 'date' inputs show, respectively, a nice calendar picker, and an ugly box that looked like it fell out of a 1990's accounting system. Consistency is, apparently, for chumps? But that's our problem now, as the developers.
From a UX perspective, there are huge differences between touchscreen devices and desktop devices. And I thank my lucky stars that the Windows 8 era hybrid devices haven't taken off more than they have, TBH.
I don't disagree about different input/output methods sometimes needing different design. However, sometimes this ends up meaning that certain capabilities are only available on one platform or another. For example, right-click type menus and searching within text are usually unavailable on touch interfaces (or at least not obvious). Providing or emphasizing those capabilities is a choice that developers or designers could make, in a way that's suitable to a given platform.
This is what I mean, though. It's a rare designer who can make all options available on both platform types. So it may be best to design the two apart, each focusing on making its best UX available.