TokenMap is a route planner that is operated by tokens and touch. It will also provide information on heritage sites. For the purpose of this project, we would like to focus on a specific heritage site, which would be Boat Quay and the area around it. Unlike conventional information booths, TokenMap provides users with a route planning service, which is what many tourists require. While doing so, it will also provide information on heritage sites. This will promote these heritage sites and also ensure that the user visits places they are most interested in.
Our target users are tourists who have not done sufficient planning beforehand, lack guidance, and have flexible schedule. We visualise them to be backpackers. So why did we choose them? They are the ones who require assistance and will actively seek help and information. This is a helpful attribute as they would be more receptive to the information that we can provide them. Also, these tourists are less constrained by time. This will allow them to explore the area without too much restriction and would be able to use our system to plan their schedule accordingly.
Here are some photographs showing potential target users for our system. In general, during our observations of tourists, we realised that they often have to stop to plan routes. Some of these tourist also had to approach a random passerby as they did not have sufficient information. When we did an observation at the City Hall MRT, the frequency of foreigners referring to the locality map was also quite high.
Our goal is for our target users to learn about heritage sites. From our observations, we gathered that a route planning service would be a good platform to provide information about heritage sites which are open, such as Little India and Boat Quay. We intend to provide our target users with information about heritage sites through a route planning service. We could bring awareness to our target users about these places and possibly influence their route planning. It is also possible for them to use our system solely for finding out more about the heritage sites. The task would then be to interact with the system using the tokens and the touch interface, to identify the features in the heritage site, to view information about these places and plan their route according to what interests them.
This is a visual of the context in which our system would be in. We intend to deploy our system in City Hall and Clark Quay MRT Station which are nearest to Boat Quay. For the physical context, we would expect the MRT station to be noisy and crowded as depicted in the photo. As for the social context, since there would only be 1 system initially, and only 1 user can interact with the system at any time, we foresee a queue to use the system. Our users would then have to use the system under the pressure of a queue, and possibly under the scrutiny of others since there is no way of preventing others from overlooking. Our system would be using tokens such as sampans and coolies, and foreigners may not understand why. So, we intend to provide sufficient description in order for foreigners to have a better understanding. We also noted the organizational context of our system. There are existing structures and information panels at the heritage site. As a result, we will work to support these existing structures to provide a complete experience for the tourists, rather than compete with these structures.
Here is our proposed solution. It will be in the form of a table, and users will interact using the tokens dispensed. Imagine this scenario. When the tourists exit from the gantry, they can immediately locate the Token Map nearby. They will be greeted with a map of the area around Boat Quay, showing their current location and highlighting all areas of interest. If they want to view only cultural heritage sites, then they should place a coolie token on to the surface. If they want to see all the food outlets as well, they can place a food token on the surface too.
This represents a particular view of the interface, however, users would be able to zoom in and out of the map to get a close up view or a broader overview. When they have decided on the places to go, they can use the route planning token to indicate the order of visitation by sliding the token from place to place in that order. The route planner will provide information that tourists will appreciate, such as how long it takes to walk between destinations. The information can also be printed out or transferred to compatible devices over bluetooth so that they can refer to it on the go. The tokens will be made of thin cardboard which can also act as bookmarks or souvenirs for the tourists.
Our system is feasible as the technology is similar to the microsoft surface. The microsoft surface is already available in the market. It can recognise 2D codes which will be used to identify the tokens and their positions.
Why use the TokenMap? It provides more than just information. It provides route planning services as well. When tourists do research online, they may not have thought about everything. Also, it may be troublesome to find information about a particular site all over the internet. We have done the job of consolidating that information to make it relevant and accessible. Our solution provides local support and greater interactivity. It is similar to why service desks and tour guides exist. It also allows tourists to plan closer to the location to account for weather conditions, last minute decisions or traffic jams. Furthermore, the interface contributes to the fun factor so that users can have a more enjoyable experience while finding our more about heritage sites.
Our system can only be used by one person or a few persons from the same group at most. Queues may form if many groups of tourists want to use the system at the same time or if anyone hogs the machine for a long time. As mentioned before, the meaning of the pictures on the tokens could be different for people of different cultural background. Hence, they may not instinctively know what the tokens stand for and may require more prompting on our side.
![[object Object],[object Object],[object Object],[object Object],Token Map](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)