Let’s approach to user’s interface design from the most radical standpoint. I do not mean any particulary radical view but non-compromising, no-prisoners-taken approach.
Users are interacting with controls and then observing the results of theirs actions through output device. That’s all users do, don’t they? Well, then the device to work with the users must comprise of an output device and input controls. Funny enough, that’s exactly how it was built: multiple terminals all hooked up to a mainframe. So far the approach doesn’t seem to be radical at all but I will go on.
What has happened later were two things: real radical change of of userbase and, as a direct consequence of it, introduction of the managers. Regular non-technical full-of-crap business managers.
That’s when workaround concept has been born. And here I will try to dive into the depth of distinction between the concept of abstracting or virtualization and one extremely nasty implementation of it, that is cache or proxy.
Abstraction is good. Abstraction is a building block of system architecture. Whenever we face the tasks of scalability, performance, reliability or redundacy, which are four major design/architecture tasks, we use virtualization/abstraction to solve it. IPs are abstracted from MACs in TCP/IP, logical partitions are abstracted from physical disks in RAID, messaging queues are freeing us up from a transport implementation, code is compiled on the fly based on local architecture. All these are notorious applications of abstraction. They are addressing the issues that belong to the domain of system architecture and design.
And there is cache or proxy. That is a workarounds per se, patches for poor engineering, helpers to insufficient resources, crutches to someone’s premature obligations. Cache or proxy is a very particular type of abstraction:
1. It delivers a compromise, half-and-half solution to the issue.
2. It addresses the lack of the resources. There is always another solution that utilizes more resources but delivers the result in full.
3. It makes an assumption that some data is more static than the other
User’s interface should not be using cache because the assumptions that the very concept of cache is built on, are wrong. I have just deleted a passage why cache proxy worked and still work nowadays. It’s more or less obvious from the previous statements. Because things should get done. THe question is why doesn’t it work any longer. ANd surprisingly, the answer just repeats itself: because things should get done.
With this in mind let me draw the conclusions of abandoning cache approach.
Disable background execution — that is the first consequence of radical user interface design. If users doesn’t work with it then he doesn’t need it. Users shouldn’t wait and they shouldn’t be distracted by some nightly backup/antivirus/indexing/whatever processes on their machines if they didn’t just asked their device to do so.
Increase Bandwidth/Compress data with the speed which is significantly faster than bandwidth. So, 3G seems to become more and more popular — and so iPhone designers switched from EDGE to 3G. IT is still insufficient but it’s much better.
Remove local storage. What is it that should be stored locally? Right, it is precisely nothing. Nothing should be stored locally — for the end user. The end user has nothing that needs to be stored on his local flash card/hard disk/usb stick. Because he has a way to get it whenever he needs it from the location which is dealing with the tasks, specific to storage of the data. e.g. virus checking, integrity guarantees, archiving, versioning, etc
Kill VNC(Citrix)/Add really swift video output devices and set all video protocols to be abstracted from the hardware.
The examples of radical user interface thinking would be SideKick phone from T-Mobile where most of the functions are executed on the server, rendered and then delivered to the client. Another example would be iPhone — not of implementation yet, but of an approach. Interestingly, these solutions are developed on the markets with extremely high competitiveness, markets that were real drivers of technological changes lately
iPhone is not an ideal device, of course. But it is good — it tries to address almost all items I have listed. Alas, the requirements of the moment are prevailing and we are getting file managers, Remote VNC and what not. But the ideas that were used when building this device, or the extrapolation of the ides, worth following up.