Testing and Improving Instructions for Xcode
22 March 2016Introduction
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 theoccasional “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