3 ms·

> "keyboard/mouse-oriented UI and ergonomics and a touch-oriented UI and ergonomics cannot successfully co-exist" I'm not sure that's necessarily true. Are you

> "keyboard/mouse-oriented UI and ergonomics and a touch-oriented UI and ergonomics cannot successfully co-exist" I'm not sure that's necessarily true. Are you aware of Mac Catalyst? https://developer.apple.com/mac-catalyst/ https://developer.apple.com/mac-catalyst/ (Of course, the user experience will always be somewhat different on a small phone screen compared to a big Mac screen. But that doesn't mean you can't build an app that works well on both from one code base. And certainly an iPad app is not all that different from a Mac app.).

1123581321 7y ago
Again, you are thinking of porting a touch app to a non-touch device when the issue is that good touch and non-touch UI and ergonomics cannot co-exist on the same device. And I am familiar with Catalyst. I think Catalyst is a good example of how software suffers in a K/M-oriented environment when it came from a touch environment without many modifications. Even the Apple-developed apps have too many controls and views designed for tactile screens. The Catalyst development team is introducing UI elements that make more sense in macOS, like a compact calendar picker to replace the touch-style picker wheel, but it’s going to take a long time before a Catalyst app lets a developer quickly make a macOS version that feels designed for macOS, and again, there is a need for that native macOS feel because quality touch UI interfaces are slow and difficult to use on a laptop or desktop.
- melling 7y ago
  Well, let’s use our imagination... ... and hope that Apple reinvents user input on mobile. A little Soli for advanced gestures: https://atap.google.com/soli/ https://atap.google.com/soli/ A selfie keyboard? https://www.cnet.com/news/samsungs-selfietype-creates-a-magic-invisible-keyboard-for-your-phone/ https://www.cnet.com/news/samsungs-selfietype-creates-a-magi... Better voice commands. For example, why can’t I say “build app” “Rename function foo to bar“
  - 1123581321 7y ago
    Voice certainly seems like a viable solution to some of that. In some ways it’s imminent if the accessibility improvements pushed to iOS, iPadOS and macOS are advanced just a bit further. However, we should also expect to see PC use pushed into more advanced and specialized territory on our most powerful and versatile devices as phones and tablets assume more traditional PC work. That specialized use will advance as fast as the most attuned interface for that platform (keyboard+mouse) and the others will necessarily lag behind.
  - dmitriid 7y ago
    All of this won't solve the mobile/desktop dichotomy. I rename things dozens of times a day. Saying "rename function A to B" dozens of times a day is unviable on desktop and is nearly unusable on the phone. And this is a fundamentally different UI.
- coldtea 7y ago
  >Again, you are thinking of porting a touch app to a non-touch device when the issue is that good touch and non-touch UI and ergonomics cannot co-exist on the same device. Sure they can, just not on the same screen sizes/input methods. You could have Excel that looks like iOS Excel when opened in the iPhone that automatically turns into Excel that looks like macOS Excel when the iPhone is connected to a larger screen with a mouse and everything.
  - dmitriid 7y ago
    You couldn't. Not without exceptionally complex UI code amounting to writing two different apps inside of one.
    - coldtea 7y ago
      Since you have both of those apps already, you can trivially combine them. In the process you'll also get to reuse large parts of both UI code, and almost all of the non-UI code. And if you've started from scratch, it would be even easier to find ways to reuse more UI code -- e.g. components could come in "auto-dual" versions that adapt.
      - dmitriid 7y ago
        > can trivially combine them Could you explain to me how can you trivially combine two apps? > In the process you'll also get to reuse large parts of both UI code, and almost all of the non-UI code. Yes to the non-UI code. Hard no to the UI code. You will need to design a completely different set of interactions, components, layouts etc. for the mobile version compared to the desktop version.
        coldtea 7y ago
        >Could you explain to me how can you trivially combine two apps? You already have the UI code for mobile and desktop. All you need to do is switch to one or the other when the user connects/disconnects an external monitor. At the most basic, you could just save the spreadsheet state (staying with the Excel used as an example), and load in the background and switch to show the desktop version of the app with it pre-loaded. Same way as if the user manually saved their spreadsheet, closed the mobile version of the app, and opened the same spreadsheet with the desktop version - but more transparently. Between this and "sharing UI" there is a big spectrum. If you already have the mobile and desktop version, and the backend is more or less the same (as can be the case with apps like Excel for macOS and iOS), then compared to the work you've already done its trivial to add an intelligent way to switch from one UI to the other keeping all the other state (working spreadsheet, clipboard, current executing action, etc). >You will need to design a completely different set of interactions, components, layouts etc. for the mobile version compared to the desktop version. Not necessarily. A sphreadsheet cell is a sphreadsheet cell. Whether you click on it with touch or the mouse pointer doesn't matter. You could easily share the same underlying widget (and e.g. just show more of them). The formula editor that appears can similarly be shared. Other forms might need some extra padding, or some widgets to become larger or smaller etc. We already have apps that run the same in iOS and macOS, through Apple's translation layer + layout constraints and switches on widgets. The "Voice Memos" apps is basically the exact same thing between iOS and Mac.

1123581321 7y ago

Again, you are thinking of porting a touch app to a non-touch device when the issue is that good touch and non-touch UI and ergonomics cannot co-exist on the same device. And I am familiar with Catalyst. I think Catalyst is a good example of how software suffers in a K/M-oriented environment when it came from a touch environment without many modifications. Even the Apple-developed apps have too many controls and views designed for tactile screens. The Catalyst development team is introducing UI elements that make more sense in macOS, like a compact calendar picker to replace the touch-style picker wheel, but it’s going to take a long time before a Catalyst app lets a developer quickly make a macOS version that feels designed for macOS, and again, there is a need for that native macOS feel because quality touch UI interfaces are slow and difficult to use on a laptop or desktop.

melling 7y ago
Well, let’s use our imagination... ... and hope that Apple reinvents user input on mobile. A little Soli for advanced gestures: https://atap.google.com/soli/ https://atap.google.com/soli/ A selfie keyboard? https://www.cnet.com/news/samsungs-selfietype-creates-a-magic-invisible-keyboard-for-your-phone/ https://www.cnet.com/news/samsungs-selfietype-creates-a-magi... Better voice commands. For example, why can’t I say “build app” “Rename function foo to bar“
- 1123581321 7y ago
  Voice certainly seems like a viable solution to some of that. In some ways it’s imminent if the accessibility improvements pushed to iOS, iPadOS and macOS are advanced just a bit further. However, we should also expect to see PC use pushed into more advanced and specialized territory on our most powerful and versatile devices as phones and tablets assume more traditional PC work. That specialized use will advance as fast as the most attuned interface for that platform (keyboard+mouse) and the others will necessarily lag behind.
- dmitriid 7y ago
  All of this won't solve the mobile/desktop dichotomy. I rename things dozens of times a day. Saying "rename function A to B" dozens of times a day is unviable on desktop and is nearly unusable on the phone. And this is a fundamentally different UI.
coldtea 7y ago
>Again, you are thinking of porting a touch app to a non-touch device when the issue is that good touch and non-touch UI and ergonomics cannot co-exist on the same device. Sure they can, just not on the same screen sizes/input methods. You could have Excel that looks like iOS Excel when opened in the iPhone that automatically turns into Excel that looks like macOS Excel when the iPhone is connected to a larger screen with a mouse and everything.
- dmitriid 7y ago
  You couldn't. Not without exceptionally complex UI code amounting to writing two different apps inside of one.
  - coldtea 7y ago
    Since you have both of those apps already, you can trivially combine them. In the process you'll also get to reuse large parts of both UI code, and almost all of the non-UI code. And if you've started from scratch, it would be even easier to find ways to reuse more UI code -- e.g. components could come in "auto-dual" versions that adapt.
    - dmitriid 7y ago
      > can trivially combine them Could you explain to me how can you trivially combine two apps? > In the process you'll also get to reuse large parts of both UI code, and almost all of the non-UI code. Yes to the non-UI code. Hard no to the UI code. You will need to design a completely different set of interactions, components, layouts etc. for the mobile version compared to the desktop version.
      - coldtea 7y ago
        >Could you explain to me how can you trivially combine two apps? You already have the UI code for mobile and desktop. All you need to do is switch to one or the other when the user connects/disconnects an external monitor. At the most basic, you could just save the spreadsheet state (staying with the Excel used as an example), and load in the background and switch to show the desktop version of the app with it pre-loaded. Same way as if the user manually saved their spreadsheet, closed the mobile version of the app, and opened the same spreadsheet with the desktop version - but more transparently. Between this and "sharing UI" there is a big spectrum. If you already have the mobile and desktop version, and the backend is more or less the same (as can be the case with apps like Excel for macOS and iOS), then compared to the work you've already done its trivial to add an intelligent way to switch from one UI to the other keeping all the other state (working spreadsheet, clipboard, current executing action, etc). >You will need to design a completely different set of interactions, components, layouts etc. for the mobile version compared to the desktop version. Not necessarily. A sphreadsheet cell is a sphreadsheet cell. Whether you click on it with touch or the mouse pointer doesn't matter. You could easily share the same underlying widget (and e.g. just show more of them). The formula editor that appears can similarly be shared. Other forms might need some extra padding, or some widgets to become larger or smaller etc. We already have apps that run the same in iOS and macOS, through Apple's translation layer + layout constraints and switches on widgets. The "Voice Memos" apps is basically the exact same thing between iOS and Mac.