4 ms·

Eh, yes, and the yells of "Over budget, we can not afford new machines for the whole team, just because your app is not 386 backwards compatible." And the part

Eh, yes, and the yells of "Over budget, we can not afford new machines for the whole team, just because your app is not 386 backwards compatible." And the partial rollouts, with teams being split into and stuck- and demanding you hack together tooling on the fly to allow for work to continue anyway. And the horrible cross-application databases, which would went inconsistent if you didn't include basically a reduced data version controlling in every of your applications. And those proto-typed tools, made by some intern in obscure languages, that would in secrecy fester into the "Main-Tool" of a department. And all hell would break loose, if some virtual environment update would break those env-dependcies. You know what- it was bad back then. Real bad. And today is better. And even nostalgia cant save it.

alkonaut 10y ago
You wouldn't have to use antiquated tools and practices just to use desktop apps. I'm not arguing to use the old apps, I'm arguing that a lot of new development should be desktop when it's often made as web apps without thought. We threw all the good stuff with desktop out at the same time as we moved to intranets. You can still have centralized deployment, thin clients etc, but have the niceties of proper native apps (good multi screen/multi window support, better, good support for complex interactions like shortcuts, ctrl-clicks etc). Even on mobile where native has fewer benefits than on desktop we can't make web based apps that are better than native ones. A clean understandable web UI is good for a seldom used app, but a lot of the intranet apps are "constant use" and were faster to use in their legacy dos implementation than the newer web version. Browser hell just makes the problem worse.
- donatj 10y ago
  > A clean understandable web UI is good for a seldom used app, but a lot of the intranet apps are "constant use" and were faster to use in their legacy dos implementation than the newer web version. Browser hell just makes the problem worse. This. Click, wait, click, wait, click, wait is in no way better than how quickly you can fly with a well memorized set of keyboard shortcuts in a native app.
  - nine_k 10y ago
    I use keyboard shortcuts extensively in gmail, jira, stash, and a bunch of other apps. There's no problem implementing it. The designer should just think about it.
  - untog 10y ago
    This is not a web vs. native problem. You can implement keyboard shortcuts in a webapp. You can neglect to implement keyboard shortcuts in a native app. This is all about attention to detail, which internal corporate apps almost always lack.
    - DougWebb 10y ago
      You can add keyboard shortcuts to a webapp. What you can't do is control or override the keyboard shortcuts that the browser adds, and you can't make use of the full suite of possible keyboard shortcuts. I've looked at adding shortcuts to my webapps many times over the years, and it's never been worth the effort because the result is just confusing to the user.
- fbender 10y ago
  > (good multi screen/multi window support, better, good support for complex interactions like shortcuts, ctrl-clicks etc). Totally do-able on the web. It's often the web apps architecture that prevents a good UX, not the browser's capabilities (which are really good now). > Even on mobile […] we can't make web based apps that are better than native ones. That's an issue of the developer, not the browser itself. I do admit that Safari/iOS is really hurting here but you can work around that if you really want to (it will still be a sub-par UX, though).

alkonaut 10y ago

You wouldn't have to use antiquated tools and practices just to use desktop apps. I'm not arguing to use the old apps, I'm arguing that a lot of new development should be desktop when it's often made as web apps without thought. We threw all the good stuff with desktop out at the same time as we moved to intranets. You can still have centralized deployment, thin clients etc, but have the niceties of proper native apps (good multi screen/multi window support, better, good support for complex interactions like shortcuts, ctrl-clicks etc). Even on mobile where native has fewer benefits than on desktop we can't make web based apps that are better than native ones. A clean understandable web UI is good for a seldom used app, but a lot of the intranet apps are "constant use" and were faster to use in their legacy dos implementation than the newer web version. Browser hell just makes the problem worse.

donatj 10y ago
> A clean understandable web UI is good for a seldom used app, but a lot of the intranet apps are "constant use" and were faster to use in their legacy dos implementation than the newer web version. Browser hell just makes the problem worse. This. Click, wait, click, wait, click, wait is in no way better than how quickly you can fly with a well memorized set of keyboard shortcuts in a native app.
- nine_k 10y ago
  I use keyboard shortcuts extensively in gmail, jira, stash, and a bunch of other apps. There's no problem implementing it. The designer should just think about it.
- untog 10y ago
  This is not a web vs. native problem. You can implement keyboard shortcuts in a webapp. You can neglect to implement keyboard shortcuts in a native app. This is all about attention to detail, which internal corporate apps almost always lack.
  - DougWebb 10y ago
    You can add keyboard shortcuts to a webapp. What you can't do is control or override the keyboard shortcuts that the browser adds, and you can't make use of the full suite of possible keyboard shortcuts. I've looked at adding shortcuts to my webapps many times over the years, and it's never been worth the effort because the result is just confusing to the user.
fbender 10y ago
> (good multi screen/multi window support, better, good support for complex interactions like shortcuts, ctrl-clicks etc). Totally do-able on the web. It's often the web apps architecture that prevents a good UX, not the browser's capabilities (which are really good now). > Even on mobile […] we can't make web based apps that are better than native ones. That's an issue of the developer, not the browser itself. I do admit that Safari/iOS is really hurting here but you can work around that if you really want to (it will still be a sub-par UX, though).