Cursus feedback

Estafettesysteem

Aanvankelijk stond ik wat sceptisch tegenover het estafettesysteem. Ik verwachte dat dit nooit afgewerkte applicaties zou kunnen opleveren. Achteraf bekeken bleek dit nog wel goed mee te vallen. Toch moet dit wat genuanceerd worden:

• Ik ben nog altijd voorstander van de beslissing om het aantal handovers te reduceren tot één. Het aanleren van een nieuwe technologie gaat altijd gepaard met een aanpassingsperiode van lage productiviteit. In het geval van twee handovers had dit kunnen betekenen dat tegen dat je je ingewerkt had, je al weer moest doorschuiven en misschien amper functionaliteit had kunnen toevoegen aan je applicatie.
• Het estafettesysteem werkt het best als alle teamleden even goed/hard werken. Wanneer iemand minder goed meekan, bestaat het risico dat jij moet verderwerken aan een applicatie die nog niet ver genoeg gevorderd is en dat de ander jouw applicatie ook niet helemaal kan afwerken, waardoor je met twee onvoltooide applicaties zou kunnen blijven zitten. In een systeem van één technologie per persoon zou jouw applicatie dan tenminste nog afgeraakt zijn.

Hoewel de handover noodzakelijk was om het mogelijk te maken om ook eens met een andere technologie te werken, merkte ik toch dat ik het jammer vond dat ik de iOS-applicatie, waarvan ik de basis gelegd had, moest doorgeven en niet zelf mocht afwerken. Ik verlies niet graag de controle over mijn werk.

Positief

• De mogelijkheid gehad om hands on experience met iOS en Android op te doen. Eerste keer dat ik er mee in contact kom, maar had het altijd al eens willen doen. Niet alleen een hot topic tegenwoordig, maar ook handig voor mijn thesis.
• Geen examen, altijd mooi meegenomen.
• Het eindresultaat van dit project is tastbaarder en ‘cooler’ dan pakweg de ontwikkeling van een framework voor berekeningen op grafen. Als je iets deftig gemaakt hebt zou je het zelfs in je portfolio kunnen steken.
• De mogelijkheid gehad om met Google App Engine te leren werken.
• De backendcode die we kregen illustreerde niet alleen hoe de structuur en implementatie van de backend er zou kunnen uitzien, maar was ook direct bruikbaar en nuttig voor in onze applicaties. Zo moesten we niet zelf nog iets schrijven voor het ophalen van tweets en blogposts, maar kregen we direct toegang tot deze data, hetgeen het testen van onze eigen client applicaties ook vereenvoudigde.
• Je wordt eens geconfronteerd met het verderwerken aan code van iemand anders.

Negatief

• Geen examen betekent hoge werklast gedurende het semester, af te raden in combinatie met een groot aantal andere projectvakken en/of thesis
• De les over context in mobiele applicatie was interessant, maar kwam eigenlijk net iets te laat aan bod. Je zat namelijk al zo ver in de implementatie van je applicatie dat je niet meer plots ging beslissen om je idee te herzien en (meer) sensoren te gaan gebruiken.
• Hoewel niet van toepassing op mezelf (ik heb een Mac), is het niet ideaal om voor een vak waarvoor wekelijks ettelijke uren gewerkt moet worden, afhankelijk te zijn van een lokaal met Macs dat maar beperkt toegankelijk is. Tussendoor eventjes thuis/op kot programmeren zit er niet in en wanneer je voornamelijk in de weekends tijd hebt voor multimedia zit je met een probleem. Ook wanneer je ‘s avonds wil werken moet je al zien dat je voor 19u in het lab zit, anders kan je niet meer binnen. Desalniettemin kan je niet rond een Mac heen als je aan iOS-development wil doen.
• Het vak draait voornamelijk rond het programmeren van mobiele applicaties, maar de enige “lessen” die hier aan besteed worden zijn de korte introsessies voor de twee technologieën. Naast deze ‘tutorial’-sessies, kan het misschien ook nuttig zijn een paar lessen te besteden aan het ontwerp van mobiele applicaties in het algemeen of best practices met betrekking tot het ontwerp van de applicatiesoftware en de gebruikersinterface (hoewel dit laatste eigenlijk meer bij een ander vak hoort). Alles zelf moeten uitvissen heeft ergens wel zijn charme, maar het is vervelend als je foute ontwerpkeuzes maakt waar je achteraf aan vastzit.

Cursus feedback

Positieve aspecten:

• Tijdens dit vak heb ik veel bijgeleerd over elk van de technologieën (iOS, HTML5, Android en GAE). Ik heb zelfs bijgeleerd over de technologie die ik niet gebruikt heb (Android), aangezien bepaalde aspecten van deze technologie ter sprake kwamen bij de vergaderingen met het team. Ook door de stukken van het verslag van andere teamleden te lezen, leerde ik wat bij over Android.

• Het doorschuifsysteem is zeer geschikt om de discussie over de technologieën met de teamleden te bevorderen. Na het doorschuiven van je eigen code, is het mogelijk dat je heel wat vragen krijgt, wat een uitstekende manier is om over je eigen design en implementatie na te denken. Ook het ontvangen van iemand zijn code laat toe, om over bepaalde aspecten na te denken, waar je bij het werken in de vorige technologie niet aan gedacht hebt.

• Een ander positief punt is het feit dat de werklast over het semester verdeeld wordt en bijgevolg de blok- en examenperiode lichter is.

Negatieve aspecten:

• Na de eerste weken van de implementatie zou (tussentijdse) feedback moeten gegeven worden op ons design en implementatie. Op deze manier weten we of we goed bezig en of we het design of de implementatie al dan niet moeten bijsturen alvorens een handover te doen.

• Het tweede tussentijdse verslag werd minder in diepgaand besproken als het eerste. Terwijl dit vak zich toch vooral concentreert op het ontwerpen van de structuur en de implementatie van een programma (hetgeen in het tweede verslag aan bod kwam).

Presentations: feedback

Streamy

Presentatie: 5 – Applicatie: 3

Pro:

• Zelfde look en feel over verschillende platformen heen
• App ziet er goed uit!
• Initiële uitleg van het idee achter de applicatie + verzorgde presentatie

Con:

• Inloggen niet mogelijk (mogelijk om met iemand anders zijn naam commentaar te geven)
• Gebuik van cookies i.p.v. datastore voor het bijhouden van gelezen items
• Opslagen en laden van documenten werkt niet

Sint

Presentatie: 1 – Applicatie: 2

Pro:

• Stellen en beantwoorden van vragen + ratings

Con:

• Todo’s verdwijnen na afvinken: kan geen geschiedenis bijhouden van gedane activiteiten

BPToledo

Presentatie: 1 – Applicatie: 1

Pro:

• Linken van google en twitter accounts voor verschillende services in  app.
• In-line comments toevoegen zonder apart pop-up scherm

Con:

• Bugs tijdens de demo lieten een negatieve indruk na

Mediablitz

Presentatie: 2 – Applicatie: 3

Pro:

• Veel functionaliteit: docs, calendar, notifications, communicatie
• Integratie met Google Calendar

Con:

• Met ratings van een vak wordt binnen de applicatie niets gedaan
• Presentatie HTML5 begonnen met het vermelden van een bug, geeft een slechte indruk

MobilEnvy

Presentatie: 1 – Applicatie: 1

Pro:

• Feeds gradueel inladen voor grotere performantie
• Veel functionaliteit.

Con:

• Onverzichtelijke applicatie, aangezien ze veel op 1 scherm proberen te zetten.

Source code

Forgot to add the source code for our applications, so here it is:

iOS Application

HTML5 Application + Google App Engine Backend

Android Application

Final report

Our final report can be found here: Click! (in Dutch!)

Peer review review

Last week we were asked to perform a peer review about our team members by using the peer review grid listed below. Afterwards we discussed these results with our team members.

Peer Review Grid

We think a peer review like this makes it easier to address any problems in the team, since now you’re explicitly asked to evaluate your fellow team members, whereas normally you would perhaps be more reluctant to criticize each other, in order not to ruin the team spirit. A peer review also helps team members to determine and improve their weaknesses. For example in our team we have to improve our communication.

In our opinion the only downside to a peer review is its subjective nature. For example some people received contradictory remarks during the review. Another example could be that a team member does not communicate enough, but does a lot of work. In this case the rest of the team might think that this team member doesn’t put in enough effort. Of course this potential problem could be prevented if an open discussion is kept after the evaluation.

A final remark about the peer review is that it should be executed more regularly / earlier on, so that it is possible to improve your weaknesses during the project.

Context in Mobile Applications

Last Friday, professor Martin Wolpers gave a presentation on context in mobile applications during our Multimedia session. Afterwards, we were asked to reflect on the material presented in this presentation, with respect to our own application.

Context of a typical user

The application is mainly used on campus, when the user is checking in for his course or trying to find out when and where he has to be; or at home, when working on the course. In the latter case, the user can then start timing events which are currently in progress and can communicate with the other participants of a course using connections to social media such as Twitter. The progress of each user is also recorded and is shared with other users in the form of a leaderboard, where a student can measure himself against his colleagues

Context elements

A user can track events, these events contain time, location, individuality and activity context information. The event tracking records the duration of an event and the location of the event. It also represents an activity the user has completed or will complete. Finally, this activity tracking is personal and unique to each individual user.

The leaderboards for each course show the time the user has worked on that course, in comparison to the time spent by the other students. It thus provides relation context information, as it compares the different users. At the same time it also provides time and activity context information, as it shows the time each student has spent on that particular course.

Users can communicate with other users by tweeting, writing blogposts or making discussion posts. These forms of communication contain relation context information, since it creates a dependency between two or more users. It is also related to activity context information, since the communication contains information about the activity this person is involved in.

Most of the previously mentioned context-elements are only used superficially, which means they are just presented as information in our application. The only context information that really affects our application is the activity context information. This activity information is shown to the user as a progress bar and determines the ranking of the user in the leaderboard for a course.

Sensors

Currently, the use of sensors in our application is fairly limited. Hardware sensors other than the touchscreen, such as the accelerometers, gyroscope, GPS, Wifi, microphone, … are not used as input for any of our application’s features. For the stopwatch feature, we use a built-in timer, which is a time tracking sensor. If social networks can be seen as sensors, one could perhaps argue we use Twitter as a sensor, although we merely display the tweets relevant to a course present in our application, and do not change any behaviour depending on the content of a tweet.

When using the stopwatch function to track the time worked on course, the user afterwards has to enter a description of that activity. One of the required pieces of information is the location of that activity. If we use the GPS sensor (possibly assisted with Wifi), we could automatically enter this information, given that we can convert raw geolocation coordinates to a more useful location description (such as an address of the building). We didn’t implement this up until now, because we had put little thought into using sensors when we were looking for an idea for the application. A remark has to be made though: we don’t actually do anything else with the location information other than display it. Nevertheless, we could still try to implement this.

Another sensor we could use, is the microphone. Instead of typing a question, a user could record his question and provide a title. This way it can be show in our list of questions as well. The answers given to these type of questions could be typed or spoken. Allowing this type of communication provides a faster way to ask questions, but there are a few difficulties, which prevent us from using this type of communication:

• Could be difficult to understand questions because of the speaker’s pronunciation
• More difficult to quickly skim through a few questions
• Harder to add links and other media

Second report

You can find our second report here.

First report

You can find our first report here.

New idea, scenario and storyboard

During previous feedback we were told to better integrate social media (like blogs, wikis and Twitter) into our application and to put less focus on purely logical stuff (room, schedule, deadlines…). Hence we decided to redesign our application.

In our previous application we mainly focused on the presentation of events (a combination of an agenda and a TODO list) and how to access the files related to these events. Only as a secondary goal we focused on forum-like communication.

In our new design, we focus on 2 concepts: communication through social media and keeping track of the work you’ve done for a course, combined with gamification. We’ll still provide a way to access a schedule with upcoming events. We did away with the centralized repository for documents. Most courses already have a central hub for professors to distribute documents (e.g. Blackboard/Toledo, wiki’s, etc. ) and extra documents can still be shared by sharing the link to the document in a twitter post.

Scenario

Friday at noon Freddy, wants to know where he has to be for MUME. He opens our application on his smartphone and checks the list of upcoming events (courses, meetings and deadlines). In this list Freddy can find an entry for MUME, describing when and where he has to be. After class he goes back to the application and indicates he has followed the course session.

Saturday morning, Freddy decides to work on MUME. He opens up the application again and sees he has new notifications for MUME. He selects this course and sees a list of all upcoming events related to this course. Next he goes to the communication screen. Here, Freddy can read Twitter messages concerning this course (indicated with the appropriate hashtag), check RSS feeds of blogs and read discussion posts. Now Freddy is up to date, starts a timer using the time tracking feature provided by the app and starts working on the application he has to program for MUME. While programming, Freddy has a question, so he goes back to the communication screen of the course and asks his question. Freddy keeps himself busy and a while later he receives an answer. The answer helped him out with his problem so he upvotes this answer. Freddy programs a little longer and eventually stops the timer. The application asks him to describe the activity he has just done.

Freddy is curious to see how much time and effort he is spending for this course compared to the other students, so he checks the leaderboard. The leaderboard shows a ranking of students based on hours spent or based on points received. A student receives points based on hours spent on this course, questions asked and the rating of given answers.

Storyboard

1) The application starts with the home screen which shows all the courses, with the number of new notifications for that course, and a progress bar showing how much time Freddy has already spent on the course.

Home Screen

2) Freddy goes to the schedule view, by clicking the tab with a calendar icon in the upper right hand side corner, to quickly see all his upcoming events.

Schedule View

3) By clicking on a course in the home screen, Freddy arrives on the time tracking screen. In this screen, the time he spent and the time he has planned to spend are visible in a chronologic list. At the bottom the progress bar is also shown. In this view he can also indicate if he has actually performed these activities, such as gone to class.

Time tracking view

4) Freddy taps on the speech bubble tab, to navigate to the communication screen, where this course’s twitter posts and RSS feeds for the blogs are shown, as well as any questions asked by students.

Communication view

5) Freddy is ready to start working and returns to the time tracking screen, by pressing the stopwatch tab. By clicking on the stopwatch in the bottom left corner, he opens up the timer screen, which he uses to track how long he has worked on his assignment.

Stopwatch view

6) By clicking on the cup, Freddy accesses the leaderboards. The first view is that of the leaderboards where the people with the highest scores, based upon work effort and posing/answering questions, are shown. By selecting the time button at the bottom of the screen, he switches to the leaderboard where the rankings are according to time spent. Here he can also see the average time spent on this course, to get an indication of whether he’s doing good or has fallen behind.

Leaderboard points

Leaderboard hours