You are on page 1of 4
Testing and Improving Instructions for Xcode 22 March 2016 Introduction Xcode is used to design apps for the entire suite of Apple products, and can also be used to simulate programs running on specific devices. This report assesses the usability of instructions that help the user write a simple iPhone program from scratch and test it using Xeode’s built-in iPhone simulator. These instructions are intended for users with little experience with Xcode, and some experience with programming. Accordingly, the individuals tested had little experience with both. ‘As time passes, smartphones become increasingly important parts of our lives. Understanding how to use this enormously powerful tool from the perspective of an app developer instead of as aa passive user can encourage a useful engagement with technology that touches many lives. Furthermore, the thrill of turning your idea into a product is rewarding in itself, but can be rewarding in a financial sense as well. In particular, this research was designed to find the weak points in these instructions: hidden assumptions, misleading diagrams, or steps that needed more detail. Method Individuals to test were selected based on their lack of experience with Xcode and programming, in general. They were then invited to a specific location, where the Test Administrator began to read a standardized introduction and asked about the User's major, experience with Xcode, and experience with programming. After this introduction, the User was handed the instructions, and was asked to describe the purpose and organizational structure of the document. Following this part of the test, the User was handed a copy of the scenarios and was asked to accomplish the tasks set forth in the scenarios using only the instructions. After approximately 30 minutes, the ‘User was asked to stop, and the Test Administrator asked a series of post-test questions. For each of these sections of the test, the Test Administrator stayed very close to the script to ensure the validity of the results. Tasks -How to create a new Xcode project -How to add a label to a storyboard -How to connect a label to code -How to change the default label text -How to add a Tap Gesture Recognizer -How to add code to manage user input During the test, QuickTime Player was used to record the sereen and the audio for later review. ‘The recording began before the introduction, and ended when the User finished with the post-test questions. ‘The instructions were tested on a MacBook Pro running OSX version 10.1.3 and with Xcode version 7.2.1, Scenarios: -You have been hired by a paint company to design an app that lets its users determine paint colors by controlling the color of their iPhone screen until it matches the paint. Begin by setting up a storyboard with three labels to reflect the RGB (red, green, blue) values and connecting the labels to code. ~ Next, set up the program so that as the user taps on a certain part of the screen, the individual red, green, or blue value increases or decreases, the background color changes accordingly, and the labels update to reflect the new values. This program should work by dividing the screen into vertical columns, each 1/3 of the width of the screen. It should then change the value for either Red Green or Blue (left to right) proportionally based on the distance of the tap from the top of the screen and should then update the background color. Post-test questions: -Was there a specific section of the instructions that you found confusing? -Was anything unclear? -Did you find the layout of the instructions useful? -Do you have any ideas of how to improve the instructions? Results Asa result of the first test, a number of weaknesses with the instructions came to light. First, the scenarios did not go into enough detail. After the test, when I asked the user to describe to me how the final program would work, there were major differences between what I had imagined when I wrote the instructions and what they understood from the document. Adding clarification here would help focus the scope of the instructions. An additional issue I found while testing this individual is that the snippets of code were not documented well enough, He was confused by the purpose of each of the examples, which suggests further explanation is necessary to not alienate the target audience (beginners). A table of definitions or using less technical terms ‘would also improve the instructions, since one individual suggested that there was too much “jargon” in the document. Smaller issues that came up were a misunderstanding about how to add labels to the storyboard and how a tap gesture recognizer works. These issues can be resolved with a clearer explanation and perhaps a couple of diagrams The second test involved a user that had much more experience with programming, although none with Xcode, During this test, the user had trouble finding the buttons referenced in the instructions on the screen. As a result, I placed more emphasis on the Interface section, and used a red box to highlight the interface elements that would be toggled later on. There was also some confusion about how many labels needed to be on the storyboard. To help clarify this aspect of the 8 added more details within the instructions about how many labels you might need, although I stopped short of actually telling the user how many. This user thought that the occasional “Note:” additions to the instructions were “too wordy.” Despite this observation, I have kept in the Notes, since the concepts of the programming language are abstract enough to necessitate detailed explanation. ‘The third user had little experience with programming, and no experience with Xcode. They ran into problems that stemmed mostly from not reading the instructions closely enough. When I saw that they were having problems, I would ask them to read the instructions out loud, which would resolve the issue. Since neither of the first two tests ran into this issue, I will assume it was a fluke, and this user was tired or otherwise distracted. As a result of this text, I changed Figure 7 to have a third red box in the middle, highlighting how you were supposed to change the name of the Action. I also added more explanation to Useful Task #4 to make the connection between the label and the code more clear. Additionally, I added page numbers. Conclusion Considering the limited number of tests, the ability to quickly tweak the instruetions before the next test was essential to improving the document as much as possible. One weakness, though, is that there was only one test for each version of the instructions. For instance, a weakness identified by one User could be a problem rarely encountered in the general population. Having ‘more individuals test the same document would give a better idea of what problems arose for many people. None of the users made it all the way through the test, so the Code Snippets and the iPhone simulator aspects of the instructions were not tested. Further research could explore the effectiveness of the annotated code, and test ways of helping the user better understand the functions and relationships between different snippets. It was surprisingly difficult to explain the actions the user had to perform to accomplish each task, and doing these three tests poked holes in a document that I had thought was rock-solid. With each new version, the user made more progress (accounting for programming experience level), and subtler problems came to the surface. We are left with a more efficient, clearer document that is more accessible as well

You might also like