Current Issue
The application of model matching principle in user interface design - Part 2 - 16 January 2008
by Liang Zhang
Read this article in Chinese (English editor: Anthony Sonego)
4. Understand the model matching principle from the perspective of programming language development
For programmers, a programming language is a software tool. Its interface consists of its lexicon, grammar and semantic rules. From this view, using a language to do programming is actually using that tool to accomplish something. As we will see shortly, different languages vary greatly in the degree of how they get close to programmer’s conceptual model.
4.1 From machine languages to assembly languages to high level languages
Assume that the problem to be solved by the programmer is to calculate the sum of two numbers. Let’s first examine machine languages. They are the ultimate implementation models for all programming languages. The implementation model of this “machine language” product is equivalent with its system model. So, it is the most difficult to learn. Programmers need to know how the machine instructions are composed from bit 0 and bit 1, and the meaning of each bit in the instruction.
The assembly language pushes the system model one step closer to programmers’ conceptual model. When using assembly languages, all the programmer need to know is to use the “mov” instruction to put a number into a register and use the “add” instruction to get the sum of the numbers stored in two registers. They need not care about how these “mov” or “add” instructions are translated into machine instructions. That is the job of the assembler program. But obviously, even with assembly languages, programmers still need to be familiar with the concept of “register” and the “mov” instruction, both of which don’t belong to the problem domain.
The system model and conceptual model are almost the same in high level languages, such as the C programming language. Programmers can use the following statement to get the sum of two numbers:
C = a + b
The following screen shot shows the differences among these three types of languages: From top to bottom:
the hex number in black background is the machine language (Intel X86 CPU),
the line “c = a + b;” is the C language.
the text in white background is the assembly language (MASM assembly language of Intel X86 CPU on Windows platform)
Figure 3：A comparison of machine language, assembly language and C language
With the ever more increasing complexity of the problem to be solved, programming languages keep developing in the following directions and pushing the system model toward the conceptual model furthermore:
4.2 From procedural languages to object-oriented languages
or complex applications, it is more natural and effective to do requirement analysis using object-oriented methods. It is also the way how people thinking. Object-oriented programming languages realized this and support it on both a grammar and semantic level, thus making the system model closer to the way how programmers think. For example, the entities in the real world have different properties and behaviors: an animal’s properties include its weight, height, age, etc, and its behaviors include eating, sleeping and running etc. In OO languages such as C++ and Java, programmers can define a class to model an entity by using class member variable to model property and using member methods to model behavior.
4.3 From 3GL to 4GL
ne of the most obvious features of 4GL languages, represented by PowerBuilder, Visual Basic and Dephi, is that they hide many implementation details of operating systems, especially when being used for developing applications of rich GUI. The following code sections compare how to change a window’s background color to black using PowerBuilder and C respectively.
In PowerBuilder, the following one line code can change a window’s background color to black, supposing “w_main” is a window object:
w_main.BackColor = RGB(0,0,0)
However, for C language, the following code in bold font will be needed to be inserted into the window processing function of the window (Suppose the window is a dialog box):
LRESULT CALLBACK About (HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
。。。
case WM_CTLCOLORDLG:
{
HGDIOBJ Brush = GetStockObject(BLACK_BRUSH);
return (LONG)Brush;
}
break;
}
return FALSE;
}
If the window is not a dialog box, then the way to change its background color will again be different. The reason for the complexity with the C language is rooted in the mechanism of how a window’s background is painted in the Windows operating system. When a window’s background is to be painted, the system will send a WM_CTLCOLORDLG message to the window. The return value after processing this message is a brush handle which will be used to do the painting job. If the user is programming in the C language, they have to know this mechanism in order to correctly change a window’s background color. While, with PowerBuilder, the simple assignment statement will handle this type of complexity for you.
4.4 From general purpose languages to domain specific languages
It can be said that domain specific language (DSL) is one of the ultimate goals of programming language development. It is trying to make the language consistent with the programmer’s conceptual model completely. Perhaps by that time, anyone familiar with the problem domain can be a programmer in that domain, as the concepts in the programming language are the same as in their daily work.
Currently available DSL includes: ABAP for SAP, Lex & Yacc for compiler development, SQL for database applications, etc. Let’s take a look at Lex for an example. Its application is for developing lexical parser for programming languages. Suppose variables in the new language consist of one or more English letters, then this requirement can be described by Lex as “[a-zA-Z]+”. The Lex compiler can generate the needed parser code (in C language) based on this description. In this example, “[a-zA-Z]+” is the description for the problem in the application domain and Lex supports it directly at language level, thus the system model and the conceptual model are almost the same.
5. Apply the model matching principle in product design
Obviously, in order to make a product’s system model consistent with user’s conceptual model, the primary task of the designer is to find out what the user’s conceptual model is. A prominent feature of user centered design methodology is that it pays great attention to the study of the user’s conceptual model. The following are some techniques which are often used to study the user’s conceptual model. Some might be more effective than others, depending on the products to be designed.
User interview: Have a face to face discussion with real users or potential users and listen to their requirements or expectations of products.
Field analysis: This method is especially useful when designing new products. This is because it is very hard for users to imagine the functionalities of a product which he or she has never seen before, while designers, by observing potential users in their natural environment and finding out the real interaction processes of their activities, can help them to fulfill that intention in a new way provided by the new product.
Analyze competitor’s products: Users may have already formed an expectation of a product if it has already been available on the market. So, by analyzing those products, you can find out those expectations indirectly.
Analyze user feedback of your existing products: These types of feedback include historical data from technical support and customer complaints. With the popularity of the internet, it will most likely include user’ comments posted in newsgroups or various online discussion forums. Studying this feedback can assist designers in uncovering their users’ unsatisfied expectations, thus helping them arrive at a more complete conceptual model.
6. Summary
For users, a product’s interface is tantamount with the product itself. Neither can they see nor do they care about the product’s internal structure and working principle. The primary task of interface design is to convert the concepts and behaviors (conceptual model) which can be understood by users to the implementation model embodied inside the product, so as to present to the user a product (system model) which is as close to the conceptual model as possible. Products designed in the above way can reduce users’ learning and memory burden, thus making the product easy to use.
Mr. ZHANG Liang is a senior software engineer at Sybase R&D center in BeiJing. He got his master's degree in Artificial Intelligence and Pattern Recognition in the National Laboratory of Pattern Recognition, Chinese Academy of Sciences.
Comments made
Possible Related Articles:
Jan
nice article.
Those model names are not really set in stone, which makes it all bit harder to discuss… i think :)
“The actual way that a system works from the programmer’s perspective: Norman called this the System Model; Cooper called this the Implementation Model; IBM called it the Programmer’s Model.”
http://www.lauradove.info/reports/mental%20models.htm