• Specify the platform and software requirements for your prototype.
  • Give brief, step-by-step instructions for starting up your prototype. A URL will most likely be sufficient. All Athena users have a Public directory which is accessible by the URL http://web.mit.edu.ezproxy.canberra.edu.au/_username_/Public/.
  • Describe which parts of the prototype are shallow (incompletely implemented or canned), so that your evaluators know what should work and what shouldn't.
  • Your prototype must remain frozen (no changes) and accessible at the URL you provide for two weeks after the due date.

Application requirements:

There are two parts of this project: the app website is design for smartphones and the website is design for computers. We implemented our both parts of the designs on webpages for the purpose for convenience.

The app website is designed for the patients; the website is design for the doctors.

Application requirement:

Mac OS: Chrome, Firefox

WIndows: Firefox

Instructions to access the prototype:

The link for the phone app design:  http://web.mit.edu.ezproxy.canberra.edu.au/ylwu/www/src/patient_log_in.html

The link for the website design:  http://web.mit.edu.ezproxy.canberra.edu.au/ylwu/www/src/doctor_login.html

Features that are partially implemented:

Doctor Webpage:

  1. Always logging in as Dr. John Williams from login page
  2. Creating new doctor account will ignore user input and log in as Dr. John Williams
  3. The chatting history will always show chat with Amy Fox
  4. The missed drug calendar on patient’s page is not live and the calendar name is always drugA
  5. Deleting, adding or editing patient on addPatient page will not have global effect on other pages
  6. Deleting, adding or editing drugs on addDrug page will not have global effect on other pages. Deleting drug will have no local effect

Patient Phone App Webpage:

  1. The history page is static not dynamic.
  2. Actions with the pill (check a drug a press “take” or “miss”) will only remove the pill from the interface, not the actual database, so if you take a pill, edit a drug and go back to the home page, the drug will reappear.
  3. Deleting drug will not delete the drug events right away, however, after refreshing, the events will disappear.
  4. The time is static on the page
  5. No permanent database implemented, therefore you cannot edit any medication but you can add new pills. 
  6. When you add new pills, you can submit your input, but the general information will not show up to the next page. Cycle selection does not work.
  7. No matter what you enter for the log in page, when you click on log in, it will take you to the main page. When you click on sign up, it will take you to the sign up page.
  8. For the sign up page, what you enter will not affect the response of the button. If you click on log in, it will take you back to the log in page. And if you click on sign up, it will take you to the main page.
  9. When you click on “Contact Doctor” button, it will take you to the page where there is a list of doctors. But only the first doctor is clickable. When you click on the first doctor, it will take you to the message box page.
  10. On the message page with the doctor, you are able to submit messages to the doctor, but you will not get any response from the doctor.
  • No labels

5 Comments

  1. Unknown User (findley@mit.edu)

  2. Unknown User (summit@mit.edu)

    Here you go! Feel free to email or talk to me if you feel like I didn't explain something well!

    TakeYourPillsHeuristicEvaluation.pdf

  3. Unknown User (hlwalker@mit.edu)

    I tried to explain everything clearly. If I didn't, feel free to contact me.

    Heuristic Evaluation.pdf

  4. Wiki presentation: - Good job with the level of detail that you guys went into talking about what's been fully/partially implemented. Next time, also differentiate by whether it's lacking in breadth/depth.

    Fidelity: - Add Patient should really not have the 'Delete Patient' button.
    '- I think your overall implementation is really good, you have covered a good breadth of features and they really outline the important features of your system.
    ' The chat system, though in a prototype phase, is very well done
    '- Not really sure what Edit Pills does?.

    Usability: - In the 'Add Patient' dialog for the doctors, the Delete Patient, Clear Form and Save look too similar. Either move them further apart, and/or give them visually distinct looking buttons. This will help improve the Safety of your application, and reduce the likelihood of a doctor clearing/deleting a patient without meaning to.
    '- For external consistency, you should make it such that clicking on the Take Your Pills logo in the top left hand corner brings you back home.
    '- For many of your windows/screens, there is no way to recovery except by using the browser's back button. Be very careful of this, as different browsers react differently to resending/caching of data.
    ' Using check boxes for an important task like taking/missing pills seems like not a good idea. Perhaps make the check boxes bigger, or make it such that touching the row brings up the dialog for taking/missing.
    '- I think "See more pills" feels a little weird. Why hide the pills until the user clicks on that. Maybe just use a scrollable list?
    '- Good use of the colors to represent that a pill is overdue. THough you might want to use something more obvious (like the text LATE). Just imagine if Stellar only used colors and not the word "LATE!". This is a better visual variable.

  5. Unknown User (kamkha@mit.edu)

    Awesome prototype, guys! My HW2 evaluation is attached; let me know if you have any questions.

    HW2_Take_Your_Pills_Kamran_Khan.pdf