InteractivePrototype-Group:Group F

From CS 160 User Interfaces Sp10

Jump to: navigation, search

Contents

Introduction

Veterinary emergency doctors treat the widest array of patients and have little time to prepare (e.g. look up information on breeds, symptoms, treatment, etc.) due to the very nature of their jobs: treating unexpected emergencies. Our solution is a mobile social network for veterinary emergency doctors who treat small, non-exotic animals (such as dogs and cats). This system takes the form of an iPhone client application, which allows users to ask questions on disease diagnosis and treatment, and receive answers from other physicians in real-time. The replies have ratings associated with them, provided by other doctors. Each physician also has a profile that includes the amount of questions they’ve answered and the average rating of their answers. Our objective is to create an application that will improve how veterinarians diagnose and treat animals, by creating a system that facilitates the spread of knowledge.

Group Members

All group members contributed equally. As before, the majority of the project work was done with all the group members within five feet of each other! This facilitated discussion and collaboration. We found peer programming to be a particularly helpful tool in developing on a platform that none of the members had programmed on before this course.

Our application consists of a server and client. We had one member of the group developing the server end, and the rest working on the client (iPhone). There was a lot of interaction between the two sides - particularly in defining the client/server interfaces, as well as knowledge transfer.

Tasks

Easy: View questions and responses

  • Users will be able to view all the questions that other vets have asked from the main screen in a list form, in chronological order. Furthermore, they can see all the responses to each question if they select one of those questions.

File:GroupFEasyTask.mov

Medium: Post response to question

  • Users will be able to answer questions posted by other physicians. They will be able to answer questions from the response screen, and then be able to view their response on the question screen.

File:GroupFMediumTask.mov

Hard: Attach image to question

  • Users will be able to attach image files to questions they post. The images can be taken with the iPhone camera or can be transferred from a computer (in the case of digital x-rays). The attachments will serve to clarify the question. Users will be able to do this after the question has been posted. The rationale for doing this (as opposed to having them attach it when they post) is the user may have a question that they want to post before the x-ray has been done (and the x-ray isn’t really necessary). So they have the option to attach it later. Also, we want to keep the post question interface very simple and straightforward.

File:GroupFHardTask.mov

Revised interface design

Changes

Attachment option in Ask A Question screen

  • From what we have learned from our Lo-Fi prototype, we know that our target users have troubles using the attachment function. Users wait for something to happen after they check the attachment box. They do not know that the attachment screen will pop up only after they tap on the submit button. Therefore, in our interactive prototype, we use a switch instead of a checkbox to indicate if the user decides to add an attachment or not. Switches are widely used in Settings pages. When users use a switch in setting pages generally, the results will not appear right now until the users click on the OK button. By using a switch for the attachment option, users can assume that the changes will only take an action after they are done with their current page.


Old New

Screen title and button names

  • It also came to our attention that we had too many screens using the word "Post" in the screen title, and too many buttons that are all named "Post", which can be very confusing. Therefore, on the main screen where users can browse questions or post a question, we change the "Post" button to "Ask", so users can know that if they want to ask a question they can tap on "Ask" instead of not knowing if the button "Post" means to post a question or a response. For the screen where user can ask a question, instead of "Post A Question", we also change the title to "Ask A Question," and the button "Post (the question)" is changed to "Submit." And finally, when responding to a question on the Question screen, the user now presses "Reply" instead of "Post".
Old New

Different placement of Upload attachment button

  • We decided to change the placement of the Upload button for uploading an image from the top-right corner of the navigation bar, to near the bottom of the screen right beneath the picture about to be uploaded. This new button also appears only after the user has selected an image to upload. We thought this was a good idea because our users from our Lo-Fi prototype became confused as to what to do next after selecting the picture to upload. They had some difficulty realizing the Upload button on the navigation bar was the button they were suppose to press. We figured that a bigger button under the image, which only pops up after the user selects an image, would probably make it more intuitive for users to understand how to upload the selected image.
Old New

Addition of the Questions title on the Main Menu

  • We added a title bar on the main menu that says "Questions" above the list of all the most recently posted questions. Some users from our Lo-Fi prototype were a little confused when they first saw our list of questions on the main menu. They weren't really sure what they were looking at. We felt that a title describing the list might shed some more light on these users.
Old New

Unimplemented Features

Sketches of all the unimplemented features. These unimplemented features are all also described more thoroughly in the Prototype Overview.

Screens Descriptions
  • Login screen: Only appears on the first time the user fires up the app, or if the user logs out from their settings page. This feature wasn't vital in showing how our application functions (reasoning below).
  • "Sort by" and "Filter by" functionality in the main screen: Again we felt these features weren't too vital in showing how our application works at this time (reasoning below).
  • Rating responses: Users can only rate responses up now. We'd like to eventually have a thumbs up and thumbs down button for being able to rate responses both up and down.
  • User profile creation and user settings: Individual profiles weren't too important at this time in order to show how our application works. Eventually we'd like to have each iPhone app be associated with one user. But for now, we just have a default user called iPhone User.

Prototype overview

Big Picture

Figure 1: Big picture architecture overview

This application consists of two parts: the iPhone client application which runs on the device itself, and the Web server component which is responsible for storing, processing, and retrieving the data securely. The client application connects to the server via HTTP to retrieve data (questions, answers, ratings, etc) formatted in XML, and to post data (questions, answers, ratings). With this RESTful approach, the server becomes the central hub as shown in Figure 1, which all the doctors' iPhone devices communicate with.

All connections to the server are secured via SSL. This ensures that any sensitive data is encrypted. No data is cached on the device to further ensure privacy. The reason for such a no-cache policy, is for cases when information needs to be removed immediately. This way, when it's removed from the Web server database, we can be quite sure that all traces of it are gone. The server is VPS-hosted, running Ubuntu 8.04.2, Apache 2.2, PHP 5.3.2, and MySQL 5.1. All proper security patches have been applied.

Feature Summary

Note: Further details are provided next to each referenced figure in the section below.

The main screen (figure 3) is the central one for the application. After users start the app, they will see a brief loading screen (figure 2), and be taken to the main screen every time. When they hit this screen, data is automatically downloaded from the server, parsed, and displayed. This screen consists of all the recent questions that have been asked by physicians who are part of the mobile network. More specifically, the question title is displayed and the date when the question was asked. The questions are sorted by most recent on top - much like a forum. The user can tap on a question title to view the entire question and the responses.

When a question is selected, the user sees the screen shown in figure 4. When this screen opens, a unique question identifier number is passed to the server, and the appropriate data is synchronously downloaded (similar things are done for almost every screen which involve data transfer to and fro device). This screen consists of various details about the question (full description, animal type, breed, gender, age, and attachment). Not all questions will have attachments. Users can view the attachments (if they're present) by taping on them - this will open the iPhone browser with the image path (ie, a server URL). Below the question are the responses. Each response includes the date it was posted, a rating (provided by other doctors), and the name of the physician who provided the answer. A user can post a reply when viewing a question, by tapping the Reply button at the top.

Figure 5 illustrates the screen that allows users to post replies (that are posted to the server). Because it will be used often (or so we hope), it was designed to very simple to use - it's very clean and provides ample room for the user to write his or her response. After a user posts a reply, he or she is able to immediately see it in the list of responses for that particular question.

Figure 6 illustrates the screen that allows users to post questions. Users can enter various details concerning the pet, as well as upload an attachment (which is a separate screen; on this screen, they only specify the intent).

After a question is posted, if users specified that an attachment will be present, the attachment screen is opened (figure 7). Users are able to select images from their iPhone devices, that are then uploaded to the server. (When other doctors view the question, they'll be able to view the attached image as mentioned above).

Left Out Features and Justification

We're happy to say that the most important features of the prototype were implemented! A small subset of the planned features were left out of this initial phase due to focus being placed on the core set of functionality (described in the section below). The left out features aren't particularly difficult, and we foresee no problems implementing them in later prototypes.

The first feature we decided to leave out was the initial Login screen. In theory, users will only see this screen once, and their login credentials will be stored thereafter. Also, by leaving this out, we temporarily put off building a login and authentication (for signing the HTTP requests) system on the server end. On a final note, the login screen will be a standard one (2 text-fields, and a button) employed by hundreds of other iPhone application such as Facebook - so various iterations of it are not necessary (we don't want to tinker with something proven, when there's a lot of other functionality in our application).

We decided to leave out sorting and filtering question functionality from the main screen. As mentioned in the last writeup, we decided against lo-fi prototyping sorting/filtering due to various aforementioned reasons. We weren't sure whether to dedicate time to implementing this functionality at this phase. We answered this question via introspection, as well as recounting lo-fi tests we did with our target users. We realized that we ourselves rarely sort/filter posts when we browse forums, especially when the forum was more sparsely populated. This gave us some initial intuition, but it was only after going over the experiments with our actual users that we came to a conclusion. Although we didn't prototype this actual functionality with them, we recounted that none of them expressed particular curiosity toward this feature even though the Sort and Filter buttons were very visible on the paper prototype.

Next, a couple of technical features having to do with viewing a question and its responses that were left out due to time constraints. Firstly, we have the image attachment implemented in such a way that clicking on the attachment link takes you to where the image is hosted by the server (See "Viewing a Question" in the table section below). For now, we felt that this was a good tradeoff between functionality (the image is still uploaded to the server, and the user can still see the image) and usability (launching Safari takes you out of the application state). In the future, however, we will modify our app so that the image automatically appears as a thumbnail in that screen, and clicking it downloads it in a way that doesn't clear the application's state. Secondly, responses can currently only be rated up because of a technical detail. Again, this was a tradeoff between functionality (the presence of a rating system) and usability (bad responses can't be discredited very easily), but we felt that we still had the overall rating system idea in tact. In the future, the rating system will very clearly present buttons to the user for rating a response up or down.

The settings screen (which lets users log out, change alert frequency, etc.) was left out of this prototype. This feature is not central, and was left out so time could be spent on more important functionality.

The profile/edit-profile screens are the final screens that were left out. Although these screens are non-essential for the three tasks, they are the most important among the ones left out. The core essence of our application involves facilitating the spread of knowledge among veterinary emergency doctors. The profile doesn't play a direct role in this (one of the reasons we left out this feature; a second one being time constraints), but it allows doctors to evaluate the information posted by others on the basis of credentials and years of experience. The profile/edit-profile screens will be the first implemented in later prototypes.

Wizard of Oz

No wizard-of-oz techniques are employed in this prototype. We felt like our application did not lend itself easily to use of such techniques (users aren't interacting with a system - the system merely facilitates communication between users), and the use of these was not essential in creation of the prototype.

Prototype screenshots/scripts

Overview of all screens

Screens Descriptions
Figure 2
  • Login : After the users login for the first time, they do not have to login every time when they use the app. Users will be brought to the main screen automatically after 1 second.
Figure 3
  • Main Screen: This screen displays the list of posted questions. The title "Questions" has been added to tell the user what they are looking at, and the "Post" button in the top right corner has been changed to an "Ask" button for clarity of its function. Users can tap on the question that brings them to the specific question they want to read. The "Sort By" and "Filter by" functions are not implemented yet.
in-linein-line in-linein-line
Figure 4
  • Viewing a Question:
    • Top left: This is where the question, responses to the question, and ratings for each response are shown.
    • Top right: The responses are listed below the question in a different color.
    • Bottom left: The user can tap on the original question's attachment URL, which will open a safari browser that takes them to the image.
    • Bottom right: The image in a new window of the Safari browser.
in-linein-line
Figure 5
  • Post A Response: Users can enter the response here. The title of the question is also showed to remind the users what question they are answering. When done, press the Post button, or go back to the question screen by tapping the Cancel button.
in-linein-line
Figure 6
  • Ask A Question: Users can enter the pet's basic information, such as animal type, breed, sex, age, and the symptom description as well as attaching images to show the pet's situation more fully. When the switch for attachment option is on, users will be brought to the Attachment screen after tapping the Post button. Otherwise, a new screen that contains their newly posted question will be shown and they are done posting the question.
in-linein-line in-linein-line
Figure 7
  • Attach an Image: As a second step in posting a question, vets can upload an image attachment to the server for other vets to see. The attachment process takes two steps: browsing locally for the image, and then uploading it.
    • Top Left: This screen appears if the vet turned on attachments when posting a question. It notifies the vet that they are now in the process of attaching an image.
    • Top Right: If the vet clicks on "Browse", they are taken to their local Photo Gallery, where they can choose an image from there to upload.
    • Middle Left: The vet selects the photo from a specific album.
    • Middle Right: The image is blown up so that they vet can make sure it's the correct image with the necessary detail.
    • Bottom: The original screen once again, with the selected image. Clicking on the Upload button uploads the image and posts the question to the server so that all other vets can see.

Storyboards

  • Task 1: Viewing Questions/Responses
    • After the app finishes loading the login (not implemented yet) and welcome screen, the vet is presented with the Main Menu. Browsing up and down shows the vet the list of all questions asked in chronological order. The vet can tap any question to see more details about it. Information about the question: description, animal type, breed, gender, age, attachment, are all presented at the top. The vet can then scroll down to see the responses to the question. Pressing the Main Menu button takes the vet back to the list of questions again, where the he/she can select another question to view.

in-line in-line in-line in-line in-line in-line in-line

  • Task 2: Posting a Response to a Question
    • Starting from the Main Menu again, the vet can tap a question to get to the Question-viewing screen, and then tap the Reply button in the top right to post a response to the question. The vet can then fill out a text box and hit the Post button in the top right to post the response. Doing so takes the vet back to the Question-viewing screen, where the response they just posted appears at the bottom.

in-line in-line in-line in-line in-line

  • Task 3: Asking a Question and Attaching an Image to the Question (2 Tasks)
    • The vet can ask a question directly from the Main Menu by tapping the Ask button in the top right. That takes the vet to a form where he/she can fill in information about the case in question. The vet can then tap on the Attachment segmented UI widget to toggle the attachment mode on. If that is on, tapping submit in the top right of the screen will bring the vet to an Attachment screen page prompting them to browse their iPhone for the appropriate image to upload. Finally, after finding the right image, the vet is taken once again back to the Attachment page, where the vet can hit upload to upload the image and post the question simultaneously. Doing so brings the vet to the new Question-viewing page of the question they just posted.

in-line in-line in-line in-line in-line in-line in-line in-line in-line

Scripts

File:GroupFHiFiScripts.doc

Appendix

Source Code

File:GroupFHiFiSource.zip

Videos of Tasks

Works Cited

Presentation



[add comment]
Personal tools