Comic Book, Pt. 1

As a personal side project this semester, I will also be developing my own app with the intent of distributing a comic book. It will be an iOS native app. Without getting too much into the nitty gritty of the book, I have put together two simple prototypes to consider as interface alternatives. The comic book will initially only include one "book" (episode/chapter...still working on terminology), so further versions will need to include capability for multiple book navigation. The MVP, however, will start with a splash screen, enter right into the first page of the book, and have a way to move from scene to scene. The main differences between the two prototypes, however, is in the main navigation. If a user decides to exit the page view, they will be presented a way in which they may skip to alternate pages. These differences will be outlined in greater detail below.


The first version begins with a splash screen to be viewed during loading. I am still debating whether or not to include a progress indicator for this activity. Because the app is loading photos, the build could take a while, and the user should be notified the app is still functioning. On the other hand, I do not want the progress bar to take away from the comic book feel of the app. There are several progress indicators with a tech-y feel that might transition nicely, so...that decision will remain pending.





Once the program has loaded, the user will be directly presented the first page of the book. "Page turn" indicators in the bottom corners will indicate tap areas to navigate forward and backward through the book. There will also be a "home" button in the top, which will allow the user to access the main navigation mentioned earlier.






The main navigation will be presented in a grid view, just like a standard photo album. This will allow the user to skip forward or backward to view a different part of the book. Once clicked, the user will be taken back into page view as seen above.








The second version also starts with a standard splash screen while the program loads. That is then followed by a similar page view, but the "page turn" indicators have been left out in favor of a swipe navigation between pages, with a page turn animation instead. Also, the "home" button has been switched to a "close" button in the top right corner. Finally, the main navigation is presented in a carousel format.

These two paper prototypes will be used this week for testing as follows:

Goals

-Are "page turn" indicators necessary?

-Is a progress indicator necessary?

-Which navigation style is preferred?

Participants

I intend to obtain feedback from 25+ potential users. I will begin by testing the others on the comic book committee (3 individuals) as well several of my easily contacted friends (8 individuals). I will augment those numbers with other individuals from my classes and environment as well. I intend to have all data obtained by Wednesday.

Method/Tasks

I will first give the test subject a short introduction to the process the test, then flip a coin to determine which version will be presented first. I will then present the first splash screen to the individual and start a timer. I anticipate the user will tap the splash screen once. After that, I will stop the timer upon their next action, as this action will most likely be out of frustration rather than expectation. I will simultaneously present them with the next page, which is the first screen of the book. I anticipate those with the "page turn" indicators presented first will immediately try to use those, but when presented with the other interface will have a little more difficulty transitioning to swipe movements. I will have two or three additional "book pages" prepared for the user to navigate through, and will run through the experiment until the user decides to quit. 

Upon completion, I will ask the user the following three questions:

-Which style of navigation did you prefer (carousel/grid)?

-Which method of turning pages did you prefer (swipe/tap)?

-Did the "page turn" indicators augment your user experience?

Measures

The timing of the initial sequence will later be compared to actual load times to determine whether or not a progress indicator is necessary. The user comments will also be taken into consideration and tested at a 90% confidence interval. I also will need to put both prototypes on the same color of paper so that does not influence their decision. 

Stay tuned to find out what comes of the experimentation!

Implementation, Pt. 2

After an in-depth discussion with our instructor, we boiled our project down to the absolute essentials we need to include in our MVP, and we decided the best route to go for now is to simply build an app where users can read jokes. We will postpone implementing any user submissions, marking favorites, etc. for future versions. As such, we also decided to develop two versions of our interface. Our first version opens each new joke into a separate screen. Here are pictures of the landing page as well as the first joke opened.

Version 1, Home Screen

Version 1, Joke 1

For our second version, we decided to test a collapsible list (that's the term used by jQuery Mobile, while 4ourth Mobile uses the term "windowshade"). Here is a screenshot demonstrating two jokes open simultaneously.

Version 2

User testing will begin shortly on these two different versions, followed by more detailed CSS designing to implement different visual elements.

Show Me More

In a return glimpse at possible designs this week, we take a look at ways of displaying more information to the user, as outlined by 4ourth Mobile Design in the chapter "Revealing More Information". The common theme behind this section is revealing additional information on the same screen where the user is already working rather than taking the user to a new screen. This can be done in several ways. The first is a simple pop-up. Apple uses this design a lot to confirm actions before proceeding. Here, the app Bump uses a pop-up menu, which populates the screen from the bottom:

Bump

Another popular method is to employ a windowshade concept where information spreads, revealing information in a way that it seems as though the window shades have been drawn, granting access to information previously hidden behind them. Here are two examples of the pattern from the iPhone's Weather app as well as their home screen menu:

Weather

Home Screen

Unfortunately, as you can see, sometimes the revealing of information distorts an otherwise adorable photo. Maybe it would be better to employ this as a pop-up, thus covering a portion of a photo rather than slicing it into pieces. What do you think?

Implementation, Pt. 1

After Martin and I got together and reviewed our four prototypes, I sat down and started building the project. This week I was able to put together the main navigation. Although we decided we would prefer to have filmstrip navigation, I have not yet been able to figure out how to implement that, so I went with a menu bar across the top. We are using jQuery Mobile to put the project together, which utilizes basic HTML/CSS to build a web app. For anyone interested in seeing the preliminary implementation, it is currently being hosted here. Stay tuned for more information as the project progresses!

So Many Choices

Before Martin and I began any project implementation, we decided to bring together several prototypes to ensure we had the design we wanted. He already had one prototype, so he submitted a second, and I also submitted two prototypes.

The first I designed utilizes menu navigation, with the drop-down menu in the upper right-hand corner of the screen. The "Read" page also requires several steps with the user navigating from the broad category to a more narrow category. Here are some photos of this prototype:

The other prototype I submitted used filmstrip navigation. I also recommended just letting the user browse all categories. I think this design looks incredibly sleek:

Ultimately, Martin and I agreed on filmstrip navigation. He also suggested we add icons at the top of the "Read" page to act as category filters, and those same icons can be used to add the category when submitting a joke. The idea sounded fantastic to me!

As we progress and further consider implementation, we need to solicit some user feedback. We will offer the user a preview of the joke on the main "Read" page. When they click on the joke, we need to decide whether the list will expand to allow the joke to fill out the screen or if we will instead choose to load a new screen displaying just the single joke. This is probably something that would be better tested directly on the mobile device so the user can see just how cluttered the screen becomes when adding the joke in the middle of the list. Ultimately, that means writing the code for two different navigation styles, but I think that is within the scope of my capabilities. If you would like to be one of our guinea pigs, please leave a comment, and I will get in touch!

I've Got the Power!

Ringer Off

Ringer On

When designing the user-interface, it is incredibly important to keep in mind the feedback the app provides the user, as well as feedback the user provides the app. These can be thought of as past and future tense actions. For example, the app can provide the user confirmation on what they have just done, i.e. a past action. Here are some examples of how the iPhone 3 confirms the ringer has just been turned off or on.

Confirm Purchase

Confirm Delete

Additionally, confirmation can be requested from the user on a future action the user has tasked the phone to perform. The app store confirms purchase by subtly prompting the user to tap the same area of the screen a second time. The photo on the left shows the purchase button has changed from a price to a "green light" as the user gives the go-ahead to continue with the action. The photo on the right, however, shows the confirmation requested to delete the photo. The prompt is in red, in essence telling the user to "stop" and think before continuing with the action.



Ultimately, providing and requesting confirmation or feedback leaves the control, the power in the user's hands.