A Web-Based Mashup Tool for Information ... - Semantic Scholar

A Web-Based Mashup Tool for Information Integration and Delivery to Mobile Devices Prach Chaisatien and Takehiro Tokuda Department of Computer Science, Tokyo Institute of Technology Meguro, Tokyo 152-8552, Japan {prach, tokuda}@tt.cs.titech.ac.jp

Abstract. The immense popularity in mobile internet has driven the part of classic web information and services to transform and shrink themselves to match diversity of web-capable mobile devices. This paper will present a Webbased mashup tool to work with range of Japanese domestic mobile handsets and their variety of limited functionalities. Our purpose is to provide users an alternative option to customize information to be displayed and to integrate available services for their mobile phone. Three major working components, functionality tester, service aggregator and output simulator will aid users in understanding the capability of their mobile device and selecting corresponded functionalities. Successfully simulated and simplified information services will be able to access via user’s mobile phones with correct configurations. Keywords: Mobile Devices, Web-based, Customization, Integration, Mashup

1 Introduction The capability of web access via mobile phones has begun to build up new browsing and using behaviors. After the voice and text only mobile communication age have passed, the remaining popularity of mobile devices such as mobile phones or PDAs still plays a big role in accelerating number of people browsing on mobile internet in the current generation. Moreover, the massive growth of internet over the last decade and the introduction of the broader, faster third generation (3G) mobile network also have a major influence in revising the traditional wireless protocols [1]. The data communication on-the-go via mobile phones is becoming the key trend in re-designs and re-implements the web application to work effectively on mobile platform. Many new mobile applications such as Mobile Google Voice Search and Google Maps for Mobile (with GPS location service) are very competent examples of re-designed web applications which can deliver a good match with new available technology on mobile phone. While the renovate method has its potential, the great challenge for mobile developers still remains in dealing with devices’ specification. One functioning web page or application on a mobile phone may not work or display properly in the others. Additionally, users always confront overloaded information on the small screen which tends to consume both service charges and interaction time. Besides, classic web information/services alone cannot serve the right task in particular situation such as

finding instant directions from the current position. Instead of accessing the top page and drilling down to what information user currently need, we believe that a faster and more sensible solution need to be developed. In this paper, we are proposing a web-based tool which can help users build a mashup mobile application from specific information source, select integratible web services and compile them into his/her personal mobile web service. The primary objective is to aid user in creating mobile phone’s mashup application regarding user’s preference and his/her mobile phone’s specification. For technical basis, the current system is compatible only with Japanese domestic mobile handsets. The functional components in the proposed web-based tool are divided into three portions. First, functionality tester (FUNCTE) can automatically match, detect mobile phone’s configurations or conduct a manual test for detailed specifications. Second, service aggregator (SERVAR), will work as a personal mobile web service mashup engine which correspond to formerly detected configuration from FUNCTE. Output prototype from SERVAR will be passed to the third section called SIMULO, a webbased simulator, which will display and test the final product.

2 Research Backgrounds 2.1 Mobile Technologies and Trends in Japan Mobile devices available on current market can be broken down into a few broad classes [2], [3]; feature phones, smart phones, PDAs and voice/text only phones. The term feature phones refers to the most common device type which typically comes with voice, messaging and data capabilities. Most feature phones in the past three years also come with built-in cameras and media players. Additionally, mobile devices in Japanese market are likely to take a step forward from overseas phones [4]. The recent domestic feature phones usually come with internet browser, built-in email address, two-dimensional bar code reader and electronic money function. The big changes begins in late 2001 [5], the rapid development of 3G technologies by three major carrier (e.g. NTT DoCoMo, KDDI au and SoftBank) is considered as one of the most important developments in the mobile arena in Japan. With greater bandwidth and rapid download and upload speed in the new 3G technologies, the developments in turn opened up opportunities for the telecom companies to offer a plethora of multimedia services on the mobile phone platform. 3G was also paralleled by the availability of compatible handsets with high-resolution screens and the development of a number of web, java and flash applications that run on these cell phones. Recently, the availability of smart phones and internet portable devices in Japanese market (e.g. iPhone, iPod Touch and Windows mobile phones) also drive another aspect in mobile service development. There so-called overseas rival phones come with greater compatibility which have let Japanese manufacturer reconsider about integrating the full mobile browser (desktop-like) into new phone models.

2.2 Problems in Mobile-Wireless Information System The apparent differences from desktop and mobile browser are the screen size and functionality. Ruti Gafni [6] has stated major problems in mobile wireless information system which are listed below: Table 1. General Problems in Mobile-Wireless Information Systems. Problem area Hardware Characteristics Size Security Network

Details Small memories, short battery life, limited calculation and computation capabilities The application must be adaptable to a wide variety of devices which possessing different characteristics. Tiny screens, low resolution, and small keyboards are difficult to operate. Security problems can arise when devices are lost, due to possible unauthorized access to sensitive data. Limited bandwidth, inconsistent connection stability, transfer delays, and varied standards and protocols, some with high overhead, decrease the performance level. The connection point to the network can change, obstacles can disturb, causing temporary disconnections, interruptions, or disturbances.

The specific problems in Japanese mobile-wireless information system which can be extended from area of characteristics in Table 1 are, first, the phone models and technologies are distinguished by each carrier. In common example, a Nokia mobile phone purchased with contract from DoCoMo cannot be used with other mobile network. Second, Japanese mobile services do not share usage across carriers. This problem is a major conflict with the World Wide Web and initiative of globalized internet technology. Therefore, mobile service developers are with no choice but to face the complicated cross-platform and cross-carrier development scheme. Table 2. Problems in Japanese Mobile-Wireless Information Systems. Problem area Carriers Services Charges Compatibility Development

Details Phones are carrier dependent. No cross-carrier usage is allowed. Overseas phones are not functioning. Most of mobile internet services are exclusive to each carrier. Some mobile services require a registration and monthly charge. Flat-fee data connection charge is range from moderate to expensive. Some websites can only be viewed with mobile browser. Most of mobile sites cannot be accessed with a desktop browser Not only device but also carrier specification has to be considered significantly. Multiple development schemes are needed to handling all phones.

The main reason behind the exclusive service problem is the service development is bind strictly with business model which derived from market success of NTT DoCoMo’s i-Mode [7], [8].

2.3 Motivations and Research Methods While Japanese mobile technologies gain major accomplishment in domestic market, rigid rules for designing mobile web services need to be adhered. Since this era has formed the transition and convergence between internet and mobile technology, the current Japanese mobile technology has obvious drawbacks and compatibility problems. Various case studies have been observing the i-Mode services outside Japan [9], [10]. The latest report shows that European mobile operators in Australian and United Kingdom are began to discontinue the i-Mode services under their administration by the year 2007 – 2009. Additionally, in many market outside Japan, WAP based internet service running on open technologies as opposed to the walled garden approach of i-Mode, seem to have taken the lead over the Japanese model. Consequently, Japanese mobile users are having no choice but to follow the regulation from dependent services and profile-specific phones. With the aim to address these problems mentioned above, this research propose an alternative option to deliver independency to combine internet technology and the ability to create mashup from applicable services for mobile phones with following specifications.

Fig. 1. System overview.

1. Our assumption is that users know how to operate their mobile phone browser in certain level. Current system will aid how to integrate information, services and application into their device which working entirely on web pages. We still require minimal effort from users on some specification test and adjustments which will help system run correctly and efficiently on their mobile phone.

2. Detection via the user agent string and HTTP headers will be conducted after mobile phone was registered and accessed to the initial page in FUNCTE. System will automatically detect working functions from this process. Some specification may need to be tested as it is not available or not provided by carrier’s official website. 3. Users are facilitated by narrowed choice of mashup modules from the previous detection. All configurations will be passed to SERVAR and match the working services in association with mobile phone’s carrier. 4. SERVAR, the main web mashup engine, is accessed by desktop browser for customization of services, information and applications. Users can choose applicable services and select compatible web application to create their mobile mashup application. 5. After users finish adjusting their mobile service components, simulation of the output page will be display on SIMULO. It will limit its functionality to match user’s phone specification. We are planned to include look and feel color adjustments which will be available for some model via CSS or fixed HTML code corresponding to its compatibility. As soon as user completed his/her tuning, the mobile web service page is ready to be published and accessed online. 2.4 Related Works and Technologies Although, several methods in detecting mobile phone specification (spec-detection) have been presented and used worldwide, there are still no centered standard for Japanese domestic mobile phones. The user agent profile (UAProf) [11], [12] is an XML documents that contains information about the agent type and device capabilities. This information is used by providers to create content in a compatible format for specific devices. Link to UAProf’s URL often be found in the HTTP headers x-wap-profile. Apparently, UAProfs fail to cover all devices in the market since not all devices’ spec is provided with this standard. Some international brand manufacturer (e.g. Nokia, Samsung) have a compatible UAProfs on their selfmaintenance server. On the other approach, an open-source project intended for developers working with the WAP and wireless called WURFL has been driven under initiative by Luca Passani [13]. The WURFL is also an XML configuration file which contains device specification. In common terms, WURFL is a manually imported UAProfs with additional sources and fixes submitted by other developers. The WURFL provide greater range of device profiles with rapid updates from developers around the world. A mobile device web service database called DetectRight [14] was introduced by a Norwegian company in 2005. DetectRight provides free and paid subscribers with APIs and development tools which can be integrated with mobile communication server. HTTP headers from mobile client along with other resources will be match with local database in order to find device’s type and specification. A better server management solution is introduced with real-time analyzer and map view of connected clients. Work and developments in mobile customization are being developed alongside the desktop-based ones. The combination of Yahoo pipes and iPhone [15] is suitably leveraged a creation of mobile mashup application via a visual editor. Christian S.

Jensen et al [16] demonstrate an idea of user-generated content for mobile services by introducing the STREAMSPIN service management system. STREAMSPIN enable users to generate their own mobile services from text/photo posting and geospatial information. A method that allows users to tailor their mobile web page was proposed by Yung-Wei Kao et al. [17] A user can determine which block elements in a web page should be retained. The sequence of these blocks can also be altered according to individual preferences.

3 The Web-based Mobile Service Customization System Creating a hybrid web application is considered not a new innovation. However, mashing up services for mobile devices can be a multifarious piece of task since the end-user has to deal with several boundaries as we mentioned in the previous statements. In this research, we are using this prototype system to encourage user to understand those limitations. Spec-detection, service matching and output simulation are main keys which we applied to these following components. The outline of current prototype tool is limited (but not restricted) to Japanese domestic phone models. 3.1 FUNCTE: Functionality Tester

Fig. 2. Workflow of FUNCTE.

Mobile functionality tester called FUNCTE in our prototype tool will perform several tasks to detect or test mobile device functionality. As shown in Fig. 2, first, users will

be asked to create their account via mobile device. After the registration complete, the testing or detection process will begin in the following page. After user accessed to the main page, the detection process start here as FUNCTE server detect user agent string pattern. Some HTTP header might be used to associate this detection, for instance SoftBank’s phones are also using HTTP headers affiliated with x-jphone header terms. We have gathered all available phone specifications and stored them in FUNCTE’s database. Available information resources for specdetection are listed in Table 3 with all working process shown in Fig. 3. Table 3. Information resources for spec detection Carrier NTT DoCoMo KDDI au

Method Web extraction, Manual Web extraction

SoftBank

File extraction

Others

Web extraction, Manual

Category User agent string patterns, Specifications User agent string patterns, Specifications, Device IDs User agent string patterns, Specifications, HTTP header patterns User agent string patterns, Specifications

Source Official developers pages (HTML, PDF) Official developers pages (HTML) Official developers pages (HTML, CSV) Official developers pages (HTML, PDF)

Despite of server’s automatically extracted and updated information form official pages, manual work still needed for some phone’s specification. Some of them may not in a complete version due to the lack of accessibility to more detailed resource. Nevertheless, in our evaluation, we are trying to contribute this test page to as many users as possible. Therefore, not only the official specification will complete the system’s spec-detection database but newly tested ones will assist our goal as well.

Fig. 3. Spec-detection flowchart.

In the case that user’s mobile device exists in our database; the test process is complete with no further examination. Full specification test might need to be conducted for some new mobile devices. Since some specification is not precise, such as compatible version of JPG,GIF and PNG file, partial specification test (or

confirmation test) is required to fulfill the insufficient data. There are categories of both essential information extracted from Web resources and directly tested result from user’s mobile phone shown in Table 4. The screens shots of choice-based test on mobile phone emulator are shown in Fig.4.

Fig. 4. Screen shots from FUNCTE’s device test page. (1) Initial spec detection including user agent string format. (2) Image format test page. (3) Screen width test page in vertical display mode and (4) Screen width test page in horizontal display mode. Table 4. Essential specification from mobile device and web resources. Category User agent string Display

Image format Markup languages Others

1

Details Carrier, Model number (or device ID 1 ) Screen area, Browser display area (and display mode e.g. horizontal, vertical), Number of maximum displayable characters Compatibility list including version of JPEG, GIF, PNG or BMP Compatibility list including version of HTML, C-HTML, or XHTML Screen color depth, Manufacturer2 and Serie2, Capability of running Java application, Capability of playing midi files2, Capability of accessing location based service (LBS) 2 3 , Capability of displaying PDF file, Version of compatible Flash, Capability of running full size (or desktop-like) browser1 2

Apply only with KDDI au’s phone Apply only with SoftBank’s phone 3 Apply only with NTT DoCoMo’s phone 2

3.2 SERVAR: Service Aggregator Service aggregator is a web-based mashup engine where users select and assemble their mobile mashup service. Stored output specification from FUNCTE will be passed here to check for compatible mashup modules. For example, as shown in Fig. 5, a choice of geographical service module will not be selectable in case of very low profile phones. We have listed all available resources in Table 5 with user operations and inputs in Table 6.

Fig. 5. Example of service selection in SERVAR, low profile phone (left) feature phone (midle) and smart phone (right). Table 5. Available resources in SERVAR. Category Search API

Image Search API

Map API Storage

Service Google Custom Search API Yahoo BOSS Search API Wikipedia Wikitext API Google Image Search 4 Yahoo BOSS Image Search API Wikipedia Image Search4 Google Static Map API Yahoo Static Map API Personal database 5

Various combinations of these resources, operations and inputs can be used to create mobile web services. Tentatively, SERVAR’s graphic interface is under development at present. Since number of services are planned to be included, we are deciding whether to use drop down box base or diagrammatic drag and drop of components. Sample uses and workflow diagram are provided in section 4.2. 4 5

Since official APIs are unavailable, these resources are directly extracted from search results. A local database server with simple select, insert, delete and update function.

Table 6. User operations and inputs in SERVAR. Operation Type Input Search Use as input Tag Use position

Form type Textbox Textbox N/A Selectable list N/A

Display Store

N/A N/A

Details Use text as input Use text to search Pass output from search as another input Tag an input or search result Use geospatial information from search results or from current position (via carrier’s service) Display input or search result on screen Store input or search result in database

3.3 SIMULO: Spec-aware Web Simulator We are providing users the same way as most of developer’s networks always provide a development kit with mobile simulators. SIMULO test the completed mashup application from SERVAR. Rather running as a native application, SIMULO are completely implemented using HTML, CSS and AJAX techniques with these specification and limitations. 1. Simplified tags in C-HTML or iHTML will be translated to regular HTML tags. 2. Size of screen, texts and color depth are directly retrieved from FUNCTE 3. Image format and its color depth will be adjusted to match the specification. 4. Geospatial information of current user’s position is not available. 5. The CSS look and feel adjustment module is still under development at this time. Components will be selected by using component picker before color is set. 6. For calculating data service charge, SIMULO will also show how many bytes received and sent during the access.

4 Evaluations and Mashup Examples 4.1 Spec-detection Extracted specifications from carrier’s official records are stored in FUNCTE database. Listed amount of phone models and user agent string patterns is shown in Table 7. DoCoMo’s phones use more than one user agent string per model which screen sized can be instantly detected. On the other hand, both KDDI au’s and SoftBank’s phones only have single agent string pattern per a phone. Instead, they use HTTP headers to provide their specification. Table 7. Amount of Phone Models, User Agent String Patterns and Header Patterns. Carrier NTT DoCoMo KDDI au SoftBank

Phone models 302 184 183

User agent string patterns 1,967 184 183

Header patterns 0 552 366

This information can only provide screen sizes, browser display mode (horizontal or vertical) and display font size. Another set of information including color depth, supported image format, supported HTML version and location-based service are also extracted. Since this information is not likely to match the actual specification, all users are asked to complete choice based test (Fig. 4) to help correcting our database. We have selected 7 tested subjects with all their descriptions shown in Table 8. Table 8. Tested mobile phones and their description. No. 1 2 3

4

5

6

7

Carrier Model ID Browser Others DoCoMo N903i N/A Screen size: 24 by 12 characters, DoCoMo/2.0 N903i(c100;TB;W24H12) DoCoMo M702iS N/A Screen size: 24 by 13 characters, DoCoMo/2.0 M702iS(c100;TB;W24H13) SoftBank 705P Teleca 3.1 Java: MIDP 2.0, CLDC 1.1 SoftBank/1.0/705P/PJP10/SN Browser/Teleca-Browser/3.1 Profile/MIDP-2.0 Configuration/CLDC-1.1 SoftBank 911SH Netfront 3.3 Java: MIDP 2.0, CLDC 1.1 SoftBank/1.0/911SH/SHJ001/SN Browser/NetFront/3.3 Profile/MIDP-2.0 Configuration/CLDC-1.1 N/A HTC_TyTN Mozilla 4.0 Java: MIDP 2.0, CLDC 1.1 PPC; 240x320; HTC_TyTN/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IE Mobile 7.7) Up.Browser MMP version: 2.0 KDDI au KC-28 6.2.0.10.1 KDDI-KC28 UP.Browser/6.2.0.10.1(GUI) MMP/2.0 Up.Browser MMP version: 2.0 KDDI au T23G 6.2.0.13.2 KDDI-T23G UP.Browser/6.2.0.13.2(GUI) MMP/2.0

From Table 8, the primary key to match other configurations is model ID since the other parts of user agent string patterns are in diverse form and incompletely provided. Device no. 5, which is a SoftBank’s smart phone, is unknown to our database and need to perform a full spec-test. Since not all browser versions were shown, markup language specs are also undetectable and have to be manually extracted from the official resource. In fact, all mobile carriers in Japan apply charges on every data communication from mobile phones. This condition makes NTT DoCoMo and its detection method the cheapest. SoftBank’s mobile phones provide more resources but indeed consume more bytes in data communication while KDDI au’s phones require an extra set of mobile IDs. Different design patterns are required to lower communication charges. 4.2 Creating Mobile Mashups Mashup Example 1: Retrieve Position by Search Keyword. The main objective in this example is to find a position from Wikipedia page and pass extracted coordinate to Google Map service to retrieve a map as an image file in compatible format.

Fig. 6. Workflow in mashup example 1.

Fig. 7. Screen shot from example 1. (1) Give a search keyword and language mode. (2) Extracted and translated geospatial coordinate from Wikipedia page corresponding to the given keyword. (3) Display map corresponding to retrieved coordinate.

Fig. 8. Screen shot from mashup example 2. (1) and (2) Input texts and choose to store as a tag. (3) Select search engine and input search keyword. (4) and (5) Search results are displayed with two items selected. (6) Review selected result and assign a tag to store in the database.

Mashup Example 2: Tag and Store Search Results in Personal Database. Local database is available for storing information. User creates a tag to apply with short search results afterward and store this information for further use.

Fig. 8. Workflow in mashup example 2.

Mashup Example 3: Retrieve Map from Current Location. Similar to technique applied by Google Map but using the carrier’s geo-location web service to retrieve current coordinate as a substitute. Theoretically, the geo-location information is commonly provided in latitude and longitude format. However, some backup service such as DoCoMo Open i-Area, which makes use of radio tower triangulation, may not provide precise location as GPS-based one do.

Fig. 10. Workflow in mashup example 3.

Fig. 11. Screen shot from mashup example 3. (1) Select one from available location-based services (2) Extracted and translated coordinate from selected service. (3) Display map of the current position.

4.3 Discussions From our mashup example, many untested components are still in development. Hereby we would like to review their limitations and restrictions which occurred during this evaluation and including the planned system components. 1. The full potential of supported HTML version is not presented. The current markup language is now shifting from generic HTML to extended HTML which rendered pages are slightly different. 2. Network latency of each web resources need to be tested and revised. The current method save the amount of data received and transmitted but randomly did not conserve a short connection time. In mashup example 1, some client can go through the map search procedures in no time but others did not. Indexed database from crawled search results might be considered. 3. In providing map image to users, zoom level is not adjustable. Our default zoom level set for Google map API is fixed at 14 in example 1 and 16 in example 3. This adjustment has to be done manually by users which correspond to their display area. 4. There is no search keyword suggestion module in our system. In the later implementation, we will put this module as a choice for users. They can choose to conserve network traffic or save time to input keywords. 5. The number of text in search result is limited to a short description. Our intention is not to provide user an extra mobile search engine but to have it integrated for the other use. By storing tagged search results, user can share information between mobile phone and desktop or with other users. 6. Search language preference in Wikipedia API is specific to Japanese. Wikipedia provide geo-tag in Japanese article and English article differently and we are still working on the conversion module. The others can be applied with both Japanese and English.

5 Conclusion and Future Work In a research to converge mobility and mashup information, there are several approaches needed to be considered. Most of the mobile applications are bounded with devices’ specification as well as relevant web services to be applied. Additionally, mobile service carriers in Japan tend to keep their service exclusive to their contracted customer or even specific phone model. Therefore, we developed a system that address device configurations problem at the first hand and provide users an option to mash and use their application independently. Technically, the current system is able to test mobile phone specification or make detection with user agent string and HTTP headers. Integratible service will be listed in creating mashup application process. Hereby, partial tasks are done by users which, as well, fulfill information resources for further development. There are still some components currently under development which covers output simulator, look and feel configurator and to add adjustable feature. We are planning to revise the APIs to improve their speed, size and stability to use in the actual setting.

Although our purposed method is able to provide an alternative manner in delivering information to mobile phone, there is still no assurance to support plethora of mobile devices. Besides, the consideration has to be made for whether to strict with design basics, to be more specific or to let all works done by adaptive method. In the current evolving trends, mobile phone is not only capable of input and display texts, the advantage of camera and microphone on the device is extensively interesting to apply. A splendid mashup application can be created in support of Javascript-capable phone and accessible low level API such as ones appeared in Android or iPhone platform. Indeed, this study ultimately needs more flexible access to lower level of device controls and higher level of web APIs.

References 1. Funk J.L., The emerging value network in the mobile phone industry: The case of Japan and its implications for the rest of the world. In: Telecommunications Policy, vol. 33, no. 1-2, pp. 4--18, Elsevier Science Press (2009) 2. Turowski, K., Pousttchi, K.: Mobiltelefonie. In: Mobile Commerce Grundlagen und Technik, pp. 41--78. Springer-Verlag, Berlin/Heidelberg (2004) 3. Semmelhaack, B.: Market Development of Mobile Device Classes and Operating Systems, http://www.iwi.uni-hannover.de/lv/seminar_ws06_07_en/semmelhaack.pdf 4. Tanaka E., The status of Nippon Telegraph and Telephone Corporation (NTT). In: Telecommunications Policy, vol. 21, no. 2, pp. 85--99, Elsevier Science Press. (1997) 5. Japanese mobile data white paper, http://www.5myths.com/Publishing/Whitepapers/Japan/ All.aspx, Consumerease (2006) 6. Gafni R.: Framework for Quality Metrics in Mobile-Wireless Information Systems. In:Interdisciplinary Journal of Information, Knowledge, and Management, vol. 3, pp. 23-38, Informing Science Institute (2008) 7. Ishii, K.: Internet Use via Mobile Phone in Japan. In: Telecommunications Policy, vol. 28, no. 1, pp. 43--58, Elsevier Science Press (2004) 8. Business Model, http://www.nttdocomo.com/services/imode/business/index.html, NTT DoCoMo, Inc. (2009) 9. O'Brien K.J.: Forerunner of mobile Internet, i-mode is fading in Europe, http:// www.iht.com/articles/2007/07/17/business/imode.php, International Herald Tribune (2007) 10.Suri, V.R., Sawhney, H.: The internet and its wireless extensions in Japan: the portentous interface between chaos and order. In: info, vol. 10, no. 3, pp. 10--21, Emerald Group Publishing (2008) 11.Hellesø-Knutsen, O.: DetectRight launches first W3C compliant mobile web service database, http://www.esato.com/news/article.php/id=1784, Esato (2008) 12.UAProf profile repository, http://w3development.de/rdf/uaprof_repository/ 13.WURFL, http://wurfl.sourceforge.net/ 14.DetectRight, http://www.detectright.com/ 15.Trevor, J., Doing the Mobile Mash. In: Computer, vol. 41, no.2, pp. 104—106, IEEE Computer Society Press, Los Alamitos, (2008) 16.Jensen, C.S., Vincente, C.R., Wind, R.: User-Generated Content: The Case for Mobile Services. In: Computer, vol. 41, no. 12, pp. 116-118, Computer Society Press, Los Alamitos, (2008) 17.Kao Y., Kao T., Tsai C., Yuan S.: A personal Web page tailoring toolkit for mobile devices. In: Computer Standards & Interfaces, vol. 31, no. 2, pp. 437--453, Elsevier Science Press (2008)