7 ms·

Writing a native app for every conceivable platform someone might want to watch Prime Video on seems an awful lot of work

titzer 5y ago
"But why, though?" I keep asking myself, from a "how many darn buttons and doodads does it really need to have?" perspective. I suspect the issue is that people write entirely too much dang code to solve what is, after all, a fairly simple UI problem [1]. I mean, seriously. The Alto had less than a megabyte of RAM and managed to invent the GUI--menus, mouse, all. How have we managed to make this harder in 40 years? [1]...until Branding(tm) enters the chat.
- bastawhiz 5y ago
  Because it's not just buttons and doodads, it's all the error handling and loading indicators and UI edge cases that are needed to make it seamless and good. Title too long? Does it get truncated or shrunk? Does the UI reverse itself for RTL languages? Does the focus ring move in a sensible order? This is front end engineering. It's a whole profession, and when it's done poorly, folks think your software is garbage. Forty years ago half of the software was in English and required a specific screen resolution. Of COURSE it's going to be harder.
  - titzer 5y ago
    Frontend engineering is a thing because of the accidental complexity of a massive software stack that's evolved by accretion and gone through fad after fad after fad. I'm not looking down on frontend engineers, but I don't believe right-to-left languages or focus order inevitably leads to hundreds of thousands of lines of code or 50+ MB binaries.
    - nexuist 5y ago
      > don't believe right-to-left languages or focus order inevitably leads to hundreds of thousands of lines of code or 50+ MB binaries It does. It literally does. Try writing your own operating system, or font parser, or graphics engine. The work our shitty React apps sit on top of is unimaginably complex. It would take centuries for one single person to grasp what is going on in an iOS "Hello World" app. It's not simple, at all. Especially not for a video streaming service! I mean, my God, just being able to understand the codecs and licensing issues would take you months, let alone writing decoders that run natively on every platform. Let alone dealing with monitors and color schemes and HDMI and Chromecast streaming and window resizing and bandwidth limits and buffering and.... It's not simple. EDIT: For reference, vim, a Hacker News favorite and widely considered one of the most popular TUIs ever built, is currently sitting at about 1.2 million lines of code. All it does is edit text files. Imagine if it had to play video.
      - d110af5ccf 5y ago
        > For reference, vim Vim is an incredibly useful tool but I've seen frequent complaints about its codebase. Competitors with significantly higher code quality exist (ex Kakoune). > > don't believe ... inevitably leads to > It does. It literally does. Try writing your own operating system, or font parser, or graphics engine. There are working examples of such and the code appears to be significantly simpler than the status quo. I'm far from an expert here but to the best of my understanding feature creep combined with maintaining backwards compatibility is to blame for a significant amount of current complexity. Consider that if you rewrite a low level API with the benefit of hindsight, everything that uses that API has to be updated. Often multiple distinct APIs will be involved though, not just one. Look at the difficulty the Linux ecosystem has had gaining full support for Wayland, which necessitated the likes of PipeWire and a number of other new ways of doing things, and has been "nearly ready" for production for how many years now?
        sangnoir 5y ago
        > There are working examples of such and the code appears to be significantly simpler than the status quo Status quo is bloated -> someone rewrites a simple replacement -> becomes popular -> "Can you cover this reasonable use case, it's not currently supported" -> repeated previous step several hundred times -> oh fuck, the "lightweight" rewrite has become the bloated status quo -> GOTO step one
        titzer 5y ago
        In some sense, this is WAI. Hopefully along the cycle, people learn to build better architectures that are modular, scriptable, customizable, and not giant monolithic piles. If things were more scriptable, then I as a user could script them how I want creating of a wall of my own "UI" and then swapping out the backends as I see fit. In my 25 years or so programming, I wish I had done this more; scripts for everything. Learn how to use my own scripts and only adjust them when stuff breaks/is swapped out. In retrospect, I have been buffeted by the whims of UI designers for decades, and I'm kinda mad about it.
        5y ago
    - root_axis 5y ago
      Alternatively, it could be that building high quality cross-platform front-ends that look and behave consistently across those different platforms is actually complex and the tools to solve those problems reflect that complexity. In my view, this is pretty common knowledge... just consider, every example of native software is horrible outside of one or two platforms, and most native software project/products don't even support more than two platforms.
    - bastawhiz 5y ago
      Where do you think all that code lives, then? The support for dark mode, the ability to look at the pixel data of an image so that you can display text with the right color on top of it to have high enough contrast, the subtle animation when you tab between elements in a scrollable grid, the annotations for accessibility, the code that makes drag and drop work like you expect... As much as you don't think it is "hundreds of thousands of lines of code", it really is. I started a business online five years ago. I used as little JS as possible: the first version was probably 500 lines total. Today, it's approaching a quarter million, and it's all just me. Why? Because I want forms to show helpful errors when you type the wrong thing, and my pages to show appropriate visual cues at the right time in the right places, and for the page to look right when dark mode kicks in on your laptop or you resize your window, and for decimals to be formatted correctly for folks in Europe. Or for the power users who expect things to be fast, so navigating forward and back loads and caches data correctly. Or for folks with high-dpi displays (or as it were, folks who zoom in) who don't want pixelated icons. And has it paid off? Yeah. As an example, my service hosts a surprising majority of blind podcasters, including the American Council for the Blind. I didn't get here with a spring in my step and a strong belief in semantic HTML, I got here by investing in all the fiddly edge cases so no matter what size your screen is, the browser you use, the language you speak, the currency you want to get paid with, your ability to use a mouse, your screen reader or level of vision, you still have a great experience. As much as you'd like to call it a fad or accidental complexity, it's really just your inexperience with actually building good user interfaces in the 21st century.
      - ad-astra 5y ago
        Hey, I share your passion for human interfaces - huge kudos to you. I built the main interface for the redesigned Amazon Photos iOS app and went through a lot of the things you mentioned - totally agree that it pays off. If you ever want to chat over coffee my email is johnanthony.dev@gmail.com
        DonHopkins 5y ago
        I share that passion too! Most people grossly underestimate how difficult it is to implement something as seemingly simple as a text field or menu, when there are so many hidden issues and techniques that make them easy to use because you don't notice all the support you're getting. Well implemented user interfaces have polish that makes their inherent complexity invisible, but polish is actually millions of tiny little scratches, not just a clean simple perfectly flat surface. Accessibility and internationalization are two crucial dimensions that most people forget about (especially non-sensory/motor-impaired Americans), which each add huge amounts of unavoidable complexity to text fields and the rest of the widget set. Then there's text selection, character/word/paragraph level selection, drag-n-drop, pending delete, scrolling, scrollbar hiding, auto scroll, focus management, keyboard navigation and shortcuts, copy and paste, alternative input methods, type-ahead, etc, all which need to perfectly dovetail together (like auto-scrolling working correctly during selection and drag-n-drop, auto-scrolling triggering on a reasonably scaled timer regardless of mouse position instead of mouse movements only inside the text field, so scrolling is deterministically controllable and happens at a reasonable speed, and doesn't freeze when you stop moving the mouse or move it too far, etc). There are so many half-assed custom text fields out there written by well intentioned people who just didn't realize the native text fields supported all those features, or weren't intimately familiar with all of the nuances and tweaks that have been hashed out over the decades (like anchoring and extending the selection, controlling and editing the selection with the keyboard, inserting and removing redundant spaces at the seams of the beginning and the end of the selection when you drag and drop text, etc). Even when somebody achieves the straightforward task of implementing a text field that looks pixel-for-pixel equivalent to a native text field, they're usually making a promise that they can't keep, that it also operates exactly the same as a native text field. I've seen many text fields in games (and browsers) that break type-ahead by dropping keyboard input when you type too fast, because instead of tracking device events in a queue, they're polling the current state of the keys each frame update, so when you get slow frames and stuttering (which is often, like during auto save or browser thrashing), they miss key transitions. Most games poll the mouse buttons and positions this way too, so they break mouse-ahead by dropping mouse clicks if you make them too fast, and they perform actions at the current position of the mouse instead of its position when the click happened. Even a beautifully designed well implemented AAA quality game like Dyson Sphere Project running on a high-end PC has this problem. After you place a power pole, you have to hold the mouse still for a moment to let the game handle the mouse down event and draw the screen a few times, before daring to move your mouse away from where you want to place the pole, otherwise the pole goes into the wrong position, away from where you clicked the mouse, and this really throws a monkey wrench into smooth fluid interaction, predictable reliability, mouse-ahead, etc. The Xerox Star had a wonderfully well thought out and implemented text editor, which pioneered solutions to many of these issues in 1982 (including internationalization), demonstrated in this video: Xerox Star User Interface (1982) 2 of 2 https://www.youtube.com/watch?v=ODZBL80JPqw https://www.youtube.com/watch?v=ODZBL80JPqw See Brad Myers video "All the Widgets (Fixed v2) - 1990". This was made in 1990, sponsored by the ACM CHI 1990 conference, to tell the history of widgets up until then. Previously published as: Brad A. Myers. All the Widgets. 2 hour, 15 min videotape. Technical Video Program of the SIGCHI'90 conference, Seattle, WA. April 1-4, 1990. SIGGRAPH Video Review, Issue 57. ISBN 0-89791-930-0. https://www.youtube.com/watch?v=9qtd8Hc90Hw https://www.youtube.com/watch?v=9qtd8Hc90Hw Also by Brad Myers: Taxonomies of Visual Programming (1990) [pdf] (cmu.edu) https://news.ycombinator.com/item?id=26057530 https://news.ycombinator.com/item?id=26057530 https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf Updated version: http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf Brad Myers is finishing a book (tentatively titled “Pick, Click, Flick! The Story of Interaction Techniques”) which is partially a history of Interaction Techniques. Probably more than 450 pages. The initial chapter list can be seen at www.ixtbook.com. It is based on Brad’s All The Widgets video and Brief History of HCI paper, and also on his class on Interaction Techniques which he taught three times. As part of that class, Brad interviewed 15 inventors of different interaction techniques, all but one of whose video is available on-line, which also might be a useful resource. Pick, Click, Flick! The Story of Interaction Techniques: http://www.ixtbook.com/ http://www.ixtbook.com/ https://www.cs.cmu.edu/~bam/ixtbook/#abstract https://www.cs.cmu.edu/~bam/ixtbook/#abstract Brad Myers' Interaction Design Class: https://www.cs.cmu.edu/~bam/uicourse/05440inter/ https://www.cs.cmu.edu/~bam/uicourse/05440inter/ Here's the video and slides of the talk I gave to Brad's Interaction Techniques class about pie menus -- there's a discussion of mouse ahead, event handling, and polling around 16:30: Video: https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=f0600d9d-282e-4b83-a6f4-a9f2003ad407 https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=... Slides: https://docs.google.com/presentation/d/1R9s4EEAwUjI_7A8GgdLYD_U1yUs9omaVqkY9GY-2D78/edit?usp=sharing https://docs.google.com/presentation/d/1R9s4EEAwUjI_7A8GgdLY... Pie Menus: A 30 Year Retrospective (Timeline): https://medium.com/@donhopkins/pie-menus-936fed383ff1 https://medium.com/@donhopkins/pie-menus-936fed383ff1
    - shroompasta 5y ago
      This comes off incredibly naive of FE engineering. Buttons and Doodads? sigh. A significant factor as to why Apple has succeeded the past 2 decades is due to the design of their products - from the sleek aluminum bodies of their hardware to the UI/UX of their operating systems. Unless you want your UI to look like something out of 1995, you're going to have to make it look good. Making it look good will require a decent amount of code. From animation libraries like Framer Motion, or data visualizations using d3, or even After Effects renders from Lottie. That isn't even mentioning the amount of state that is required to be stored so that proper renders could occur - If your user has logged in, if your user has typed something into an input field, how many times you should retry a request if it fails, what functions to run due to a websocket response, and myriads of other things that FE engineers have to deal with. Please reconsider your thoughts.
      - lpcvoid 5y ago
        I, for one, would love if UIs looked like it's 1995 again. Imagine the crispness, everything is fast, responsive and written in sensible languages. A simpler, and better time.
        shroompasta 5y ago
        While I agree in some cases, tech companies aren't marketing to those with that specific taste pallete
        lpcvoid 5y ago
        Yeah, it's unfortunate. No money in a small minority.
        sofixa 5y ago
        I don't know you, but from what i recall Windows 95 and 98 were anything but with fast and responsive UIs. Many windows were fixed size, and with significant input lag
        5y ago
  - saagarjha 5y ago
    > all the error handling and loading indicators and UI edge cases that are needed to make it seamless and good You mean the single instance of “owo we are very sorry” that shows up for any error, including the case where you might just have the gall to use the app on a non-perfect connection? The lack of a loading indicator? The poor and non-seamless experience because somebody wanted to ship Branding™?
  - kortilla 5y ago
    But I still think prime video, Netflix, Apple TV, etc are still garbage. They are woefully inconsistent, laggy, etc despite it “being it’s own profession”. I think the fact that it is its own profession is part of the problem. Every company feels the need to reinvent the wheel.
- sjtindell 5y ago
  I feel like you could make tons of money proving everyone wrong.
hn_throwaway_69 5y ago
A company that makes an awful lot of money can afford to not make an awful app on major platforms. A native app on Windows, macOS, iOS and Android (TV), and some other solution for other platforms, isn't an unreasonable ask in this context.
- dumpHero2 5y ago
  It takes an awful lot more money to ask engineers to do boring things like, “reciprocate this behaviour from iOS to Android “
  - hn_throwaway_69 5y ago
    Once I broached this subject with a developer at a start-up that developed totally separate native apps for iOS and Android. I queried him about the use of native apps, and he made the point that you do whatever it takes to keep your users happy. This was a startup. Not a billion dollar company. When your app is used by millions, it's a worthwhile investment. It's also hardly boring to achieve the same end result on multiple platforms by using appropriate native code for each. Particularly when it produces satisfyingly fluid and responsive end results. Perhaps an engineer that considers it boring is in the wrong field. A UI developer should get satisfaction from developing UIs, not as it being a stepping stone to get into systems development. I can't think of anything more boring in app development than developing an app which operates in a mediocre way. A carefully planned native app for each platform can still share parts of the same codebase, you're not necessarily reinventing the wheel each time.
    - imwillofficial 5y ago
      “This was a startup.” And? They have the latitude to make big risks. Larger companies can’t eat that risk as easily. “it's a worthwhile investment.” Obviously not, or you’d see it more.
- postalrat 5y ago
  And when comes the payoff for writing all those native apps?
jimbob45 5y ago
In this world where the only real differences between streaming services are their apps and their catalogues, you’d think everyone would be doing everything in their power to acquire every advantage on those fronts. My own strategy would be to keep the generic electron version and then make a native app for the top 5 most popular TV models but that’s just me.
BatteryMountain 5y ago
No. You just build one abstraction and then use a code generator to build a client for different targets. So as long as you have good developers with an interest in code generation and that will stick around for a few years to maintain the generators, then it works out fine. Resist the temptation to create a new DSL or programming language. Pick a language with a strict compiler, good typing system and good reflection capabilities and you are good to go. Ideally you code your app/abstraction once and then then everything else gets generated automatically by some build pipeline.
- potatoman22 5y ago
  Isn't the abstraction essentially their wasm and js libraries? And they just use a vm instead of code generator.
  - BatteryMountain 5y ago
    In their case, most likely yes. I honestly don't know and how don't know how many of their targets can be blanketed this way. The scenario I describe will not work for 8000 device types as you will end up with 8000 codegen libraries. Or that is, with my current implementation you will end up with that amount, as each target gets it's own little generator. I recently swapped out a big chunk of my codegen code and let my code call the flutter cli, so then I generate a flutter project which in turn can generate a few clients (like web, desktop, android etc). I'm currently optimizing the way I keep state between generations: certain parts can/should be overwritten but other parts need to be kept in tact. Trickier than it sounds. I highly recommend people to try building their own generators, scaffolding & tools. Very enriching!
kuschku 5y ago
In the pre-streaming era, every platform had a native player and content library app that worked fine. If streaming services desire to replace local playback, they’ll also have to replace the convenience that provided.

titzer 5y ago

"But why, though?" I keep asking myself, from a "how many darn buttons and doodads does it really need to have?" perspective. I suspect the issue is that people write entirely too much dang code to solve what is, after all, a fairly simple UI problem [1]. I mean, seriously. The Alto had less than a megabyte of RAM and managed to invent the GUI--menus, mouse, all. How have we managed to make this harder in 40 years? [1]...until Branding(tm) enters the chat.

bastawhiz 5y ago
Because it's not just buttons and doodads, it's all the error handling and loading indicators and UI edge cases that are needed to make it seamless and good. Title too long? Does it get truncated or shrunk? Does the UI reverse itself for RTL languages? Does the focus ring move in a sensible order? This is front end engineering. It's a whole profession, and when it's done poorly, folks think your software is garbage. Forty years ago half of the software was in English and required a specific screen resolution. Of COURSE it's going to be harder.
- titzer 5y ago
  Frontend engineering is a thing because of the accidental complexity of a massive software stack that's evolved by accretion and gone through fad after fad after fad. I'm not looking down on frontend engineers, but I don't believe right-to-left languages or focus order inevitably leads to hundreds of thousands of lines of code or 50+ MB binaries.
  - nexuist 5y ago
    > don't believe right-to-left languages or focus order inevitably leads to hundreds of thousands of lines of code or 50+ MB binaries It does. It literally does. Try writing your own operating system, or font parser, or graphics engine. The work our shitty React apps sit on top of is unimaginably complex. It would take centuries for one single person to grasp what is going on in an iOS "Hello World" app. It's not simple, at all. Especially not for a video streaming service! I mean, my God, just being able to understand the codecs and licensing issues would take you months, let alone writing decoders that run natively on every platform. Let alone dealing with monitors and color schemes and HDMI and Chromecast streaming and window resizing and bandwidth limits and buffering and.... It's not simple. EDIT: For reference, vim, a Hacker News favorite and widely considered one of the most popular TUIs ever built, is currently sitting at about 1.2 million lines of code. All it does is edit text files. Imagine if it had to play video.
    - d110af5ccf 5y ago
      > For reference, vim Vim is an incredibly useful tool but I've seen frequent complaints about its codebase. Competitors with significantly higher code quality exist (ex Kakoune). > > don't believe ... inevitably leads to > It does. It literally does. Try writing your own operating system, or font parser, or graphics engine. There are working examples of such and the code appears to be significantly simpler than the status quo. I'm far from an expert here but to the best of my understanding feature creep combined with maintaining backwards compatibility is to blame for a significant amount of current complexity. Consider that if you rewrite a low level API with the benefit of hindsight, everything that uses that API has to be updated. Often multiple distinct APIs will be involved though, not just one. Look at the difficulty the Linux ecosystem has had gaining full support for Wayland, which necessitated the likes of PipeWire and a number of other new ways of doing things, and has been "nearly ready" for production for how many years now?
      - sangnoir 5y ago
        > There are working examples of such and the code appears to be significantly simpler than the status quo Status quo is bloated -> someone rewrites a simple replacement -> becomes popular -> "Can you cover this reasonable use case, it's not currently supported" -> repeated previous step several hundred times -> oh fuck, the "lightweight" rewrite has become the bloated status quo -> GOTO step one
        titzer 5y ago
        In some sense, this is WAI. Hopefully along the cycle, people learn to build better architectures that are modular, scriptable, customizable, and not giant monolithic piles. If things were more scriptable, then I as a user could script them how I want creating of a wall of my own "UI" and then swapping out the backends as I see fit. In my 25 years or so programming, I wish I had done this more; scripts for everything. Learn how to use my own scripts and only adjust them when stuff breaks/is swapped out. In retrospect, I have been buffeted by the whims of UI designers for decades, and I'm kinda mad about it.
      - 5y ago
  - root_axis 5y ago
    Alternatively, it could be that building high quality cross-platform front-ends that look and behave consistently across those different platforms is actually complex and the tools to solve those problems reflect that complexity. In my view, this is pretty common knowledge... just consider, every example of native software is horrible outside of one or two platforms, and most native software project/products don't even support more than two platforms.
  - bastawhiz 5y ago
    Where do you think all that code lives, then? The support for dark mode, the ability to look at the pixel data of an image so that you can display text with the right color on top of it to have high enough contrast, the subtle animation when you tab between elements in a scrollable grid, the annotations for accessibility, the code that makes drag and drop work like you expect... As much as you don't think it is "hundreds of thousands of lines of code", it really is. I started a business online five years ago. I used as little JS as possible: the first version was probably 500 lines total. Today, it's approaching a quarter million, and it's all just me. Why? Because I want forms to show helpful errors when you type the wrong thing, and my pages to show appropriate visual cues at the right time in the right places, and for the page to look right when dark mode kicks in on your laptop or you resize your window, and for decimals to be formatted correctly for folks in Europe. Or for the power users who expect things to be fast, so navigating forward and back loads and caches data correctly. Or for folks with high-dpi displays (or as it were, folks who zoom in) who don't want pixelated icons. And has it paid off? Yeah. As an example, my service hosts a surprising majority of blind podcasters, including the American Council for the Blind. I didn't get here with a spring in my step and a strong belief in semantic HTML, I got here by investing in all the fiddly edge cases so no matter what size your screen is, the browser you use, the language you speak, the currency you want to get paid with, your ability to use a mouse, your screen reader or level of vision, you still have a great experience. As much as you'd like to call it a fad or accidental complexity, it's really just your inexperience with actually building good user interfaces in the 21st century.
    - ad-astra 5y ago
      Hey, I share your passion for human interfaces - huge kudos to you. I built the main interface for the redesigned Amazon Photos iOS app and went through a lot of the things you mentioned - totally agree that it pays off. If you ever want to chat over coffee my email is johnanthony.dev@gmail.com
      - DonHopkins 5y ago
        I share that passion too! Most people grossly underestimate how difficult it is to implement something as seemingly simple as a text field or menu, when there are so many hidden issues and techniques that make them easy to use because you don't notice all the support you're getting. Well implemented user interfaces have polish that makes their inherent complexity invisible, but polish is actually millions of tiny little scratches, not just a clean simple perfectly flat surface. Accessibility and internationalization are two crucial dimensions that most people forget about (especially non-sensory/motor-impaired Americans), which each add huge amounts of unavoidable complexity to text fields and the rest of the widget set. Then there's text selection, character/word/paragraph level selection, drag-n-drop, pending delete, scrolling, scrollbar hiding, auto scroll, focus management, keyboard navigation and shortcuts, copy and paste, alternative input methods, type-ahead, etc, all which need to perfectly dovetail together (like auto-scrolling working correctly during selection and drag-n-drop, auto-scrolling triggering on a reasonably scaled timer regardless of mouse position instead of mouse movements only inside the text field, so scrolling is deterministically controllable and happens at a reasonable speed, and doesn't freeze when you stop moving the mouse or move it too far, etc). There are so many half-assed custom text fields out there written by well intentioned people who just didn't realize the native text fields supported all those features, or weren't intimately familiar with all of the nuances and tweaks that have been hashed out over the decades (like anchoring and extending the selection, controlling and editing the selection with the keyboard, inserting and removing redundant spaces at the seams of the beginning and the end of the selection when you drag and drop text, etc). Even when somebody achieves the straightforward task of implementing a text field that looks pixel-for-pixel equivalent to a native text field, they're usually making a promise that they can't keep, that it also operates exactly the same as a native text field. I've seen many text fields in games (and browsers) that break type-ahead by dropping keyboard input when you type too fast, because instead of tracking device events in a queue, they're polling the current state of the keys each frame update, so when you get slow frames and stuttering (which is often, like during auto save or browser thrashing), they miss key transitions. Most games poll the mouse buttons and positions this way too, so they break mouse-ahead by dropping mouse clicks if you make them too fast, and they perform actions at the current position of the mouse instead of its position when the click happened. Even a beautifully designed well implemented AAA quality game like Dyson Sphere Project running on a high-end PC has this problem. After you place a power pole, you have to hold the mouse still for a moment to let the game handle the mouse down event and draw the screen a few times, before daring to move your mouse away from where you want to place the pole, otherwise the pole goes into the wrong position, away from where you clicked the mouse, and this really throws a monkey wrench into smooth fluid interaction, predictable reliability, mouse-ahead, etc. The Xerox Star had a wonderfully well thought out and implemented text editor, which pioneered solutions to many of these issues in 1982 (including internationalization), demonstrated in this video: Xerox Star User Interface (1982) 2 of 2 https://www.youtube.com/watch?v=ODZBL80JPqw https://www.youtube.com/watch?v=ODZBL80JPqw See Brad Myers video "All the Widgets (Fixed v2) - 1990". This was made in 1990, sponsored by the ACM CHI 1990 conference, to tell the history of widgets up until then. Previously published as: Brad A. Myers. All the Widgets. 2 hour, 15 min videotape. Technical Video Program of the SIGCHI'90 conference, Seattle, WA. April 1-4, 1990. SIGGRAPH Video Review, Issue 57. ISBN 0-89791-930-0. https://www.youtube.com/watch?v=9qtd8Hc90Hw https://www.youtube.com/watch?v=9qtd8Hc90Hw Also by Brad Myers: Taxonomies of Visual Programming (1990) [pdf] (cmu.edu) https://news.ycombinator.com/item?id=26057530 https://news.ycombinator.com/item?id=26057530 https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf Updated version: http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf Brad Myers is finishing a book (tentatively titled “Pick, Click, Flick! The Story of Interaction Techniques”) which is partially a history of Interaction Techniques. Probably more than 450 pages. The initial chapter list can be seen at www.ixtbook.com. It is based on Brad’s All The Widgets video and Brief History of HCI paper, and also on his class on Interaction Techniques which he taught three times. As part of that class, Brad interviewed 15 inventors of different interaction techniques, all but one of whose video is available on-line, which also might be a useful resource. Pick, Click, Flick! The Story of Interaction Techniques: http://www.ixtbook.com/ http://www.ixtbook.com/ https://www.cs.cmu.edu/~bam/ixtbook/#abstract https://www.cs.cmu.edu/~bam/ixtbook/#abstract Brad Myers' Interaction Design Class: https://www.cs.cmu.edu/~bam/uicourse/05440inter/ https://www.cs.cmu.edu/~bam/uicourse/05440inter/ Here's the video and slides of the talk I gave to Brad's Interaction Techniques class about pie menus -- there's a discussion of mouse ahead, event handling, and polling around 16:30: Video: https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=f0600d9d-282e-4b83-a6f4-a9f2003ad407 https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=... Slides: https://docs.google.com/presentation/d/1R9s4EEAwUjI_7A8GgdLYD_U1yUs9omaVqkY9GY-2D78/edit?usp=sharing https://docs.google.com/presentation/d/1R9s4EEAwUjI_7A8GgdLY... Pie Menus: A 30 Year Retrospective (Timeline): https://medium.com/@donhopkins/pie-menus-936fed383ff1 https://medium.com/@donhopkins/pie-menus-936fed383ff1
  - shroompasta 5y ago
    This comes off incredibly naive of FE engineering. Buttons and Doodads? sigh. A significant factor as to why Apple has succeeded the past 2 decades is due to the design of their products - from the sleek aluminum bodies of their hardware to the UI/UX of their operating systems. Unless you want your UI to look like something out of 1995, you're going to have to make it look good. Making it look good will require a decent amount of code. From animation libraries like Framer Motion, or data visualizations using d3, or even After Effects renders from Lottie. That isn't even mentioning the amount of state that is required to be stored so that proper renders could occur - If your user has logged in, if your user has typed something into an input field, how many times you should retry a request if it fails, what functions to run due to a websocket response, and myriads of other things that FE engineers have to deal with. Please reconsider your thoughts.
    - lpcvoid 5y ago
      I, for one, would love if UIs looked like it's 1995 again. Imagine the crispness, everything is fast, responsive and written in sensible languages. A simpler, and better time.
      - shroompasta 5y ago
        While I agree in some cases, tech companies aren't marketing to those with that specific taste pallete
        lpcvoid 5y ago
        Yeah, it's unfortunate. No money in a small minority.
      - sofixa 5y ago
        I don't know you, but from what i recall Windows 95 and 98 were anything but with fast and responsive UIs. Many windows were fixed size, and with significant input lag
        5y ago
- saagarjha 5y ago
  > all the error handling and loading indicators and UI edge cases that are needed to make it seamless and good You mean the single instance of “owo we are very sorry” that shows up for any error, including the case where you might just have the gall to use the app on a non-perfect connection? The lack of a loading indicator? The poor and non-seamless experience because somebody wanted to ship Branding™?
- kortilla 5y ago
  But I still think prime video, Netflix, Apple TV, etc are still garbage. They are woefully inconsistent, laggy, etc despite it “being it’s own profession”. I think the fact that it is its own profession is part of the problem. Every company feels the need to reinvent the wheel.
sjtindell 5y ago
I feel like you could make tons of money proving everyone wrong.

hn_throwaway_69 5y ago

A company that makes an awful lot of money can afford to not make an awful app on major platforms. A native app on Windows, macOS, iOS and Android (TV), and some other solution for other platforms, isn't an unreasonable ask in this context.

dumpHero2 5y ago
It takes an awful lot more money to ask engineers to do boring things like, “reciprocate this behaviour from iOS to Android “
- hn_throwaway_69 5y ago
  Once I broached this subject with a developer at a start-up that developed totally separate native apps for iOS and Android. I queried him about the use of native apps, and he made the point that you do whatever it takes to keep your users happy. This was a startup. Not a billion dollar company. When your app is used by millions, it's a worthwhile investment. It's also hardly boring to achieve the same end result on multiple platforms by using appropriate native code for each. Particularly when it produces satisfyingly fluid and responsive end results. Perhaps an engineer that considers it boring is in the wrong field. A UI developer should get satisfaction from developing UIs, not as it being a stepping stone to get into systems development. I can't think of anything more boring in app development than developing an app which operates in a mediocre way. A carefully planned native app for each platform can still share parts of the same codebase, you're not necessarily reinventing the wheel each time.
  - imwillofficial 5y ago
    “This was a startup.” And? They have the latitude to make big risks. Larger companies can’t eat that risk as easily. “it's a worthwhile investment.” Obviously not, or you’d see it more.
postalrat 5y ago
And when comes the payoff for writing all those native apps?

jimbob45 5y ago

In this world where the only real differences between streaming services are their apps and their catalogues, you’d think everyone would be doing everything in their power to acquire every advantage on those fronts. My own strategy would be to keep the generic electron version and then make a native app for the top 5 most popular TV models but that’s just me.

BatteryMountain 5y ago

No. You just build one abstraction and then use a code generator to build a client for different targets. So as long as you have good developers with an interest in code generation and that will stick around for a few years to maintain the generators, then it works out fine. Resist the temptation to create a new DSL or programming language. Pick a language with a strict compiler, good typing system and good reflection capabilities and you are good to go. Ideally you code your app/abstraction once and then then everything else gets generated automatically by some build pipeline.

potatoman22 5y ago
Isn't the abstraction essentially their wasm and js libraries? And they just use a vm instead of code generator.
- BatteryMountain 5y ago
  In their case, most likely yes. I honestly don't know and how don't know how many of their targets can be blanketed this way. The scenario I describe will not work for 8000 device types as you will end up with 8000 codegen libraries. Or that is, with my current implementation you will end up with that amount, as each target gets it's own little generator. I recently swapped out a big chunk of my codegen code and let my code call the flutter cli, so then I generate a flutter project which in turn can generate a few clients (like web, desktop, android etc). I'm currently optimizing the way I keep state between generations: certain parts can/should be overwritten but other parts need to be kept in tact. Trickier than it sounds. I highly recommend people to try building their own generators, scaffolding & tools. Very enriching!

kuschku 5y ago

In the pre-streaming era, every platform had a native player and content library app that worked fine. If streaming services desire to replace local playback, they’ll also have to replace the convenience that provided.