Jul 3, 2004 - Index Terms â User Interface, Touch Screen, Mobile devices. ... single-layered touch screen based UI is presented in Section 3. The interface ... maximizes what we know about human strengths, for example, .... If the search option is selected, the function will go through the .... Change in data-set-ready. 1.
IEEE Transactions on Consumer Electronics, Vol. 50, No. 4, NOVEMBER 2004
1156
Design and Implementation of User Interface for Mobile Devices P. H. J. Chong, P. L. So, P. Shum, X. J. Li, and D. Goyal Abstract — The inspiration behind the wireless world came from the need to provide users with mobility and to offer an alternative to the limitations of wired mediums. As a result, there are various wireless mobile technologies like GSM, GPRS, WLAN, and Bluetooth available. The user interface and the size of mobile devices are one of the main concerns in the design of mobile devices. In this paper, we design a singlelayered touch screen based user interface. Unlike conventional multi-layered user interface, a single-layered user interface will make the user interface more user-friendly with smaller size. The memory requirements can be further reduced by implementing it in low-level languages. After design and implementation of the user interface, we integrate the user interface with the hardware of mobile devices through serial port with the help of AT commands. Index Terms — User Interface, Touch Screen, Mobile devices.
I.
INTRODUCTION
Mobile Communication technology is undoubtedly one of the most significant developments in the electronic system field in recent years. All sections of mobile communications are growing rapidly. Apparently, the growth of voice applications has benefited us a lot. However, the data applications have lagged behind. Recently, the system operators have made provisions to transmit data over the cellular systems, which are primarily designed for voice. To provide mobile data transmission, where people can transmit and receive information wherever they are and whenever they like to, mobility is at the heart of these wireless systems. The size and the user interface of mobile devices are the main concerns in the design of mobile devices. With the advancement in semiconductor technology, its size has reduced a lot. But we still intend to make it as small as possible. We can actually reduce it further by making a touch screen based user interface. The goal can be achieved because it will avoid the need of physical keypad, which takes a lot of space. The other important concern in the design of mobile devices is the User Interface (UI), because it is the one with which users have to interact all the time. The user interface design that is commonly used in mobile devices is based on multi-layered approach, which is not very user-friendly. Therefore, a well-designed single-layered user interface will be more user-friendly than the conventional one and having edge over others. In this paper, we design a single-layered touch screen based user interface. Compared to conventional multi-layered user interface, it can help us in many ways. For example, singlelayered touch screen can increase the size of screen without increasing in the overall size of mobile device; and that would Contributed Paper Manuscript received July 3, 2004
be very beneficial especially for Internet access services in handheld devices. The memory requirements can also be further reduced by implementing it in low-level languages. After design and implementation of user interface, we integrate the user interface with the hardware of mobile devices through serial port with the help of AT commands. This paper is organized as follows: In Section 2, we analyze the requirements and needs for the design of an efficient user interface for mobile devices. The design of a user-friendly single-layered touch screen based UI is presented in Section 3. The interface technique between UI and the hardware is explained in Section 4. Section 5 describes the handshaking sequence for the design of applications for mobile devices. Finally, concluding discussion is given in Section 6. II. DESIGN REQUIREMENTS FOR AN EFFICIENT USER INTERFACE User Interface (UI) is a part of an application that the user sees and interacts with. It is related to the underlying structure, architecture, and code that make the software work. The interface includes the screens, windows, controls, menu, metaphors, online help, documentation and training. Anything the user sees and interacts with is part of the interface. An intelligent interface is easy to learn and use. It allows users to do their work or perform a task in the way that makes the most sense to them. Furthermore, it is specifically designed for the people who will be using it. In other words, it maximizes what we know about human strengths, for example, analysis and decision-making. It also minimizes what we know about human limitations, for example, memory and complex computations. It takes the environment, tasks, and experience of the people using the product into account in its design. Well-designed interface reduces errors, training time and costs. It makes people more productive and results in superior customer services. With intelligent interface design, we can improve software’s competence. A. SAPCO To recognizing a well-designed UI, whether one is better than another, seems to be driven by a small number of salient characteristics evident on a half-hour tour of an application. The characteristics of a good UI are based on five major principles with simple, aesthetic, productive, customizable and others (SAPCO). Although some computerized user tasks are relatively complex and cumbersome, the real world counterparts of software objects are relatively simple. Software objects provide productivity enhancements and augmentations without unnecessary complexity in a UI [1]. Minimalism and layering are used extensively in an initial presentation and interaction
0098 3063/04/$20.00 © 2004 IEEE
P. H. J. Chong et al.: Design and Implementation of User Interface for Mobile Devices
style. Key guidelines influencing the principle of simplicity are: • Minimal and layered objects • Err on the side of simplicity • Aesthetic Key guidelines influencing the principle of aesthetics are: • Less like a computer artifact and more like a user object • Enticing (inviting, appealing) • Visualized • Productive Key guidelines influencing the principle of productivity are: • Being task sensitive • Using the 80/20 rule for interface optimization • Reducing work steps to the absolute minimum • Providing convenience features • Forgiving Software objects are available in various forms in order to suit individual needs. Software UI objects as well as end users created objects are tailor able to: • Follow a toolbox model in the design • Include entry-level features of initial objects • Provide multiple views, fonts and colors to select from • Be progressive disclosure gradually to reveal all features In addition to the principles of simplicity, aesthetics, productive, and customizable, there are countless other principles available. The majority are variants of the SAPC. B. Interface Design Intelligent interface design can be divided into three phases: • Analysis • Design • Construction In the analysis phase of intelligent interface design, we analyze about the requirements of customers, what they want, what the problems in the existing one are etc., because without this we cannot design an interface that is better and easier to use. After analysis, we take all the information and then shape it to an interface. Finally, we should construct the software for the desired user interface [2] depending upon the hardware and software requirements etc. III. DESIGN AND IMPLEMENTATION OF USER INTERFACE
For a good UI design of mobile devices, besides the constraint that it should be as user-friendly as possible, we have another constraint that it should be as code-optimized as possible. This is because mobile devices, being of small size, are having limited memory. Among the three available topologies of UI, which are mouse-based UI, command-based UI and touch-screen-based UI, the last one can be an ideal choice for mobile devices. As we know, touch screen eliminates the requirement of physical keypad, and this helps reduce the size of the device and equivalently increase the screen size.
1157
From the layman point of view, most of the user interfaces that are used by mobile devices are not user-friendly enough. One possible of this is that they are multilayered, where before performing any operation, the user should know where that function is and how to find that. In our design, we implement a single-layer based UI. In this single-layer approach all the functions are right in front of the user, so users can choose the function straightaway to perform what he wants. The functions that we have included in the designed user interface for the Bluetooth and GSM/GPRS related environment are: • making a call manually or through the entries saved • receiving a call • terminating a call • sending and receiving short messages • data transfer through Bluetooth • adding a record • searching a record • deleting a record • listing of last dialed entries All the functions are implemented in C language so that it should be very efficient in terms of memory requirement and can be easily ported to most hardware, which support C compiler. Fig. 1 shows the flow chart of a designed function to compose and send a message. It will take care of two situations whether the phone number of a person, whom the user wants to send a message to, is already in the record or is a new number. First, it will prompt the user to enter the message, and scan it one by one, print it and store it, until the user presses the enter button. After that, it will ask the user whether he wants to search the number or wants to enter the number manually. If the search option is selected, the function will go through the complete search sequence and send the message to the selected number. Otherwise, it will ask the user to enter the number, and then it will go through the complete manual operation: scan the number, print it, store it temporarily and send the message to the number. In our design prototype, for sending message, it will use the designed hardware, and message can be imported from PC with the help of AT command and serial port programming. The other functions are also designed in a similar way. For the ‘adding a record’ operation, we can add as many records as we want by varying the array size and it will store up to eight alphabet name and contact number of up to eight digits. In the ‘deleting a record’ operation, it will first show all the entries that the user has saved, by scrolling up and down key one by one. Then, the selected entry will be deleted from the record and then all other entries will be moved one level up to enable continuous display of the records. For making a call, it uses GSM/GPRS compatible hardware. Here it is also possible to make a call from PC to AT commands and serial port programming. To make a new call manually, it prompts the user to save the number for future use. Basically the designed UI has five buttons as shown in Fig. 2. The Up (U) and Down (D) buttons are to move the cursor up and down respectively; along with that they are also used for showing next and previous entries wherever there is more than one entry. The Enter (E) button is basically to select any
1158
IEEE Transactions on Consumer Electronics, Vol. 50, No. 4, NOVEMBER 2004
operation, whereas Cancel (C) button is for canceling any operation. The Off (O) button is for turning off the mobile device.
that contains all the required keys like all alphabets and all numeric numbers. The software keypad is shown in Fig. 3. Every key is assigned a specific position on the screen.
Fig. 3. Designed Software Keypad.
In any operation there is a need of keying in something, the software keypad will be popped up. Every position of the software keypad has a specific meaning. Whenever a user presses a particular key in a particular position, the specific key will be identified in this way: first, find the coordinates of the pressed location, then compare it with the database and finally find out the meaning assigned to that location. The driver will sense the location and identify which operation the user wants to perform or which key the user wants to input. Accordingly, that task will be performed. IV. INTEGRATION BETWEEN USER INTERFACE AND HARDWARE
Fig. 1. Flow Chart of composing and sending a message.
Fig. 2. Designed user interface model.
We have implemented the designed user interface in a lowlevel language to make it code efficient. It is able to keep mobile devices as small and lightweight as possible. Besides that, it can be easily ported to most of the hardware because of its operating system independence. It would be very beneficial for designing applications for the environment where various communication technologies and hardware have been integrated together. The user interface that we have implemented is touch screen based, so there is no need of physical keys. We have written a driver for the emulation of all the required keys and sensing of the corresponding key. We have designed a software keypad
To run the applications, we need to integrate the designed UI with the necessary hardware. The hardware for mobile devices is GSM/GPRS supported, that supports voice and data services. Fig. 4 shows the block diagram of GSM/GPRS enabled software. For Bluetooth applications, we have used BlueEZ Module developed by Excel Point and Development Kit designed by Cambridge Silicon Radio (CSR). All the information is handled in the form of a single character. To implement serial transmission and reception of data, first each byte is converted into a stream of 1s and 0s, bits that can be transmitted over the communications medium. The UART device actually performs this function. Here logical 1 and 0 are referred as MARK and SPACE respectively, and change in status from MARK to SPACE will make the receiver to understand that it is the beginning of a character and known as a start bit. A pattern of bits follow the START bit to represent the character and that bit is known as PARITY bit. Finally, the line transition to its idling MARK condition, which represents the STOP bit and indicates the end of the current character. Sometimes two STOP bits are used, but it is not a great deal whether you use the one or tow STOP bits as long as the transmitter and the receiver use the same number. The number of bits used for representing the character is known as word length. It is usually seven or eight. In our design, we use character of word length equal to seven. The PARITY bit is for the purpose of error detection. Both the transmitter and receiver must know the duration of bits; otherwise they will never be able to extract the proper information. Therefore, they must know the baud rate of each other. Serial port supports different baud rate, and we have chosen baud rate equal to 9600 bps (for binary transmission, 1 symbol/second =
P. H. J. Chong et al.: Design and Implementation of User Interface for Mobile Devices
1 bit/second), for both PC and the hardware board. Along with this internal clock, the two ports should not be very different from each other; otherwise, it will cause frame error. Because the serial port samples the input register once every cycle upon seeing the START bit, to read the next bit. Note that the length of that cycle is determined by the clock that controls the system. If the receiving clock rate is not close enough to the transmitter’s clock, a bit gets overwritten and it will create a frame error.
1159
•
AT+IPR=9600 /*It will make baud rate of hardware equal to 9600bps. */ • AT+ICF=3,1 /*It will enable the setting at the hardware, where a character is equal to 8 bits, one stop bit and even parity. */ The Status of a Serial Port can be known with the help of various bits in register AL and AH. As shown in Fig. 5, we can know about the status of communication. TABLE 1 Encoding of Various Bits
Fig. 4. Block Diagram of GSM/GPRS Enabled Software.
A. Serial Port Initialization at PC Side We have used here first serial port that is number zero and set it to baud rate 9600 with even parity, seven data bits and one stop bit. The default setting of the first serial port is generally 1200 baud with even parity, seven data bits and one stop bit. Interrupt 14H, service 0 is used to initialize a serial port. As with other BIOS interrupts, the AH register is used to hold the service number [3]. The AL register holds the initialization parameters that are encoded into one byte as shown here in Table 1. The number of data bits is set by the code in bits l and 0 of an initialization byte. Only two of the four possible bit patterns are valid. If bits 1 and 0 contain the pattern "10", seven data bits are used. If they contain the pattern “11”, eight data bits are used. The number of stop bits is determined by bit 2 of the serial port of the initialization byte. If bit 2 is 1, two stop bits are used; otherwise, one stop b it is used. The parity is decided by bit 3 and 4. If it is “01” then it is odd parity and if it is “11” then it is even parity. The baud rate is decided by the most significant 3 bits as given in the table. After serial port initialization, the required hardware can be interfaced to the user interface through the serial port. B. Serial Port Initialization at Hardware Side As mentioned earlier that for reliable communication between transmitter and receiver, the baud rate and other settings should be the same at the both sides. Now to set these settings at the hardware side, we can use the AT command. The header format for that is shown below:
Line Status (AH) Meaning when set Data ready Overrun error Parity error Framing error Break-detect error Transfer holding register empty Transfer shift register empty Time-out error Hardware Status (AL) Meaning when set Change in clear-to-send Change in data-set-ready Trailing-edge ring detector Change in line signal Clear-to-send Data-set-ready Ring indicator Line signal detected
Bit 0 1 2 3 4 5 6 7 Bit
0 1 2 3 4 5 6 7
Fig. 5. Meaning of various bits
1160
IEEE Transactions on Consumer Electronics, Vol. 50, No. 4, NOVEMBER 2004
C. Receiving and Transmitting Bytes BIOS interrupt 14H, service 2 is used to read a byte from a serial port. Again, the serial port to use is specified in the DX register. Upon return from the interrupt, the character read is in AL. As with transmitting a character, upon return, bit 7 of AH is used to indicate success or failure. BIOS interrupt 14H, service 1 is used to transmit a byte through the serial port, specified in register DX. The byte that we have to send must be placed in AL register. The function SPORT is used to transmit one byte through the specified serial port. In the functions both transmitting and receiving a character, register DX is used to specify the serial port that has to be used. V. IMPLEMENTATION OF DATA EXCHANGE AND HARDWARE HANDSHAKING The protocol used for transmitting information is explained below. There are six active signals used for the control of data transfer between the PC and the GSM/GPRS enabled hardware. • Request to Send (RTS): This signal is issued by PC to indicate that it is ready to transmit data. • Clear to Send (CTS): This signal is output by the hardware to acknowledge that it is ready to receive data. • Data Carrier Detect (DCD): This signal is output by the hardware to indicate that it has detected a valid carrier. • Data Terminal Ready (DTR): This signal is output by PC, which indicates that it is present and ready for communication. • Data Set Ready (DSR): This signal is output by the hardware in response to DTR to indicate that it is on and connected to the communication channel. • Ring Indicator (RI): This signal is output by the hardware and is active in synchronization with the telephone ring signal. To provide the reliable transmission, we have used here Hardware Handshaking with the help of RTS and CTS signals. Without any flow control it may lead to overrun and unreliable transmission. Hardware handshaking ensures reliable transmission, because whenever a transmitter has to send something, first it will send RTS signal. If the receiver is ready to receive the data, it will acknowledge the transmitter by sending the CTS signal. Thus, the transmitter will know that it can transmit [4]. If the transmitter does not get CTS signal in response to RTS signal, then it will understand that receiver is not ready to receive. So, it will not transmit. Although RTS-CTS hardware handshaking will reduce the effective transmission speed, it provides a reliable transmission by avoiding overrun error. The sequence used between PC and hardware to make an outgoing call is shown in Fig. 6. In the beginning DTR is active. If the hardware device is connected and turned on, it responds with DSR [5]. This establishes the connection between them.
Fig. 6. Sequence for outgoing call.
The number selected is dialed with the help of designed UI and sent to the GSM/GPRS enabled hardware with the help of AT commands. ATD command is used for dialing a number. The Format is like this: “ATD< Destination phone Number>; \r “ When the called party responds, it makes DCD signal active. So, the connection between the called and the calling party is established. To start transferring data, it makes RTS active and then waits for CTS active response signal. Then the handshake protocol between the RTS and CTS is performed for the transfer of data. For receiving a call it uses “ATA” command, and it will send this string and then the call can be answered. When the data transfer is complete and the connection is to be broken, it sends the on-hook command, through the ‘CANCEL’ button of user interface. Actually for terminating a call, it sends the string “ATH”, which will terminate the call. For sending a message with the help of UI, AT command format is like as shown below. “AT+CMGS=\ < phone number> \r”. The handshaking sequence between PC and hardware is similar to what we have discussed for making a call, but the difference will be in the header of signal that we are going to transmit, which would be created the pattern as shown above. VI. CONCLUSIONS User interface (UI) is one of the most critical parts of all mobile devices, because users have to interact with it all the time. An utmost care in its design is required in order to make it as user-friendly as possible. Besides that, it should be code optimum as well so that it can save memory space
P. H. J. Chong et al.: Design and Implementation of User Interface for Mobile Devices
requirement, mobile devices are always having a memory constraint. To make our user interface more user-friendly, we use a single-layered design approach, unlike conventional multiple layer approach. To make it code optimum, the code is written in a low-level language, and then it will occupy minimum memory space. To reduce the size of mobile devices, we design and implement a touch screen based user interface, unlike conventional keypad based user interface. It completely eliminates the need of physical buttons, because all the buttons are emulated with the help of driver written for that. It can help us in many ways, like to increase the size of screen without any increase in size of mobile devices for the same overall size and that would be very beneficial especially for Internet access services in handheld devices. After design and implementation of user interface, we integrate the UI with the hardware of mobile devices through serial port with the help of AT commands. Since serial port communication is very economical but unreliable, hardware handshaking protocol is designed and implemented for all types of communication between PC and hardware in order to make it reliable. The GSM/GPRS supported hardware is used that supports both data and voice services. Lastly, the designed user interface is also having support for designing future applications related to mobile devices. So it can be used as an emulator as well for designing future applications for the environment where various communication technologies have been integrated together. For future research, there are several points that we want to emphasize: • Integration of WLAN protocol along with GSM/GPRS and Bluetooth. • Provision of switching between various integrated technologies automatically. • Introduction of more applications for GSM/GPRS and Bluetooth integrated environment. REFERENCES [1] [2] [3] [4] [5]
J. Pinson, Designing Screen Interfaces in C, Prentice Hall: New Yprk, 2000, pp. 64-91. M. J. Rochkind, Advanced C Programming for Displays, Addison Wesley: New York 1998, pp 423-494. M. Alimazide, The 8086 IBM PC and Compatible Computers, Prentice Hall: New York, 1994, pp. 112-118. V. K. Garg, Principles and Applications of GSM, Prentice Hall: New York, 1998, pp 424-438. B. Barry, Microprocessor/Hardware Interfacing, Addison Wesley: New York 2000, pp 212-228.
Peter H. J. Chong (M’00) was born in Hong Kong, China, on June 4 1970. He received the B.Eng. (with distinction) in electrical engineering from the Technical University of Nova Scotia (currently Dalhousie University), Halifax, NS, Canada, in 1993, and the M.A.Sc. and Ph.D. degrees in electrical engineering from the University of British Columbia, Vancouver, BC, Canada, in 1996 and 2000, respectively. Between July 2000 and January 2001, he worked with Advanced Networks Division at Agilent Technologies Canada Inc., Vancouver, BC, Canada. Between Feburary 2001 and May 2002, he was a Research Engineer in the Radio Communications Laboratory at Nokia Research Center, Helsinki,
1161
Finland, and was involved in research on WCDMA and standardization. Since May 2002, he has been with the School of Electrical and Electronic Engineering, Nanyang Technological University, Singapore, as an Assistant Professor. His research interests are in the areas of wireless and mobile communications systems including channel assignment schemes, radio resource management, multiple access, and mobile ad hoc networks. P. L. So (M ’98, SM ’03)joined China Light & Power Company Limited, Hong Kong as General Assistant Engineer in 1980 and later as Second Engineer working in the field of power system protection. He left this company in 1991 to further his studies in the U.K. He received his B.Eng. degree with first class honors in Electrical Engineering from University of Warwick in 1993, and his Ph.D. degree in Electrical Power Systems from Imperial College, University of London in 1997. He is currently an Assistant Professor in the School of Electrical and Electronic Engineering, Nanyang Technological University, Singapore. His research interests are power system dynamics, stability and control, FACTS, power quality and power line communications. Ping Shum received his BEng and PhD degrees in electronic and electrical engineering in 1991 and 1995, respectively, from the University of Birmingham, United Kingdom, where he remained as an honorary postdoctoral research fellow. In 1996 he carried out research in semiconductor laser and high-speed optical laser communication with the Depart of Electrical and Electronic Engineering. Hong Kong University, as a visiting research fellow. Since July 1997, Dr. Shum has been with the Department of Electronic Engineering, Optoelectronics Research Centre, City University of Hong Kong. In 1998, he has received the IEEE EDS/MTTs India Chapter best paper award for his paper at Photonics-98. In 1999, Dr. Shum became an assistant professor with the School of Electrical and Electronic Engineering, Nanyang Technological University. In June of 2002, he was appointed as a director of Network Technology Research Centre. Dr. Shum received the National Young Scientist Award in 2002 for his achievement in Next Generation Optical Communication Technologies. His research interests are optical communications, nonlinear waveguide modeling, fiber gratings, and wavelength-division multiplexing communication systems. Dr. Shum is a member of IEEE and SPIE.