A conceptual analysis of iTunes

A Conceptual Analysis of iTunes

by

Mary G. Thielking

S.B., Massachusetts Institute of Technology (2018)

Submitted to the Department of Electrical Engineering and Computer

Science

in partial fulfillment of the requirements for the degree of

Master of Science in Electrical Engineering and Computer Science

at the

MASSACHUSETTS INSTITUTE OF TECHNOLOGY

June 2019

c

○ Mary G. Thielking, MMXIX. All rights reserved.

The author hereby grants to MIT permission to reproduce and to

distribute publicly paper and electronic copies of this thesis document

in whole or in part in any medium now known or hereafter created.

Author . . . .

Department of Electrical Engineering and Computer Science

May 24, 2019

Certified by . . . .

Daniel Jackson

Professor

Thesis Supervisor

Accepted by . . . .

Katrina LaCurts

Chair, Master of Engineering Thesis Committee

A Conceptual Analysis of iTunes

by

Mary G. Thielking

Submitted to the Department of Electrical Engineering and Computer Science on May 24, 2019, in partial fulfillment of the

requirements for the degree of

Master of Science in Electrical Engineering and Computer Science

Abstract

Many users of Apple iTunes have anecdotes of frustration and confusion when trying to use the application—whether it stems from losing songs, trying to sync a new device, or struggling to find a voice memo. In order to identify a potential explanation for these frustrations, I explore the conceptual design of iTunes and compare it to users’ perceived mental models, focusing on differences between the two as possible sources of frustration. After identifying these differences, I propose several changes to the conceptual model that remove some of the differences between the existing and perceived models.

Thesis Supervisor: Daniel Jackson Title: Professor

Contents

1 Introduction 9

1.1 Motivation & Background . . . 9

1.2 Choice of iTunes . . . 10

2 Theory of Conceptual Design 13 2.1 Anatomy of a Concept . . . 14

3 A Conceptual Model of iTunes 17 3.1 Data Model Notation . . . 17

3.2 Concepts of iTunes . . . 19

3.2.1 Playlist . . . 19

3.2.2 Container . . . 20

3.2.3 Sync . . . 22

3.3 Conceptual Model Analysis . . . 24

3.3.1 Name Collisions . . . 24

3.3.2 Voice Memo Syncing . . . 25

3.3.3 First Time Syncing . . . 29

4 Evaluation 31 4.1 Plan for Evaluation . . . 31

4.2 User Study Results . . . 32

4.3 Analysis . . . 34

4.3.2 Updates to the Conceptual Model . . . 35 4.3.3 Revisiting Special Cases . . . 39

5 Related Work 41

6 Future Work 43

List of Figures

2-1 Data model for the Trash concept on a Mac computer. . . 14

3-1 Full data model for iTunes. . . 18

3-2 Structure for the Playlist concept. . . 20

3-3 Structure for the Container concept. . . 21

3-4 Behavior when two devices containing distinct playlists with the same name get synced. . . 25

3-5 Behavior of iTunes when an iPhone with a recorded Voice Memo is synced with a computer. . . 26

3-6 Behavior of iTunes when an iPod with a recorded Voice Memo is synced with a computer. . . 26

3-7 Behavior for syncing a Voice Memo from a computer to an iPod. . . . 27

3-8 Adding a Playlist containing a Song and a Voice Memo to an iPod. . 28

3-9 Adding a Playlist containing a Song and a Voice Memo to an iPhone. 28 3-10 Behavior when syncing an iPod to a computer for the first time. . . . 28

4-1 Questions asked to users about their previous experience with iTunes. 31 4-2 The tasks users were asked to complete. . . 32

4-3 Data model for the proposed updated conceptual model of iTunes. . . 36

4-4 Updated behavior when an iPod with a recorded Voice Memo is synced with a computer. . . 39

Chapter 1

Introduction

1.1

Motivation & Background

Traditionally, there have been two aspects to software design: usability principles and software engineering. Usability principles deal with shaping the behavior of a user interface, generally with the goal of improving ease of use. These principles include Jakob Nielsen’s ten usability heuristics [20], as well as identifying affordances, as in-troduced by Donald Norman [21]. In software engineering, there exist general notions of separation of concerns, abstraction, decoupling, and representation independence that tend to qualify a well-designed application. Frederick Brooks introduces the idea of "conceptual integrity" in software engineering, and claims that it is"the most important consideration in system design" [4]; however, he fails to define exactly what conceptual integrity is—his research focuses more on the process of achieving conceptual integrity, rather than on explicitly defining it. Other research focuses on how to represent concepts (e.g. using formal specifications), or focuses on usability separately from the system design.

In 2013, Daniel Jackson introduced a research agenda [13] that proposes a theory of conceptual design which encompasses the intersection of usability and software engineering principles. This research agenda looks at the concepts themselves, how they are chosen, and the role that they play in the design process. A concept is defined as a notion that is either preexisting in the world outside of a system, or that

is invented for the purpose of structuring the functions of the system. One preexisting concept is "airline flight", as compared with invented concepts that have no real-world analogy, such as "paragraph style" in a word processor. Concept does not refer to elements that exist in either the interface (e.g. "button") or the implementation (e.g. "callback"), but rather to the basic concepts that both a user and developer understand when they are interacting with the system and building it.

Within the scope of usability, concepts can be seen as "abstract affordances". Similarly to an affordance as defined by Norman [21], an abstract affordance implies its function. While concepts can be analogies to the real world, such as a shopping cart, more often they are abstract, like the concepts of "friending" and "posting" in Facebook.

In software engineering, at a low level, the conceptual model for an application defines the vocabulary used throughout the development process, and helps enforce consistent terminology during the development process. The conceptual structure also determines the structure of the code itself - whether that is in a relational database, or in creating components that have distinct state.

1.2

Choice of iTunes

iTunes is a computer application that allows users to organize, consume, and buy various forms of media, as well as share media across devices. Currently, iTunes supports managing music, movies, television shows, podcasts, and audiobooks [1] on a computer running macOS or Windows. In addition, iTunes can be used to manage photos [2] and files [5] on another device (such as an iPod or iPhone) when it is connected to the computer. While iTunes incorporates all of this functionality into one computer application, the functionality is split into different apps on other Apple devices: Apple Music, iTunes Store, Apple TV, Podcasts, Apple Books, Photos, Files. One reason for choosing to analyze iTunes is that it has a significantly large user base. Apple released data in early 2018 that listed 1.3 billion active apple device users [26]. Prior to that, there were 800 million iTunes accounts reported in April

2014 [28]. These numbers indicate that Apple products, including iTunes, are widely used, though it’s difficult to know exactly how many active users for iTunes there are. When creating a new iTunes account, there is no way to merge a new account with an old one, so it’s likely that many of the existing accounts are no longer used, and of the ones still in use, Apple has not released data about how many users actively access and use iTunes. Even if only a small fraction of the reported accounts are active on iTunes, it still is a widely used application that has many users, as well as many complaints.

As several users have pointed out, iTunes maintains the "clean" look associated with Apple products [3, 6]. This clean design leads to an oversimplified user interface that makes discovering and using all of the functionality difficult. One iTunes user does not, however, blame the designers at Apple, but rather points the blame at the impossible task given to them: "cramming way too much functionality into a single app while also making it look ‘clean’" [19]. While these observations explicitly center around the interface of iTunes, they indicate a misunderstanding between the users and the application of how the application should behave.

One reason for iTunes containing a wide variety of functionality is the growth that the application has experienced since its first version was released in 2001 [22, 29]. Originally, iTunes was a music manager that allowed users to sync music with their devices. Over the past 18 years, iTunes has been expanded to include the iTunes Store and Apple Music, as well as to support additional kinds of media: movies, television shows, podcasts, books. With the addition of each new function, iTunes has grown more complex, with much of the complexity getting masked by the ever-simple user interface of the desktop application.

Usability issues in iTunes have come to light in a variety of different ways as users try to accomplish various tasks in iTunes. One user lost over 4,700 songs he had uploaded and purchased after enabling and disabling Apple Music in iTunes [7]. Another user found that a song on her iPhone disappeared after syncing her iPhone with iTunes on her computer [11]. Similarly, a third user shared an anecdote about connecting his iPad to his laptop for the first time. He was given two options: to

sync and delete all the apps on the iPad, or to stop syncing the two devices and keep the apps. Although he chose the latter, the iPad continued syncing with iTunes, and all of the apps disappeared [27].

These few anecdotes, among others, motivated the need for an analysis of iTunes. Users have pointed to the simplicity of the user interface design and the complexity of the functionality as iTunes’ flaws, both of which can be explained using the theory of conceptual design. Through conceptual analysis, I will explore the hypothesis that the issue it that users misunderstand the key concepts behind iTunes.

Chapter 2

Theory of Conceptual Design

Daniel Jackson’s paper [14] defines concepts as objective features of a system’s design. Each concept in any given application should have its own unique purpose, and a corresponding tactic that provides a scenario to explain how the concept fulfills its purpose. A well-defined concept is inventive, purposeful, behavioral, self-contained, and reusable [16]. Together, the concepts of an application form a conceptual model that is a state machine, with each concept having its own state components and actions that produce the transitions between different abstract states.

Concepts are the building blocks of a software system, and understanding the concepts of a system helps engineers to build the system, as well as users to interact with it. When analyzing an application to determine the conceptual model behind it, it’s necessary to think about the components of the application that would need to be explained to a new user in order for them to successfully use that application. For example, when introducing someone to Facebook, they would need to understand the concept of "friending" before starting to use the application, and very quickly they would then need to know the concept of "post" to know what is appearing in front of them. While those two particular concepts have no analogy in the real world, one strategy to help users understand concepts is to make them analogous to things with which they are already familiar. For example, the concept of a "cart" used by many online retailers requires little explaining to a new user, since they are familiar with the use of a physical shopping cart.

Figure 2-1: Data model for the Trash concept on a Mac computer.

2.1

Anatomy of a Concept

Each concept can be described with four parts: purpose, tactic, structure, and actions. Throughout defining each of these parts of a concept, I will use an example of the trash concept as it exists on a Mac computer1_.

Purpose. The purpose of a concept answers the question "what is this concept for?" in order to justify the concept and focus its design. For the trash concept, its purpose is to allow users to undo deletion.

In general, within a conceptual model, there should be a one-to-one mapping of concepts to purposes. A concept with more than one purpose is considered overloaded, and may fail to or inadequately fulfill one or more of its purposes. On the other hand, having more than one concept motivated by the same purpose leads to redundant concepts that may share functionality.

Structure. A concept’s structure is a data model which defines vocabulary and possible states for the concept. The terms used in the structure will be used by both the actions and tactic of the concept. In Figure 2-1, the structure for the concept includes All and Deleted, where All is the set of every file on a device and Deleted is the set of files on the device that have been moved to trash. Deleted is a subset of All, as indicated by the large, open-headed arrow2_.

Actions. Actions are used to describe the behavior of a concept. They are specified by naming them, listing their arguments, and informally describing the effects they have on the state. Some actions to describe the trash concept:

1_{This example was used in a lecture given for the 2018 Software Studio course at MIT [16].} 2_{See section 3.1 for a full explanation of the notation used in data models.}

delete ( x : T) r e q u i r e s x i n A l l D e l e t e d += x restore ( x : T) r e q u i r e s x i n D e l e t e d D e l e t e d −= x empty ( ) A l l −= D e l e t e d and D e l e t e d := {}

Breaking these actions down, delete accepts an argument x of type T, and if x is in All, then adds x to Deleted. Restore also accepts an argument x of type T, and if x is in Deleted, then x is removed from Deleted. Since Deleted is a subset of All, the requirement that x exists in Deleted implies that x also exists in All. Lastly, empty removes the contents of Deleted from All and from Deleted.

Tactic3. A concept’s tactic is an archetypal scenario that describes how the concept fulfills its purpose. When describing a tactic, the language from the structure and the actions should be used. In the case of the trash concept, the tactic is that if a user deletes x and then restores x, they have successfully undone the deletion, and if a user deletes x and then empties the trash, x is lost and storage space is regained.

Chapter 3

A Conceptual Model of iTunes

iTunes’ purpose, according to Apple, is to organize, enjoy, and shop for music, movies, and TV shows [1]. Through using iTunes in conjunction with an iPod and an iPhone1_,

I have developed a conceptual design for iTunes, shown in Figure 3-1.

3.1

Data Model Notation

The structure for each concept is represented as a relational data model, using di-agrams that are like those developed for the Alloy modeling language [12], and are in the same style as diagrams used in previous literature about conceptual design [14, 23, 24]. Using this form of visual description allows the diagrams to be easy to understand yet precise enough to support objective analysis. None of the nota-tion used in these diagrams is specific to this analysis—it can be extended to other domains.

The relational data model in Figure 3-1 shows the concepts that are included in the conceptual model for iTunes. Each box in the diagram represents a set of atoms, and the arrows between them represent relations between the atoms. As previously discussed in section 2.1, a large, open-headed arrow indicates a subset. In the data model for iTunes, Song and Voice Memo are subsets of Type. Since they share an arrowhead they are disjoint subsets of Type, meaning that an item cannot be both

Figure 3-1: F ull data mo del for iT unes.

a Song and a Voice Memo. Object also has two disjoint subsets (File and Playlist); however these are not disjoint from the subset Synced, which means an Object can be both a Playlist and Synced.

A small, closed arrow indicates an association relationship between the two atoms which are connected. For example, the arrow labelled playlists that connects Con-tainer to Playlist associates a conCon-tainer with the set of playlists it holds. A bar across the arrow indicates an immutable relation. In the case of the arrow labelled type that connects File to Type, the bar indicates that a file will be associated with a type, and that type cannot change. However, in the other direction, a type can be mapped to any number of files, and which files it is associated with may change.

The symbols used next to arrows are multiplicity markings, where ! indicates exactly one, ? indicates one or none, + indicates at least one, and * indicates zero or more. In order to reduce clutter in the data model, any lacking multiplicity marking is assumed to be *. When looking at a relation, the position of the multiplicity marking matters. In the relationship device between Device and Container, a device holds at least one container, while a container must belong to exactly one device.

3.2

Concepts of iTunes

For the purpose of this project, only a subset of the functionality and concepts in iTunes were studied. In the iTunes desktop application, only the Music section was studied, which includes both Songs and Voice Memos. Even with the smaller scope of this project, preliminary use of other sections in iTunes (e.g. Movies) indicates that these concepts are general enough to apply across the entire application, with modification to expand the number of types.

3.2.1

Playlist

Purpose. To organize and consume media in a way that is not predefined (e.g. Album, Artist, Genre).

Figure 3-2: Structure for the Playlist concept.

Playlist. Only the atoms and relations necessary to contain the state of Playlist are included in this structure, as opposed to including the entire data model from Figure 3-1.

Actions.

create ( n : S t r i n g )

c r e a t e a new P l a y l i s t p w i t h p . name = n and p . i d = u n i q u e i d addFile ( p : P l a y l i s t , f : F i l e ) p . f i l e s += f removeFile ( p : P l a y l i s t , f : F i l e ) p . f i l e s −= f play ( p : P l a y l i s t ) f o r e a c h F i l e f i n p , p l a y f

Tactic. A user creates a new Playlist p (create), and then adds a number of Files (addFile) from different albums and genres to p. After adding and removing (removeFile) files until they are organized as he wants, he can press play (play) to start playback of the Files in p.

3.2.2

Container

Within iTunes, there exist several predefined containers. A Computer has a Music container, and an iPod and an iPhone each have Music and Voice Memo containers.

Figure 3-3: Structure for the Container concept.

Purpose. Container has two distinct purposes, one from the perspective of the system and one from the perspective of a user, since the two parties have different goals for using this concept. From the system’s point of view, the purpose is to organize and differentiate media by type. From the user’s perspective, the purpose is to organize and consume media across devices.

Structure. Figure 3-3 depicts the structure for Container. While Type exists in the overall data model (see Figure 3-1), the Container concept does not include the relation to Type in its structure. This is done by design, since a user only has access to one Container at a time, either via an app on their iPhone or iPod, or in a section of iTunes. While the system does have access across multiple containers at a time, any type-checking is handled when syncing, as defined in the Sync concept in section 3.2.3. Actions. addFile ( c : C o n t a i n e r , f : F i l e ) c . f i l e s += f addPlaylist ( c : C o n t a i n e r , p : P l a y l i s t ) c . f i l e s += f f o r e a c h f i l e f i n p . f i l e s n o t a l r e a d y i n c . f i l e s c . p l a y l i s t s += p removeFile ( c : C o n t a i n e r , f : F i l e ) c . f i l e s −= f r e m o v e F i l e ( p , f ) f o r a l l p l a y l i s t s p i n c t h a t c o n t a i n f removePlaylist ( c : C o n t a i n e r , p : P l a y l i s t ) c . p l a y l i s t s −= p

These actions are intentionally left generic, though in practice there are multiple ways to add files and playlists to a container. Files can be added by uploading a file to iTunes, in the case of a song, or by recording, in the case of a voice memo. Both files and playlists can be added a to a container through syncing, which is enumerated in the definition of the Sync concept. A playlist can also be added to a container by creating a new playlist.

Tactic. A user adds a Playlist (addPlaylist ) and some additional Files (addFile) to his iPhone. Then, he can go to Music on his iPhone to listen to the songs he has stored. After he tires of a song, he removes that File (removeFile) from his iPhone.

3.2.3

Sync

Purpose. To share media across devices.

Structure. The structure for Sync is the same as the full data model, which can be found in Figure 3-1.

Actions.

addFileToDevice ( d : Device , f : F i l e , d u r i n g S y n c : b o o l e a n ) s w i t c h ( d , f . t y p e )

c a s e ( Computer , * ) : a d d F i l e ( Computer . Music , f ) c a s e ( iPhone , Song ) : a d d F i l e ( iPhone . Music , f )

c a s e ( iPhone , VoiceMemo ) : a d d F i l e ( iPhone . VoiceMemo , f ) c a s e ( iPod , * ) : a d d F i l e ( iPod . Music , f )

i f ( d u r i n g S y n c ) Synced += f addPlaylistToDevice ( d : Device , p : P l a y l i s t , d u r i n g S y n c : b o o l e a n ) f o r a l l F i l e s f i n p . f i l e s : a d d F i l e T o D e v i c e ( d , f , d u r i n g S y n c ) f o r a l l C o n t a i n e r s c on d t h a t c o n t a i n a F i l e from p . f i l e s a d d P l a y l i s t ( c , p ) i f ( d u r i n g S y n c ) Synced += p

sync ( d1 : Device , d2 : D e v i c e ) i f ( d2 n o t i n d1 . s y n c e d and d1 n o t i n d2 . s y n c e d ) i f ( d1 i s Computer ) f o r a l l F i l e s f i n a l l C o n t a i n e r s c on d1 a d d F i l e T o D e v i c e ( d2 , f ) e l s e i f ( d2 i s Computer ) f o r a l l F i l e s f i n a l l C o n t a i n e r s c on d2 a d d F i l e T o D e v i c e ( d1 , f ) e l s e f o r a l l c o n t a i n e r s ( c1 , c2 ) on ( d1 , d2 ) r e c o n c i l e F i l e s ( c1 , c2 , c2 . d e v i c e ) r e c o n c i l e F i l e s ( c2 , c1 , c1 . d e v i c e ) r e c o n c i l e P l a y l i s t s ( c1 , c2 ) r e c o n c i l e P l a y l i s t s ( c2 , c1 ) d1 . s y n c e d += d2 d2 . s y n c e d += d2 [ syste m o n l y ] reconcileFiles ( f i l e S e t 1 , f i l e S e t 2 , d2 : D e v i c e )

r e q u i r e s f i l e S e t 1 and f i l e S e t 2 a r e both C o n t a i n e r s o r both P l a y l i s t s f o r a l l f i l e s f i n f i l e S e t 1 . f i l e s and n o t i n f i l e S e t 2 . f i l e s i f ( f i n Synced ) r e m o v e F i l e ( f i l e S e t 1 , f ) e l s e a d d F i l e T o D e v i c e ( d2 , f , t r u e ) i f ( f i l e S e t 1 == iPod . VoiceMemo ) r e m o v e F i l e ( f i l e S e t 1 , f ) [ syste m o n l y ] reconcilePlaylists ( c1 : C o n t a i n e r , c2 : C o n t a i n e r ) f o r a l l P l a y l i s t s p1 i n c1 . p l a y l i s t s i f ( e x i s t s a P l a y l i s t p2 i n c2 . p l a y l i s t s w i t h p1 . i d == p2 . i d ) r e c o n c i l e F i l e s ( p1 , p2 , c2 . d e v i c e ) e l s e i f ( p1 i n Synced ) r e m o v e P l a y l i s t ( c1 , p1 ) e l s e a d d P l a y l i s t T o D e v i c e ( c2 . d e v i c e , p1 , t r u e )

For the actions addFileToDevice and addPlaylistToDevice, when a user adds a Playlist or File, the parameter duringSync will be false by default - only the system can set it to true, as can be seen in the actions reconcilePlaylists and reconcileFiles.

Tactic. A user syncs (sync) his iPod to his Computer in order to add new music and playlists to his iPod. After deleting some songs from his Computer, and adding a

new Playlist to the iPod (addPlaylistToDevice), he syncs the iPod and the Computer again. After this sync, he finds that the new Playlist is present on his Computer, and the songs he deleted are no longer on either Device or in any Playlist.

3.3

Conceptual Model Analysis

The conceptual model for iTunes is complex, especially when considering the simple user interface that hides much functionality. The use of a Container to organize files appears to be iTunes way of implementing a pseudo-file system on different devices, without having a true file system in place. This lack of a file system and the way files are transferred, leads to the Sync concept being a "near miss" of traditional file syncing. Many users are likely familiar with the conceptual idiom of file syncing as it exists outside of iTunes, and when using iTunes it at first appears that the recognizable conceptual idiom is being used, however this implementation differs in small but surprising ways that affect use. Jackson warns that using partial instantiations of conceptual idioms can confuse and frustrate users [13], as it seems to have done in the case of iTunes. This section enumerates several of the situations in which syncing in iTunes differs from traditional file syncing.

3.3.1

Name Collisions

In traditional file syncing systems, a name is generally considered a unique identifier; however, in iTunes this is not the case. Figure 3-4 illustrates how two distinct playlists with the same name can be created on two separate devices, and syncing these two devices results in two playlists with the same name on each device. In the illustrated situation, the two playlists have distinct contents (one playlist holds file b while the other holds file c), but the situation remains the same even if the playlists have identical contents and behaves in the same way with files that share the same name. In a system with unique names, the situation of having two playlists with the same name in the same container would not occur. While this behavior may be inconsistent with traditional file syncing systems at the surface level, objects are being treated as

Figure 3-4: Behavior when two devices containing distinct playlists with the same name get synced.

distinct, indicating they still have unique identifiers, they are just hidden from the view of the user. One situation in which allowing name collisions might be useful is if a user has two songs with the same name, or even if they have two versions of the same song. Another reason to sync objects based on hidden unique identifiers is so that name can be treated like a property of the object. Thus, a name change on one device will be propagated to other devices during a sync.

3.3.2

Voice Memo Syncing

Figure 3-5 displays what happens when a voice memo is recorded on an iPhone and then synced with the computer. Unexpectedly, the synced voice memo is in a different container on the computer than it is on the iPhone, due to the computer not having a Voice Memo container. Similarly, when syncing a voice memo from an iPod to a computer, the voice memo appears in the Music container on the computer. However, the process of syncing the voice memo from an iPod to a computer strays even further from the expected behavior for a traditional file syncing system since the voice memo gets removed from the iPod Voice Memo container, as shown in Figure 3-6. In order to access the voice memo from the iPod after the iPod is synced with a computer, the Voice Memo must be synced from the computer back to the iPod by putting the

Figure 3-5: Behavior of iTunes when an iPhone with a recorded Voice Memo is synced with a computer.

Figure 3-6: Behavior of iTunes when an iPod with a recorded Voice Memo is synced with a computer.

Figure 3-7: Behavior for syncing a Voice Memo from a computer to an iPod.

voice memo onto a playlist. After re-syncing the iPod and computer, the voice memo is now found in the Music container on the iPod as opposed to where it was originally located in the Voice Memo container. Figure 3-7 illustrates this behavior.

When using iTunes on a computer, songs and voice memos can be put onto the same playlist. Syncing this playlist to an iPod leads to both the voice memo and the song being visible in the Music container in the same playlist (Figure 3-8), which is actually consistent with the expected behavior of a traditional file syncing when considered in isolation from recording the voice memo originally, since both the song and voice memo remain in the Music container on the iPod and the computer. On the other hand, syncing the same playlist to an iPhone results in the song and voice memo in two different containers: the song remains on the playlist in the Music container, while the voice memo is put into the Voice Memo container, as illustrated in Figure 3-9. This behavior differs from what would be expected of a more traditional syncing system since the files in the playlist get separate from one another - a situation which the user has no control over and must work around.

Figure 3-8: Adding a Playlist containing a Song and a Voice Memo to an iPod.

Figure 3-9: Adding a Playlist containing a Song and a Voice Memo to an iPhone.

3.3.3

First Time Syncing

In the case of syncing an iPod with a computer for the first time, the two devices do not get treated the same way in iTunes. If the iPod and the computer are being synced for the first time, then any files on the iPod are ignored, the iPod gains the files from the computer, and the state of the computer is unaffected by the sync. This behavior can be seen in Figure 3-10, and is the reason for the first conditional statement in the action sync. In traditional file syncing, the files on two devices would be merged in the same way regardless of it is the first time syncing or not.

Chapter 4

Evaluation

4.1

Plan for Evaluation

To determine how the conceptual model for iTunes differs from users’ perceived mod-els, several users were asked to complete a set of tasks in iTunes using the same computer, iPod, and iPhone that were used when determining the conceptual model. These tasks were developed with the observed unexpected behaviors described in sec-tion 3.3 in mind in order to determine if the Sync concept being a "near miss" of traditional file syncing could be used to explain some of the differences in the actual conceptual model and users’ perceived models.

Prior to completing the tasks, users were asked to answer a few questions about their experience using iTunes, as well as using Apple products in general. The ques-tions were asked in the same order each time, as shown in Figure 4-1. After answering

1. Do you own or have you ever owned any Apple products?

2. Have you synced your mobile device with your computer? Why?

3. Have you ever used the iTunes desktop application? When was the last time? How often do/did you use it? What is/was your main reason(s) for using it? 4. How would you rate your level of confidence in using iTunes?

1. Add a new Playlist to the iPod, containing a single song.

2. Record a Voice Memo on the iPod, then share the Voice Memo with the com-puter.

3. If the Voice Memo is no longer on the iPod, can you get it there?

4. Sync the iPod (which now contains a Song and a Voice Memo) to another computer.

5. Add an existing Playlist to the iPhone.

6. Record a Voice Memo on the iPhone, then share it with the computer. 7. Share the Voice Memo recorded on the iPod with the iPhone.

Figure 4-2: The tasks users were asked to complete.

the questions about their prior iTunes experience, users were asked to complete a pre-defined set of tasks, listed in Figure 4-2. Again, each user was asked to complete the set of tasks in the same order as all other users. At the completion of all the tasks, users were again asked to rate their level of confidence using iTunes.

Users were asked to narrate their thoughts and actions while doing each task, to state what they expected the outcomes of each of the their actions to be, and to react to what actually happened with each task. Asking for this narration created docu-mentation of how users’ expectations explicitly differ from the actual functionality of iTunes. Then, these differences were then used to create a model for how iTunes could better match users’ perceived version of the concepts.

4.2

User Study Results

In total, four users were tested who were a mix of graduate and undergraduate stu-dents from MIT. Each session lasted roughly a half hour, including asking the ques-tions beforehand, completing the tasks, and then a few minutes for discussion about the tasks and about their anecdotes with using iTunes prior to this study. All four of the users currently own at least one Apple product and have used iTunes in the last five years; however, only one user has used iTunes within the past year.

When asked to rate their level of confidence using iTunes on a scale from one to five, two users put themselves at three, one considered himself a four, and the final user was five out of five confident in his abilities. One of the users explained her level of confidence as a three because "[iTunes] is so hard to use, that even when I used it daily I still wasn’t great at using it." On the other side of things, the user that said he has full confidence noted that he could get any task done, "even if it takes [him] a little while". After completing all the tasks, the two users who rated their confidence a three said their confidence remained unchanged, as did the user who originally rated his confidence level as a five. The user who’s original confidence level was a four, said that after the tasks his level was then a three, since the tasks proved more "confusing and complex than [he] anticipated".

When asked to add a Playlist to the iPod and then, later on, to the iPhone, none of the users struggled to complete the task, though they did use various methods to achieve the end goal. While this project does not explicitly analyze the user interface of iTunes, it was interesting to see the different methods that existed for completing each task in the user study. In the case of adding a Playlist from the computer to another device, the playlist name could be dragged to the device in iTunes, or the user could navigate to the page for the device and then select a checkbox to sync the playlist to the device.

Sharing voice memos between the iPod, iPhone, and computer, however, caused issues for each of the users. Each user successfully recorded a voice memo on the iPod, after which the voice memo appeared in the Voice Memo container on the iPod. After syncing the iPod with the computer, every user expected the voice memo to remain in the Voice Memo container, and looked in several places for the voice memo after realizing it was no longer in the original container. One user even said "it should NOT be in music", although that is exactly where the voice memo ends up - in the Music container, on a playlist entitled "Voice Memo" by default, as seen in Figure 3-6, though the voice memo can be added to any playlist. This behavior can be contrasted with the behavior of executing the same task with an iPhone, as is depicted in Figure 3-5. Although the actual behavior of syncing a voice memo from an iPhone is the

same as the behavior every user originally expected when using the iPod, three out of the four users changed their expectation to expect syncing the iPhone to occurring the same way as syncing an iPod. Only one user correctly predicted that the voice memo would remain in the Voice Memo app on the iPhone.

4.3

Analysis

After completing the user sessions, two main issues were identified which aligned with the observations made after analyzing the differences between iTunes Sync and traditional file syncing, as discussed in section 3.3. First, there are inconsistencies between the containers present on different devices (illustrated in Figures 3-6 and 3-5). Second, playlists are allowed to span multiple containers, which can lead to difficulty finding files after syncing (Figures 3-8 and 3-9). Thirdly, devices that are being synced for the first time are synced in a different way than every other time the sync action occurs (Figure 3-10). In order to resolve these issues, I propose several edits to the existing conceptual model of iTunes, rather than an entirely new one, with the intent that the newer model more closely approximates a traditional file sync. The existing model is not inherently confusing, though some aspects of it lead to unexpected behavior in the implementation.

4.3.1

Suggestions for Improvements

The largest change would be to alter the predefined Containers so that they are consistent across every device, allowing each Container to only have a single type. This means that the computer would now have a Voice Memo container. Introduc-ing this consistency between devices would simplify the Sync concept, since syncIntroduc-ing would no longer need to occur on the level of devices. Containers could be synced one-to-one (e.g. iPhone.Music with Computer.Music and iPhone.VoiceMemo with Computer.VoiceMemo), instead of each container on the iPhone being synced with each container on the computer. It would also remove the special case that occurs for syncing voice memos between an iPod and a computer, since voice memos would

exist only in the Voice Memo container on each device.

Along with making Containers consistent, I propose linking playlists to one type. This would remove the ability to add both a voice memo and a song to the same playlist. One argument against preventing this behavior is that a user may want to record a song as a voice memo, and then be able to enjoy it along with the rest of their music. In iTunes currently, this voice memo-turned-song would not appear in any playlists after being synced to an iPhone, but rather would appear in the Voice Memo app. In order to keep the voice memo in a playlist across all devices, the voice memo would need to be downloaded, and then uploaded to iTunes as an MP3 file, in which case it would be classified as a Song and thus could be treated as such. This behavior would be the same in the proposed implementation, so while it is no easier, this is an edge case that may or may not occur for different users. Similarly to standardizing Containers, restricting Playlist to a single type would simplify the process of syncing. Currently, playlists can span multiple containers, which adds additional things to do in the sync process to keep track of in which containers a playlist exists. In the proposed implementation, a playlist would be restricted to single type, thus would only exist in one container.

Finally, I propose to sync two devices in the same way regardless of if it is the first time syncing the two devices. In the original conceptual model, the sync action has a special case for handling the first time syncing two devices, and this special case is the reason for the synced relation between two devices. I believe this is the change least likely to happen with the actual iTunes application, due to concerns with syncing that were not considered as a part of this limited conceptual model. Beyond dealing with devices and files, iTunes also manages accounts and purchasing of media, and these factors could be the reason that the songs from an iPod cannot be synced to a new computer, so that media does not get shared outside of the appropriate channels.

4.3.2

Updates to the Conceptual Model

With the proposed improvements, the conceptual model will still consist of the same three concepts: Playlist, Container, Sync. The new data model, shown in Figure 4-3,

Figure 4-3: Data mo del for the prop osed up dated conceptual mo del of iT u nes.

is largely the same, with just a few key changes. The relation between Container and Type that was formerly types is now type, since a Container is limited to exactly one Type, instead of at least one. Additionally, the relationship type that used to exist from File to Type is now from Object to Type, since Playlists would have a type as well. Finally, the relation synced that existed between Devices is no longer present, since all devices will be treated the same regardless of if they have been synced together before or not, in fact, the sync action occurs between Containers instead of Devices, as discussed below.

The biggest changes to the conceptual model will occur in the actions for each of the concepts. For Playlist and Container, a couple of the actions need to be updated to reflect restricting each playlist/container to a single type. The actions for Sync experience the largest changes, since syncing will now occur between two containers instead of two devices.

Playlist Actions. create ( n : S t r i n g , t : Type ) c r e a t e new P l a y l i s t p w i t h p . name = n , p . i d = u n i q u e i d , p . t y p e = t addFile ( p : P l a y l i s t , f : F i l e ) r e q u i r e s f . t y p e == p . t y p e p . f i l e s += f

Both create and addFile have been changed to take into account the addition of the relation between Type and Playlist, while removeFile and play remain unchanged.

Container Actions. addFile ( c : C o n t a i n e r , f : F i l e ) r e q u i r e s f . t y p e == c . t y p e c . f i l e s += f addPlaylist ( c : C o n t a i n e r , p : P l a y l i s t ) r e q u i r e s p . t y p e == c . t y p e c . f i l e s += f f o r e a c h f i l e f i n p . f i l e s n o t a l r e a d y i n c . f i l e s c . p l a y l i s t s += p

Both addFile and addPlaylist now require that the Object being added has the same type as the Container, while removeFile and removePlaylist remain unchanged.

Sync Actions. sync ( c1 : C o n t a i n e r , c2 : C o n t a i n e r ) r e q u i r e s c1 . t y p e == c2 . t y p e r e c o n c i l e F i l e s ( c1 , c2 ) r e c o n c i l e F i l e s ( c2 , c1 ) r e c o n c i l e P l a y l i s t s ( c1 , c2 ) r e c o n c i l e P l a y l i s t s ( c2 , c1 ) [ syste m o n l y ] reconcileFiles ( f i l e S e t 1 , f i l e S e t 2 )

r e q u i r e s f i l e S e t 1 and f i l e S e t 2 a r e both C o n t a i n e r s o r both P l a y l i s t s r e q u i r e s f i l e S e t 1 . t y p e == f i l e S e t 2 . t y p e f o r a l l f i l e s f i n f i l e S e t 1 . f i l e s and n o t i n f i l e S e t 2 . f i l e s i f ( f i n Synced ) r e m o v e F i l e ( f i l e S e t 1 , f ) e l s e a d d F i l e ( f i l e S e t 2 , f ) Synced += f [ syste m o n l y ] reconcilePlaylists ( c1 : C o n t a i n e r , c2 : C o n t a i n e r ) r e q u i r e s c1 . t y p e == c2 . t y p e f o r a l l P l a y l i s t s p1 i n c1 . p l a y l i s t s i f ( e x i s t s a P l a y l i s t p2 i n c2 . p l a y l i s t s w i t h p1 . i d == p2 . i d ) r e c o n c i l e F i l e s ( p1 , p2 , c2 . d e v i c e ) e l s e i f ( p1 i n Synced ) r e m o v e P l a y l i s t ( c1 , p1 ) e l s e a d d P l a y l i s t ( c2 , p1 ) Synced += p1

Both addFileToDevice and addPlaylistToDevice are removed, as a result of sync now occurring between two containers instead of between two devices. Both recon-cilePlaylist and reconcileFiles have been updated to reflect sync occurring between two Containers and the remove of the two other actions. The action sync is by far the most changed, with its input being entirely different, the action no longer requiring iteration over the Containers in a Device, and no longer having the special case for when two Devices are synced together for the first time.

Figure 4-4: Updated behavior when an iPod with a recorded Voice Memo is synced with a computer.

4.3.3

Revisiting Special Cases

These updates to the conceptual model for iTunes are meant to remove the confusing situations that arose during user testing and observation, and overall to make the Sync concept more align with traditional file syncing by removing some of the special cases discussed in section 3.3.

The unexpected behaviors with syncing Voice Memos described in section 3.3.2 have been removed by having consistent containers across all devices. Having consis-tent containers also removed any differences between syncing an iPod and syncing an iPhone. Figure 4-4 illustrates the new behavior for syncing voice memos between an iPod and a computer, which is the same behavior as it would be for an iPhone as well. Since sync now occurs between two containers, there is no device listed separately from the container with which it is associated.

In the updated model, all syncing is handled the same way, even if two devices are getting synced for the first time, so the behavior discussed in section 3.3.3 no longer occurs. Since Objects can still share names, the situation described in 3.3.1 where two playlists can exist with the same name can occur in the new model in the same way that it occurred in the current conceptual model. While this behavior may be inconsistent with traditional file syncing in that names are not unique, the new model does not fix this inconsistency due to situations such as a user having two songs with the same name.

Chapter 5

Related Work

The idea that a user’s perceived conceptual model aligning with what a system sug-gests is not a new one. Don Norman discusses this idea [21], giving an example of the temperature controls for a refrigerator. In a standard refrigerator, there are two temperature controls and two compartments, thus users tend to assume that changing one temperature control affects one compartment, and the other controls the other compartment. However, changing either control affects both compartments. Nor-man argues that the controls suggest a false conceptual model, thus causing users to perceive a conceptual model that is wrong.

Regarding the theory of conceptual design used in this project, in his initial re-search proposal [13], Daniel Jackson proposes several components for developing the theory: studying existing applications, cataloging conceptual idioms, case studies in redesign, and theory development. To date, at least one research project exists for each of these components. Jackson has continued to work on theory development, through speaking about it [16] and publishing literature that expands upon the orig-inal proposal [14]. Under Jackson’s guidance, Santiago Perez De Rosso conducted a study of Git, a file management command line system [25, 24]. In addition to study-ing the existstudy-ing application, Rosso also created a redesign of Git, called Gitless, and evaluated it using user studies [23, 25]. As for cataloging conceptual idioms, mem-bers of the Software Design Group at MIT, led by Jackson, are developing a set of concepts that are implemented in JavaScript and can be used and combined to create

full applications [15].

In addition to previous work done with regards to conceptual models, other work has been done regarding iTunes. As discussed in section 1.2, several users have com-plaints of iTunes packing in too much functionality while also hiding that functionality behind a very clean user interface [3, 6, 19]. Artists have also proposed redesigns to the user interface of iTunes [8, 17, 18], with one research group even proposing adding a the idea of a physical album back to iTunes [9]. Another research group, from Uni-versity of Wisconsin-Madison, looked at the file system underlying multiple Apple desktop applications, including iTunes, and came to the conclusion that "a file is not a file" in the system [10].

Chapter 6

Future Work

Within the scope of the conceptual model put forth in this thesis, expanding user testing could provide additional insights. One clear expansion would be to include more users, and also to include users who have never used iTunes before. To expand the study to be more like an experiment, it would be interesting to alter the order of the user tasks to determine if the order has any effect on what users expect to happen for each task. Within this study, users were always asked to complete tasks with the iPod, and then with the iPhone. This did seem to affect users’ expectations since several users expected syncing the iPhone and the computer to behave in the same as syncing the iPod and the computer, even though those expectations were different from how they originally expected the iPod syncing to behave. A larger scale experiment could be used to disprove or support this observation.

Continuing a study of the conceptual design of iTunes, it would be interesting to expand the model to include other forms of media: Movies, TV Shows, Podcasts, Books, Photos, and Files. From previous use and observation of iTunes, I hypothesize that these would behave much in the same way as Songs and Voice Memos; however, I do not know what edge cases would arise to cause interesting, unexpected situations to occur. In addition to including the other types of media, the model could also be expanded to include Apple IDs, which correspond to user accounts, and iCloud, which can be used by each user to store files and share media across devices.

re-views and usability issues that could benefit from a conceptual analysis. Creating a model and conducting a user study similar to this one could help to support the idea that confusing applications can find explanations for their issues in misconceptions of their conceptual models.

Appendix A

Software & Hardware Versions

Throughout this project, iTunes version 12.9.0.164 on a 2013 Macbook Pro running macOS Mojave was used. The iPod used was a fifth generation iPod nano from 2009 running software version 1.0.2, and the iPhone was a 2015 iPhone 6 running software version 10.3.1.

Bibliography

[1] Apple iTunes. https://www.apple.com/iTunes/.

[2] Apple Support. https://support.apple.com/en-us/HT201313.

[3] Marco Arment. Don’t order the fish, July 2015. At: https://marco.org/2015/ 07/26/dont-order-the-fish.

[4] Frederick P. Brooks. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, Reading, Massachusetts, 1975.

[5] Sam Costello. How to Sync an iPhone to a Computer, May 2019. At: https: //www.lifewire.com/sync-iphone-to-computer-2000128.

[6] Graham Cox. Why do people hate iTunes so much?, May 2017. At: https: //www.quora.com/Why-do-people-hate-iTunes-so-much.

[7] Jim Dalrymple. Apple Music is a nightmare and I’m done with it, July 2015. At: http://www.loopinsight.com/2015/07/22/ apple-music-is-a-nightmare-and-im-done-with-it/.

[8] Doney den Ouden. Goodbye iTunes. Hello Music!, August 2017. At: https://medium.com/@dexwell_/goodbye-itunes-hello-music-32af84851222. [9] Jamey Graham and Jonathan J. Hull. Icandy: A tangible user interface for

itunes. In CHI ’08 Extended Abstracts on Human Factors in Computing Systems, CHI EA ’08, pages 2343–2348, New York, NY, USA, 2008. ACM.

[10] Tyler Harter, Chris Dragga, Michael Vaughn, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau. A file is not a file: Understanding the i/o behavior of apple desktop applications. ACM Trans. Comput. Syst., 30(3):10:1–10:39, August 2012.

[11] Karen Haslam. iTunes problems and fixes, January 2018. At: https://www. macworld.co.uk/how-to/mac-software/iTunes-problems-fixes-3670342/ #toc-3670342-4.

[12] Daniel Jackson. Software Abstractions: logic, language, analysis. MIT Press, 2006. Revised edition, 2012.

[13] Daniel Jackson. Conceptual design of software: A research agenda. Technical Report MIT-CSAIL-TR-2013-020, MIT, Cambridge, Mas-sachusetts, 2013. At: https://groups.csail.mit.edu/sdg/pubs/2013/ conceptual-research-agenda-2013.pdf.

[14] Daniel Jackson. Towards a Theory of Conceptual Design for Software. 2015 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software, 2015. (Onward! 2015).

[15] Daniel Jackson. Concepts: A New Modularity for Software. Talk at Splash 2018, 2018. MIT.

[16] Daniel Jackson. Conceptual Design. Lecture notes, 2018. MIT.

[17] Jordan Kahn. Concept imagines a simplistic iTunes/Apple Music redesign for Mac [Gallery], May 2016. At: https://9to5mac.com/2016/05/09/ concept-itunes-apple-music-redesign/.

[18] Brye Kobayashi. iTunes Concept, May 2014. At: http://kurocha.blogspot.com/2014/05/itunes-concept.html.

[19] Robinson Meyer. iTunes Really Is That Bad, July 2015. At: https://www. theatlantic.com/technology/archive/2015/07/why-is-iTunes-so-bad/ 399833/https://www.theatlantic.com/technology/archive/2015/07/ why-is-iTunes-so-bad/399833/.

[20] Jakob Nielsen. 10 usability heuristics for user interface design. http://www. nngroup.com/articles/ten-usability-heuristics.

[21] Donald Norman. The Design of Everyday Things. Basic Books, New York, New York, 2002.

[22] John Patrick Pullen. I hate iTunes. And I think Apple does, too, June 2015. At: https://qz.com/441111/i-hate-iTunes-and-i-think-apple-does-too/. [23] Santiago Perez De Rosso. A conceptual design analysis of git. Master’s thesis,

Massachusetts Institute of Technology, May 2015. At: https://dspace.mit. edu/handle/1721.1/97817.

[24] Santiago Perez De Rosso and Daniel Jackson. What’s wrong with git? a concep-tual design analysis. Proceedings of the 2013 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software, 2013. (Onward! 2013).

[25] Santiago Perez De Rosso and Daniel Jackson. Purposes, concepts, misfits, and a redesign of git. Proceedings of the 2016 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications, 2016. (OOPSLA 2016).

[26] Craig Smith. 275 Apple Statistics and Facts (2019), May 2019. At: https://expandedramblings.com/index.php/ by-the-numbers-amazing-apple-stats/.

[27] Jason Snell. iTunes: Time to right the syncing ship, April 2012. At: https://www.macworld.com/article/1166274/ iTunes-time-to-right-the-syncing-ship.html.

[28] Nina Ulloa. iTunes Has 800 Million Accounts... and 800 Million Credit Card Numbers..., April 2014. At: https://www.digitalmusicnews.com/2014/04/ 24/iTunes800m/.

[29] History of iTunes. At: https://en.wikipedia.org/wiki/History_of_ iTunes#iTunes_1.