Arbeitsberichte des Lehrstuhls für Allgemeine und Industrielle Betriebswirtschaftslehre an der Technischen Universität München Prof. Dr. Dr. h.c. Ralf Reichwald (Hg.)

Michael Koch, Georg Groh, Christian Hillebrand und Natalie Fremuth

Mobile Support for Lifestyle Communities

Arbeitsbericht Nr. 34 (November 2002) des Lehrstuhls für Allgemeine und Industrielle Betriebswirtschaftslehre der Technischen Universität München Leopoldstrasse 139, 80804 München, Tel. 089 / 289 24800 www.prof-reichwald.de ISSN 0942-5098 © Copyright 2002 by Michael Koch, Georg Groh, Christian Hillebrand, Natalie Fremuth, TUM. Alle Rechte vorbehalten.

Koch/Groh/Hillebrand/Fremuth

2

Michael Koch*, Georg Groh*, Christian Hillebrand** und Natalie Fremuth***

Mobile Support for Lifestyle Communities

Bericht Nr. 2 aus dem Forschungsprojekt COSMOS**** (Community Online Services and Mobile Solutions, FKZ 01 HW 0107 – 0110)

* Technische Universität München, Fakultät für Informatik, Lehrstuhl Informatik XI, Boltzmannstr. 3, 85748 Garching, Deutschland, Email: [email protected]; [email protected] ** Technische Universität München, Fakultät für Informatik, Lehrstuhl Informatik XIII, Boltzmannstr. 3, 85748 Garching, Deutschland, Email: [email protected] *** Technische Universität München, Lehrstuhl für Allgemeine und Industrielle Betriebswirtschaftslehre, Leopoldstr. 139, 80804 München, Deutschland, Email: [email protected] **** Information about the Research Projekt COSMOS can be found under the following URL: www.cosmos-community.org.

Koch/Groh/Hillebrand/Fremuth

3

Contents: Contents: .......................................................................................................................................... 3 Abstract............................................................................................................................................ 4 1 Introduction ...................................................................................................................................... 5 2 (Mobile) Community Support .......................................................................................................... 6 2.1 Communities and Community Support ..................................................................................... 6 2.2 Mobile Community Support Services........................................................................................ 7 2.2.1 Services for matchmaking and awareness .............................................................................. 7 2.2.2 Services that support synchronous communication................................................................ 8 2.2.3 Services that support asynchronous communication .............................................................. 8 3 Community Positioning.................................................................................................................... 9 3.1 Differences between Location-Based Information Services and Mobile Communities with Location-Based Context .................................................................................................................. 9 3.2 Positioning techniques for mobile communities and mobile networks ................................... 10 3.2.1 Manual input..................................................................................................................... 10 3.2.2 Positioning in wireless networks ...................................................................................... 11 3.2.2.1Network based positioning in wireless networks............................................................ 11 3.2.2.2 Terminal based positioning in wireless networks.......................................................... 11 3.2.3 Positioning in wired networks .......................................................................................... 11 3.3 Transfer protocols and positioning requests ............................................................................ 12 4 Lifestyle Communities.................................................................................................................... 13 4.1 What are Lifestyle Communities? ........................................................................................... 13 4.2 Business Opportunities ............................................................................................................ 14 4.3 Community Selection for Pilotation ........................................................................................ 15 5 Cosmos Lifestyle Prototype............................................................................................................ 17 5.1 Lifestyle Platform – studiosity.de............................................................................................ 17 5.2 Basic Platform Concepts.......................................................................................................... 18 5.2.1 User Profiles ..................................................................................................................... 18

Koch/Groh/Hillebrand/Fremuth

4

5.2.2 Items ................................................................................................................................. 18 5.2.3 Messages........................................................................................................................... 19 5.2.4 Categories ......................................................................................................................... 19 5.3 Services.................................................................................................................................... 19 5.3.1 Services for the maintenance of personal profiles ............................................................ 19 5.3.2 Services for the maintenance of shared buddy lists .......................................................... 20 5.3.3 Services for retrieving information about other users....................................................... 20 5.3.4 Communication services................................................................................................... 20 5.3.5 Creating new information items (events and comments) ................................................. 21 5.3.6 Presenting the information items ...................................................................................... 21 5.4. Architecture of the Platform ................................................................................................... 22 6 Summary......................................................................................................................................... 23 References ......................................................................................................................................... 25

Abstract Community support and (location-based) mobile services are two prominent topics in research and development currently. However, they are usually not combined – there is little work on mobile community support services. In the project Cosmos we are working on such services. This paper briefly introduces the topic and presents first results from designing and implementing mobile support for lifestyle communities. Thereby, both technical issues and the organizational/economical issues are addressed.

Koch/Groh/Hillebrand/Fremuth

5

1 Introduction Human beings are social creatures with an inherent desire for communication and interaction with others. The term „community“ describes groups of people that identify themselves with a common idea (often reflected in common interests) and that have the means to communicate with each other, which they use to collaborate in the context of the common idea. Communities offer a context for people to meet and communicate and thereby support awareness of people and communication among each other. Community support systems help communities to form or function by providing a physical and/or virtual space where people can communicate and where they can find other people. A functioning community depends on the active participation of a significant percentage of its members. Hence, the availability and modality of access to the community support infrastructure can be considered a major issue, because only a broad participation in the community activities can sustain the functioning of the community. However, experience so far demonstrates that the common user base of community support systems is mainly composed of computer literate individuals, accessing the network with an already existing desktop computer at home or at the workplace. In fact, from the technology point of view, community support systems are often based on large bulletin boards and the main user interface is usually a Web browser. Electronic community support has been, till now, determined by boundaries of stationary computers and desktop based user interfaces. Ubiquitous computing, i.e. new user interfaces and the disappearing computer, and mobile computing are addressing these boundaries and offer possibilities for enlarging the reach of community support systems. In addition to enlarging the reach, mobile interfaces open completely new fields for community support – new functionalities and new scenarios can be contrived. The new possibilities (new functionalities, new user groups, new situations where community support systems can be accessed) require the development of new service types and of new technological solutions, but also ask for new business models and organizational concepts. In the project Cosmos (Community Online Services and Mobile Solutions)1 we are currently exploring possibilities and solutions in the area of mobile community support. In this paper we present first results from the Cosmos project. We first discuss the design and implementation of context and location aware mobile community support services (Section 2). In the next 1

The project COSMOS (Community Online Services and Mobile Solutions) is funded by the German Ministry

of Research and Education (BMBF FKZ 01HW0107 - 01HW0110). See http://www.cosmos-community.org/ for more information.

Koch/Groh/Hillebrand/Fremuth

6

step we address the central issue of positioning in the context of community support (Section 3). In Cosmos we are going to implement community support platforms for two different application domains. In Section 4 and 5 we are discussing the economic and organizational (Section 4) and technological (Section 5) solution for one of the prototype domains: lifestyle support. Section 6 finally wraps up, draws some conclusions, and presents our plan for future work.

2 (Mobile) Community Support 2.1 Communities and Community Support The main activities in communities are finding other people and communication in order to collaborate or help each other. Therefore, community support usually can be seen as “communication and matchmaking support”. In this context, the term communication is understood in a very broad sense. Communication can be classified as direct (email, SMS, chat, etc.) or indirect (publishing information for potential prospects, retrieving previously published information from the community information space etc.), synchronous or asynchronous, automatically triggered or manually triggered, and according to many more aspects. In summary, the following basic support concepts can be derived: -

Providing a medium or channel for direct communication and for indirect exchange of information objects or comments on objects within the common scope (the information space) of the community. The information channel can be enhanced with features that use information about the community member to do (semi-)automatic filtering and personalization.

-

Providing awareness of other members and helping to discover relationships (e.g. by visualizing them). This can help to find possible cooperation partners for direct interaction (matchmaking, expert finding).

Using networked computers for supporting communities can be tracked back to the beginnings of the Internet (Hafner & Lyon 1996). Current solutions mainly consist of bulletin board like systems, which are often integrated in different information offerings, and of different awareness and direct communication tools (see e.g. Ishida 1998a, Ishida 1998b, Michalski 1997). We believe that electronic support for several types of communities, especially local communities (built around a locality, meetings in physical space) can only be successful if the access to the support infrastructure is broadly extended into the real places through new user interface metaphors mixed with classical community support media, and not only offered through home or work desktop computers. It should be possible to use community support platforms “anytime” and “anyplace” – one should no longer need to go to special (work-)places to interact with other community members .

Koch/Groh/Hillebrand/Fremuth

7

Some projects have already started to tackle this objective. For example the project Campiello (Agostini et al. 2000, Grasso et al. 2000) was targeted towards the development of a community support system for the tourist domain. The main problem addressed was the fact that even while information systems are available anytime and anyplace they -

are not smoothly integrated into all interaction and task situations– some tourists would like to interact with the information system when walking around in a museum, and

-

are not available to anyone – especially computer amateurs are quite reluctant when it comes to interacting with a community support application via desktop based Web user interfaces.

2.2 Mobile Community Support Services In addition to the anytime, anyplace features (access from everywhere and at anytime, being accessible anywhere and at anytime) the extension of support for communities into the real world via the integration of mobile devices makes a broad spectrum of context data available for communication services. The most important contextual information is the information of someone’s whereabouts (the current location). Other contextual data include the interaction in which the user is currently involved, the temperature outside, the velocity and direction of movement etc. In general we can understand the context of a (mobile) user as all data that is measurable by sensors and that can be reasonably represented in a computer in order to improve the quality of services. Previous systems used contextual data in location based information services. For community support we are thinking of location and context based communication services. In the following we will discuss possible service categories according to the basic community support categories presented in Section 2.1.

2.2.1 Services for matchmaking and awareness Matchmaking is the process of bringing together people that have common attributes (flirting services, expert finder services etc.). This can be done proactively by pointing to a person that might be interesting to contact (and displaying an explanation why) or non-proactively by simply providing awareness of who is around (a topic, a place) and visualizing interesting (public) features of these persons. Providing awareness can also be offered for people one already knows. Such awareness services (Schlichter et al. 1998) provide information and notifications about people one has put on special (buddy) lists. Having this information available can help to arrange spontaneous communication. The features of mobile devices that open possibilities for new services are 1) that it is possible to query from everywhere or to be notified of possible contacts at any place, and 2) that location and other context attributes can be taken into consideration for selecting contacts. These features make it possible to

Koch/Groh/Hillebrand/Fremuth

8

use matchmaking for spontaneous activities and for immediately meeting face to face (if contacts where selected based on similar location). Implementing matchmaking and awareness features in a community (platform) might also help in addressing the privacy issues that usually come up when using and presenting user profile information. A community can be a perfect place to control access to such attributes by capturing and defining relationship networks (e.g. in the form of buddy lists) that can be used to define access control.

2.2.2 Services that support synchronous communication Synchronous (speech) communication is currently the most important use of mobile devices. Synchronous communication can profit from being embedded into a community in different ways. First, community platforms can provide more powerful functions for reachability management. Users can specify rules and parameters in their profiles that enable other community members to look up the reachability status of someone they want to call before actually placing the call. Knowledge of other user’s profiles and contextual data (which can conceptually be regarded as part of the profile) can substantially increase the power of a reachability management component by e.g. automatically detecting a business meeting by deducing it from the fact that a certain number of coworkers are in a room together. By monitoring not only the motions and contexts of single persons but also the motions and contexts of groups of persons, a much broader basis for the application of machine learning algorithms for inductively learning reachability patterns will be given.

2.2.3 Services that support asynchronous communication Sending asynchronous messages (email, SMS, etc.) is a very effective way of communicating and profits much of the community scenario and the mobile scenario as well. Sending messages to groups of people that are defined through combinations of attributes is one possible application. E.g. the groups can be defined as “the group of people with a current location near me” or “the group of people with a future location near xy” (tagging messages to places). In addition to pure messages community support services should also allow to collect community information and comments on such information, and make new items available as messages. Besides manually triggered asynchronous communication or information pull, automatically triggered personalized and context-sensitive communication (push services) are very useful too. E.g. the system can inform users of other community members around, or of information that is useful to groups of community members around. What is common to all community support services (and in particular for mobile community support services) is that the focus is on social interaction through communication. This is in contrast to the “services” offered on existing web-portals with some more or less dedicated thematic focus, which

Koch/Groh/Hillebrand/Fremuth

9

mostly offer access to content which is rather static in nature and which is mostly collected or produced by a team of editors. The strength of information management with a community paradigm lies in the dynamics (context-sensitiveness) and self-organized nature of the information that is communicated via (mobile) community support services. Thus, in a sense, mobile community information spaces can be a means to close the gap between one-to-one communication and rather static information portals on the web.

3 Community Positioning A very important aspect of mobile community services is providing location information to users, doing notifications triggered by location changes, and providing location-sensitive communication services. Hence, location and positioning services are a central part of mobile community services. They are needed for information services like “where is the next pub”, for communication services like “who is at the moment in this special pub”, and for group communication services like “where are my friends and where is the best meeting point”. The location information plays a very special role. The more exact and the more current the position of the community members is known, the better the offered location based services will be. Ideally, the system would know the exact position of every community member at any time. Unfortunately, it is not possible to have such a system yet. The computation of the position depends on the technology, which is used. E.g. the GPS (Global Positioning System) is very exact, but the receiver costs a lot of money and even the stand-by function consumes a lot of power. Less exact positioning can be provided with mobile networks as they are used for mobile phones. Another trade-off can be found in costs for the user. Because of these trade-offs considering different refreshing methods for the community member’s position is an important issue.

3.1 Differences between Location-Based Information Services and Mobile Communities with Location-Based Context Location based services are not a brand new thing. A lot of persons are already using location-based services without knowing the name “location-based services”. The GPS (Global Positioning System), installed by the US Army, was first used for military positioning. Now it is also used for non-military applications like car navigation, fleet management or tracking services. Five years ago, another way to provide location-based services has been developed: In mobile phone networks, it is possible to get the user’s position from the surrounding base stations. With a WAP (Wireless Application Protocol) enabled mobile device it is possible to get location-based services like finder services or accounting services. One big advantage of this method is, that there is no expensive additional hardware needed to use the services. But all in all, the described location-based services have all the same characteristics: The user wants to get information in context to his current position. The services are typically “pull” information ser-

Koch/Groh/Hillebrand/Fremuth

10

vices. The initiator asks for special location-based information, and therefore, the position is calculated. There is no interference with any other user or member of the system. Mobile community support with location context is different. The services are mainly about communicating information from one member of the community to another member depending on the position of both members, or to make the position of other members available. So, information about the position of a member has to be available even when this member currently uses no community service. The mobile community with location context can be seen as evolution of the location-based information services. In location-based information services, one’s location information was only important for himself. In location-based community services the location information from each community member will help all the other community members.

3.2 Positioning techniques for mobile communities and mobile networks There are a lot of different positioning techniques to get a member’s position. These techniques differ in many characteristics: handling, exactness, technical request and costs. We now will discuss the different techniques in the context of mobile community support. 3.2.1 Manual input The continuous manual input of the position is the easiest possibility to get position information. The user finds out her position (e.g. by using a GPS receiver) and manually submits it whenever it changes significantly. The only costs are the connection charges for transferring the information to the community server. The position information can be provided in different formats (granularities): 1. Area format, e.g. town, district or municipal area: For mobile community services like friend finding in the surrounding area, requests to the events database or the weather information this exactness is sufficient. 2. Exact position input with address input: Street name and house number are provided and used by the system to calculate the exact position. With this format, it’s possible to offer services like the exact position of my friends or sticking information to a location. 3. Exact position input in geographical format: The current position is provided in geographical coordinates (e.g. geographical length and width or Gauss-Krüger notation). This position information is the most exact one and can be received from positioning systems like GPS receiver. In order to enter the position information manually, the system can offer a WAP form or accept position information by SMS. Intelligent user interfaces or pre-defined locations can make entering the current location more convenient. Another simplification would be to provide the possibility to define

Koch/Groh/Hillebrand/Fremuth

11

rules about where a user is when or even allow retrieving location information from an online appointments book (position timetables). 3.2.2 Positioning in wireless networks The problem with manual input is that the user has to act to change her location information. It would be easier to have the network determine the location and publish it (semi-)automatically. In mobile phone networks there is the possibility to calculate the position relative to base stations. This is done by triangulation with the signal arrival times from different base stations to the mobile terminal. The information about the base stations’ locations it needed in order to translate the relative position to a geographical position. By now, there are five different methods known: Cell-ID, Enhanced Cell-ID, E-OTD, TOA and A-GPS. The methods can be used in network based positioning and in terminal based positioning. 3.2.2.1Network based positioning in wireless networks Network based positioning is the most common method for location-based services in mobile phone networks. The mobile networks include a location server. This server calculates on demand the position for each user in geographical format. Third party service provides can query the position information via interfaces like Parlay to offer location-based services. In order to use the user’s position for community support services, the community server would need such a connection to the mobile phone network’s positioning server. 3.2.2.2 Terminal based positioning in wireless networks For terminal based positioning, a logical unit in the mobile terminal and information about the base stations’ geographical positions is needed. The logical unit reads the important positioning information (Cell ID and/or signal strength and/or surrounding cells) and sends them to an independent location server (located in the community server), which has a big database with the base stations’ geographical positions. The server calculates the geographical position from the data and returns it to the mobile terminal. Logical units in the mobile terminal could be Smart Phones, PDAs or even the SIM Application Toolkit. The biggest problem for terminal based positioning is to get the base stations’ geographical positions. Mobile network operators are currently not releasing this information. If this information is available, the community positioning system would be independent from the mobile phone operators. 3.2.3 Positioning in wired networks Mobile community members will not only work with mobile terminals. Some of the interaction in the community will also take place from stationary computers (home computers, computers at work/university or even computers in Internet cafes).

Koch/Groh/Hillebrand/Fremuth

12

So we should also look at retrieving position information when the user is working from a stationary computer. The main information for this is the computer’s IP address. An IP address is a unique number in the whole Internet. It is separated into net-id and host-id. Using a database with information about IP address and geographical position a community support system would be able to derive the client’s position (e.g. the IP addresses from the university are best known as well as the geographical position). This relation should be maintained and stored for every community member separately. Even if there is IP address masquerading done by the Internet service provider, the community server is able to find out the network id and therefore the service provider. If the community server knows from the user’s profile wherefrom the user uses a particular connection (e.g. user x always uses service provider y to connect to the Internet at home) then it is possible to determine a position.

3.3 Transfer protocols and positioning requests Network based positioning and (free) automatic notifications about location changes by the network infrastructure would be ideal for getting most accurate position information in the community server. Problems for implementing this approach are different technologies used at the different network operators and the unwillingness of the network operators to provide this service. For terminal based positioning or network based positioning without change notifications we have to consider costs per position announcement. In mobile networks, each byte sent or each second online costs money, and network providers charge money for every positioning request to the network. Therefore, the communication protocol for the positioning in wireless networks should be very effective. Unneeded overhead is not acceptable. There are three different position update methods in order to achieve this goal: 1. Manually controlled position update: The user decides when there should be a position update. In contrast to the manual input it is not needed to enter the position, just to trigger the update. The more often she updates her position, the better known the position is and the better information the community will get. 2. Time controlled permanent update: The user’s position is automatically updated every time interval. This method is useful for community member, who are always on the move. However, if the location does not change very often communication cost are wasted. 3. Update on location change: The position information is updated if it has changed. This approach need special programming in the device or network. Both approach 2) and 3) do not provide awareness about when location information is transmitted to the server. If the server does not provide appropriate awareness and privacy functionality these approaches might be turned down by the users.

Koch/Groh/Hillebrand/Fremuth

13

4. Location update on demand: The user’s position is calculated on demand when there is a positioning request for the community member. The community location system requests the positioning information from the user, calculates and then responds the result. The main problem with this solution it the time delay. The different positioning request methods, the transfer protocols and the positioning methods offer different information qualities for different costs. In current mobile networks all the positioning costs have to be covered by the user that is positioned. Since in contrast to location based information services in mobile community platforms the advantage of having the location information available is relevant to other users, we should consider schemes where the costs are shared. Different models for this have to be designed and evaluated.

4 Lifestyle Communities The general issues about mobile community support as described in the previous sections will be concretised in the Cosmos project. We will build a configurable support platform for mobile communities and evaluate the platform in two different application domains – Lifestyle and Healthcare. The main goal of the pilotation is to find and test new ideas regarding conception and operation of mobile communities in order to provide recommendations for operation and business models. Only by piloting mobile communities new investigations about acceptance/adoption of mobile services and changes in user behaviour or communicational preferences can be carried out well. In this paper we will focus on one of the pilots, the mobile lifestyle communities. We will discuss how they will be implemented and what particular features will be provided in our prototype platform.

4.1 What are Lifestyle Communities? A community is a group of people who share some commonalities, have the possibility to communicate and collaborate together / help each other (see definition of communities in Section 2). Lifestyle communities are communities where the commonality and the cooperation / helping is rooted in the lifestyle of the members. In Webster’s New World Dictionary “lifestyle” is defined like this: “the consistent, integrated way of life of an individual as typified by his or her manner, attitudes, possessions, etc” Since the “way of life of an individual” is a very broad concept we will restrict lifestyle for our work to the non-work part of an individual’s life, which is the leisure part. So when addressing a lifestyle community we more talk about a “leisure community”, that is a community with the main purpose of organizing and performing leisure activities in a group of people. Examples for leisure communities in real life are sports clubs or cliques of friends. The selection of groups for our evaluation is further lim-

Koch/Groh/Hillebrand/Fremuth

14

ited by economic aspects and by aspects of access to user group and technology-affinity of the user group. We will discuss these aspects and present our selection in Section 4.3. In the area of leisure support there are already several existing support tools. Two main classes of tools can be identified: -

Lifestyle portals (information for organizing leisure activities), and

-

matchmaking services (dating, finding sport/cinema/... partners).

The lifestyle portals are mostly centred around edited information offerings and do not provide real community support. Mobile access and location based services are available with some of these portals (e.g. showing what films start soon in nearby cinemas).

4.2 Business Opportunities The goals of Cosmos are to find out about and evaluate technical requirements and conceptions for mobile community support. Additionally, relevant economic questions should be identified and investigated. In this context we focus our research activities on operation and business models for mobile communities. Up to now, the economic experiences of enterprises and other professional organizations with operation of community platforms have shown that the expenses for operation and technical maintenance are enormously high. (see e.g. Panten et al. 2001). But without perspective for revenues or profits there will hardly exist motivation of professional operators to offer and maintain Web-based or any other platforms for communities. In spite of the importance that ideas like „lifestyle“ and „leisure“ are getting in the life of human beings and the related consumption expenses, community operators hardly manage to generate significant revenues or profits from their operations. In Germany for example, only very few economic success-stories of community operations can be identified (see Konitzer 2001). From an economic perspective, we see the following opportunities to generate revenues from community-operations (see details in Reichwald et al. 2001): -

Primary sources of revenues from community operations are the typical direct and indirect revenue streams of the telecommunications and media sector (Zerdick et al. 2001). Examples are subscription fees, advertising or pay-per-view/pay-per-click fees. However, these revenues can so far hardly be realized as consumers only have a very low willingness to pay for services and content in the Web.

-

New secondary sources of revenues should be identified out of the operator’s knowledge about the preferences, needs of „his“ community. This knowledge can be interpreted as knowledge about target groups that can be the base for new product developments or consult-

Koch/Groh/Hillebrand/Fremuth

15

ing services for other companies. Customer Communities, for example, can contribute a lot of ideas for product innovation (e.g. the community „LUGNET“ that was established around LEGO™ toys). Furthermore, a community-operator can consider its community as his own field for market research. The extraction of special know how about the needs of target groups can be transferred into new business opportunities as e.g. consulting (the community „Powderhausen“ (a community for young snowboarders) is a good example how community operators themselves opened new business opportunities in the field of technical consulting and market research consulting services). It is still unclear, which new opportunities for revenues can be identified by offering mobile community services. In principle, telecommunication operators see a higher willingness to pay for mobile services than for web-services. Regarding user preferences and willingness to pay for services we aim to get some new data by piloting the mobile lifestyle community. The offer of mobile services also leads to a new technical complexity and organizational challenges for the operation of a community platform. So far we could observe, that media enterprises cooperated with software companies in order to build up, maintain and „feed“ the community with new information and services. Now, mobile community support also makes coordination with mobile network providers necessary in terms of airtime or revenue sharing. How this new technical requirements will affect or transform the present operation models is also an important research topic in the Cosmos project.

4.3 Community Selection for Pilotation For answering the research questions we do not need to support community building on our platform but can concentrate on supporting already existing communities. So the first step of our pilotation was to identify existing lifestyle communities in our area and evaluate their potential for mobile community support. As defined in Section 4.1 we are focusing on common leisure activities. Excursions, sports activities or other hobbies can be considered main activities, which people organize and spend together. So, group events, group experience and mobility are very important aspects for lifestyle communities. In the area of Munich lots of different, existing lifestyle communities have potential and needs of mobile community support as e.g. snowboard communities, biker communities, sailing clubs, partycliques, etc. Regarding the long-term empirical evaluation of this mobile community prototype it is important to carefully select the communities. So we define the following assumptions as critical points that guide the selection: -

Access to the selected community: in order to do the long-term empirical evaluation of the mobile community prototype the research team should have direct access to the community.

Koch/Groh/Hillebrand/Fremuth

16

This facilitates the organization and procedure of regular feedback loops or group interviews, which are the empirical methods that will be used for the empirical research (Flick et al. 1995; Bortz & Döring 1995). Regarding the user-friendly conception of the community platform, knowledge about the needs and preferences of the selected community can also be seen as important aspect, which can be facilitated by ease of access to the community. -

The members of the selected community should be open-minded towards new technologies.

-

The opportunities of mobile community support should significantly enrich the forms of communication and interaction within the community.

-

Ideally, the selected, existing community should already use fixed-line communication services for their community-conversations. This aspect can then facilitate the investigation of changes regarding use of communication services within the community. Additionally, this could help to clear up the different requirements of web-based community support and mobile community support.

Considering all the issues lead us to selecting groups of or around students of Technische Universität München (TUM) as communities for the pilot. The groups will be supported in coordinating their activities in the university and especially outside university. All the requirements listed before are met by this selection: -

As employees and lecturers at TUM we easily have access to our students. This helps us, to get to know about and understand their needs, preferences and activities beyond their study work. So, these already existing relationships really help us in order to offer an interesting design of community support. The easy access to the selected groups also facilitates the realization of our empirical work.

-

Students at TUM are all working in technological sciences and can be considered to be openminded versus technology. However, they can also be critical users towards technological innovations.

-

In their lifestyle, students often undertake lots of different activities, which require to be very flexible and mobile (see all this activities as e.g. attending university (lectures and seminar groups), part-time jobs, sports, going-out in the evening etc.). New mobile, group-oriented communications services can offer them enormous support for their super-active, spontaneous and mobile life.

-

At TUM students have generous support for using Internet and telecommunication services (computer labs, low-price Internet connections, etc.). Hence, they are used to communicate via electronic media to each other. But there is a growing number of students and young people, who do not have any more a fixed-line telecommunication connection at home. The interest

Koch/Groh/Hillebrand/Fremuth

17

for mobile community-support within these communities of students can be considered as very high. This will help us get new findings about acceptance and use of mobile services as well as to get empirical data about changes in user behaviour and willingness to pay for mobile service. Student groups at Technische Universität München, which can be selected as prototype users for our mobile community, are e.g. the active students in our TUM-Business-Club, the students of our „SportKreativ-Werkstatt“ or the student groups that are organizing events like TU Cinema or TU Summer Festival. All these mentioned groups have in common, that they do not only study together, but also undertake the organization of (leisure) activities together in the environment of the university. By piloting mobile community support for student groups at Technische Universität München we will face in practice all of these new questions. The last chapter details the new requirements and tasks for the technical realization of mobile community support, which will be the base for further economic research on finding efficient structures for community-operations and business models.

5 Cosmos Lifestyle Prototype In this chapter we will present the concept for a prototype community support system, which will be developed in the course of the Cosmos project. We will explain the basic framework, the envisioned services and will describe the architecture of the system in order to give an insight, how the ideas of the preceding chapters can be realized.

5.1 Lifestyle Platform – studiosity.de For the lifestyle application domain we are building a generic support platform. As outlined in the previous section the platform will address students in general and especially support small (open or closed) sub-groups. The platform will be targeted towards enabling the community members to coordinate their lifestyle activities. Thereby, we focus on community-centered positioning and presentation of this positioning information and on text/multimedia based messaging and community content services that make use of the location information. Services (desktop and mobile) will be targeted towards: -

Coordination of activities and exchange of information around events

-

Location awareness in sub groups

-

Location and availability aware communication

As one medium we will provide an information space that can be filled and extended by the community members. The information space of the community will be centered around lifestyle events (information items which have a clear temporal and spatial reference). Extension of the space means both

Koch/Groh/Hillebrand/Fremuth

18

adding new events to the information space and adding comments and discussion to the events. In addition to the information space we will provide different communication channels and user profile attributes for location and availability which can be accessed by other users or used in automatic processing rules (to ensure privacy and provide different information granularity to different users).

5.2 Basic Platform Concepts The most important elements within the concept of the platform are information items, messages and user profiles. 5.2.1 User Profiles User profiles are attribute value vectors which represent the complete information about a user which is available within the platform. There are parts of the profile, which are rather static in nature (such as name, age, sex, interest-keywords, subscribed topics, phone numbers), and there are parts, which are rather dynamic in nature (such as location, current state of interaction (with devices or programs), current state of reachability, etc.). These attributes are supplemented by a set of preference rules, which manage -

The access-privilege-(privacy)-preferences of the user (who may access what parts of a user’s profile under what circumstances (in what context))

-

The communication preferences of the user (who may communicate with me on what channel under what circumstances (in what context))

-

Automated setting patterns for dynamic profile parameters which are not desired to be measured automatically or which are not desired to be manually updated (E.g. location is not tracked automatically, but rather set by such “default” rules like e.g. “if(0800