New planning

In the presentation I suggested a new planning which was approved by the teachers and advisors, especially because I work in an iterative way, and not a waterfall kind of way.
I will try to keep me to this schedule as best as possible:

• 13/12 - 19/12: evaluation paper prototype iteration 1
• 20/12 - 26/12: paper protoype iteration 2 (with feedback of iteration 1)
• 02/01 - 03/02: exams
• 04/02 - 13/02: getting to know the development software I will work with
• 14/02 - 06/03: implementation iteration 1 (with hardcoded data)
• 07/03 - 13/03: evaluation iteration 1
• 14/03 - 20/03: adjusting iteration 1 (with evaluation feedback)
• 21/03 - 10/04: implementation iteration 2
• 11/04 - 24/04: evaluation iteration 2
• 25/04 - 08/05: final implementation (with evaluation feedback)
• 09/05 - ........: writing report + presentation

Christmas presentation

Last tuesday I had a presentation about the work I have done so far.
The slides of the presentation can be found here.

The feedback and comments and remarks I received from both teachers as other students were really helpfull.
I will explain them a bit more:

• One remark was that I did not explain why I had chosen for this kind of application.
  I will adress this issue by searching for papers that explain the problems that students face on campus, along with results that support the idea of creating this sort of applications, one that (partially) solves these problems.
• Also I need some more and better reasons why I chose for Android OS.
  That is why I will make a deeper comparison between the different mobile OS's in the next couple of weeks, and will make a final decision based on this comparison.
• They pointed out that I have to make sure that students keep using the check-in functionality, otherwise my application will lose a great part of its intended purpose.
  I will look for some kind of reward-system and look at how Foursquare and Waze solve this (both applications were suggested to me after the presentation, although I already have been using, and thereby know Foursquare)
• In my presentation I talked a bit about privacy concerns when integrating with Facebook.
  One solution for this is a so called social network path which limits the number of friends to 50.
• Because I want to display extra information about users (on buddy info page), I will probably have to keep profiles for every user. This will give me a very large database to deal with.
  So either I drop out some unnecessary or either I implement some profile page for every user.
• As a last remark one student said I could be an advantage to have the functionality where you cannot just check in at buildings and classrooms, but also send a request to some buddy to ask him where he is.
  I will consider this in the next couple of weeks, and see whether the persons wich test my paper prototype have the same remark.

Core functionality + planning

After the meeting with prof. Duval I was asked to think about what core functionality I would like to implement in my app, and to have a planning until the end of the year.

Core functionality:

• Display maps of campuses of KUL + google map of Leuven
• Search for buildings and classrooms on these campus maps
• Display or describe the path to buildings/classrooms from user's current position
• Managing a buddy list
• Searching for nearby buddies
• Check in at buildings/classrooms
• Display events from KUL or student associations
• Search for nearby events
• Display news from KUL or student associations
• Search for an available PC (by means of non-booked PC classroom)

Planning:

• December: paper protype (+ evaluation)
• February: implementation of first iteration (maps + buddy list)
• April: adding events, news, available PC functionality
• During entire year: literature study
• May: final report + presentation

Choosing a final direction

About a month ago I had a meeting with prof. Duval to show him my ideas.
This meeting was very interesting since I had some feedback on the ideas.
At the end of the meeting he asked me to make a choice:
Either I should concentrate on creating an app for use in the classroom (answering questions, polls, following presentations and marking or taking notes on slides, ...)
Or I should concentrate on an app for use around the campus (with maps, events, buddy list, ...)

After some thought I decided to go for the second one, because I think this idea lends itself more for use on a smartphone. It will probably make more use of the several features that a smartphone offers (e.g. GPS).
Answering questions, polls are things that are also possible an a simple mobile phone with text messaging.
And taking notes or markings on slides while following a presentation is maybe not the best idea to do on a smartphone, because of the small screen and small keyboard.
This could be done on an iPad, but I really wanted to stick with a smartphone, so I chose to go for the campus app idea.

In the meeting prof. Duval also pointed out some apps that where already available on this part.
iStanford
This is a mobile app for people at the Stanford University.
It can show a map, events, news, videos...
http://mobile.stanford.edu/
iPrinceton
This is a mobile app for people at the Princeton University.
It has much of the same features as iStanford.
http://mobile.princeton.edu/
iTU Delft
This is a mobile app for people at the Delft University of Technology.
It has less features than iStanford and iPrinceton but it has at least the ones interesting for me to look at.
http://www.e-learn.nl/2010/02/01/itu-delft-iphone-app-van-de-tu-delft

iStanford: list of some events at the university

 

iPrinceton: searching a building on the map

Since I would like to implement a buddy list, prof. Duval also advised me to install foursquare on my iPod Touch.
This app uses a check-in system where people can check in at places and manage a buddy list.
I used the app for some time, and I have to say I like the concept.
I will probably handle the buddy list in my app in a similar way (with the ability to check in at campus buildings...)
http://foursquare.com/

foursquare: a place nearby where the user can check in

Using the smartphone on campus: use cases

Use case: Finding the way to a classroom

A student (the user) has trouble finding some classroom he needs to go to. He wants to use his smartphone to show him the way.

• Pre-condition: the user is on the campus and has the app running
• Post-condition: the way to the classroom is shown on the smartphone and he can now follow the indicated path
• Main scenario:

1. The user indicates he wants directions to a classroom by touching the 'find classroom'-icon on his smartphone screen
2. The app asks him to enter the building abbreviation and the classroom number
3. The user inputs the info using the keyboard on the screen
4. The app calculates the shortest path to the classroom and shows it on the map

Use case: Searching for nearby friends/colleagues

A student (the user) wants to see whether there are friends or colleagues in his nearby surroundings.

• Pre-condition: the user is on campus and has the app running, he has some friends/colleagues added to his buddy list (done by some use case to add friends/colleagues)
• Post-condition: nearby friends/colleagues are shown on the smartphone
• Main scenario:

1. The user indicates he wants to look for nearby friends/colleagues by touching the 'buddies'-icon on his smartphone screen
2. The app asks him to enter some extra filter options (name, only friends/colleagues, ...)
3. The user selects and inputs the wanted filter options
4. The app searches for nearby friends/colleagues using this filter options and shows the results on the map
5. The user selects one of his friends/colleagues by touching that person's position on the map on the screen
6. The app gives some extra info about the selected person (name, major, current activity, ...)

Use case: Searching for nearby events

A student (the user) wants to check whether there are current or future events nearby that might be interesting.

• Pre-condition: the user is on campus and has the app running
• Post-condition: nearby current or future events are shown on the smartphone
• Main scenario:

1. The user indicates he wants to look for nearby current or future events by touching the 'events'-icon on his smartphone screen
2. The app asks him to enter some extra filter options (period, location, sort of event, subject ...)
3. The user selects and inputs the wanted filter options
4. The app searches for nearby events using this filter options and shows the results on the screen
5. The user selects one of the events by touching that event on the screen
6. The app gives some extra info about the selected event
7. The user indicates he wants to find the way to the event by touching the 'location'-icon
8. The app calculates the shortest path to the event and shows it on the map

Use case: Finding an available PC

A student (the user) needs a PC to complete some task for school, or maybe just because he has some spare time. He wants to find an available one quickly without having to check every PC classroom.

• Pre-condition: the user is on campus and has the app running
• Post-condition: the available PC's are shown to the user
• Main scenario:

1. The user indicates he wants to find an available PC by touching the 'free PC'-icon on his smartphone screen
2. The app asks him to enter some extra filter options (location, operating system, ...)
3. The user selects and inputs the wanted filter options
4. The app checks all PC's that adhere to the filter options to see whether it's available (no one is logged on or there has been no activity since 15 minutes or so)
5. The app shows a list with available PC's, sorted by location starting with the ones most nearby
6. The user selects a PC by touching it's name on the screen
7. The app shows some info (name, location, operating system(s), reservations for the classroom, ...)
8. The user indicates he wants to find the way to the PC classroom by touching the 'location'-icon
9. The app calculates the shortest path to the PC classroom and shows it on the map

Using the smartphone in class: use cases

Use case: Asking a question

A student (the user) wants to ask a question to the teacher about the course in the classroom. But he is afraid other students will laugh at him, so he asks it using his smartphone.

• Pre-condition: the user is in the classroom and has the app running
• Post-condition: the question is asked and added to the question list which is viewable by the teacher
• Main scenario:

1. The user indicates he wants to ask a question by touching the 'ask question'-icon on his smartphone screen
2. The screen shows a textline and a keyboard
3. He inputs the question about the course using the keyboard on the screen
4. The question is added to the question list

Use case: Answering a question from a colleague

A student (the user) wants to answer some questions of his colleagues.

• Pre-condition: the user is in the classroom and has the app running
  
• Post-condition: the question list is updated (the answered questions are updated with an answer)
• Main scenario

1. The user indicates he wants to see the question list by touching the 'question list'-icon on his smartphone screen
2. The screen shows the question list, all questions asked by the user and his colleagues
3. The user touches the 'answer'-icon next to a question he thinks he knows the answer to
4. The question list is updated
   (Steps 3 and 4 are repeated until there are no questions left the user can answer to)

Use case: Voting on a question

A student (the user) wants to see the question list and vote on questions that he finds are interesting.

• Pre-condition: the user is in the classroom and has the app running
• Post-condition: the question list is updated (all questions the user voted for have received an extra vote)
• Main scenario

1. The user indicates he wants to see the question list by touching the 'question list'-icon on his smartphone screen
2. The screen shows the question list, all questions asked by the user and his colleagues
3. The user touches the 'vote'-icon next to a question he finds interesting
4. The question list is updated
   (Steps 3 and 4 are reapeated until there are no questions left that the user finds interesting)

Use case: Asking a poll to the students

The teacher (the user) wants to start a poll, u multiple-choice question to check whether the students are paying attention and understand the course.

• Pre-condition: the students in the classroom have the app running
• Post-condition: the poll has been asked, and is sent to the smartphones of the students
• Main scenario:

1. The user indicates he wants to start a new poll by touching the 'poll'-icon on his smartphone screen
2. A poll list is seen on the screen of the user
   (It is more likely that the teacher has created these polls at home, rather than having to make them during his lecture. For this there should be an extra use case for creating a poll, or sending a poll from laptop to smartphone for example)
3. The user chooses one of the polls
4. The poll is sent to the students' smartphones

Use case: Answering a poll

A student (the user) wants to answer a poll that is given by the teacher.

• Pre-condition: the user is in the classroom and has the app running
• Post-condition: the user has answered the poll and the poll is updated
• Main scenario:

1. A message pops up indicating that there is a new poll from the teacher
2. The user touches the screen at the message and the poll shows up
3. The user answers the poll by touching the right answer on his screen
4. The choice is sent back to the teachers smartphone and there the poll is updated

Taking notes on slides: use cases

Use case: Taking notes on a slide

A student (the user) wants to take notes relating to the current slide that is shown.

• Pre-condition: the user is in the classroom and is following the presentation of the teacher on his smartphone
• Post-condition: the new notes are stored at the current slide
• Main scenario:

1. The user navigates to the current slide on his smartphone (if this slide wasn't on top yet)
2. He indicates he wants to add extra notes to the slide by touching the screen at the 'add notes'-icon
3. A 'window' pops up in the style of a notebook, along with a keyboard on the screen
4. The user types in the notes using the keyboard on the screen
5. He confirms the notes by touching the 'store notes'-icon
6. The application stores the new notes with the current slide and returns to the slideshow

 Use case: Sharing notes with a colleague

A student (the user) wants to share and exchange notes about some presentation with a colleague.

• Pre-condition: the user and his colleague both have the presentation on their smartphone
• Post-condition: the notes are exchanged so both students have each other's notes along with their own
• Main scenario:

1. The user indicates he wants to share his notes with a colleague by using the 'share notes'-feature of the application
2. His smartphone gives a list of possible presentations to share notes of
3. The user selects a presentation
4. He types in the mobile phone number of his colleague or selects the colleague's smartphone by Bluetooth or Wi-Fi
5. The colleague sees a message whether he wants to share notes on his smartphone and accepts
6. The notes relating to the presentation are exchanged between the smartphones and integrated in the according presentation