Throughout the whole interface the thought is that the user marks an object with a single tap and choose it with a double tap. The objects are placed with regards to that most people are right handed and with the aim to let the user manoeuvre the interface as much as possible with only one hand.
As could be seen in the previous section the application has three different graphic styles that the user can choose between. Only the drag and drop suggestion is developed into an interface suggestion, and therefore that is the only one presented here.
The application is called KIT, a short form of Keep-In-Touch. The name and symbols that shows the status of the application is shown in a status bar on top of the screen.
There you can see if your position is visible for anyone of your contacts, how much reception the phone has, the mane of the application, how much power that is left in the battery and if there are any unread messages. Except for the status bar there are three tabs visible on the screen, MAP, TALK and MENU. For a visualisation, see figure 7.5.
If the MAP tab is dragged from the right to the left side of the screen, a map with four icons is shown. The plus and minus icons are for zooming on the map, the pin is for using way finder and the i-symbol is for administrating what information should be shown on the map. An image of this is shown in figure 7.6.
If the MENU tab is dragged out from its place on the left side to the right side the different menu options becomes visible. Figure 7.7 shows how this looks.
If the TALK tab is dragged from its plce in the bottom of the screen to the top of the screen a list of contacts becomes visible. Here you can tap on a contact and start communicating with him/her via instant messaging, SMS or telephone call. To see an image of the active TALK tab and the contact list, see figure 7.8.
If both the MAP and the TALK tabs are active at the same time the contacts that reveal their position will be shown on the map. From this view the user can tap on a contact on the map and start communicate. The conversation will be shown on the
7.2. Interface 35
map, but even if the blue tab is inactivated, the conversation will still continue without the map. To see an example of how it can look with both TALK and MAP active, see figure 7.9.
The software prototype of this interface shows how parts of the interface should look and feel. The three tabs can be dragged in and out and the TALK and MAP tabs can be combined. All of the contacts are static and have static data. To navigate through the prototype you need to know which buttons to tap and in which order. The interface can be run on a HTC Touch.
Figure 7.1: Handhold device to show screensize.
7.2. Interface 37
Figure 7.2: The functionality of the instant messaging part of the application.
Figure 7.3: The functionality of the positioning/map part of the application.
Figure 7.4: The functionality of the menu part of the application.
7.2. Interface 39
Figure 7.5: The KIT interface when all tabs are closed.
Figure 7.6: Image of the MAP tab active.
7.2. Interface 41
Figure 7.7: The MENU tab when it is active.
Figure 7.8: Image of the TALK tab active.
7.2. Interface 43
Figure 7.9: Image of the MAP and TALK tabs active. Contacts can be shown on the map.
Chapter 8
Conclusions/discussion
The goals that were set in the beginning of the master thesis about developing a new user interface to an existing application, to create a software prototype in Flash Lite that can run on a HTC Touch, to learn graphics and animation programs and apply my knowledge from my education on a real project are all reached. I ran into some problems and therefore the prototype is not as extended as planned.
When I was looking for information about which version of Flash that could be used with touch screens I realised how much harder it can be to find out that something does not work than to find that something does work. To find out that something does not work means that you have to examine every possible solution, to find out that something do work you only need to find one working solution.
The user interface suggestion did not turn out as I had expected, the fact that I could not use gradients as a part of the graphics made the interface not as modern looking as I had hoped in the beginning.
When the implementation of the software prototype was about to start my plan was to make much of the prototype from code and not use the timeline in the Flash animation programme for more than just a few lines of code. This approach would have made the prototype easier to build on in the future. However, since I had little experience about actionscript, the programming language used in Flash, it was hard to find a system design that worked. When I had tried to do that for a while, I realised that I did not have time to do it that strictly and a prototype built on code in the timeline was the solution.
When I started to implement the prototype I realised how many design decisions there is to be made in every little button in the interface. Even if I had decided on the big things and how main-screens should look, there were still buttons and small choices in menus to make decisions about. A list of some of the design decisions made can be found in the appendix A.
8.1 Future work
The first thing that needs to be done is to examine if there exists any interest for this kind of application and then to examine if the interface suggestion developed in this master thesis is liked by the users. If there exists an interest for both the application and the interface, then it needs to be implemented, either in Flash to work with the existing proxy or in some other technique.
45
As the interface looks today it is the colours of the Apptoo logotype that dominates the interface. To make it easier to sell it to other companies they need to be able to brand it. More discrete colours would make branding easier.
Chapter 9
Acknowledgements
This master thesis would not have been done without the cooperation with Apptoo AB.
They have given me insight in how it is to work in a small software company. They also provided two different supervisors, Hugo B¨orjesson and Martin Kurtsson, which I would like to thank for their input and support. I would also like to thank my supervisor at the university, H˚akan Gulliksson, both for being my supervisor during this master thesis and for his commitment in creating and constantly developing the program interaction technology and design. I appreciate all the help and encouragement I have received from my family and friends. And last but not least, thank you to all that helped me with brainstorming and evaluation during the design process.
47
References
[1] Jakop Berg and Martin Kurtsson. A position aware mobile instant messaging client.
2008.
[2] Densitron Corporation. Introduction to touch solutions. 2007.
[3] Mark Dunlop and Stephen Brewster. The challange of mobile devices for human computer interaction. Personal and Ubiquitous Computing, 6:235–236, 2002.
[4] Apple inc. http://www.apple.com/se/iphone/guidedtour/, 2008-10-19.
[5] Helen Sharp Jennifer Preece, Yvonne Rogers. Interaction Design Beyond Human-Computer Interaction. John Wiley Sons, Inc., John Wiley Sons, Inc., 605 Third Avenue, New York, NY 10158-0012, 2002.
[6] I. Scott MacKenzie and M. William Soukoreff. Text entry for mobile computing:
Models and methods, theory and practice. HUMAN-COMPUTER INTERAC-TION, 17:147–198, 2002.
[7] inc. Mass Multmedia. http://www.touchscreens.com/intro-touchtypes-saw.html, 2008-10-19.
[8] Donald A. Norman. The Design of Everyday Things. The MIT Press, London, England, 1998.
[9] Donald A. Norman. Emotional Design. Basic Books, Basic Books, 387 Park Avenue South, New York, NY 10016-8810, 2004.
[10] SonyEricsson. http://www.sonyericsson.com/x1/index.aspx?en-gb/product, 2008-10-19.
49
Appendix A
Design choices
As mentioned in the report, there are a lot of design choices to make. Designing a user interface is a complex task since there are many parameters to take into account and you do not even know if there exists an optimal solution.
During the work, small design decisions have been taken all the time. Decisions like where to place a button, what colour it should have, what size is appropriate etcetera.
However, these small decisions are based on some bigger decisions like what colour the interface should have, what interaction model should be used and if it needs to be used without a stylus. Some of the design choices are described here.
One of the first design decisions that were taken was that the application should be usable without a stylus as much as possible. I had used the SonyEricsson P1 smartphone and did not like that it was almost impossible to use it without a stylus. I thought that a chat application is something you want to use for a short while, put it away for a moment, use it again a while and so on and that you do not want to find a stylus every time you use the application.
Since the decision about finger interaction was taken, text input was a problem. To use a software qwerty keyboard on the screen provided for the master thesis was almost impossible without a stylus. Handwriting recognition and electronic ink is also based on stylus interaction. I found a text input method called MessageEase on the Internet that was developed to overcome my problem. Since it will be a new input method for the user it will take some time to learn it, but I thought it looked practical. No stylus needed. But, since I know that everyone are different when it comes to text input, I want the input method to be changeable.
I thought a lot about how to design for both right and left-handed persons. In the beginning I thought that the interface should be as symmetric as possible so that a left-handed person would be able to use the application in the same way as a right-left-handed person. Later this informal decision was changed because the interaction concept that was developed was based on asymmetric menus.
Privacy issues are a problem in this kind of applications. I am aware of them, but are those not interested in technology aware of that other can see where they are? To make the users aware of when they reveals their position, I added an icon that looks like a watching eye. The icon is visible as long as the user reveals the current position.
I looked at other interfaces, especially the iPhone, Xperia and HTC Touch to find out what kind of graphics are popular now. Black, grey and blue were the colours used together with gradients to create a feeling of a not totally flat interface. I did not want
51
the dark colours that were used in the other interfaces, and therefore decided to use the colours in the Apptoo logotype that is colourful and light. I played around and found a style that I liked and decided to continue with. Unfortunately it did not look good with the gradients on the screen, so I changed the graphics.
Icons versus text in menus is a tricky question. Text is good in the way that even the first time you see the interface, you can find what you are looking for. The bad thing is that text is in a particular language and you need to find the right word in that language. It is also harder to remember the next time you use the interface. Icons are multi-lingual and if the icon is good you will know what it means already the first time you use the interface and also the next time you will recognise it. The bad thing is that designing an icon is a science in itself. Some icons are used in the interface, but since icons were not a focus area in the master thesis, I decided to use icons where there exists some kind of standard and to use text elsewhere.
The master thesis that were made prior to this at Apptoo stated that a status bar was good to have both because the user should be informed of the system status and that the user will then recognise the application as a part of the operating system. A status bar with battery level and signal strength was therefore designed.
One design problem that I did not really solve was what to do in the map-view with contacts without available positions and with contacts outside the current view. As the application looks now, persons without position can only be found in the view without map and persons outside the view are not visible until that part of the map is shown.
Appendix B
Brainstorming
This is the areas I asked the group to brainstorm around:
– What functionality can be valuable to have if you have a map in a mobile phone?
– If you at the same time can chat with your friend, what functionality can be valuable then?
– What privacy issues can you see with this and how to avoid them?
– How can map, instant messagning and other functilonality be visualised? (like pan, zoom, information)