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!
woensdag 23 november 2011
Blackboard Mobile SDK
Beside their own Learn app, Blackboard also offers a Blackboard Mobile SDK solution. With this universities can create their own app based on the underlying Blackboard services. This is most certainly sometime to keep in mind when I will create my own app. I have tried to find out how to get this SDK, but so far the only option seems to ask for more information. I guess they will need official licensing from the university. So before I send an email, I will finish my evaluation of the other university apps.
Because of this approach, the biggest part of the available university apps on the Android market are of this kind: apps powered by Blackboard with a link to the Learn app. Aside from that, they all offer their own choice of functions, like campus maps, sports schedules and scores etc.
Because of this approach, the biggest part of the available university apps on the Android market are of this kind: apps powered by Blackboard with a link to the Learn app. Aside from that, they all offer their own choice of functions, like campus maps, sports schedules and scores etc.
woensdag 9 november 2011
Survey
I didn't have much time for my thesis these last few weeks, hence this is the first post in a little while.. (Due to moving, student job, some personal stuff)
I have created a little survey about the possible functions that a mobile version of Toledo should offer. You can find this survey here.
I will try to get as many responses as I can and after that I will post a complete summary of them.
I have created a little survey about the possible functions that a mobile version of Toledo should offer. You can find this survey here.
I will try to get as many responses as I can and after that I will post a complete summary of them.
dinsdag 18 oktober 2011
Planning
19/10 : Brainstorm possible features + questionary
26/10 : Finish questionary, summarize results
26/10 : Start design web app
29/10 : Start writing code for web app
02/11 : Finish first iteration of web app
04/11 : First report
05/11 : Start design native app
08/11 : Start writing code for native app
16/11 : Finish first iteration of native app
17/11 : Start first serie of user tests
23/11 : Evaluate the results and start redesign both apps
31/12 : First presentation + deadline second iteration both apps
20/02 : End second evaluation
24/02 : Scientific article + start writing code for third iteration
30/03 : Second report + second presentation
11/04 : Deadline third iteration both apps (No more coding!)
18/04 : End third and final evaluation
27/04 : Poster
18/05 : Finish complete draft
08/06 : Ultimate deadline!
26/10 : Finish questionary, summarize results
26/10 : Start design web app
29/10 : Start writing code for web app
02/11 : Finish first iteration of web app
04/11 : First report
05/11 : Start design native app
08/11 : Start writing code for native app
16/11 : Finish first iteration of native app
17/11 : Start first serie of user tests
23/11 : Evaluate the results and start redesign both apps
31/12 : First presentation + deadline second iteration both apps
20/02 : End second evaluation
24/02 : Scientific article + start writing code for third iteration
30/03 : Second report + second presentation
11/04 : Deadline third iteration both apps (No more coding!)
18/04 : End third and final evaluation
27/04 : Poster
18/05 : Finish complete draft
08/06 : Ultimate deadline!
Small summary
The main goal of my Thesis is to create a usable interface of Toledo for mobile users, or the lay the foundations for one. And I would like to create this interface in 2 different versions, one as a mobile web page, the other as a native app on a mobile operating system (Android or iOS). Doing this, will show us the opportunities both methods offer. The main advantages of a mobile web page are its massive user reach and instant adaptability. Whereas the native app will have the support of all the native options the smartphone platforms offer these days. For example, calendar and mail integration, file managers, etc.
As for the functions of the web/native app, I would try to keep them as simple as possible. Only the functions that people need or want when the use their smartphone to interact with Toledo will be included. This means there will be no social or fun additions. To find out what the users want from this interface, I will first ask them. To do this, I have a 2 step questionary in mind, first ask them what they would use a mobile Toledo for, and what do would expect from a native app. In the second step I would offer them a listen of functions I came up with it, so they can give those functions a score of how useful they think those functions would be.
After we have formed a core set of functions that users would require, we can start the design and implementation. For this I hope to get the support from the people who administrate Toledo. So we can make a web page and app that users can really use. I've heard some good and bad news about this. The good news being that the guys from Toledo would offer me some help with the API. The bad news is that they don't administrate all the functions of Toledo, a (big?) part of those are under control of the SAP team, who are more reluctant to give access to those features.
After we have a working interface, we can start to evaluate it by a serie of user tests.
As for the functions of the web/native app, I would try to keep them as simple as possible. Only the functions that people need or want when the use their smartphone to interact with Toledo will be included. This means there will be no social or fun additions. To find out what the users want from this interface, I will first ask them. To do this, I have a 2 step questionary in mind, first ask them what they would use a mobile Toledo for, and what do would expect from a native app. In the second step I would offer them a listen of functions I came up with it, so they can give those functions a score of how useful they think those functions would be.
After we have formed a core set of functions that users would require, we can start the design and implementation. For this I hope to get the support from the people who administrate Toledo. So we can make a web page and app that users can really use. I've heard some good and bad news about this. The good news being that the guys from Toledo would offer me some help with the API. The bad news is that they don't administrate all the functions of Toledo, a (big?) part of those are under control of the SAP team, who are more reluctant to give access to those features.
After we have a working interface, we can start to evaluate it by a serie of user tests.
donderdag 13 oktober 2011
Introduction
Hello, I am Tom Crauwels, a master student of the department Computer Science at the KULeuven.
On this blog I will post updates about my master thesis, which is part of the research group Human Computer Interaction of professor Erik Duval.
The subject of my master thesis is a mobile version of the digital learning environment Toledo (Blackboard).
Abonneren op:
Posts (Atom)