How to Build a User Friendly Application Interface

Why Using Regular Statement String (RSS)

By Liu Rui
Jan.18 2004

As a ten years experienced developer, I am still puzzled by one question essential to software productivity. The question is "how to build a user friendly application interface". In fact, there are two kinds of friendly application interface: one is "human user friendly" ; and the other is "computer friendly". The latter is used for non creative, complicated, and automated development work, which is not discussed in this article. So what is a human user friendly application interface? As I know, it should be an application interface which is easy to learn, to develop, and to maintain. It will greatly ease the burden of developers and users. Here I am trying to give some new, interesting, and maybe unconventional guidelines to show a possible way to build user friendly application interfaces, and sell my idea of Regular Statement String (RSS) solution as well.

One thing I should consider is the makeup of the application interface. I will give three suggestions for it.

Several days before on a plane to Shanghai, I met a US woman of Chinese origin, who can speak very fluent Chinese (much better than my English). Once I saw the air hostress asked her to "open Zhe-Yang-Ban", and said two times, the woman was still confused. So I told her just to open the cover on her side window. "Zhe-Yang-Ban" is a proper name in Chinese which she does not understand, and therefore got confused at all. Similarly, if we use too many macros, nested structures, diverse types, and large number of positioned parameters to construct application interface, I am sure it will confuse most developers. So my first suggestion is: It's better to eliminate unnecessary rules and conceptions from the application interface. With RSS solution, we only use few conceptions such as key, value, and array with very simple syntax.

Some most headache things are resource management and error control. Sometimes I found a half of program source code is doing these things. It is really very boring. So my second suggestion is: Try to let the service program to take the most responsibility of resource management and error control. With RSS solution, there's no need to construct and destruct objects, and the internal return code does a lot of work of error controls. Using Java is also a good choice. Java is very good at object lifecycle management, and developers do not need to write code to destruct garbage objects.

A thinner schoolbook is usually easier. But if that book only includes outlines and summaries, it will not be so easy to learn and understand. The same is as in software development, so my third suggestion is: Make sure to let your code more expressive. Using a lot of comments is a good idea. RSS solution uses free style, runtime binding named parameters with the weakness of some performance issues.

The other thing I should consider is the platform or infrastructure of the application interface. I will give another three suggestions for it.

From a developer's view, OOP is a very good method. However, it's only a myth that at every time OOP is the best method. So my fourth suggestion is: Find out whether to use OOP method or not. A rookie will get lost to face thousands of object class or interface definitions with thousands of properties and methods inside it. But if you show him a step by step way, he or she will be able to get to the destination. A hierarchical API manual system is also very helpful. Process oriented programming interface is usually easier than object oriented programming interface to build reliable application. However, object oriented programming interface is better at resource management and producing high performance code.

Only a few APIs such as JDBC, SPEC1170, and SOCKS can be used in different platforms and systems. These APIs are proved to be high valuable. So my fifth suggestion is: A reusable and portable API is much valuable. After all, few APIs can be accepted by most system vendors. SPEC1170 is accepted by most UNIX vendors but not Microsoft. There are too much difference in SOCKS between UNIX and WINDOWS, and it is not exactly the same between different brands of UNIX. Why it is so difficult, I think one major reason is implementation. It is very difficult for other vendors to accept all syntax, types, and structures defined by the original author, when they make a new implementation. With RSS solution, there are not such syntax, types, and structures. The service code and client application code are decoupled using a runtime binding mechanism. So it's much easier to build reusable and portable applications.

There are so many languages in the world such as Chinese, English, French, Spanish, Russian, and so on. Similarly, there are also tremendous languages in the computer world, such as Java, C, C++, C#, Basic, Java Script, COBOL, PERL, PHP, PASCAL, and so on. And there are also a lot of useful special languages such as SQL, HTML, XML, EDI, and so on. There will not be only one language in the world or computer world. So my sixth suggestion is: A language neutral API is welcomed by more developers. This is one of the strong points of RSS solution. The same manual can be shared by developers using different programming languages.

I hope the six suggestions may be useful to your development work. We can argue over it.