Faster than a bullet – on response times
If the hardware is sized correctly, our applications tend to be very fast. However, we may wonder if there is not a more important aspect to “fast response”.
In the traditional sense, response times are basically the time that the application needs to start or finish a response. Basically: you click on an icon and a list appears after n milliseconds (start). Or the full page display finishes after n milliseconds after the icon is clicked on (finish). Obviously, “icon” and “list” are just examples. There are software suppliers that (automatically) create a build (version) each night, test it (again automatically) and “throw away” if the buiId is slower than the previous one.
This is of course important, but maybe there is something that is more important.
The more important aspect?
There is a second aspect to timing: the time it takes a human (using the application) to respond. Think of this: in a previous version option X took 1 second, then person Y using it had to figure what to do and that took him or her 14 seconds. In a new version option X takes 3 seconds, but the figuring out bit is now largely done for him; it now takes 2 seconds. Though the option is now 3 times slower, the total time needed has gone down from 15 to 5 seconds. If Y does this 2,000 times a year, 20,000 seconds are saved. When calculated over multiple years, that single change represents a significant bit of time and money.
Infor’s applications are full of such time-savers, ranging from the presence of facets on lists to macros for the whole application over fine-grained access control. And many others.
What would you choose?
The obvious choice is of course: a fast aspect 1 and a fast aspect 2 (so 1+2 seconds). The best of both worlds. That’s what we strive to build into our applications. But in a world where an upside often brings along a downside: if you had to choose, which one would you pick?
- Library and Information Systems