4 ms·

> Of course there's nothing preventing web based UIs from supporting the same speed and productivity, but I know of few examples that actually do this. Can you

by holri 7y ago

> Of course there's nothing preventing web based UIs from supporting the same speed and productivity, but I know of few examples that actually do this. Can you give a few of those examples? What must be done to accomplish this?

darkwater 7y ago
No the GP but I'd say that they should: * be 100% keyboard driven (so, indexed inputs for easy TAB navigation) * really quick and responsive (probably with all the needed code locally available, storing data locally and then sync when no action is going on). It's probably one of the best example where a SPA would be really useful * be really lightweight so it can run on older hardware (like 10+ years old) But doing those points "right" with nowadays frontend-mindset I'd say that's pretty difficult.
- holri 7y ago
  isn't SPA and lightweight a contradiction? My ten year old N900 can not run a modern SPA frontend but is pretty "snappy" with plain old small HTML sites.
  - darkwater 7y ago
    But that probably lies more in the framework used rather then in the "SPA concept". Disclaimer: I'm not a front-end developer so I may be totally wrong.
    - goldenkey 7y ago
      The only things needed to make SPA possible are same page requests and DOM updates. We have pretty much always had iframes and form posts that can be targeted to submit to hidden iframes that JS can read, so XMLHttpRequest is easy to polyfill. We used to use jQuery and globals or straight DOM manipulation. Or Backbone.js or just straight classes. It has always been possible to make a SPA. And if you actually are able to download and cache most of the app upfront, it should be pretty quick. The question is, I suppose, how big is the SPA codebase and do newer browsers know how to cache identical codebases into their "entry points"? The real draw of React and Vue, and more recently, Lit-Element (Google), is that they update the DOM in a smart efficient way, doing updates much more efficiently than you might could do without an intermediate layer.
- skrebbel 7y ago
  Yep, this! That said, > (probably with all the needed code locally available, storing data locally and then sync when no action is going on). I'm not sure this is a requirement. Eg the D forum is extremely snappy yet server side rendered: https://forum.dlang.org/ https://forum.dlang.org/. HN itself is pretty snappy too. I think "no cruft" is probably the better guideline. And it's a hard guideline to follow in Single-Page Webapp Land :-)
  - TeMPOraL 7y ago
    I'd say not only the code needs to be local, but it can't make synchronous requests on the network at all until you've completed a task. One of the underappreciated things about such productive software which enables it to be used without looking is predictable reaction times. Consider the "amazing data entry" video posted elsewhere in the thread, or good old feature-phones. If you have an action that you perform frequently, the key to learning how to do it without looking is to learn how quickly you can feed the input, where do you have to wait for it to be processed, and how long it takes. It's one of the things I still miss about my last feature-phone (Sony Ericsson K800i). I could do a lot with it without even taking it out of my pocket, because I committed to muscle memory sequences like "up arrow, up arrow, OK, wait half a second, down arrow x3, OK, OK, exit". There's no way I could do this with an Android phone, because input and processing delays are random. Similarly, on the web, if your action shoots out a network request, it can complete anywhere between half a second and half a minute. You can't do actions like these without looking because there's a non-zero chance a delay will mess it up.
    - darkwater 7y ago
      And I'll add that a POS should be 100% working even with no internet connection, which it's much more likely to fail than electricity.
      - Slartie 7y ago
        POS Developer here. Offline capability (both kinds, with regard to a store server and with regard to an internet connection out of the store) is actually a very important requirement for any serious retailer, but not necessarily 100%, in terms of functionality. Today, you usually want to support some features that are impossible to realize in an offline capable way, like accepting gift cards. For these it's acceptable to be unavailable in an offline scenario. However, this actually creates the next big problem: you need to isolate these services and any connectivity-related errors with them from your offline-capable core ringing process in a way that ensures that your predictable response times of the core ringing process (which are super important for good UX, as the previous commenter already explained correctly) are compromised as little as possible if your online-only feature goes into a failure state - a typical example for "you're doing it wrong" would be waiting for a timeout on an online service on every single request while the connection is down before signaling the cashier that this service cannot be used right now.

by holri 7y ago

darkwater 7y ago

No the GP but I'd say that they should: * be 100% keyboard driven (so, indexed inputs for easy TAB navigation) * really quick and responsive (probably with all the needed code locally available, storing data locally and then sync when no action is going on). It's probably one of the best example where a SPA would be really useful * be really lightweight so it can run on older hardware (like 10+ years old) But doing those points "right" with nowadays frontend-mindset I'd say that's pretty difficult.

holri 7y ago
isn't SPA and lightweight a contradiction? My ten year old N900 can not run a modern SPA frontend but is pretty "snappy" with plain old small HTML sites.
- darkwater 7y ago
  But that probably lies more in the framework used rather then in the "SPA concept". Disclaimer: I'm not a front-end developer so I may be totally wrong.
  - goldenkey 7y ago
    The only things needed to make SPA possible are same page requests and DOM updates. We have pretty much always had iframes and form posts that can be targeted to submit to hidden iframes that JS can read, so XMLHttpRequest is easy to polyfill. We used to use jQuery and globals or straight DOM manipulation. Or Backbone.js or just straight classes. It has always been possible to make a SPA. And if you actually are able to download and cache most of the app upfront, it should be pretty quick. The question is, I suppose, how big is the SPA codebase and do newer browsers know how to cache identical codebases into their "entry points"? The real draw of React and Vue, and more recently, Lit-Element (Google), is that they update the DOM in a smart efficient way, doing updates much more efficiently than you might could do without an intermediate layer.
skrebbel 7y ago
Yep, this! That said, > (probably with all the needed code locally available, storing data locally and then sync when no action is going on). I'm not sure this is a requirement. Eg the D forum is extremely snappy yet server side rendered: https://forum.dlang.org/ https://forum.dlang.org/. HN itself is pretty snappy too. I think "no cruft" is probably the better guideline. And it's a hard guideline to follow in Single-Page Webapp Land :-)
- TeMPOraL 7y ago
  I'd say not only the code needs to be local, but it can't make synchronous requests on the network at all until you've completed a task. One of the underappreciated things about such productive software which enables it to be used without looking is predictable reaction times. Consider the "amazing data entry" video posted elsewhere in the thread, or good old feature-phones. If you have an action that you perform frequently, the key to learning how to do it without looking is to learn how quickly you can feed the input, where do you have to wait for it to be processed, and how long it takes. It's one of the things I still miss about my last feature-phone (Sony Ericsson K800i). I could do a lot with it without even taking it out of my pocket, because I committed to muscle memory sequences like "up arrow, up arrow, OK, wait half a second, down arrow x3, OK, OK, exit". There's no way I could do this with an Android phone, because input and processing delays are random. Similarly, on the web, if your action shoots out a network request, it can complete anywhere between half a second and half a minute. You can't do actions like these without looking because there's a non-zero chance a delay will mess it up.
  - darkwater 7y ago
    And I'll add that a POS should be 100% working even with no internet connection, which it's much more likely to fail than electricity.
    - Slartie 7y ago
      POS Developer here. Offline capability (both kinds, with regard to a store server and with regard to an internet connection out of the store) is actually a very important requirement for any serious retailer, but not necessarily 100%, in terms of functionality. Today, you usually want to support some features that are impossible to realize in an offline capable way, like accepting gift cards. For these it's acceptable to be unavailable in an offline scenario. However, this actually creates the next big problem: you need to isolate these services and any connectivity-related errors with them from your offline-capable core ringing process in a way that ensures that your predictable response times of the core ringing process (which are super important for good UX, as the previous commenter already explained correctly) are compromised as little as possible if your online-only feature goes into a failure state - a typical example for "you're doing it wrong" would be waiting for a timeout on an online service on every single request while the connection is down before signaling the cashier that this service cannot be used right now.