3 ms·
Quote: It wasn’t even that slow. Something like a quarter-second lag when you opened a dropdown or clicked a button. But it made things so unpleasant that nobod
by tabtab 7y ago
Quote: It wasn’t even that slow. Something like a quarter-second lag when you opened a dropdown or clicked a button. But it made things so unpleasant that nobody wanted to touch it.
I'm skeptical that's the reason they didn't use it unless it's a high-volume application. Like everything in IT, it depends.
A high-volume app definitely needs attention to response and performance because employees will be wasting tons of hours if it's not. That's why primary applications should probably be desktop client-server applications, where it's easier to control the UI. But that's typically only roughly 1/4 of all apps used by an org.
Something used only occasionally, such as for customers with special conditions, a somewhat sluggish web app is probably fine. If it's easy to make it snappy, great, but not everything is, due to our annoying web (non) standards[1]. If it takes 100 hours of programming to reduce 50 hours of UI waits over say a 10 year period, then the org doesn't benefit. 10 years is a good default rule of thumb duration for software lifetime. Your org may vary. Remember to include program maintenance, not just initial coding.
In short, use the right tool for the job, and do some analysis math before starting.
[1] My "favorite" rant is that web-standards suck for typical work-oriented productivity applications, and need a big overhaul or supplement. Nobody wants to solve this.
- mcguire 7y agoI'm sorry; are you saying that electronic patient care reports are not a "high volume application", that they should be "desktop client-server applications," or that the statements by the users about why they don't use the system should be disregarded?
- tabtab 7y agoI don't have the usage & programming labor stats to make a definitive statement on that particular application including the size of the org using it. My main point was that "it depends" and should be subject to further tradeoff and business analysis rather than "X is always bad". A quarter-second lag does not sound like a significant problem to me, and may require a lot of IT funds to remove. Often such is only justified if it's a high-use application. Would you agree that 100 hours of extra programming to save 50 hours of data entry time is usually not worth it (all else being equal)? If so, let's start there and slice into further factors. Please don't give me bad scores for trying to be logical and rational, people! Resources are limited, orgs have to spend with care. Sure, it's nice job security for us IT people if orgs spend big bucks to make all apps snappy, but from a business and/or accounting standpoint, it could be the wrong decision. You view the world different when your money is on the line. If you know a way to make all apps cheap, good, AND snappy at the same time, let's here it! I'm all Vulcan ears. Note that one can make web apps snappy, but there are often maintenance and/or creation time tradeoffs for doing such. A few well-run shops do it well, but most shops are average-run.
- tabtab 7y agoCorrection: "let's hear it" instead of "let's here it". Modnays.