The impact of NFC on multimodal social media application

Transcription

1 Second International Workshop on Near Field Communication The impact of NFC on multimodal social media application Erkki Siira, Vili Törmänen VTT, Finland Abstract In this paper we describe the NFC-based multimodal social media application Hot in the City. This application allows users to make friends by touching other users NFC devices through the peer-to-peer mode. Users can also inform friends of their current location by touching hotspot tags. This study describes the three NFC modes in detail and delineates what kind of impact NFC has had in the creation of the Hot in the City social media application. In addition, we analyse how the use of different NFC modes reader/writer and peer-to-peer has unique consequences on user interface and system design. Even though NFC offers intuitive, natural interactions, the changing between modes seemed to confuse less experienced users. Index Terms NFC, peer-to-peer, reader/writer, social media I. INTRODUCTION Near Field Communication (NFC) is a wireless communication technology that operates within a range of a few centimetres. NFC devices offer three different modes. A reader/writer mode interacts with NFC tags, while peer-topeer mode allows two NFC devices to exchange data when they are placed near one another. The third mode is a card emulation mode in which the NFC device acts as a smart card. Only one mode can be selected at a time. The popular reader/writer use case scenario is a smart poster in which users can get desired information from a poster by touching an attached tag. This information is usually a URL as the tag cannot hold much information. The card emulation mode is used in smart card use case scenarios which include payment and ticketing. In the use case scenarios of the peer-topeer mode, the Bluetooth connection is paired with the two devices. The adoption of NFC in mass market phones has been a relatively lengthy process as new models with NFC have been introduced to the market at a slow pace even though market predictions have been positive in terms of the level of penetration of NFC devices. The main focus for the NFCrelated industry involves making payment and ticketing operative as these are considered to be the driving force in the adoption of NFC. In general, there are many incentives to incorporate social media into mobile devices. Social media are relevant to users throughout the day and idle moments are windows of opportunity to get users to access social media. In this paper, we describe the Hot in the City application, which combines social media and NFC. Hot in the City is a multimodal application that uses the reader/writer mode to create new location hotspots while allowing users to log on to location hotspots. The peer-to-peer mode permits users to make friends by exchanging personal information between devices. NFC-enabled social media applications raise a series of questions: how can these applications be created? What are their restrictions? What are the best design choices? Multiple studies [1, 2] have shown that the touch paradigm of NFC is intuitive and natural for users to understand, but most studies have not examined the multimodality of NFC and how to create understandable process for user in order to facilitate different modes. In general, the issue involves the implications of creating a multimodal NFC application, or in other words, what needs to be addressed when the read/write and peer-to-peer modalities are used. The implementation of the application is studied in terms of how social media and NFC can be combined, with the goal of implementing a general multimodal NFCapplication. Incorporating NFC to social media has effects on many levels. This paper focuses on three: the system level, the protocol level and the user interface level. II. NFC AND SOCIAL MEDIA In recent years, social networks have been introduced to the mobile context. They are mainly established social networks used through a mobile interface. Some concepts, like Google Latitude [3], are exploring location-aware services for social networks. Satellite positioning can be used to inform users of the location of his or her friends are. The penetration of GPSenabled mobile devices has grown in recent years so there is customer base that can use the new feature. Satellite positioning, however, presents problems when people head indoors which is often where people are when they would like to be located by friends. NFC is a one solution to the problem of indoor positioning in the context of social networking as people can be located by fixed hotspots. Only a few social media endeavours have used /10 $ IEEE DOI /NFC

2 NFC tags to locate people. For example NFCSocial [4] and Friendticker [5] have implemented tag-based positioning in social media. The system differs from satellite positioning: the tags are unaware of their own position. Instead, they rely on the context information provided by the tag distributor or user. Hot in the City is a mobile social network application. It is a cross-platform system that is meant to be used on the move with an NFC-enabled mobile phone and with a computer (when the user has the possibility to do so). The novel aspect of Hot in the City lies in its use of peer-to-peer mode of NFC, which represents a potential technology for social media. Hot in the City may be combined with Facebook. Facebook is a social media website with over 350 million users [6] and it has grown to become the world s largest social media website. Facebook offers third party developers the chance to develop applications that Facebook users can add to their profile and utilise. Applications range from games and quizzes to enhancing the social media experience; they must be approved by Facebook to be searchable for all users. Facebook s friend system works in such way that a user must send an invitation to another user and the other user must then accept him/her as a friend. Facebook provides this friend network information to applications that can use it as they wish and users have permitted them to do. The restriction is that the information must not be saved or used outside of Facebook. III. OVERVIEW OF HOT IN THE CITY Hot in the City is a social media application that combines tags-based positioning, NFC-enabled mobile phones, Facebook and the novel idea of forming a network of friends through touching. Making friends through touching is the concept Hot in the City introduces to the field of social media. It takes social situations from the real world to the context of social media. It means that creating friend connections in social media networks is done just as it is in the real world face to face. NFC excels in interacting with real world elements and thus seems to be suitable for incorporating real world events into the virtual world. Locations are defined by tags. Tags which are called hotspots are distributed by users or businesses that would like to offer the Hot in the City services. A hotspot tag has user-written information about the location, but the tag and the location information are mapped together in a backend system to ensure the location information is available when they are installed. The location information consists of descriptive texts the user inserts; as a result, the reliability of the location information is what the users make of it. Tags can be used to mark more than locations in Hot in the City: the concept of events has also been incorporated. Events in Hot in the City represent any occasion that has a start time and an end time. Any number of tags can be linked to an event, meaning that users can join the event on any of the tags. This is useful in the case of large events (like a festival or a trade show) and tags can be inserted at all of the entrance points. Making friends at an event is a special case because a trace of the meeting remains and the user may later check back to remember whom he or she met at the event. Events are also created by users. To distinguish event tags from location hotspots, we have created different graphics to install at the top of the tags. As events are more complex concepts than location hotspots, user needs to enter more information when creating one. The user is asked to provide a name, a text description and both the start and end time when the event is created. There is a Facebook application for Hot in the City. It combines friends from Facebook and friends gathered with Hot in the City. The Hot in the City Facebook application creates another interface for the Hot in the City system. A user may browse the information about his or her friends and see the event where the friendship was formed. All of a user s Facebook friends who have installed the Hot in the City Facebook application are shown on the login list. IV. MODES OF NFC NFC s functionality is divided into three different modes. The modes are reader/writer, peer-to-peer and card emulation [7, 8]. Only one mode can be selected at a time, which means that when the reader/writer mode is on, the peer-to-peer mode cannot be used. In other words, the user must manually select the mode of choice; otherwise, the application requires some kind of predetermined algorithms that predict the user s needs. The Hot in the City application uses the reader/writer mode to read and write information from and to tags, while the peerto-peer mode allows users create friendship connections between users when two phones approach one another. In the following sections, the reader/writer, peer-to-peer and card emulation modes are all described. A. Reader / Writer This mode enables NFC devices to read data from different standardised tag types. The compliant tag types are mandated by the NFC Forum. [9, 10] The Hot in the City application reads tags in two situations: when the user logs on to a hotspot and when he/she logs on to an event. There are no restrictions on the tag type so basically every compliant tag can be read. Part of the reading mode is the auto-launch feature where Hot in the City registers a record it wants to be auto-launched from the operating system. There are no restrictions in terms of writing on certain tag types but the tag size is restricted. Data are stored on the tag in NDEFRecords, which consist of type, type format, an identifier for payload and the byte array of a payload. In addition to the information about the hotspot or event, the application also provides a download link to the tag. The download links is an individual NDEFRecord while the hotspot or event information is another NDEFRecord. These are both included in the NDEFMessage that is written on the tag. The tags, however, can still be modified. 52

3 In order to allow users to create their own hotspots and events, the Hot in the City application is able to write information to tags. The information written on the tag is an NDEFMessage which consists of two NDEFRecords. NDEFMessage and NDEFRecord are NFC Forum defined message and record formats. B. Peer-to-Peer This mode enables two NFC devices to exchange data with one other. The peer-to-peer mode is standardised in ISO/IEC In the peer-to-peer mode, NFC devices can be in either active or passive mode and communication is transported over a bidirectional half duplex channel. [11] The peer-to-peer mode has two different operating modes: ISO-standardised NFC IP-1 and LLCP[12] (Logical Link Control Protocol), which is currently in the standardisation process. However, a non-standardised implementation already exists in the Nokia 6212 Classic mobile phone. NFC IP-1 is based on an initiator-target paradigm. The devices must know which device is the initiator and which is the target. This must be agreed on beforehand. During a peerto-peer communication session, this may be changed, but when establishing the first connection, the target must be listening to incoming transmissions and the initiator must be sending the transmission. LLCP makes peer-to-peer transactions smoother as it enables NFC devices to be equal in communication. LLCP handles the initial handshake and may randomly assign which device will send the data first. When the session is established, the decision logic is in the application layer. The applications know who has the data to be transmitted and it can then be negotiated because the communication channel exists. The Hot in the City application uses the peer-to-peer mode to create a friendship connection between users. Users manually select the option of adding a friend and then touch the other person s device with their own. Devices send their unique user ID to the other device and the information is then sent to the backend system. In the first versions of Hot in the City, NFC IP-1 was used, mainly because it was the only protocol available at that time. The initiator-target approach presented a problem in terms of design. The application menu for making friendship had to be divided in two separate menu items and users had to vocally negotiate who selected the initiator mode (Invite friend) and who selected the target mode (Accept invitation) as phones couldn t negotiate it by themselves. For a use study [13], Hot in the City was implemented with the NFC IP-1 peer-to-peer mode. Adding friends proved difficult because users had to perfectly align the two devices to avoid error. The model utilised in the use study was the Nokia 6131 and its NFC antenna proved unsatisfactory in peer-to-peer communication. The phones did not find the other phone without the correct antenna alignment. Users often had to bring phones together many times and test different alignments before the information was successfully exchanged. Even more experienced users who routinely did the peer-to-peer connection with the Nokia 6131 noted that it was difficult to add friends and that it was impossible to rectify the problem because the programming interfaces do not provide any help in this regard. When the LLCP became available for the Nokia 6212 Classic, it was implemented in the application because it allowed for a more intuitive user interface for the users. With LLCP, there was only option for adding friends (Make friends). User satisfaction with the make friends option was higher with LLCP than with NFC IP-1. Though neither the speed nor the reliability was measured, users reported that the phones found each other with fewer alignment problems. We do not know if there is really a difference between the two protocols at the hardware level. It was difficult to make a decision to replace NFC IP-1 with LLCP, because LLCP-capable devices were outnumbered by devices that were NFC IP-1 capable, but considering the users experiences, the choice had to be made. Two interesting observations about the Nokia 6212 Classic phone model were made during the implementation of application. Although the phone supports both protocols, these observations are related to LLCP. First, the alignment of phones is most successful when phones are brought together sideways and facing same direction; the antennas of both phones should also be aligned. The second is related to the factory settings of the phone model. In order to make the peerto-peer model work smoothly on J2ME applications, the user had to make modifications to the default NFC settings. If these modifications are not made, the phone s operating system opens a dialog box requesting users approval to allow the card use mode when devices are brought close to one another. C. Card emulation In the card emulation mode, an NFC device functions as a contactless smart card. In this mode, the NFC device will not generate its own RF field. [11] The supported card types are Mifare ISO/IEC Type A and Type B, FeliCa and ISO Card emulation is an important mode of NFC as it permits payment and ticketing. In addition, it makes use of existing smart card infrastructure. Hot in the City does not use the card emulation mode. V. IMPLEMENTATION A. The system level To make an NFC-enabled social media application possible, a backend system is required to control it. The backend system is needed to map all the tags to locations and events. Tags are identified by their unique ID. Users may rewrite tags to create new meanings for them. This creates a risk of vandalism, but the re-usability of tags is a good reason to keep them open. This rewrite function has a peculiar effect, for example, if a hotspot name is changed when a user has logged on to the hotspot, the user appears to be in a new hotspot since only the new name is shown. The decision to allow tags to be rewritten 53

4 is important for NFC applications and the consequences must be considered thoroughly. Figure 1 shows a system diagram of Hot in the City. The system is divided in three parts. The first part is the local infrastructure, which includes tags and users with NFCphones. The Hot in the City MIDlet-applications are installed in the phones themselves. The second part is the WWW where users may browse their Hot in the City-related information on Facebook. The Facebook requests the application logic from our server that is in the third part the backend system. The backend system has two servers: one for Facebook and the master server that has access to the database. Although the accuracy of the information cannot be assured, it costs nothing as auto-launching data must be entered anyway. The backend system keeps a record of friendships created by users. In Facebook, this friendship information is then combined with Facebook s own. This concept of the visibility of friends reflects Facebook s decision to keep the friendship information within Facebook and such information may not be used, for example, in our mobile Hot in the City application. Thus user may view different sets of friends in different views of the system. When making friends by touching devices, both devices send a confirmation of the transaction to the backend system after the phones have exchanged data in the NFC field. As LLCP is used, there is no real way to determine to whom the application should issue the network costs. The randomness of the LLCP would put either of the users in the position of incurring costs, but the other person would not have to inform the backend system of his/her decision to add a friend. In Hot in the City, the process for making friends requires both parties to connect to the backend system to confirm the addition of a new friend and the network costs are thus shared by both users. NFC applications that use peer-to-peer functionality and then initiate related network traffic need to clarify which user will incur the network costs. In some scenarios, the old NFC- IP1 initiator-target paradigm works, but when friends are added, the responsibility is clearly shared and thus both users should bear the costs. Figure 1: The system diagram of Hot in the City Keeping record of tags, a part of tag management, is the unique feature the NFC has in terms of managing the stress of the backend system. The ability to scale the system to determine the number of tags inserted in the system is an important feature. Searches of the database for unique tag IDs will slow down as new tags are inserted. Tag management is a part of several NFC-applications but performance problems have not yet appeared as systems are still so small. This will be a future challenge for NFC-based systems. During development, the use of other tags (i.e. tags other than those entered in Hot in the City) as sources of location information was discussed, but no mutually agreed convention existed to describe locations in generic tags. It would be useful to think about other applications as well when designing the infrastructure of the system. When entering a hotspot tag or an event tag, the Hot in the City application enters the location or event information onto the tag. The backend system, however, already knows this information, so it is not actually needed. The benefit is that other applications can get some information from the tags. B. The user interface level Two fundamentally different versions of the Hot in the City application have been made. The first was a proof of concept that went through a use test [13]. This application used NFC IP-1 as a peer-to-peer protocol and needed users to determine who invites another user as a friend and who accepts the invitation. After the use test, the proof of concept application was redesigned and re-implemented. A user experience test was done with five people to gauge users opinions on the design and identify errors. Detected errors were corrected and the design was discussed. The user interface consists of three main elements which are divided in tabs. A user moves between tabs by pressing left or right with the centre soft key. The different tabs are called menu, status and events. The menu presented in Figure 2 consists of selections for making new friends, creating new hotspot or events, checking personal codes and viewing information about the application. The status tab presents the user and his friends login information In the events tab, the user can view current and previous events with their name, a one line description, and the start and end time. Detailed information with long descriptions is available and on the event details screen, users can also opt to leave the current event. 54

5 Figure 2: Menu screenshot When Hot in the City users want to become friends with each other, they need be within touching range. Both users select Make friends from the menu options. The application then asks the users to place the devices close to one other. Now the phones try to send a message though the peer-to-peer mode to the other phone. When phones come close enough together, the messages are exchanged and then the application sends a notification of the new friendship connection to be saved to the backend system. After a successful save, the user will see that a new friend has been added and his/her new friend information is available on the status tab. The tag reading mode, which allows users to log on to hotspots or events, is a default mode in Hot in the City and is possible at all times except when creating a new hotspot or event or while making friends. These two features use either tag writing mode or peer-to-peer mode. The adding of friends or hotspot creation features must be manually selected from the menu. This distinction between the default mode and the manually selected modes was a challenging feature for some users. In the user experience test, the test users were afraid to touch hotspot tags to log on because there is no indication that the reading mode is constantly on. When users learned that the reading mode is a default, the same use pattern was used to make friends as they just tried to touch the other user s phone without manually selecting the Make friends option from the menu. This user experience test underlines the problem of the lack of clear use patterns with multimodal applications. Even though the touch paradigm may be familiar to a user, the distinction between modes might not be easy for them to recognise. There are some options to help guide the user to make the right choices. One way to tackle the problem would be adding the Read tag option in the menu tab. Having the option on the menu tab would make it necessary for users to go to that tab when they would like to log on to a place or event. If there were no default mode, use patterns would be coherent but not efficient. Another option could be teaching the specific application to the users, but this might not always be possible. In addition, the user study group indicated that it was not familiar with the ability to launch the software by touching a tag. How could the user be made aware of this option without having to resort to the help section? An additional study must be done with users to find out the best approach to tag reading, the changing of modes and the indication that device is ready to read tags. If the user has to first select the option of reading the tag from the application, then the ease of use of the whole touch paradigm is reduced. The creation of icons or global graphical guidelines could help users become familiar with the different modes of NFC. In an application that uses tags, the user interface level also contains the tags. As shown in Figure 3, the Hot in the City hotspot tags have a circle with a different colour than event tags. Hotspot tags all have the same image while the event tag images vary depending on the event type (i.e. a party or a work-related event). The type of tag, i.e. hotspot or event, could be written in the graphical layout of tags or clearly stated elsewhere in the application because users do not know what kind of tag they are going to touch without a trial and error process. Figure 3: A hotspot tag is shown on the left, and an event tag on the right C. The protocol level Simple XML structured data are used to exchange information between the server and the mobile client. The mobile phone sends requests and the server sends back responses which are either data that the mobile client wants or an error if the server encountered incorrect data or could not handle the request correctly. Hotspot and event tags have two NDEFRecords. One is the event or place information for the application s use; this is an external_rtd type record. The other NDEFRecord is a URL which points to the download link for the application. Hot in the City makes an auto-launch registration when the application is launched for the first time. When the tag is touched, the phone looks up its push registry information if it has any application registered to handle the tag s first NDEFRecord. If this information exists, the phone starts the application and gives the tag information to the application. In this case, the application is Hot in the City and the procedure to log on to the hotspot or event is triggered. If there is no Hot in the City application installed, the phone gives the second NDEFRecord, which has the URL of the phone browser; the browser then asks the user to confirm the download. This 55

6 enables users to download the Hot in the City application from any Hot in the City tag they encounter. Applications have a unique ID that is assigned to them when the user registers on the backend system. This unique ID is exchanged when the peer-to-peer connection is established to make friends. This exchanged information is then sent to the backend system, where the friendship is created and applications are updated with the added friends. VI. CONCLUSION Hot in the City is a social media application that uses two modes of NFCs: peer-to-peer and reader/writer. NFC brings unique challenges that need to be addressed when creating a multimodal social media application. The user needs to manually change the application from the default reading mode to writing or peer-to-peer mode. Even though users may be acquainted with the touch paradigm, switching between modes is not necessarily as familiar to them. NFC lacks coherent use patterns to inform users when devices are in the reading, writing or peer-to-peer mode. Hot in the City solves this by guiding the user through the processes but it is not very efficient in this regard. Tag management is one of the most prominent challenges when creating an application with free-tag implementation. As users may add their own tags, the system must be able to handle an ever increasing amount of tags. A part of tag management is the ability to rewrite old tags. Both NFC-IP1 and Nokia s prestandard-llcp were tested during the development. LLCP peer-to-peer protocol does not define which device is the initiator. It streamlines user interfaces as users do not have to agree beforehand who is the initiator and who has device in target mode. The user experience in making friends with LLCP was considered better than the process with NFC IP-1. Another consequence of LLCP is that the cost of triggered network traffic can randomly be assigned to either of the devices. In Hot in the City, the devices are equal in terms of network traffic as both are responsible for sending the new friend information. In general, NFC offers new prospects for social media. It is possible to create applications with smooth multimodal functions, although some problems can only be solved by educating users and further developing NFC technology. [4] A. Fressancourt, C. Hérault and E. Ptak. NFCSocial: Social networking in mobility through IMS and NFC. [5] Friendticker, " [6] Facebook. Press room - statistics (11/27), [7] International Organisation for Standardisation, "Near Field Communication - Interface and Protocol (NFCIP-1). ISO/IEC 18092," [8] International Organisation for Standardisation, "Proximity cards ISO/IEC 14443," [9] NFC-Forum, "Technical specification of Type 3 Tag Operation," [10] NFC-Forum, "Technical Specification of Type 4 Tag Operation," [11] S. Grünberger and J. Langer, "Analysis and test results of tunneling IP over NFCIP-1," in Proceedings of First International Workshop on Near Field Communication, 2009, [12] NFC-Forum, "Specification Candidate for Logical Link Control Protocol," [13] J. Häikiö, T. Tuikka, E. Siira and V. Törmänen, " Would you be my friend? creating a mobile friend network with Hot in the city," in Proceedings of the 43rd Hawaii International Conference on System Sciences (HICSS-43), 2010, REFERENCES [1] E. Rukzio, K. Leichtenstern, V. Callaghan, P. Holleis, A. Schmidt and J. Chin, "An experimental comparison of physical mobile interaction techniques: Touching, pointing and scanning," in Proceedings of the 8th International Conference on Ubiquitous Computing, 2006, pp [2] J. Riekki, T. Salminen and I. Alakarppa, "Requesting pervasive services by touching RFID tags," vol. 5, pp , [3] Google, "Google Latitude 56