Archive | november 2013

Digitizing mock-ups

I started digitizing the mock-ups, not all of the screens have been digitized yet.
Also the EMR in the home screen isn’t supposed to be there, it’s there for demonstration purposes only and will be removed later.
Don’t mind the color scheme, I haven’t given it any thought yet, but later on I will try to provide a nice looking GUI.

http://www.youtube.com/watch?v=Sy1JRJne4ys&feature=youtu.be

Scale of Usability

This week we finished up the mock-ups and started asking potential users to perform some tasks and fill in a scale of usability. The main results were good no real changes will have to be made to the application. The only thing that was confusing for the users was the term “Events”, when I asked to show me CPR courses in their neighbourhood some of the users went looking under Information instead of Events. So I asked if it would be better to change that to “Courses and Session” and they agreed that would be a more suited term. Below you’ll find a link with the pdf of the scans with mock-ups and some of the forms filled in by the users.

Besides that I have started to make some of the screens in Xcode using storyboards. This would be a nice start for the application later but also a nice demo to show at the presentation I have coming up in December. Perhaps when it is done, I’ll show make a video of it and post it here as well.

Mockups and users Evaluation

Next step with mockups

This week we’re going to finish the mockups and start evaluating them. We are going to evaluate them by using the System Usability Scale and invite 10 random people to perform some tasks. For example give them the application and ask them to find the legal document or to look at AED locations near them. Another important task will be what to do if an emergency notifications arrives. These 10 random people will have to represent the general population of users. So we won’t be asking fellow computer science students to perform those tasks. Because let’s face it, computer scientists have a lot of experience using applications and finding the information they need. Off course it also wouldn’t be appropriate to evaluate this application by asking users who don’t have any experience at all with the use of a smartphone, hence this application is built for one. My parents for example would be good guinea pigs to evaluate the application, they are in their fifties have an Android phone and an iPad but aren’t very experienced with computers and using applications. But I will evaluate the mockups on other people as well and of different ages. After we have done that, we can maybe improve the application and make some alterations to the design.

Furthermore I have looked at the code from the German project group. But it’s hard to understand what they were trying to do. I can’t import their project, there is no .apk file to install the Android application onto my device. Also weird name giving in the code, and lots of files and packages don’t make it any easier understanding their work method. At first glance I got the impression they worked with Sockets. I will ask them why, because at the moment I don’t see any need to have bidirectional communication between server and device. Once the server has sent out a notification to the devices, is there any need for the server to ask the client for information? Why not just let the client contact the server afterwards via REST and update its GPS location? And when there is no emergency going on and the client just needs to update his location at certain time intervals, again why does the server want to contact the client? My mentor has a meeting with the German project team, I hope I will get answers on why they did it this way and not to choose for a simpler approach. 

Requirements and Distance

Hence my thesis will be in English my mentor asked if I would write my blog posts in English as well. So he can give give me pointers to improve my writing, because at the moment I write a bit to informal. Any reactions from you the reader are welcome as well as it will only improve my writing so I can deliver at the end a well written thesis.

First a little heads up. I have been looking into the maximum distance between volunteers and the victim. I will not go into any details about this here, if you really want to know how I arrived at my conclusion just ask me or read it later in the thesis. But we arrived at a maximum distance of one kilometre, just as most of the other projects out there. We also started this week with drawing the first mockups. Now I will post the requirements section out of the thesis.

This section will only cover the requirements of the application, any design decisions or technical aspects will be discussed in a later chapter.
The application will consist out of five main components:

  • The notification of an emergency
  • AED locations
  • Events
  • Information
  • Tracking

Notifications
When a notification of an emergency arrives, the phone must show it to the user. This event should alert the owner of the phone with visual and audible aids. The user should then be able to confirm he has seen the message and is ready to respond. After he confirms, the phone should show directions and distance to the victims location. It is also possible there isn’t shown a direct route but the route has a stop before arriving at the victim, this will happen if the volunteer is sent to an AED location before sending him to the victim. Before the confirmation of reading, the identity of the volunteer is unknown, once confirmed, his identity will be known and stored for possible later reference.

AED locations
The application will show the location of AEDs in the vicinity, using the current GPS location of the volunteer. Therefore allowing the volunteers to familiarize themselves with the locations of these AEDs. Thus when an emergency situation occurs he has already an idea where to find them.

Events
It is required for all volunteers to refresh their knowledge of CPR every year. The application will help them find courses or information sessions that can be useful for their engagement.

Information
If a volunteer wants to briefly refresh their knowledge about CPR or how to use of an AED, he should find a link to a tutorial for CPR or how the use an AED in the application. This can be useful if he forgot some details and doesn’t need the whole course again, he just wants to look up those facts. The application also provides a legal document about the duties and rights as volunteer. Off course the volunteer should have read this before joining the program, but he should also be able to reread it as well. In the application, users also find a bit off information about the EMuRgency program.

Tracking
The volunteers’ locations will be uploaded to the server on periodic times. This off course happens behind the screen and the volunteer doesn’t notice anything. It only happens periodic thus reducing server and client load. The volunteer’s identity isn’t known when uploading the current location.

These are the five main components. There are other requirements, like a volunteer has to be able to login before he can use the application, but such requirements are less interesting to discuss and obvious so we will leave them out.

Eerste versie van thesis

De eerste versie van de thesis is geschreven. Hopelijk staan er niet te veel fouten meer in. Hou er rekening mee dat mijn begeleider dit nog niet heeft nagelezen, dit zal hij volgende week pas doen. Er zullen dus nog wijzigingen komen rond dit document. In dit eerste deel draait het vooral rond de inleiding, het legale aspect en de bestaande projecten. Volgende keer zullen we zeker de requirements opnemen van ons project, eventuele testmethodes voor de GUI te evalueren en hoe we gaan beslissen wie een notificatie krijgt.

Michel Schevernels – Thesis – V1