donderdag 22 december 2011
maandag 12 december 2011
Paper Prototype
I made a paper prototype to test the user interface and to check how the users feel about the present features in the app. I would like to know whether they think some features are not in the right place there or maybe if they are missing some features they would expect in a mobile version of Toledo.
Here are some photos of part of the paper prototype:
(In total there are about 20 pieces of paper)
After the thesis meeting of today, I will be making some changes to it as suggested by my adviser. So expect a new version later this week.
Of course I can't just sit down with candidate testers and tell them to play around with it, so here is a small evaluation design:
1. Short Introduction
- Introduce myself and my thesis briefly.
- Explain what a paper prototype is and why I made one.
2. Background Check
Ask a little background survey:
- Age?
- Gender?
- Smartphone possession?
- Level of smartphone usage?
- Toledo usage on a smartphone? (regular site)
- Do you feel there is a need for a mobile version?
3. Test Explanation
- Explain the steps of the test.
- Ask them to think out loud.
- Tell them to not hesitate to ask questions or give criticism or suggestions.
4. The Test
- I will tell the testers a small story of a student that wants to use the app that will include a full flow of most of the basic functions the app offers.
1) Locate the next class.
2) Read the latest announcement of that class.
3) Mail to a contact of that class.
4) Check the time of an exam.
During these tasks:
- I will record the test (with the testers permission of course)
- I will count the number of clicks needed for the tasks
- Take note of the path taken to complete each task (if possible)
After the test I will analyse the record and check how many times they asked a question or that I had to help.
5. Free Afterthoughts
Give the tester a chance to openly speak what he thinks of the app.
(I will do this before step 6 so the tester is not influenced by the prepared questions.)
6. Small Survey
- SUS questionnaire (survey for usability)
- Would you use it?
- What features do you think are not necessary
- What features do you feel are missing?
I will try to find at least 5 or 6 candidates for this test during this week, hopefully I can then finish the evaluation in the weekend.
Some comments I already had from my adviser trying the paper prototype:
- Save announcements to a TO-DO list? (native app, Google tasks, ...)
(The same goes for saving classes to Google calendar (or native calendar app)!)
- A share option? (Build in intent in Android, lets you share stuff (like class you
are attending, announcements, etc) through different preinstalled apps, like
Facebook, twitter, sms, ...
- A back arrow? (for iPhone users, Android users have a back hardware button)
- Make it possible to the user to group contacts in different ways.
- Use colors in the next version of the prototype!
Here are some photos of part of the paper prototype:
(In total there are about 20 pieces of paper)
After the thesis meeting of today, I will be making some changes to it as suggested by my adviser. So expect a new version later this week.
Of course I can't just sit down with candidate testers and tell them to play around with it, so here is a small evaluation design:
1. Short Introduction
- Introduce myself and my thesis briefly.
- Explain what a paper prototype is and why I made one.
2. Background Check
Ask a little background survey:
- Age?
- Gender?
- Smartphone possession?
- Level of smartphone usage?
- Toledo usage on a smartphone? (regular site)
- Do you feel there is a need for a mobile version?
3. Test Explanation
- Explain the steps of the test.
- Ask them to think out loud.
- Tell them to not hesitate to ask questions or give criticism or suggestions.
4. The Test
- I will tell the testers a small story of a student that wants to use the app that will include a full flow of most of the basic functions the app offers.
1) Locate the next class.
2) Read the latest announcement of that class.
3) Mail to a contact of that class.
4) Check the time of an exam.
During these tasks:
- I will record the test (with the testers permission of course)
- I will count the number of clicks needed for the tasks
- Take note of the path taken to complete each task (if possible)
After the test I will analyse the record and check how many times they asked a question or that I had to help.
5. Free Afterthoughts
Give the tester a chance to openly speak what he thinks of the app.
(I will do this before step 6 so the tester is not influenced by the prepared questions.)
6. Small Survey
- SUS questionnaire (survey for usability)
- Would you use it?
- What features do you think are not necessary
- What features do you feel are missing?
I will try to find at least 5 or 6 candidates for this test during this week, hopefully I can then finish the evaluation in the weekend.
Some comments I already had from my adviser trying the paper prototype:
- Save announcements to a TO-DO list? (native app, Google tasks, ...)
(The same goes for saving classes to Google calendar (or native calendar app)!)
- A share option? (Build in intent in Android, lets you share stuff (like class you
are attending, announcements, etc) through different preinstalled apps, like
Facebook, twitter, sms, ...
- A back arrow? (for iPhone users, Android users have a back hardware button)
- Make it possible to the user to group contacts in different ways.
- Use colors in the next version of the prototype!
Feature list + required data
The use cases I designed were created from a basic set of features, which I forgot to add on the blog.. So here they are, together with a short description and a set of required data from Toledo:
Schedule:
Students can check their schedule and click on a link to a map which points out the right building. (Maybe even the right room/aula?)
REQ: the courses a students is following. (the schedule per course can be found online)
Announcements:
A feed of all the announcements that concern a certain student. This includes general KULeuven announcements and course-specific announcements.
REQ: announcements feeds.
Contact:
This feature presents a structured list of all the persons or services he or she may want to contact. This includes general KULeuven contacts, department staff, courses contacts, fellow study buddies, emergency numbers, ..
Creating this feature, we will have to try to keep a safe balance between student enabling and staff privacy.
REQ: most of these contacts are publicly available, maybe just the courses contacts are not.
Courses:
The student can check the schedule, announcements and contact info from an individual course. We can maybe later add some other features here like assignments, discussion board, etc.
REQ: nothing more than the reqs for the above features.
Exams:
Students can check where and when they will have exams.
REQ: exam moments data.
Campus Map:
A campus map which all the relevant buildings indicated. An option for this is the OpenStreetMap project.
REQ: none more than the above.
To conclude, I will add a summarized list of the data I would like to have, if possible, access to from the app. After a secure login off course.
- The courses a student is following.
- Announcements feeds of courses
- General KULeuven/department feeds.
- Courses contacts. (mail, office location, phone?)
- Exam moments.
Schedule:
Students can check their schedule and click on a link to a map which points out the right building. (Maybe even the right room/aula?)
REQ: the courses a students is following. (the schedule per course can be found online)
Announcements:
A feed of all the announcements that concern a certain student. This includes general KULeuven announcements and course-specific announcements.
REQ: announcements feeds.
Contact:
This feature presents a structured list of all the persons or services he or she may want to contact. This includes general KULeuven contacts, department staff, courses contacts, fellow study buddies, emergency numbers, ..
Creating this feature, we will have to try to keep a safe balance between student enabling and staff privacy.
REQ: most of these contacts are publicly available, maybe just the courses contacts are not.
Courses:
The student can check the schedule, announcements and contact info from an individual course. We can maybe later add some other features here like assignments, discussion board, etc.
REQ: nothing more than the reqs for the above features.
Exams:
Students can check where and when they will have exams.
REQ: exam moments data.
Campus Map:
A campus map which all the relevant buildings indicated. An option for this is the OpenStreetMap project.
REQ: none more than the above.
To conclude, I will add a summarized list of the data I would like to have, if possible, access to from the app. After a secure login off course.
- The courses a student is following.
- Announcements feeds of courses
- General KULeuven/department feeds.
- Courses contacts. (mail, office location, phone?)
- Exam moments.
vrijdag 9 december 2011
Use Cases
I created 10 use cases I think would be the most significant actions in the app. By actions I mean active use cases, like email a person. Possible "passive" use cases are included in those active ones, an example is to check the schedule: the schedule is listed when you execute the use case Navigate to Class.
Advice and comments are welcome!
USE CASES:
1. Log In
Primary Actor: The user.
Precondition: None.
Basic Flow:
1. Click on application icon.
2. Enter user ID and password, then press "enter".
3. The system comfirms the successful login.
2. Read An Announcement
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Feed View.
2. The system presents a list of the upcoming events and the recent
announcements.
3. The user selects one of the announcements.
4. The system displays the announcement.
Alternative Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Announcements icon.
4. The system displays a list of all the announcements, sorted to
show the most recent first.
5. The user selects one of the announcements.
6. The system displays the announcement.
3. View Course Announcements
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Courses icon.
4. The system displays a list of the available courses.
5. The user selects a course.
6. The system presents different options for that course followed by
a list of the announcements for that course.
4. View Course Contacts
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Courses icon.
4. The system displays a list of the available courses.
5. The user selects a course.
6. The system presents different options for that course followed by
a list of the announcements for that course.
7. The user selects the Contact option.
8. The system presents a list of people that teach this course.
5. View Course Schedule
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Courses icon.
4. The system displays a list of the available courses.
5. The user selects a course.
6. The system presents different options for that course followed by
a list of the announcements for that course.
7. The user selects the Schedule option.
8. The system presents a list of all the class moments for that
course.
6. Email Person
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Contact icon.
4. The system lists all the available contacts. *
5. The user types a part of the name of the target person.
6. The user selects the person.
7. The system shows the Person View of that person, including photo,
email address, office location, ...
8. The user clicks on the email address link.
9. The system will then, if present, open the native email app and
add the contact to the recepients.
10.The user writes his message and sends it.
(* available contacts include contacts from courses, departement heads,
possibly personnal study friends, ...)
7. Navigate to Person
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Contact icon.
4. The system lists all the available contacts.
5. The user types a part of the name of the target person.
6. The user selects the person.
7. The system shows the Person View of that person, including photo,
email address, office location, ...
8. The user clicks on the office location link.
9. The system lists 2 options: "Show on map" and "Navigate".
10.The user selects the first option: "Show on map".
11.The system displays the Campus Map View, focused on the target
building.
Alternative Flow:
10.The user selects the second option: "Navigate".
11.The systems opens, if present, the native navigation app and gives
the target location geo coordinates as argument to it.
8. Navigate to Exam
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Exams icon.
4. The system lists the exams of the upcoming exam period.
5. The user selects an exam.
6. The system shows the Exam View, including a link to the course,
the date and time of the exam, the location, ...
7. The user clicks on the location link.
8. The system lists 2 options: "Show on map" and "Navigate".
9 .The user selects the first option: "Show on map".
10.The system displays the Campus Map View, focused on the target
building.
Alternative Flow:
9 .The user selects the second option: "Navigate".
10.The systems opens, if present, the native navigation app and gives
the target location geo coordinates as argument to it.
9. Navigate to Class
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Feed View.
2. The system presents a list of the upcoming events and the recent
announcements. Every event has a date+time and a location link.
3. The user clicks on the location link of one of the class moments.
4. The system lists 2 options: "Show on map" and "Navigate".
5 .The user selects the first option: "Show on map".
6 .The system displays the Campus Map View, focused on the target
building.
Alternative Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Schedule icon.
4. The system displays a list of all the upcoming class moments.
Every class moment has a date+time and a location link.
5. The user clicks on the location link of one of the class moments.
6. The system lists 2 options: "Show on map" and "Navigate".
7 .The user selects the first option: "Show on map".
8 .The system displays the Campus Map View, focused on the target
building.
Alternative Flow:
7 .The user selects the second option: "Navigate".
8 .The systems opens, if present, the native navigation app and gives
the target location geo coordinates as argument to it.
10. Find Building
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Campus Map icon.
4. The system displays the Campus Map View.
5. The user types the name of the building.
6. The system lists the results of a search for that name.
7. The user chooses one of the results.
8. The systems focuses the Campus Map View on the target building.
Advice and comments are welcome!
USE CASES:
1. Log In
Primary Actor: The user.
Precondition: None.
Basic Flow:
1. Click on application icon.
2. Enter user ID and password, then press "enter".
3. The system comfirms the successful login.
2. Read An Announcement
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Feed View.
2. The system presents a list of the upcoming events and the recent
announcements.
3. The user selects one of the announcements.
4. The system displays the announcement.
Alternative Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Announcements icon.
4. The system displays a list of all the announcements, sorted to
show the most recent first.
5. The user selects one of the announcements.
6. The system displays the announcement.
3. View Course Announcements
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Courses icon.
4. The system displays a list of the available courses.
5. The user selects a course.
6. The system presents different options for that course followed by
a list of the announcements for that course.
4. View Course Contacts
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Courses icon.
4. The system displays a list of the available courses.
5. The user selects a course.
6. The system presents different options for that course followed by
a list of the announcements for that course.
7. The user selects the Contact option.
8. The system presents a list of people that teach this course.
5. View Course Schedule
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Courses icon.
4. The system displays a list of the available courses.
5. The user selects a course.
6. The system presents different options for that course followed by
a list of the announcements for that course.
7. The user selects the Schedule option.
8. The system presents a list of all the class moments for that
course.
6. Email Person
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Contact icon.
4. The system lists all the available contacts. *
5. The user types a part of the name of the target person.
6. The user selects the person.
7. The system shows the Person View of that person, including photo,
email address, office location, ...
8. The user clicks on the email address link.
9. The system will then, if present, open the native email app and
add the contact to the recepients.
10.The user writes his message and sends it.
(* available contacts include contacts from courses, departement heads,
possibly personnal study friends, ...)
7. Navigate to Person
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Contact icon.
4. The system lists all the available contacts.
5. The user types a part of the name of the target person.
6. The user selects the person.
7. The system shows the Person View of that person, including photo,
email address, office location, ...
8. The user clicks on the office location link.
9. The system lists 2 options: "Show on map" and "Navigate".
10.The user selects the first option: "Show on map".
11.The system displays the Campus Map View, focused on the target
building.
Alternative Flow:
10.The user selects the second option: "Navigate".
11.The systems opens, if present, the native navigation app and gives
the target location geo coordinates as argument to it.
8. Navigate to Exam
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Exams icon.
4. The system lists the exams of the upcoming exam period.
5. The user selects an exam.
6. The system shows the Exam View, including a link to the course,
the date and time of the exam, the location, ...
7. The user clicks on the location link.
8. The system lists 2 options: "Show on map" and "Navigate".
9 .The user selects the first option: "Show on map".
10.The system displays the Campus Map View, focused on the target
building.
Alternative Flow:
9 .The user selects the second option: "Navigate".
10.The systems opens, if present, the native navigation app and gives
the target location geo coordinates as argument to it.
9. Navigate to Class
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Feed View.
2. The system presents a list of the upcoming events and the recent
announcements. Every event has a date+time and a location link.
3. The user clicks on the location link of one of the class moments.
4. The system lists 2 options: "Show on map" and "Navigate".
5 .The user selects the first option: "Show on map".
6 .The system displays the Campus Map View, focused on the target
building.
Alternative Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Schedule icon.
4. The system displays a list of all the upcoming class moments.
Every class moment has a date+time and a location link.
5. The user clicks on the location link of one of the class moments.
6. The system lists 2 options: "Show on map" and "Navigate".
7 .The user selects the first option: "Show on map".
8 .The system displays the Campus Map View, focused on the target
building.
Alternative Flow:
7 .The user selects the second option: "Navigate".
8 .The systems opens, if present, the native navigation app and gives
the target location geo coordinates as argument to it.
10. Find Building
Primary Actor: The user.
Precondition: User is logged in.
Basic Flow:
1. The user goes to the Home View.
2. The system presents the Home View with icons leading to different
parts of the application.
3. The user clicks on the Campus Map icon.
4. The system displays the Campus Map View.
5. The user types the name of the building.
6. The system lists the results of a search for that name.
7. The user chooses one of the results.
8. The systems focuses the Campus Map View on the target building.
Campus map
Small research while working on the use cases: what maps recourse to use for a campus map? (that has to include buildings etc)
Tried Google StreetView, but no luck near campus buildings. A nice alternative is the open and free project OpenStreetMap .
Will investigate possible mobile integration later!
Tried Google StreetView, but no luck near campus buildings. A nice alternative is the open and free project OpenStreetMap .
Will investigate possible mobile integration later!
Abonneren op:
Posts (Atom)