Enclosed below are two emails I received from Prof. Anand Patwardhan (School of Management at IIT-Bombay), who also happens to be a very good friend. The emails provide a lot of food for thought, especially in the context of what we want to do in Emergic and John Robb’s post on the Next Generation Desktop:
Most of the time we need to do very simple information processing tasks – write a letter, send an email, do some arithmetic, play a game. Sometimes, we need to do something more complex. This is as true with software as it is with hardware. And it is as true for enterprise software as it is for application software.
First thing we need to do is to separate the function from the application. That is, separate the task (or function) of writing a letter from the use of MS Word. To do this we need a different architecture for the applications, one in which functions can be invoked as required (again, server side computing will help here). Having done, this we perhaps also need to change the front-end completely from a computer-oriented desktop to a task or function oriented desktop. The digital dashboard should actually become a functional tool. Perhaps one could use a diary (personal blog format) to maintain the context, rather than a file system. So that even when I’m writing a letter, the previous context is available to me. Actually, I’m not completely sure about this – to the extent that we have migrated the office metaphor to the computer – tasks, corresponding to folders, individual items to files, I dont know if we can move completely to a diary orientation.
Second, we need to have a lot of application integration at the back end. So, that many things can happen automatically on the server side. For example, format conversions, or other kind of processing (virus checking etc.).
The second email:
It is actually very hard for developers to think of a user who is not like themselves. We are actually not representative users at all for Emergic. We have been used to a situation where we had to end up knowing a good bit of computers to really use them, and in situations where we dont, we are almost at the mercy of the machines, or the support people / system administrators. For a “real” user, the computer is a tool, to perform tasks or functions. Ok, so this is nothing new (Don Norman – Invisible Computer, Dertouzous – Unfinished Revolution), but what does it mean for us, and what can we do about it in practical terms?
So, with this in mind, let me try and put down what I think the Thin Client (TC) desktop should look like and do.
The TC desktop should have a diary, a writing area and a set of icons for functions, and a “command interpreter” of sorts for non-standard tasks. What might the standard tasks be? Depends on the user segment. I can think of groups of tasks, for example, communication tasks (email, chat, message), daily tasks (these are all related to the “diary” metaphor – would include, for example, to-do lists and appointments, daily accounts, and notes). Accounts is actually important. By this I dont mean Tally, nor do I mean MS Money and Quicken, but a simple tool where I can enter expenses and receipts and which understands what is being put in. MS Money and Quicken are good examples of what happens when we put everything but the kitchen sink in the application.
There is also a group of “common tasks” – this really depends on the context. Might include writing by default – but even there, customization is possible, for example, for secretaries there may be a separate button called write letters. This button might invoke the same application, but with a letter writing module, but in any case, the user should not worry about what is being run. If we really go segment-wise, I think we will find that are are a fairly limited number of tasks in all, spread over these three groups – communication, daily and common.
When it comes to the UI, in a sense, the advantage of Linux for us is precisely that it is modular and customizable. That is, we can layer our own UI over the X server.
Many of these ideas have been tried by Apple, but then it is a single piece – you cannot take apart the hardware / software bundle and reconfigure and reprice it the way you may want for the particular set of users you want to address.
This brings me to my next point, going beyond the UI to the application architecture and design. A product like MS Word is extraordinarily powerful and feature-rich. This is because the designers have had to figure out in advance all of the ways in which a user might use Word, because once the application is out there, it has to function by itself in whichever environment it is and for whatever use it is being put to. Emergic needs an application architecture which on the other hand, caters to really the least common denominator, only the core set of
features that all users will need. It needs a unified way to store data (perhaps XML), so that other applications can also access it and work on it for special purpose tasks. We need to be able to customize the application very rapidly – server based computing is an advantage here, as we dont have to worry about modifying the application on 100’s of clients.We need to replace feature-richness and consequent design costs by rapid specialization for particular settings.
So, as I see it, Emergic really starts looking like a software solution now, with a UI component (partly server based and partly on the TC), an XML-based data model for data storage and handling, and core and extended applications invoked by the user. There is, obviously, an OS there, but completely transparent to the user on the TC.
Many enterprise (and even consumer) applications are based on the notion of “automation”. Sure, some things can (and should be automated). But what I think is more important is for IT to assist the user, and not only automate. In trying to automate, we are in fact making it more difficult for people to use IT in the first place. Because, for example, we are asking business logic to conform to the information model embedded in the ERP. If you recall, this was exactly the difference between a transaction processing system and a decision support system that was brought out during our SME survey.
Whew, I think thats it for now! Btw, feel free to put the emails I’ve been sending you on Emergic – I’ve no idea how to create a blog, but I’d be happy to get and respond to comments.
