MobileDeck: Turning SMS into a Rich User Experience

Daniel Risi
Nokia Technology Institute Rd Torquato Tapajos 7200 69048-660 Manaus, Brazil +55 92 8136 9378

Mauro Tefilo
Nokia Technology Institute Rd Torquato Tapajos 7200 69048-660 Manaus, Brazil +55 92 8171 0137

ext-daniel.risi@nokia.com

ext-mauro.teofilo@nokia.com

ABSTRACT
This paper describes the concept and the technological solution used in MobileDeck, a content request and delivery system designed for emerging markets, which uses SMS as the main communications channel. MobileDeck consists of a mobile application with a graphical user interface dynamically integrated with a content providing server. The effectiveness of this system as a way to enhance the end-user experience is demonstrated by the results of two different studies.

data feed to a rich application. In that sense, it offers a new userfriendly channel for several existent SMS services like news, horoscope, promotions and so forth. Besides a general description of the technological approach used in MobileDeck, this paper aims to demonstrate the potential effectiveness of this kind of platform as a relevant communications medium. In order to achieve that, two different studies are presented: a usability test conducted during project development at Nokia Technology Institute (INdT) and a market research made prior to the commercial release of the product.

Categories and Subject Descriptors

D.5.2 [Information Systems]: Information Interfaces and Presentation input devices and strategies, screen design, interaction style.

2. MOBILEDECK
The key idea behind MobileDeck is to provide an engaging frontend environment for requesting and receiving content via SMS. On the client side, it consists of a mobile application capable of displaying both textual information and graphics using predefined layouts that are accessed through instructions contained in a binary SMS. In other words, every time the user requests a service, the application sends an SMS that is received by a specific server, and the response is again redirected to the application. The returning SMS acts like a script that mounts and feeds the next screen with the appropriate content. This solution can be explained through the example in figure 1. From the main menu, which is a grid of icons, the user can choose one of the services, e.g. horoscope. That procedure activates the service screen (in this example, another grid menu). Once the desired content is chosen, the application requests the data by sending an SMS to a predefined short code. That request is then processed, while the application displays a receiving data feedback. When the response is received by the application (binary SMS), a result screen is populated with the respective data.

General Terms
Design, Reliability, Security, Experimentation, Human Factors.

Keywords
Mobile human computer interaction, mobile communication, SMS technology, mobile usability. wireless

1. INTRODUCTION
Short Message Service (SMS) has long been established as the de facto standard for sending and receiving text messages in mobile phones. In 2007, it was used by 74% of active users, with an average 2.6 SMS sent per day per person across the whole mobile phone subscriber base [1] and [2]. As one of the most widely adopted communications services, it has been successfully used for over a decade as marketing and services channel [3]. The fact that SMS has a relatively limited set of features basically a text string of 160 characters seems to be compensated by at least two factors: its huge active users base [4] and its high response rate [5]. In emerging markets, those characteristics are especially crucial when designing mobile services and advertising campaigns, considering that mobile Internet is still gaining momentum [6]. In that scenario, text messaging is the most viable way to reach larger audiences, albeit compromising a considerable portion of the engagement effect [7] and [8]. MobileDeck, initially introduced in the Brazilian market, where actually has more than 100k active users, is an end-to-end solution designed to address that issue, enhancing the SMS experience by adding a Graphical User Interface (GUI) to it. This implementation allows text messaging to behave exactly like a
Copyright is held by the author/owner(s). MobileHCI 2010 September 7 - 10, 2010, Lisboa, Portugal. ACM 978-1-60558-835-3.

Figure 1. Example of a service being accessed (horoscope)

All the SMS traffic involved in this data request/receive process is thus transparent to the user. The response time is usually just a few seconds, so that the whole experience is extremely close to accessing content directly from the web using a mobile device. From that perspective, it is important to stress that this solution was designed for emerging markets, where fast data networks are still inaccessible to the majority of the population. Depending on the kind of service/content being accessed, different kinds of layouts will be displayed. This includes list views, input forms, and the above-mentioned icon grids and result screens. Some services will require accessing information from the server prior to the final result, in order to populate the next screen with the respective options. This situation can be exemplified by the location finder service, in figure 2.

important to remind the user every time a service is being charged, since only part of the SMS traffic is actually paid by the user.

3. MOBILEDECK ARCHITECTURE
MobileDeck is divided in four subsystems: a) a mobile client application, embedded in the mobile phone; b) a web server (SM Platform), that bridges the mobile client with information providers; c) a SMS broker that traffics the SMS; and d) a information provider. The embedded application, designed to Nokia Series 40 and Series 60 devices, sends SMS for a specified SMS short code to achieve a determinate service. The service response is done by binary SMS, listing a predefined SMS port. The core programming language used to develop the mobile application was J2ME and its WMA 1.0 (Wireless Message API, JSR 120). The Series 60 version has a user interface developed with Lightweight UI Toolkit (LWUIT), which is a free UI library and tool for creating richer and more portable Java ME user interfaces [9]. SM Platform is a subsystem built to enable SMS to be sent, received and transferred to different purposes (e.g. enterprise to enterprise, enterprise to people, people to enterprise, machine to machine, machine to people and others).SM Platform is one of the main telecom components used in MobileDeck, and is intended to provide a multi-service environment for message based information services. The core programming language used in server side was Java, having a combination of Servlet [10] and Application Server [11]. SMS broker is a business entity that negotiates agreements with network providers, acting as a middleman for messaging services between a cellular network and third parties [12]. The brokers message aggregator uses the SMPP to maintain connections with carrier networks. Aggregators typically provide access to their servers either through that same technology or using custom APIs written in Java, PHP, Perl, and so on [13]. The information provider is responsible for making value-added services available for end-users. For example, when a mobile phone user sends an interactive text message to retrieve information, the content provider returns the information (in this case, a text message back to the user) through the SMS broker. The way the main components of the MobileDeck architecture interact is shown in figure 3. This example illustrates a user requesting a service and receiving a response. First, a plain SMS is sent using the MobileDeck embedded application to a specific short code, through a standard protocol. Then, the SMS broker routes the SMS message to the information provider, which processes the service requisition. After that, the information provider queries the MobileDeck server (SM Platform) to obtain a secure code (see section 4.1) and so, order a requisition to the broker to send the service response. Thus, a binary SMS is sent to the user, which is received in the MobileDeck application. In order to reduce cost, compression data algorithms were used to keep messages small (see section 3.3). It is worth pointing out that many times only few messages are necessary to obtain a service response. The security issues related to the MobileDeck architectural concept are explained in section 4.

Figure 2. Example of a service being accessed (location finder) When this service is accessed, the user is required to choose an icon that corresponds to specific kind of location, e.g. hotels. Once selected, the user is directed text input layout, locally stored in the application, where the postal code of the desired hotel must be filled in. At this point, the system requests the data from the server, by sending an SMS and receiving a binary SMS response. On the next step, the application displays all the hotels that are located near that postal code in a list view, so that the user can choose one. Again, the application must access the server via SMS, in order to display the result screen containing the information being sought. The obvious limitations of this system must be taken into account when designing each screen, and each service workflow. It is critical to optimize the number of SMS requests per service as well as the amount of data being exchanged, in order to avoid exceeding the maximum length of a single SMS. Even considering that a binary SMS can concatenate a series of messages, the traffic time would increase considerably, as well as the possibility of errors. These limitations are also addressed by the protocol system used in MobileDeck, offers considerable scalability and flexibility for updating content. Since all UI elements are embedded on the application, the existing icons and screen templates can be used for a number of services in runtime. Another important concern about the MobileDeck solution is that the user must be accurately informed about the cost of each request. To avoid legal issues, during the registration process the user must accept an agreement informing that he will be included in a opt-in database. The agreement also informs how much the service costs and how the billing system works. Still, it is

<secure_code>|<list_view_id>|<services>| , where: <secure_code>: The secure code generated based on mobile IMEI. The information provider partners must request this secure code to send the show screen command to MobileDeck (more details about it are showed in section 4.1). <list_view_id>: This ID informs MobileDeck that the information sent follows the specification of list view protocol, i.e., the set of services must be presented in a list view screen. <services>: | <keyword>;<service_name> |... o <keyword>: The unique keyword that represents this service. o <service_name>: Service nameto be displayed on the screen. When a list element is selected, then the keyword is send by SMS to indicate it, enabling thus a communication between the mobile application and an information provider. The same essence is used to build other screen types, like grid, input text, only text screen, etc.

Figure 3. MobileDeck Architecture (high level design)

3.1 Binary SMS

As MobileDeck sends protocol information inside a binary SMS body (see section 3.2), a brief explanation of how it works is valid here. A binary SMS uses the concept of port just like any Internet socket does. Thus, a message can be received in a given port that wakes up a specific service (in JME this is accomplished through the Push Registry API). The User Data Header (UDH) is the feature used to specify what ports our client will send the message to. It is also used to concatenate more than one SMS (in case the message exceeds the SMS maximum length). In MobileDeck, both the UDH and the body are codified in hexadecimal representation.

3.3 Data Compression

With a limitation of 160 characters per message, a compression algorithm is mandatory, helping to reduce the consumption of expensive resources, such as transmission bandwidth. On the other hand, the cost for the information decompressing process may be expansive to some systems. In this case, as one of project objectives is to reduce the overall cost, the fewer messages are sent, the better. MobileDeck uses jZlib, a lossless compression mechanism, which is a reimplementation of the Zlib software library [14]. This kind of compression algorithm is suitable to the purposes of this project because information loss cannot be allowed. Zlib supports the DEFLATE algorithm.

3.2 Protocol and Communication

MobileDecks telecom infrastructure depends on the proper interaction of three main interfaces: client application running in the mobile device, server application, including information provider, and SMS broker software. Both client and server can start the communication, depending on the type of service. Typically, the client requests a service to the server. On the other way around, the server can just push a service to the client. In all cases the broker takes action. To synchronize all cited interfaces it is necessary that all components use a standard protocol created specifically for this purpose. To execute a request to the information provider the protocol below must be followed: <secure_code><service_keyword> , where: <secure_code>: The secure code generated based on mobile IMEI. It guarantees that the content was sent by the embedded MobileDeck application. <service_keyword>: Keyword to identify a SMS service.

4. SECURITY
Although SMS is a well-designed communications protocol, there aresecurity issues that must be addressed to prevent the message from being intercepted by an unauthorized monitoring agent. MobileDecks security mechanism was developed with this premise. End-to-end security or confidentiality and integrity over the whole path between two parties (e.g., a mobile station to another mobile station) are not provided by mobile systems (such as GSM and UMTS) and therefore they have to be implemented at application level [15]. Due to this fact, some important aspects, like authentication and confidentiality must be analyzed during the project of an SMSbased service. There is a necessity to implement a level of wellknown security methods such as cryptography: to mess up the original chain of bytes to be sent in an incomprehensive chain of bytes that can only be read if the receiver has the key to put everything back in its right place. MobileDeck deals with two main different kinds of data transfer. First, the mobile application may need to send a message to the server requesting a service. The other case is when the MobileDeck server sends directly the UI instructions (see section 3.2), via SMS. During these transfers, it is absolutely necessary to guarantee that the message received by the server was sent by a

The protocol also defines whether a screen is embedded in the mobile application. For example, a horoscope service screen containing all signs could be an embedded screen because it is static (the signs are fixed). To push a screen into MobileDeck application in mobile phone, the following protocol must be used. This protocol is regarding list screen, enabling to build in MobileDeck dynamic screens. It is sent using binary SMS to a specific SMS-port.

real authorized MobileDeck-compliant application and that the UI update really came from the server. For each connection between server and application, MobileDeck uses an authentication policy based in password creation, using the IMEI (device serial number) as the key. This is a simple and efficient alternative, which makes difficult to an unauthorized third party to break the security. For a future work, this method can be improved by other techniques integration, like message digest [16] and cryptography [17].

The recommended number of evaluators for a heuristic evaluation is between three and five, given that the informational gain with an additional evaluator drastically decreases after the fifth one and that the benefit-cost ratio is highest when three or four evaluators are employed [23]. Therefore, for this experiment took part five persons, being two women and three men. To perform the usability tests was used the MobileDeck application shown in figure 1 and 2, and described in section 2, evaluating the main premise of MobileDeck system, which is to add a compelling visual and interactive experience to traditional SMS services, such as those offered by mobile operators and content aggregators (horoscope, news, promotions, etc). This experiment was made in Manaus, Brazil, where SMS technology is broadly disseminated, different from others mobile connection technology, as GPRS. The evaluation method was explained in details to each participant as well as what he/she should do and how long each session should take. Then, the use scenery was presented to user to introduce the participant into MobileDeck system conception, presenting some task, considered real and stereotyped, to be executed by participant to evaluate the usability. After finishing all tasks, the system evaluation questionnaire should be filled in by the participant. After carrying out all interaction tests, it was quantified all data of the applied questionnaires.

5. EXPERIMENT
This section describes the experiments executed in order to investigate the MobileDeck system in terms of usability and user acceptance.

5.1 Usability Evaluation

Usability is commonly comprehended as a qualitative attribute that assesses quality-in-use or how easy application are to use [18] and [19]. In these days, mobile users are increasingly becoming reliant on their mobile phones as their primary communication medium, and will nearly always carry their handsets with them. This growing dependence on the mobile device is gradually positioning it as the key repository for other core services. The increasing number of mobile users significantly implies the importance of assuring that the application is useable by means of usability evaluation method [20]. Based on it, usability tests for MobileDeck were carried out. The methodology to measure the MobileDeck usability was the Heuristic evaluation [21], which has been widely applied and investigated, most likely due to its efficiency in detecting most of usability flaws at front of a rather limited investment of time and human resources in the evaluation. However, the capacity of expert-based techniques to capture contextual factors in mobile computing is a major concern [22]. Briefly put, heuristic evaluation is a kind of analytic usability evaluation method conducted by a small group of evaluators, who examine a user interface, judge its compliance with a set of usability principles or heuristics, generate a list of usability problems, and, quite often, categorize the severity of the same thus identified according to their estimated impact on user performance or acceptance [23]. The mobile heuristics chosen for this evaluation were: user control, feedback, consistency and patterns/standards, flexibility and use efficiency, and errors proof. Such criteria were inserted in the evaluation form together with the satisfaction level evaluation scales; both are guidelines to assess the subjective feedback and the task accomplishment observation. The evaluation scales adopted for this experiment was: satisfactory, which indicates that the developed aspects demonstrate to contribute with great relevance for the system effectiveness and they must be kept; low gravity, which means the aspects present a slight difficulty, however, for a small margin of users, and they can even get better along the time; serious, it indicates that must consider its analysis and revision as soon as possible, once it will be worse in a short or medium term; extremely serious, then it must consider its immediate analysis and revision.

5.2 User Acceptance Evaluation

To evaluate MobileDeck user acceptance a consumer intercept survey methodology was used. This kind of survey is typically carried out on the street (street intercepts), in shopping malls (mall intercepts) or in retail outlets themselves, or in any space where there is a representative population of target consumers. Surveys are the most widely used data collection method for studying mobile user behavior and service usage. Surveys can be implemented using e.g. telephone, postal mail, e-mail, web, and various face-to-face questioning methods, depending on the available resources and the objectives of the research. The method used also defines the scalability and accuracy of the survey. Time series data can be produced by repeating a certain set of questions. Surveys are flexible as a wide range of information can be collected to study e.g. attitudes, values, beliefs, and past behavior. [24] However, survey responses always depend on the respondents motivation, honesty, memory, and ability to respond. While a random sample of subjects is often selected for the survey, the actual respondents are usually self-selected, meaning that the true characteristics of the whole population cannot be obtained from the sample. Finally, formulations of survey questions and answer options could lead to different interpretations, both by the respondent and the researcher. [25] The consumer intercept survey was conducted by a third-party company at So Paulo, Brazil, and was divided in two data collection locations. In the first data collection, 120 men and 120 women were interviewed, and in the second, 80 men and 80 women. In both situations the interviewees age was between 15 to 42 years, an age-group that represents the major concentration of mobile phone users in Brazil (70%), according to Anatel [26]. The interviewee should have different occupations and academic background [27]. The interviewees are included in social classes B (50%) and C (50%), according to the IBGE scale [28], and were

divided among both prepaid (86,1%)and postpaid(13,9%)plan users. During the interview, a MobileDeck prototype was presented and each person answered questions about their general perception of the application and the relevancy of accessing certain kinds contents via SMS.

Table 2. Positive reaction by social classes Positive Reactions Improve the services based on SMS usage Allow receive news about my team Check horoscope It more cheap than internet Allow to take information when Im driving Its not necessary to type Its absolutely interesting. I would see it working B 60% 54% 20% 23% 46% 53% 48% C 29% 41% 18% 38% 21% 18% 31%

6. RESULTS
We begin this section by showing the usability tests result. Then, it is presented the user acceptance survey results.

6.1 Usability test

In figure 4 1 is illustrated the usability test result. In the legend is listed the 5 test participants of the experiment (participant 1, 2, 3, 4, and 5); in the x-axis is showed singly each mobile heuristics cited in section 5.1; and in the y-axis is the adopted evaluation scale for the experiment, where 1 represents satisfactory, 2 represents low gravity, 3 represents slight difficulty, and 4 represents serious (for more details, see section 5.1).

Table 3. Negative reaction by social classes Negative Reactions Its expensive Im not interested in it Its missing services about advertising I want to customize the main service grid menu B 12% 54% 8% 43% C 46% 41% 17% 29%

6.3 Experiment Limitations

The results presented in this work may contain some variation of the reality, due to the limitations of the experiment. One of these limitations include the time spent to use the mobile application, i.e., the best scenario would be that each participant could make use of the evaluated application in his/her day by day and identify what could be improved in agreement with his/her application usage. In this case, an evaluation in long term could probably obtain different results. The type of the application used in the experiment was also a limitation; the evaluation result can be changed according to the application under observation. We also mention the expectation effect of a given person (Placebo and Hawthorne effect) and the expectation effect of the experimentalist as factors that can influence the experiment participant evaluation [29].

Figure 4. Usability Test Result Based on these results, the MobileDeck application was considered as acceptable to go to market.

6.2 User acceptance survey

In order to prove the user acceptance of MobileDeck concept, it was collected from the experiment participants the relevancy of SMS service contents, listed in Table 1, even as, the positive and negative reactions, which is conceded is Table 2 and 3, respectively. It is possible to infer the interested by user for service based on SMS. The results tabulated in table 1 make it clear. Furthermore, it was collect a good percentage of positive reaction, nevertheless negative reaction were collected. For future works the negative reactions listed in table 3 will be studied to be mitigated. Table 1. Relevancy of kinds contents via SMS Service Daily News Weather Forecast Traffic Report Sporting News Job Prospects Horoscope Movie News Total 69,6% 66,7% 56,8% 42,9% 26,7% 23,1% 22,1% Male 70,8% 69,2% 63,3% 59,2% 22,5% 16,4% 23,3% Female 68,3% 64,2% 49,0% 26,7% 30,8% 30,0% 20,8%

7. CONCLUSION
MobileDeck was developed with the idea that SMS, as a communications protocol, allows the interchange of messages at a relatively low cost anywhere at anytime. By allying this strength with a rich environment we hope to offer an alternative to mobile internet technologies like GPRS for content distribution one particularly adequate for the characteristics of emerging markets. The results of both experiments presented here suggest that SMSbased applications with a graphical UI are relevant and suitable to provide a relatively straightforward experience to the end-user. As MobileDeck is being currently released in the Brazilian market, during the next months it will be possible to evaluate its actual performance as a media channel, through access statistics provided by the server application. In this phase of implementation, it will be also possible to perform other usability tests to confirm if the results obtained previously will follow the same pattern across all operator networks and over the cultural idiosyncrasies within the country. Besides investigating how this sort of solution will meet the user expectations under real conditions, future works of this research include an overall improvement of MobileDecks underlying

technology. This will be done mainly by refining the current security workflow through cryptography and by building an algorithm to allow graphical elements (e.g. icons) to be also carried over binary SMS, as well as, include mechanism to become MobileDeck self-adaptive for the user (e.g., to make more accessible a service that is more used, even as, remove services that is not used, and update the MobileDeck with possible interesting service) such as purposed in [30] and [31]. Eventually, it is expected that market demands will also point out the technological directions of this system. Hopefully this solution will reach other countries, where new challenges will be faced.

[10] Pursnani, V. 2001. An introduction to Java servlet programming. Crossroads 8, 2 (Dec. 2001), 3-7. DOI= http://doi.acm.org/10.1145/567155.567157 [11] Dinker, D. and Schwetman, H. 2006. Using Java method traces to automatically characterize and model J2EE server applications. In Proceedings of the 38th Conference on Winter Simulation (Monterey, California, December 03 - 06, 2006). L. F. Perrone, B. G. Lawson, J. Liu, and F. P. Wieland, Eds. Winter Simulation Conference. Winter Simulation Conference, 1187-1194. [12] Pillai, P. 2005. Experimental mobile gateways. Crossroads 11, 4 (Aug. 2005), 6-6. DOI= http://doi.acm.org/10.1145/1144389.1144395 [13] Brown, J., Shipman, B., and Vetter, R. 2007. SMS: The Short Message Service. Computer 40, 12 (Dec. 2007), 106110. DOI= http://dx.doi.org/10.1109/MC.2007.440 [14] P. Deutsch and J. Gailly. ZLIB Compressed Data Format Specification Version 3.3. RFC. RFC Editor, 1996. [15] Hwu, J., Hsu, S., Lin, Y., and Chen, R. 2006. End-to-end security mechanisms for SMS. Int. J. Secur. Netw. 1, 3/4 (Dec. 2006), 177-183. DOI= http://dx.doi.org/10.1504/IJSN.2006.011777 [16] Spinellis, D. 2000. Reflection as a mechanism for software integrity verification. ACM Trans. Inf. Syst. Secur. 3, 1 (Feb. 2000), 51-62. DOI= http://doi.acm.org/10.1145/353323.353383 [17] Garza-Saldaa, J. J. and Daz-Prez, A. 2008. State of Security for SMS on Mobile Devices. In Proceedings of the 2008 Electronics, Robotics and Automotive Mechanics Conference (September 30 - October 03, 2008). CERMA. IEEE Computer Society, Washington, DC, 110-115. DOI= http://dx.doi.org/10.1109/CERMA.2008.63 [18] IEEE_Std_1061. "IEEE standard for a software quality metrics methodology". IEEE Std 1061-1998, 1998. [19] ISO/IEC (1998) 9241-11 Ergonomic requirements for office work with visual display terminals (VDT)s--Part 11 Guidance on usability. ISO/IEC 9241-11:1998 (E). [20] Hussain, A. and Ferneley, E. 2008. Usability metric for mobile application: a goal question metric (GQM) approach. In Proceedings of the 10th international Conference on information integration and Web-Based Applications & Services (Linz, Austria, November 24 - 26, 2008). G. Kotsis, D. Taniar, E. Pardede, and I. Khalil, Eds. iiWAS '08. ACM, New York, NY, 567-570. DOI= http://doi.acm.org/10.1145/1497308.1497412 [21] Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., & Mack, R.L., (Eds.), Usability inspection methods, pp. 25-64.

8. ACKNOWLEDGMENTS
Our thanks to INdTs Rosaurea Magalhes Usability Lab for performing usability tests cited in this paper.

9. REFERENCES
[1] Leung, C. H., Chan, Y. Y., and Chan, C. S. 2003. Analysis of mobile commerce market in Hong Kong. In Proceedings of the 5th international Conference on Electronic Commerce (Pittsburgh, Pennsylvania, September 30 - October 03, 2003). ICEC '03, vol. 50. ACM, New York, NY, 408-412. DOI= http://doi.acm.org/10.1145/948005.948058 [2] Church, K., Smyth, B., Cotter, P., and Bradley, K. 2007. Mobile information access: A study of emerging search behavior on the mobile Internet. ACM Trans. Web 1, 1 (May. 2007), 4. DOI= http://doi.acm.org/10.1145/1232722.1232726 [3] Zerfos, P., Meng, X., Wong, S. H., Samanta, V., and Lu, S. 2006. A study of the short message service of a nationwide cellular network. In Proceedings of the 6th ACM SIGCOMM Conference on internet Measurement (Rio de Janeriro, Brazil, October 25 - 27, 2006). IMC '06. ACM, New York, NY, 263-268. DOI= http://doi.acm.org/10.1145/1177080.1177114 [4] Enck, W., Traynor, P., McDaniel, P., and La Porta, T. 2005. Exploiting open functionality in SMS-capable cellular networks. In Proceedings of the 12th ACM Conference on Computer and Communications Security (Alexandria, VA, USA, November 07 - 11, 2005). CCS '05. ACM, New York, NY, 393-404. DOI= http://doi.acm.org/10.1145/1102120.1102171 [5] Eberspaecher, J., Bettstetter, C., and Vhogel, H. 2001 Gsm: Switching, Services and Protocols. 2nd. John Wiley & Sons, Inc. [6] Tsang, M. M., Ho, S., and Liang, T. 2004. Consumer Attitudes Toward Mobile Advertising: An Empirical Study. Int. J. Electron. Commerce 8, 3 (Apr. 2004), 65-78. [7] Kolko, B. E., Rose, E. J., and Johnson, E. J. 2007. Communication as information-seeking: the case for mobile social software for developing regions. In Proceedings of the 16th international Conference on World Wide Web (Banff, Alberta, Canada, May 08 - 12, 2007). WWW '07. ACM, New York, NY, 863-872. DOI= http://doi.acm.org/10.1145/1242572.1242689 [8] Page, C. 2005. Mobile research strategies for a global market. Commun. ACM 48, 7 (Jul. 2005), 42-48. DOI= http://doi.acm.org/10.1145/1070838.1070864 [9] White, Jim. Java ME User Interfaces: Do It with LWUIT. 2007. DevX online magazine.

New York: John Wiley & Sons.

[22] Bertini, E., Gabrielli, S., and Kimani, S. 2006. Appropriating and assessing heuristics for mobile computing. In Proceedings of the Working Conference on Advanced Visual interfaces (Venezia, Italy, May 23 - 26, 2006). AVI '06. ACM, New York, NY, 119-126. DOI= http://doi.acm.org/10.1145/1133265.1133291 [23] Law, L. and Hvannberg, E. T. 2002. Complementarity and convergence of heuristic evaluation and usability test: a case study of universal brokerage platform. In Proceedings of the

Second Nordic Conference on Human-Computer interaction (Aarhus, Denmark, October 19 - 23, 2002). NordiCHI '02, vol. 31. ACM, New York, NY, 71-80. DOI= http://doi.acm.org/10.1145/572020.572030 [24] Kivi, A. 2009. Measuring mobile service usage: methods and measurement points. Int. J. Mob. Commun. 7, 4 (Apr. 2009), 415-435. DOI= http://dx.doi.org/10.1504/IJMC.2009.023692 [25] Martin E. (1983). Surveys as Social Indicators: Problems in Monitoring Trends. Handbook ofSurvey Research, eds. Rossi P., Wright J., and Anderson A., Academic Press Inc., California,United States, pp. 677-743. [26] ANATEL. Paste/2000-perspectivas para ampliao e modernizao do setor de telecomunicaes para o perodo 2000/2005 (in portuguese). ANATEL-Agncia Nacional de Telecomunicaes, 2000. [27] S. Shan and H. V. Rocha. A Comparative Study of HumanComputer Interface Evaluation Methods. In: International Conference of the Chilean Computer Science Society, 1996. Valdivia, Chile, 1996. v. 1. p. 101-111. [28] Gazeta Mercantil Journal (in portuguese), 2002, in press.

[29] Wainer, J., Novoa Barsottini, C. G., Lacerda, D., and Magalhes de Marco, L. R. 2009. Empirical evaluation in Computer Science research published by ACM. Inf. Softw. Technol. 51, 6 (Jun. 2009), 1081-1085. DOI= http://dx.doi.org/10.1016/j.infsof.2009.01.002 [30] Tefilo, M., Cordeiro, L., Barreto, R., Pereira, J. R., Mardem, A., and Freitas, P. 2008. Mandos: A User Interaction Method in Embedded Applications for Mobile Telephony. In Proceedings of the First international Conference on Advances in Computer-Human interaction (February 10 - 15, 2008). ACHI. IEEE Computer Society, Washington, DC, 271-276. DOI= http://dx.doi.org/10.1109/ACHI.2008.25 [31] Tefilo, M., Martini, A., and Silva, W. 2009. Vair: A Tool to Improve the Usability in Embedded Applications Based on User Adjustment. In Proceedings of the 2009 Second international Conferences on Advances in Computer-Human interactions (February 01 - 07, 2009). ACHI. IEEE Computer Society, Washington, DC, 57-62. DOI= http://dx.doi.org/10.1109/ACHI.2009.44