A new planning for my thesis:
I'll generally try to work in weeks of thursday to thursday :
Week -6
Tue 27/03 to Sun 01/04 : Presentation + Thesis Chapter 2 - Literature Study
Tue 27/03 to Thu 05/04 : User tests + Evaluation
Sun 01/04 to Thu 19/04 : Google (Android) Integration
Sun 01/04 to Thu 26/04 : Complete Toledo Data Access
Week -5
Thu 05/04 to Thu 12/04 : Thesis Chapter 1 - Introduction
Week -4
Thu 12/04 to Thu 19/04 : Thesis Chapter 3 - Analysis
Week -3
Thu 19/04 to Thu 26/04 : Poster + Final user tests and evaluation
Week -2
Thu 26/04 to Thu 03/05 : Thesis Chapter 4 - Design
Week -1
Thu 03/05 to Thu 10/05 : Thesis Chapter 5 - Implementation
Week 0
Thu 10/05 to Thu 17/05 : Thesis Chapter 6 - Conclusion
I know that this looks optimistic, but I rather aim for the June deadline and miss it only to be well on the way for the August deadline, than aim for the August deadline and miss that one.
woensdag 28 maart 2012
zaterdag 25 februari 2012
woensdag 11 januari 2012
Implementation
While working on the first phase of my implementation (the UI part), I came up with a list of integration ideas:
- Save contacts to phone
- Add class / office locations to favorites
- Mail integration
- Add event to calendar
- Add whole schedule to calendar
- Add announcement as task
- Add exam to calendar
- Notifications for events / schedule
- Share! (events you are attending, new announcements, ...)
Then I also have to think how I would like to implement these options:
- Campus map: Google maps? openstreetmap? How to link to class locations?
In building navigation?
- Discussion boards (or some other form of communication between students and staff)
All of will be part of the second phase of my implementation. So expect to see solutions in the next few weeks :)
- Save contacts to phone
- Add class / office locations to favorites
- Mail integration
- Add event to calendar
- Add whole schedule to calendar
- Add announcement as task
- Add exam to calendar
- Notifications for events / schedule
- Share! (events you are attending, new announcements, ...)
Then I also have to think how I would like to implement these options:
- Campus map: Google maps? openstreetmap? How to link to class locations?
In building navigation?
- Discussion boards (or some other form of communication between students and staff)
All of will be part of the second phase of my implementation. So expect to see solutions in the next few weeks :)
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.
Abonneren op:
Posts (Atom)