Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

...

Doctor

Final Design

Description

 

Image Removed

This is the doctor's patients page that lists out all the connected patients. This page can be accessed through the navigation bar at top of the page.

Image Removed

 

Image Removed

 

Image Removed

 

Implementation

Our interface frontend was implemented using HTML, Javascript, JQuery, and CSS. The patient app is especially unique in that most of it is dynamically generated which makes it very flexible in responding in real time to user actions (ie manage pills list, and drug events list). Only the top navigation bar is hard-coded. The doctor website also makes great use of twitter bootstrap so it looks a lot nicer and simple yet professional.

For the patient app, we worked really hard on the backend and I believe that our functionality is pretty solid. We used .json files to store patient, pill, drug events, and messages data. JQuery had a very easy read .json function and was really fast. Unfortunately, writing to .json files required some php work, and we quickly discovered that writing to .json is a lot slower than reading from .json. This especially was a problem when we wanted to write updated data to .json files and immediately read from .json to update visibly for the user. Because writing was a lot slower, reading would pull the old data before PHP had a chance to update the file.

We solved this problem by creating a JS object which would be synced with the data in the .json files on document.ready. Saving any data involves updating the JS object as well as the corresponding .json file. Thus, we can read from the JS object (since adding to the JS object is comparably fast), while our data still generally persists across multiple sessions (ie you can close the browser and re-login to our application) since it is written to the .json file as well.

The .json files also function as a shared database for both the patient and doctor app, so both patient and doctor can share messages as well as see the pills and missed drug events recorded by our synced 2-app system. The patient has a history list style for taken and missed drug events. The doctor will only see missed drug events but displayed on a calendar interface, since real doctors will have multiple patients and really only care about patients missing their drugs.

Evaluation

Briefing

Patient:

You are a patient taking several drugs at different times of the day but sometimes you forget about them.. You want to keep track and be reminded to take them correctly by using this mobile app.

Doctor:

You want to hear immediate feedback from your patients about their medications. The doctor version of Take Your Pills allow you to communicate with your patients and check if they have

Scenario Tasks

Patient:

    You are Amy Fox.

  • You want to add Tylenol to your medications. You take 2 pills of Tylenol everyday at 2PM and 6PM, starting from today to end of July.
  • You want to add cough syrup to your medications. You take 1 spoon of syrup every 5 hours starting from now to end of June.
  • You realized that you actually made a mistake about Claritin. You want to remove it from your medications.
  • You want to take pain killer three times a day instead of two. You add a time 12:00pm for painkiller.
  • You missed your pain killer that you were supposed to take at 7am. Record the miss.
  • You took aspirin. Record the take.
  • You are having a headache for no reason. You are not sure if this is related to any medicine that you are taking. You want to contact your doctor.

Doctor:

    You are Dr. Williams

  • Check if there are any new notes from your patients.
  • It seems that your patient Amy is having a headache. You want to check her medication history especially that of painkiller for this week.
  • You think Amy is having her headache because she missed painkiller. You want to tell her about it.
  • You want Amy to take ibuprofen instead of painkiller. You remove painkiller from user’s drug list and add ibuprofen starting from today to end of May, 2 pills, every four hours.
USER #1 (patient)
  • The user started on the home page of the patient app. When asked to add a new pill, she was confused by and did not immediately understand that the rows on the home page were drug events. She saw "Manage Pills" but did not feel like it was something to go to to add a new pill. She thought maybe she was not on the home page so clicked on the top home button a few times (which did nothing since she was indeed on the home page..). She said she clicked on the home page hoping that the home page would give her a more high-level idea of how to use the app.** CATASTROPHIC: she did not know what page she was on. The app did not give her feedback at all.** MAJOR: "Manage Pills" did not convey what we wanted to convey. This naming issue has persisted since the first user prototypes where we tried "My Pills" and "Edit Pills" but always had some feedback with user confusion on what that encompasses.
  • When trying to remove a pill from the manage pills page, she clicked on the pill's button only to realize that it was to edit that pill. When she returned to the manage pills page, then she discovered the "-" button next to that pill and deleted it correctly.** MINOR: Maybe we should color the button (say bright red) so that the delete button is more intuitive and stand-out.
  • User finally realized that the home page of the app contained drug events and that the app functions as a record for when she indicates (with selecting a drug event and pressing whether she "took" or "missed" the pill).** MAJOR/CATASTROPHIC: Our app layout for the home page does not seem intuitive. Perhaps we could have a clearer date and time indication, to emphasize a take-your-medications EVENT as opposed to what seems like a list of pills and some info displayed?
USER #2 (doctor)
  • The user went to a patient's calendar page. When asked to delete a patient's pill, the user tried to click on the pill on the left column (the calendar then showed missed dates of that specific pill). Then the user tried clicking on the missed date purple bar that showed up in the calendar. The user finally sees the buttons at the top of the page, with "manage/edit patient's pills."
    • MINOR: Those top buttons might need to stand out more.
  • When updating an existing pill, the user feedback that says "pill updated" was in color red, so user was at first alarmed thinking that she might have accidentally deleted it, because previously when deleting a pill, a red user feedback said "pill deleted."** MINOR: Color "pill updated" differently, not red. Maybe green? or blue?
  • User would have liked the send button on the messages page to be able to work via pressing "enter."** MINOR: Consistent functionality with other standard UI's.
  • User was confused why when adding a new pill, the info did not show up in the calendar. User did not realize that the calendar only showed missed drug events.** MAJOR: Our interface does not clearly or intuitively indicate the functionality we wanted to share with users.

page that will first show up after the doctor logged in. This page displays all the message history from patients and allows doctors to send messages back to patients. Doctor can read messages from different patients by switching the tabs on the left. Unread messages will be shaded in a darker gray than rest of the messages.

Design decision:
The design for this page has not changed much since our original design. Because our main purpose for this website is to allow doctors to receive immediate feedback from patients, we decided it’s most important to show the messages first after doctors log in. In our final implementation, we added in the new shading for unread messages and also the new message counter in the navigation bar to provide more feedback to the users.

Image Added

This is the doctor's page that lists out all the connected patients. This page can be accessed through the navigation bar at top of the page. Users can add new patient on this page or click a patient’s name to access the patient’s personal pill history page.

Design decision:
In our original design, there is no page that showed a list of patients. Instead, the navigation bar presents an “Add patient” tab that leads directly to adding a new patient. The only way that doctors can access a patient’s personal pill history page is by searching the patient’s name in the search bar. In our user testing, many users found this to be very unintuitive and had trouble finding patients’ pages. Therefore, we decided to create this page to list out all the patients.

Image Added

This is a patient’s pill history page that shows all the missed pill events in a dynamic calendar. Doctors can look at a particular pill or all the pills at once. A summary of the missed events is also listed on the right of the calendar in text format to provide more details. Doctors can also go to pages where they can edit patient info and manage patient pill through this page.

Design decision:
This page originally only shows information related to missed pills. In our user testing, some users suggested that they should also be allowed to go to patient editing and pill managing pills from this page for easier navigation. This page almost became the patient’s personal page where every functionality related to that patient can be accessed through this page.

Image Added

This is the page where doctors can manage a patient’s pills. Doctors can add, edit or delete a pill on this page and all pill information is synchronized between the patient’s mobile app and the doctor’s website.

Design decision:
The design for this page has not changed since the original design. It’s important for the doctors to be able to access and manage the patients’ pill information. This also allows doctors to help patients who are not very familiar with technology to enter their pill information.

Image Added

This is the page where doctors can edit and disconnect from a patient.

Design decision:
We wanted the doctor to be able to record a patient’s medication and health history somewhere. The only field that the doctor cannot change is the email which serves as the account name or ID for the mobile app.

Implementation

Our interface frontend was implemented using HTML, Javascript, JQuery, and CSS. The patient app is especially unique in that most of it is dynamically generated which makes it very flexible in responding in real time to user actions (ie manage pills list, and drug events list). Only the top navigation bar is hard-coded. The doctor website also makes great use of twitter bootstrap so it looks a lot nicer and simple yet professional.

For the patient app, we worked really hard on the backend and I believe that our functionality is pretty solid. We used .json files to store patient, pill, drug events, and messages data. JQuery had a very easy read .json function and was really fast. Unfortunately, writing to .json files required some php work, and we quickly discovered that writing to .json is a lot slower than reading from .json. This especially was a problem when we wanted to write updated data to .json files and immediately read from .json to update visibly for the user. Because writing was a lot slower, reading would pull the old data before PHP had a chance to update the file.

We solved this problem by creating a JS object which would be synced with the data in the .json files on document.ready. Saving any data involves updating the JS object as well as the corresponding .json file. Thus, we can read from the JS object (since adding to the JS object is comparably fast), while our data still generally persists across multiple sessions (ie you can close the browser and re-login to our application) since it is written to the .json file as well.

The .json files also function as a shared database for both the patient and doctor app, so both patient and doctor can share messages as well as see the pills and missed drug events recorded by our synced 2-app system. The patient has a history list style for taken and missed drug events. The doctor will only see missed drug events but displayed on a calendar interface, since real doctors will have multiple patients and really only care about patients missing their drugs.

Evaluation

Briefing

Patient:

You are a patient taking several drugs at different times of the day but sometimes you forget about them.. You want to keep track and be reminded to take them correctly by using this mobile app.

Doctor:

You want to hear immediate feedback from your patients about their medications. The doctor version of Take Your Pills allow you to communicate with your patients and check if they have

Scenario Tasks

Patient:

    You are Amy Fox.

  • You want to add Tylenol to your medications. You take 2 pills of Tylenol everyday at 2PM and 6PM, starting from today to end of July.
  • You want to add cough syrup to your medications. You take 1 spoon of syrup every 5 hours starting from now to end of June.
  • You realized that you actually made a mistake about Claritin. You want to remove it from your medications.
  • You want to take pain killer three times a day instead of two. You add a time 12:00pm for painkiller.
  • You missed your pain killer that you were supposed to take at 7am. Record the miss.
  • You took aspirin. Record the take.
  • You are having a headache for no reason. You are not sure if this is related to any medicine that you are taking. You want to contact your doctor.

Doctor:

    You are Dr. Williams

  • Check if there are any new notes from your patients.
  • It seems that your patient Amy is having a headache. You want to check her medication history especially that of painkiller for this week.
  • You think Amy is having her headache because she missed painkiller. You want to tell her about it.
  • You want Amy to take ibuprofen instead of painkiller. You remove painkiller from user’s drug list and add ibuprofen starting from today to end of May, 2 pills, every four hours.
USER #1 (patient)
  • The user started on the home page of the patient app. When asked to add a new pill, she was confused by and did not immediately understand that the rows on the home page were drug events. She saw "Manage Pills" but did not feel like it was something to go to to add a new pill. She thought maybe she was not on the home page so clicked on the top home button a few times (which did nothing since she was indeed on the home page..). She said she clicked on the home page hoping that the home page would give her a more high-level idea of how to use the app.** CATASTROPHIC: she did not know what page she was on. The app did not give her feedback at all.** MAJOR: "Manage Pills" did not convey what we wanted to convey. This naming issue has persisted since the first user prototypes where we tried "My Pills" and "Edit Pills" but always had some feedback with user confusion on what that encompasses.
  • When trying to remove a pill from the manage pills page, she clicked on the pill's button only to realize that it was to edit that pill. When she returned to the manage pills page, then she discovered the "-" button next to that pill and deleted it correctly.**  MINOR: Maybe we should color the button (say bright red) so that the delete button is more intuitive and stand-out.
  • User finally realized that the home page of the app contained drug events and that the app functions as a record for when she indicates (with selecting a drug event and pressing whether she "took" or "missed" the pill).** MAJOR/CATASTROPHIC: Our app layout for the home page does not seem intuitive. Perhaps we could have a clearer date and time indication, to emphasize a take-your-medications EVENT as opposed to what seems like a list of pills and some info displayed?
USER #2 (doctor)
  • The user went to a patient's calendar page. When asked to delete a patient's pill, the user tried to click on the pill on the left column (the calendar then showed missed dates of that specific pill). Then the user tried clicking on the missed date purple bar that showed up in the calendar. The user finally sees the buttons at the top of the page, with "manage/edit patient's pills."
    • MINOR: Those top buttons might need to stand out more.
  • When updating an existing pill, the user feedback that says "pill updated" was in color red, so user was at first alarmed thinking that she might have accidentally deleted it, because previously when deleting a pill, a red user feedback said "pill deleted."** MINOR: Color "pill updated" differently, not red. Maybe green? or blue?
  • User would have liked the send button on the messages page to be able to work via pressing "enter."**  MINOR: Consistent functionality with other standard UI's.
  • User was confused why when adding a new pill, the info did not show up in the calendar. User did not realize that the calendar only showed missed drug events.**  MAJOR: Our interface does not clearly or intuitively indicate the functionality we wanted to share with users.
  • User would have liked to see some info of each drug on the calendar page.** (just a suggestion for additional features)
USER #3 (doctor)
  • When the user was on the message page, she was asked to check the patient's pill history. She went to the page by clicking the "Patient" tab on the navigation bar. The user didn't realize that the patient's name in the message page is actually clickable and will lead to the patient's pill history page directly.
    • COSMETIC: The patient's name on the message page doesn't provide enough affordance to show that it is clickable.
  • Clicked the edit patient button first instead of manage pill button to delete a pill for the patient.
    • MINOR: It could've been that the two buttons are placed too close together or the wording of the button was confusing so that the user thought she can manage the patient's pill in the patient's information page.
USER #4 (patient)
  • When the patient was trying to add 2 new pills, instead of inputing "2," he input "2 pills"
    • MINOR: we could have put "pills" after the form, so the user know not to put any unit for it
  • When the patient was first navigating round the app, he accidentally clicked on the delete button that would delete the pill and he didn't realize it was a delete button
    • COSMETIC: Choose icon or use word for the delete button.
    User would have liked to see some info of each drug on the calendar page.** (just a suggestion for additional features)

Reflection

Our group spent a lot of time and effort designing the look of the user interface and really went into the details of the app. How should a user take a drug? How should the user design a drug? How many messages should the user be allowed to send to the doctor everyday? These are the questions we spend a long time discussing but I think it's worth the time to do it, because those are the key decisions to make for a good user interface.

...