7 ms·

IMO desktop apps aren’t quite equivalent to native apps. Native apps look and behave in a consistent way. They have • Familiar UI primitives: - Controls and

by feifan 6y ago

IMO desktop apps aren’t quite equivalent to native apps. Native apps look and behave in a consistent way. They have • Familiar UI primitives: - Controls and chrome are in the same place - Font sizes are the same across apps - Consistent icons and button shapes • Support standard keyboard shortcuts (including obscure ones that developers re-implementing these UIs might not know about) - All the Emacs-style keybindings that work in native macOS text fields but are hit-or-miss in custom web text fields - Full keyboard access (letting me tab and use the space bar and arrow keys to interact with controls) • And consistent, predictable responsiveness cadences - Somewhat contrived example: In Slack (browser or Electron app), switching between channels/DMs (via ⌘K) has a lag of about 0.5–1 second. If I start typing my message for that recipient during this lag, it actually gets saved as a draft in the channel that I just left and my content in the new channel gets truncated. I don’t think that kind of behavior would happen in a native macOS app, which renders UIs completely synchronously by default/in-order (so it might block the UI, but at least interactions will be in a consistent state)

falafel 6y ago
I don't agree with the first two points. Native applications aren't consistent in this way. There are dozens of cross-platform GUI kits and they all behave slightly different, just like Electron apps. If you want consistency, you need to build multiple apps, one for each OS with their respective toolkits. Ain't nobody got time for that when you can easily build on Electron and target browsers, macOS, Windows, and Linux in one single app. No wonder Electron is winning the battle so far, regardless of your last point.
- madhadron 6y ago
  Native implies that you are building for each OS and their native toolkit. On macOS, you write Cocoa. On Linux you write GNOME or KDE or CDE. On Windows you write...I dunno. Win32 probably.
  - freeone3000 6y ago
    Current tech is C++/WinRT, for this year, but last year it was WPF and five years ago it was XAML, then previously it was MFC/ATL, and original Win32 somewhere back in the old days. And Linux isn't better. I think OSX is the only desktop OS that has an idea of what an app should look like.
    - squiggleblaz 6y ago
      MacOS used to have a choice between Carbon and Cocoa, didn't it? Maybe still does. C++/WinRT uses XAML. But XAML isn't a control library/toolkit. You can tell because it isn't called the Extensible Application Control Library. I'd say it shouldn't be included in your list, but MFC/ATL is just a way of accessing Win32 via C++ -- it makes the same function calls -- so it's not clear that your purpose was to make a fair statement about native development, but perhaps to complain about Windows turnover of apis. On Linux, it's quite simple to live entirely in Gtk-compatible land. I think Firefox and JetBrains are the only foreigners I use on my box, but I'd be using them on any opertaing system so it's not exactly a fair cop.
      - madhadron 6y ago
        > MacOS used to have a choice between Carbon and Cocoa, didn't it? Maybe still does. It did. Carbon was the pre-NeXT widget set and compatibility to run pre-OS X apps. It is very dead. There is only Cocoa. > MFC/ATL is just a way of accessing Win32 via C++ Okay, so we can still regard MFC/Win32 as the standard API?
      - freeone3000 6y ago
        Let's go with a file picker dialog, a simple OS-provided component. Windows provides three versions of this dialog (the "app" view, the tree-view, and the explorer-in-your-app view) depending on which API you use. You see this pattern repeated. It being the same calls "underneath" is true, but it's also irrelevant, as the user experience noticeably changes depending on which API is invoked.
pbhjpbhj 6y ago
Consistency is maybe overrated? I purposefully make my FF unlike the other apps on my system. I use a couple of workarounds to prevent OS level keybinds from working in some apps. Sometimes a completely purpose made UI is better, sometimes. In general, consistency [in desktop UI] is good, but there are good reasons to break it.
- pmlnr 6y ago
  It is certainly not overrated. See Windows 10. https://www.techrepublic.com/article/control-panel-and-settings-uis-why-are-both-still-options-in-windows-10/ https://www.techrepublic.com/article/control-panel-and-setti... https://www.windowscentral.com/sites/wpcentral.com/files/styles/xlarge/public/field/image/2015/07/windows-10-menus_.jpg https://www.windowscentral.com/sites/wpcentral.com/files/sty...
- dredmorbius 6y ago
  Depends heavily on the user community, use case, time-in-environment (short- and long-term), inter-user communication about application, and rate of change. There's almost certainly a set of interrelationships between these. For a highly technical userbase, a highly bespoke UI may be defensible,even preferable, especially: - User community is expert, highly skilled, and highly computer-literate. - If daily-weekly time-in-environment is high. User "lives in" application. - If lifetime time-in-environment is high. Users base career in application. - If there's relatively little communication between users about application state, interactions, or activities. Put another way: users interact with the app, but not about the app with others (users, clients, management, techs). - The UI avoids drastic change over time. By contrast, reverse virtually any of these conditions and you'll want a UI that conforms closely to current standards: - Users are inexpert, poorly computer-literate (the vast majority, see OECD computer skills study), or simply nontechnical with app. - Time-in-environment is low. At the extreme, all users are one-time novices. - If users must communicate with others regarding app state or tasks -- close management, team interaction, client / management interactions. All parties need a ready and clear mental model of the UI and state. - If the UI changes drastically over time, it should do so consistently with all other major elements. (Both should change as little as possible.) Somewhat more concretely, the absolute worst feature a UI can have is change. Users get confused, lose trust, and are burdened by obsolete knowledge. This afflicts both expert and nonexpert users, profoundly, though in somewhat different ways. For very technical tools used principally creatively --- virtually all editors, development environments, and many reader/browser/search/analysis tools fit this description --- a highly distinctive (and customisable) interface may be appropriate for advanced users. This is a small, but generatively critical, user community. There's a requisite complexity to such tools, simplified UI comes at the cost of vastly less efficient performance. Virtually all "weird" tools in heavy use today evolved from what were at the time of their creation, common motifs, at least within the environment of origin. Think of Unix, vi, emacs, Photoshop, Excel, and Eclipse, say. For standard workflow, control, and transactional tools, highly standard UIs are preferred. Here, users are interacting closely with others regarding state or interactions with the interface, and clarity, consistency, and common knowledge of the UI and state changes matter. Point-of-sale systems, equipment controls, general monitors, enterprise applications, end-user/customer support tools, and the like. Occasional-use, public use, and similar tools must be generally usable without training. Adherence to standard motifs is critically important. UIs and capabilities are generally simple. The trade-offs: - More expert users and more heavily-used tools can support more novel UIs. - Less literate users, more unfamiliar tools, and greater communications about UI state and interactions, demand more standard UIs. - Change is generally bad, but evolutionary change (within the tool) or conformant change (with the overall environment) are generally less disruptive than either sudden drastic or idiosyncratic changes.

by feifan 6y ago

falafel 6y ago

I don't agree with the first two points. Native applications aren't consistent in this way. There are dozens of cross-platform GUI kits and they all behave slightly different, just like Electron apps. If you want consistency, you need to build multiple apps, one for each OS with their respective toolkits. Ain't nobody got time for that when you can easily build on Electron and target browsers, macOS, Windows, and Linux in one single app. No wonder Electron is winning the battle so far, regardless of your last point.

madhadron 6y ago
Native implies that you are building for each OS and their native toolkit. On macOS, you write Cocoa. On Linux you write GNOME or KDE or CDE. On Windows you write...I dunno. Win32 probably.
- freeone3000 6y ago
  Current tech is C++/WinRT, for this year, but last year it was WPF and five years ago it was XAML, then previously it was MFC/ATL, and original Win32 somewhere back in the old days. And Linux isn't better. I think OSX is the only desktop OS that has an idea of what an app should look like.
  - squiggleblaz 6y ago
    MacOS used to have a choice between Carbon and Cocoa, didn't it? Maybe still does. C++/WinRT uses XAML. But XAML isn't a control library/toolkit. You can tell because it isn't called the Extensible Application Control Library. I'd say it shouldn't be included in your list, but MFC/ATL is just a way of accessing Win32 via C++ -- it makes the same function calls -- so it's not clear that your purpose was to make a fair statement about native development, but perhaps to complain about Windows turnover of apis. On Linux, it's quite simple to live entirely in Gtk-compatible land. I think Firefox and JetBrains are the only foreigners I use on my box, but I'd be using them on any opertaing system so it's not exactly a fair cop.
    - madhadron 6y ago
      > MacOS used to have a choice between Carbon and Cocoa, didn't it? Maybe still does. It did. Carbon was the pre-NeXT widget set and compatibility to run pre-OS X apps. It is very dead. There is only Cocoa. > MFC/ATL is just a way of accessing Win32 via C++ Okay, so we can still regard MFC/Win32 as the standard API?
    - freeone3000 6y ago
      Let's go with a file picker dialog, a simple OS-provided component. Windows provides three versions of this dialog (the "app" view, the tree-view, and the explorer-in-your-app view) depending on which API you use. You see this pattern repeated. It being the same calls "underneath" is true, but it's also irrelevant, as the user experience noticeably changes depending on which API is invoked.

pbhjpbhj 6y ago

Consistency is maybe overrated? I purposefully make my FF unlike the other apps on my system. I use a couple of workarounds to prevent OS level keybinds from working in some apps. Sometimes a completely purpose made UI is better, sometimes. In general, consistency [in desktop UI] is good, but there are good reasons to break it.

pmlnr 6y ago
It is certainly not overrated. See Windows 10. https://www.techrepublic.com/article/control-panel-and-settings-uis-why-are-both-still-options-in-windows-10/ https://www.techrepublic.com/article/control-panel-and-setti... https://www.windowscentral.com/sites/wpcentral.com/files/styles/xlarge/public/field/image/2015/07/windows-10-menus_.jpg https://www.windowscentral.com/sites/wpcentral.com/files/sty...
dredmorbius 6y ago
Depends heavily on the user community, use case, time-in-environment (short- and long-term), inter-user communication about application, and rate of change. There's almost certainly a set of interrelationships between these. For a highly technical userbase, a highly bespoke UI may be defensible,even preferable, especially: - User community is expert, highly skilled, and highly computer-literate. - If daily-weekly time-in-environment is high. User "lives in" application. - If lifetime time-in-environment is high. Users base career in application. - If there's relatively little communication between users about application state, interactions, or activities. Put another way: users interact with the app, but not about the app with others (users, clients, management, techs). - The UI avoids drastic change over time. By contrast, reverse virtually any of these conditions and you'll want a UI that conforms closely to current standards: - Users are inexpert, poorly computer-literate (the vast majority, see OECD computer skills study), or simply nontechnical with app. - Time-in-environment is low. At the extreme, all users are one-time novices. - If users must communicate with others regarding app state or tasks -- close management, team interaction, client / management interactions. All parties need a ready and clear mental model of the UI and state. - If the UI changes drastically over time, it should do so consistently with all other major elements. (Both should change as little as possible.) Somewhat more concretely, the absolute worst feature a UI can have is change. Users get confused, lose trust, and are burdened by obsolete knowledge. This afflicts both expert and nonexpert users, profoundly, though in somewhat different ways. For very technical tools used principally creatively --- virtually all editors, development environments, and many reader/browser/search/analysis tools fit this description --- a highly distinctive (and customisable) interface may be appropriate for advanced users. This is a small, but generatively critical, user community. There's a requisite complexity to such tools, simplified UI comes at the cost of vastly less efficient performance. Virtually all "weird" tools in heavy use today evolved from what were at the time of their creation, common motifs, at least within the environment of origin. Think of Unix, vi, emacs, Photoshop, Excel, and Eclipse, say. For standard workflow, control, and transactional tools, highly standard UIs are preferred. Here, users are interacting closely with others regarding state or interactions with the interface, and clarity, consistency, and common knowledge of the UI and state changes matter. Point-of-sale systems, equipment controls, general monitors, enterprise applications, end-user/customer support tools, and the like. Occasional-use, public use, and similar tools must be generally usable without training. Adherence to standard motifs is critically important. UIs and capabilities are generally simple. The trade-offs: - More expert users and more heavily-used tools can support more novel UIs. - Less literate users, more unfamiliar tools, and greater communications about UI state and interactions, demand more standard UIs. - Change is generally bad, but evolutionary change (within the tool) or conformant change (with the overall environment) are generally less disruptive than either sudden drastic or idiosyncratic changes.