final report appendixrevfcp - universidade de coimbrabraposo/youtrace/final_report_appendix.pdf ·...

Appendix

1

Table of Contents

Table of Contents.......................................................................................................1

Annex A .......................................................................................................................4

Work plan ............................................................................................................................4

Annex B........................................................................................................................6

Framework Analysis .......................................................................................................... 6

1. Ruby on Rails.................................................................................................................. 6

1.1. Ruby language .......................................................................................................... 6

1.2. Components .............................................................................................................. 7

1.3. Architecture............................................................................................................... 7

1.4. Database integration ................................................................................................9

1.5. Conventions .............................................................................................................. 9

1.6. Useful Resources .................................................................................................... 10

2. CakePHP ........................................................................................................................10

2.1. Architecture............................................................................................................. 10

2.2. Database integration and conventions................................................................11


3. Django ............................................................................................................................12

3.1. Architecture............................................................................................................. 12


4. ASP.NET ........................................................................................................................14

4.1. Architecture............................................................................................................. 14

4.2. Database integration ..............................................................................................15

4.3. Useful resources ..................................................................................................... 15

5. Spring .............................................................................................................................15

5.1. Architecture............................................................................................................. 16

5.2. Useful resources ..................................................................................................... 16

Annex C......................................................................................................................17

Planning phase .................................................................................................................17

1. Scenarios ........................................................................................................................17

2

2. Requirements analysis ................................................................................................19

3. Use cases.........................................................................................................................20

3.1. Visitor.......................................................................................................................20

3.2. Logged user............................................................................................................. 22

3.3. User profile.............................................................................................................. 24

4. Wireframes .................................................................................................................... 27

Annex D .....................................................................................................................46

Implementation ................................................................................................................ 46

1. Authentication system and user profiles................................................................. 46

2. Subscriptions service................................................................................................... 47

3. Personal information ................................................................................................... 48

4. Groups ............................................................................................................................49

5. Events..............................................................................................................................50

6. Traces ..............................................................................................................................52

7. Bookmarks..................................................................................................................... 53

8. Tags ................................................................................................................................. 53

Annex E ......................................................................................................................56

Optimizations ................................................................................................................... 56

1. Front-end........................................................................................................................56

1.1. Make fewer HTTP requests .................................................................................. 56

1.2. Compress components with GZip....................................................................... 57

1.3. Add Expires headers..............................................................................................58

1.4. Configure etags....................................................................................................... 59

1.5. Put CSS on top and JS on bottom......................................................................... 59

2. Back-end optimization ................................................................................................60

2.1. Caching .................................................................................................................... 60

Annex F ......................................................................................................................64

Design................................................................................................................................. 64

1. Identity ...........................................................................................................................64

2. Layout .............................................................................................................................65

3. Interface..........................................................................................................................66

Annex G .....................................................................................................................72

Wireframes inspection .................................................................................................... 72

3

1. Introdução...................................................................................................................... 72

2. Objectivo........................................................................................................................72

3. Caracterização dos avaliadores .................................................................................. 72

4. Tabela de Inspecção do Design ................................................................................. 74

Annex H .....................................................................................................................78

Formal Usability Analysis ..............................................................................................78

1. Analysis instructions ................................................................................................... 78

2. Subject background results........................................................................................79

3. Analysis results............................................................................................................. 80

4. Post-analysis subject interview results .................................................................... 80

4

Annex A Work plan

Figure 1 – Project plan for the first semester

5

Figure 2 – Project plan for the second semester

6

Annex B Framework Analysis

1. Ruby on Rails

Ruby on Rails (RoR) was first released to the public in July 2004 by David

Heinemeier Hansson of 37 Signals. This framework is built in Ruby, an object-

oriented language, and is based in two fundamental principles: Convention over

Configuration (CoC) and Don’t Repeat Yourself (DRY).

The first is more of a set of rules, which enable automatic actions in the framework.

In the beginning this might seem a bit odd, but after developers realize the benefits

of using the same conventions for file, functions and table names, it becomes natural

to them.

The DRY philosophy represents the importance of avoiding code duplication in

order to maintain coherent code in the entire application. This concept will be

present in many aspects of RoR framework, which will be described in the following

paragraphs.

1.1. Ruby language

Ruby is an object-oriented, dynamic and open source programming language that

focus on simplicity and productivity. [Error! Reference source not found.] Its syntax is very

readable and easy to write, even for developers with little experience.

In Ruby everything is represented as an object, even numbers and other symbols.

This can be demonstrated by a bit of code that applies an action to a number:

5.times { print "YouTrace project" }

This feature is an influence of the Smalltalk language and eases the use of Ruby,

since these rules apply to everything on Ruby.

7

1.2. Components

RoR has six main components used by different resources of the framework:

• Active Record: ORM implementation, which handles the communication

between the application and the database.

• Action View: handles the rendering of the data displayed to users. Has

different engines to handle different requests, but the most popular is the

HTML rendering.

• Action Controller: process user requests and calls the respective actions.

• Action Mailer: handles email requests (password retrieval, sign-up

confirmation, etc.)

• Active Resource: used for consuming REST services.

• Active Support: collection of classes and extensions of core libraries to assist

the development process.

In the next chapter we will show how some of these components connect to each

other.

1.3. Architecture

The Ruby on Rails framework has an MVC (Model-View-Controller) architecture,

which is organized in folder within the framework.

8

Figure 1 – Ruby on Rails architecture

The Model section is a set of classes that use Active Record, an ORM class that maps

database tables to objects. In Active Record it’s required to use the previously

referred conventions, so that the entire mapping is automatically done by this

component without the need of additional code.

The View section works with Action View component and it gathers all the HTML

files used in the application. These files act as templates with code injections and all

the dynamic content will be inserted at render time.

Finally, the Controller section is associated with Action Controller component, which

includes the ApplicationController class. All the logic code of the application is written

in this section and represents the actions served to the users. For instance, let’s have a

look at a given URL:

… /account/login

This URL will call Account controller and the respective login function defined in the

controller. Controllers handle most of users’ requests, but they should be simple and

follow the DRY principle. In the developer’s perspective, it’s better to make larger

9

models than just implementing all the logic directly in the controllers. [Error! Reference

source not found.]

1.4. Database integration

As said before, for database integration, RoR uses Active Record, which map database

tables to application models. To connect different models in the application, RoR has

four types of associations:

• hasMany

• hasOne

• belongsTo

• hasAndBelongsToMany

With these associations is possible to relate all the models in the application and

enable lots of automatic functions. For instance, if we have a model User associated

to model Group with a hasMany association, we can access user’s groups by call the

function groups() from User model.

Once again, it’s very important to follow the conventions in order to make this

“magic” work.

1.5. Conventions

Conventions are an important aspect of Ruby on Rails framework and we’ve been

talking a lot about this in this analysis. Conventions are applied to files, classes,

models and database tables.

• Files should use underscore: events_controller.rb

• Classes should use camel case: EventsController

• Models are singular: Event

• Database tables are plural: Events

• Join tables should be alphabetically ordered: Events_Groups

10

1.6. Useful Resources

The Ruby on Rails frameworks has lots of built-in resources and external plugins

available as Ruby gems. They can be easily integrated in the application and there

are lots of repositories over the Internet.

From the many available resources we’ve selected the set of helpers (HTML, CSS, JS,

forms, AJAX), REST scaffolding, rake generators, migrations, testing suite, prototype

integration and tons of additional plugins that can add extra functionalities to the

application.

2. CakePHP

CakePHP appears in the year 2005 with the objective of supplying a robust

framework for web applications developed in PHP. At the time, an even today [x],

was one of the most popular programming languages, but also one of the most

unorganized.

CakePHP took the example of Ruby on Rails framework and started developing a

similar framework built on PHP. It wasn’t intended to make a copy of RoR, but it’s

possible to find lots of similarities between these two frameworks.

The appearance of CakePHP wasn’t an isolated event, but more a consequence of the

natural evolution of PHP language. The main change was the evolution to a fully

object-oriented language, allowing the development of these kinds of frameworks.

2.1. Architecture

Just like RoR, CakePHP also uses MVC architecture. There’s no need to describe all

the architecture again, so we’ll just analyze a typical request process in the

application.

11

Figure 2 – CakePHP request path

First, the request is forwarded to the respective controller (3) by the dispatcher (1)

through the defined routes (2). Then, in the controller, the request is processed and

the necessary actions are called. The usage of external components is optional.

If the request requires information stored in the database, the controller (3) will

communicate with the models (4,5) in order to retrieve that information.

Finally, when the controller has all the information needed, the respective view (7) is

called and the render engine generates the dynamic elements. Every time a new

request is made (8), this process starts all over again.

This architecture is almost identical to the RoR framework, but in this case, model

and controllers are PHP files that extend core libraries and views are HTML files

with some code injections.

2.2. Database integration and conventions

CakePHP is also based in the same principles as Ruby on Rails: Conventions over

Configuration and Don’t Repeat Yourself.

That means that both database integration and conventions are mostly the same as

described in the RoR analysis. The main difference is the model objects mapped from

the database. In PHP, objects are defined by arrays so the mapped model is just a

group of arrays, which can be accessed by giving the respective index.

12

The conventions are identical in both frameworks.


In CakePHP the available resources remind, once again, the RoR framework.

CakePHP has access control lists, lots of helpers (HTML, CSS, JS, forms and AJAX),

scaffolding (CRUD operations), Bake (component generator), filters/callbacks in

models and controllers, integrated validation and unit tests, among other resources.

3. Django

Django is a web application framework built in Python. Born in 2003 as a tool to

develop a web application for Lawrence Journal-World, Django became open source

in 2005.

Django has some relevant characteristics that allow quick development of web

applications with less code and a clean design. Some of those characteristics are

listed below:

• Based in MVC architecture

• DRY principle

• Loosely coupled

• Modular

• ORM

• Templates

• Administration module

Developed in Python, Django also inherits all its characteristics, which makes it very

modular, interactive, portable and extensible in C and C++ languages.

3.1. Architecture

Although based in MVC architecture, Django has a different naming for its

architecture, the MTV (Model-Template-View).

The Model indicates how to access, validate and connect data. It also makes the

bridge between the data model in the application and the database.

13

The Template indicates how data should be displayed, just like the views in the

previous frameworks.

Finally, the View indicates how to access the model and route to the appropriate

templates. It’s similar to controllers in MVC architecture.

Figure 3 – Django request process

Initially the request is made from the browser to the web servers (1), which forwards

it to the URL Resolver (2). This URL Resolver is just an application component that

maps the given URL accordingly to the routes defined in configuration files. The

request in then processed by the respective function of the view (3). If stored data is

required, this component will communicate with the model (4,5) to retrieve the

necessary data. After having all the data in the view, the application formats it

through the respective templates (6,7) and the information is ready to be displayed to

users (8).


Django has some features to help developers in their projects. The most important

features are the built-in web server, ORM, template language, simple form

processing, session support, caching, URL configuration, internationalization, etc.

There are also some complete applications or modules that can be integrated in

Django project with ease. From those modules we’ve selected the complete

administration interface, authentication system, comments systems, CSRF and XSS

protection, syndication, sitemaps and dynamic PDF generation.

14

4. ASP.NET

ASP.NET is the web application technology of the .NET framework. It was

developed to replace ASP and was first released in 2002. This framework is language

neutral, but C# is commonly used to develop web application in ASP.NET.

This technology is an evolution of ASP, with improved language support, better

performance and easier deployment of the applications. It has several controls (data,

login, navigation, etc.) that can be edited and extended.

4.1. Architecture

We have to take a look on the entire .NET framework in order to fully understand

the placement of ASP.NET within this framework. This framework can be divided in

three sections: programming languages (C#, Visual Basic, J#), server and client-

oriented technologies (ASP.NET, Windows Forms, Compact Framework) and IDEs

(Visual Studio .NET, Visual Web Developer).

Figure 4 – The .NET framework architecture

The Base Class Library is shared by all the programming languages and includes

functions used to handle files, generate charts, interact with the database and

manipulate XML data.

15

All the programming languages used in the .NET framework are compiled by the

Common Language Runtime, which produces a temporary language called Common

Intermediate Language. This characteristic allows some performance gain.

The 3.5 extension of .NET framework includes a MVC framework that can be used

with ASP.NET, but others like MonoRail are also freely available to download.

4.2. Database integration

In the .NET framework, database integration is done with ADO.NET, which has

common drivers to some databases like ODBC, OLE Db, SQL Server or Access. The

database configuration and CRUD operations are quick and simple if SQL Server is

used. With other databases the process gets a lot more complicated and slow.

4.3. Useful resources

ASP.NET has some useful resources like data controls, validation controls,

membership and roles, AJAX extensions controls, navigation controls, intellisense

(programming assistant), debugging, ViewState, extensions, ACL and scaffolding

(only available with MVC framework extension).

5. Spring

Spring is an open source project that aims to make the J2EE environment more

accessible to web developers. It was released in June 2003 as a web application MVC

framework. Spring is a powerful framework and can be used in standalone

applications or with application servers.

The key feature of this framework is the Inversion of Control (IOC) concept. The

basic concept of the Inversion of Control pattern (also known as dependency

injection) is that you do not create your objects but describe how they should be

created. You don't directly connect your components and services together in code

but describe which services are needed by which components in a configuration file.

A container (in the case of the Spring framework, the IOC container) is then

responsible for hooking it all up.

16

5.1. Architecture

The Spring framework has several modules to handle different aspects of the

application.

Figure 5 –Spring framework architecture

Context is a configuration file that provides context information to the Spring

framework. It also includes some enterprise services with extra functionalities. AOP

module integrates aspect-oriented programming functionality directly into the

framework. The JDBC DAO abstraction layer offers a meaningful exception

hierarchy for managing the error messages from the database. The Spring framework

can integrate several ORM frameworks to provide its ORM tool. The Web module is

built on top of the context module, providing contexts from web applications.

Finally, the MVC framework is a full-featured MVC implementation for building

web applications. It’s highly configurable and accommodates several view

technologies like JSP.

5.2. Useful resources

Spring framework has also some important resources and features, such as the

XMLBeanFactory, the good programming practices, consistent framework for data

access, testing suite, POJO-based programming (Plain Old Java Objects) and others.

17

Annex C Planning phase

1. Scenarios

The following scenarios were written in Portuguese.

“O António sai todos os dias para o emprego e liga o seu dispositivo GPS que vai

registando o percurso. Quando chega a casa ao fim do dia descarrega o log para o

YouTrace para poder actualizar os seus percursos. Como o processamento não é feito

de imediato, o seu percurso fica visível, mas sem estar confirmado pelo sistema.

Assim, o António pode ter uma representação imediata do seu percurso, apesar de

ainda não ser a versão oficial.

Depois de descarregados os logs, vai visualizar o seu histórico de traces e marcar

quais os que pretende que sejam privados. Repara então numa notificação na sua

listagem de comunidades que lhe indica que existem actualizações no grupo criado

para os utilizadores da sua empresa. Ao entrar na página dessa comunidade vê que

de facto o seu colega Pedro adicionou um novo trace ao seu perfil que lhe mostra um

caminho novo para chegar ao emprego. Contente com a descoberta, o António

desliga o seu computador e no dia seguinte experimenta o novo caminho indicado

pelo seu colega Pedro.”

“O Luís, ao navegar pelo site, descobre o perfil de um amigo seu. Como quer estar a

par das actualizações desse seu amigo, decide subscrever o seu perfil. Mais tarde, o

seu amigo aceita o pedido e fica então na lista de subscrições do Luís. Desta forma, o

Luís pode ver na sua página pessoal os traces e as actualizações do seu amigo e de

todos aqueles que estão na lista de subscrições.

Mais tarde entra novamente no seu perfil do YouTrace e surge-lhe uma notificação

avisando-o que existem novas actualizações no seu grupo de exploradores da serra

da Boa-Viagem. Ao visitar a página desse grupo verifica que existem novas

mensagens a marcar um encontro para o fim-de-semana e decide responder. Usando

uma keyword específica, o Luís consegue responder directamente a outros

18

utilizadores apesar da sua mensagem aparecer para todo o grupo, deixando uma

notificação automática no perfil da pessoa a quem se dirige.

Como ele, há muitos outros adeptos do “off-road” e parece que a moda pegou e há

montes de gente do mundo inteiro a partilhar os caminhos. Vejam só que agora,

começa a haver mapas do mundo “off-road”!! Há mesmo malta que vai de viagem

entre cidades e de repente sai da estrada… que perigo!”

“O Alfredo é motorista numa empresa de transportes de mercadorias. Todos os dias

sai de manhã da sede da empresa e percorre centenas de quilómetros nas estradas da

região para fazer cargas e descargas. Utiliza um GPS com uma aplicação comercial

para o ajudar a “orientar-se” e a procurar os caminhos mais curtos de uma local para

o outro. Como ouviu falar do YouTrace, resolveu começar a fazer o log dos caminhos

que percorre todos os dias.

Quando chega a casa, faz upload dos traces para a sua conta pessoal no YouTrace. E

partilha os traces com o grupo “os amigos da encomenda” – um grupo de acesso

restrito onde só são admitidos funcionários da dita empresa. Além de partilharem os

traces para criarem um “mapa de estradas da empresa”, também partilham vários

tipos de informação tais como: zonas onde há radares de velocidade; estradas em

obras ou o seu estado de conservação; locais que usualmente estão congestionados a

certas horas; postos de combustível com os preços mais baixos; POIs genéricos; etc.

Como gosta de passear ao fim de semana, recolhe esses traces também para o seu

“mapa pessoal” e procura no mapa do mundo e em mapas de outros grupos novos

locais para visitar bem como informações que lhe possam ser úteis durante a viagem.

Uma feature que ele gosta bastante no YouTrace, é que quando introduz um novo

trace e as especificações do veículo usado, é possível obter uma estimativa do

consumo de combustível despendido no percurso.”

“O Carlos vive em Montemor e vai e vem todos os dias a Coimbra, pois é lá que

trabalha. Na maioria das vezes, vai sozinho. Ele tem um Corsa 1.2, que até é

poupadinho, mas a gasolina está cara!!! No entanto, graças ao YouTrace, ele pode

começar a poupar!

19

Todos os dias ele recolhe o trace de todos os caminhos que faz e com isso o mapa vai

ficando bem melhor, mas não é aí que ele poupa! É que em Montemor (e arredores),

há muita gente a fazer o mesmo e o YouTrace tem um módulo que analisa os traces

dos “vizinhos” (ou das pessoas que queremos permitir) e que identifica quando duas

ou mais pessoas costumam partilhar traces parecidos!…

Eles já podem fazer car-pooling! :-) Agora, o Carlos leva sempre o carro cheio às terças

e quintas, e vai à boleia nos outros dias.”

“O Carlos é adepto das novas tecnologias e decidiu comprar o último modelo do

iPhone. Como este modelo tem GPS, o Carlos pode usar a aplicação do YouTrace

para registar automaticamente os seus percursos através do telemóvel.

Para além das novas tecnologias, é também um entusiasta da corrida e não passa um

fim-de-semana sem dar uma corrida pela cidade. Quando vai correr leva consigo o

seu iPhone para ouvir música e ao mesmo tempo registar o seu percurso através do

YouTrace. No final da corrida pode ver directamente no seu telemóvel o percurso

que fez e submetê-lo no YouTrace para juntar às suas outras corridas e partilhar com

os seus amigos.”

2. Requirements analysis

The following list is the result of the requirements analysis on the previous scenarios:

• User account

o Create account

o Login/Logout

o View profile

o Edit profile

• Dashboard

o Add/remove comment

o Send private message

o Show notifications

• Traces

o Add/remove trace

20

o Add trace details

o Edit trace details

o View trace history

o Show consumption estimates

• Subscriptions

o Add/remove subscription

o Accept/refuse request

o List subscriptions

• Groups

o Create/delete group

o Invite users

o View group profile

o Edit group profile

• Neighbours

o List neighbours

o Car-pooling suggestions

3. Use cases

The use case diagrams are divided in three large groups: visitor, logged user and

user profile. The last group is an extension of the logged user, but given the amount

of diagrams, it was defined as an independent group.

3.1. Visitor

The following diagrams describe the actions taken by a visitor (unauthenticated user)

on YouTrace social platform.

21

User authentication

Users can login or register to YouTrace platform with the usual form or with OpenID

technology. It’s also possible to recover the password within the login process.

Figure 3 – User authentication use case diagram

Map section

The global map view is available to all users, which emphasize the open-source

philosophy of the social platform.

Figure 4 – Map section use case diagram

Social section

In the social section, visitors are able to search a scroll through public user and group

profiles.

22

Figure 5 – Social section use case diagram

General navigation

The remaining actions available to visitors are simply “go to” actions and don’t have

much to specify.


3.2. Logged user

The following diagrams describe the actions taken by an authenticated user when

navigating on the main page of the social platform.

Map section

This section is very similar to the visitor page.

23


Social section

In this section, users can do all the actions available to visitors plus the subscription

actions available from user and group profiles.


General navigation

The remaining actions available to visitors are simply “go to” actions and don’t have

much to specify.

24


3.3. User profile

As said before, this group includes actions that extend the logged user group. The

following diagrams describe the actions that logged users can perform on their

personal profile.

Home section

In the home section, users can interact with their dashboard and have a quick

overview of the entire platform.

Figure 10 – Home section use case diagram

25

Map section

In the map section, users can view their personal map built with their own traces.


Social section

In this section, users can view and manage their contact network.


Personal information section

In this section, users can view and edit their profile, including their account

password.

26

Figure 13 – Personal information section use case diagram

4. Wireframes

Figure 14 – Main: Home

28

Figure 15 – Main: Map

29

Figure 16 – Main: Social

30

Figure 17 – Main: How to

31

Figure 18 – User profile: Home

32

Figure 19 – User profile: Info

33

Figure 20 – User profile: Edit Info

34

Figure 21 – User profile: Traces

35

Figure 22 – User profile: Social section

36

Figure 23 – Group profile: Home

37

Figure 24 – Group profile: Info

38

Figure 25 – Group profile: Edit Info

39

Figure 26 – Group profile: Traces

40

Figure 27 – Group profile: Members

41

Figure 28 – General: Create Account

Figure 29 – General: Create group

42

Figure 30 – General: Login

43

Figure 31 – General: View Trace

44

Figure 32 – General: Add Trace

45

Figure 33 – General: Sidebar

Annex D Implementation

1. Authentication system and user profiles

The first step of the implementation was creating user accounts and all the necessary

actions to handle registration and login. For this matter it was used the RESTful

Authentication plugin, which automatically creates login and register forms, and has

some helpful helpers (that’s why they call them helpers, anyway) to assist in the

implementation of user profiles.

This plugin is straightforward and, with a simple generate command, lots of

functionalities are added to the application. It also provides an integrated activation-

by-email system to improve account security.

After setting up the authentication system, we built user’s personal profile pages and

created the necessary routes to handle requests. In RESTful Rails, routes are created

using the resources function, which will automatically map the routes for show,

create, edit, update and delete actions. So user profile routes look like this:

map.resources :users do |users|

users.home 'home', :controller => 'users', :action => 'home',

:path_prefix => '/users/:id'

users.network 'network', :controller => 'users', :action =>

'network', :path_prefix => '/users/:id'

users.traces 'traces', :controller => 'users', :action =>

'traces', :path_prefix => '/users/:id'

users.info 'info', :controller => 'users', :action => 'info',

:path_prefix => '/users/:id'

users.prefs 'prefs', :controller => 'users', :action =>

'prefs', :path_prefix => '/users/:id'

end

Besides the default actions, we’ve also mapped routes for the profile sections of each

user. By doing this in a nested named route it’s possible to access, for instance, the

traces section with the function user_traces_path(user). This is really helpful

47

when you have to deal with lots of different routes and will maintain a logical

structure along the implementation.

2. Subscriptions service

After implementing the authentication system and the navigation in the user profile,

we started working on users relationships in the social platform. This is a major

feature so we decided that it was best to start from here and then implement the

minor features later on the project.

Subscriptions are used to store the relations between users, but only in one direction,

which means that for each user only their subscriptions are stored, not the inverse.

One user can have multiple subscriptions and multiple followers, who might not be

the same. We opted for this solution to represent relationships between users,

because in YouTrace users will mostly store their traces and share them with others.

It’s not intended to use YouTrace as a replacement for other social networks and it’s

much more logical to have a subscription service where users can stay updated

without implying a friendship with other users. It’s much more like Twitter or

simple RSS feed subscription.

To build this table in the application we needed to generate a new model and map

the correct model associations between users and subscriptions. This was a bit tricky,

because subscriptions table is self-referential and we had to be careful to keep

database integrity. First we tried a has_and_belongs_to_many association, which is

a simple way of building this table without the need of generating a new model for

it:

has_and_belongs_to_many :subscriptions, :class_name => "User",

:join_table => "subscriptions", :foreign_key => "user_id",

:association_foreign_key => "subscriber_id"

This solution worked fine in the beginning, but then we needed to add more

attributes to this table to handle the subscription’s authorization and pausing. With

this kind of association that wasn’t possible, so we had to generate a new model for

the subscriptions and link the two models with has_many and belongs_to

associations.

On user model we have:

48

has_many :subscriptions

has_many :subscribers, :through => :subscriptions

And on subscription model:

belongs_to :user

belongs_to :subscriber, :class_name => "User", :foreign_key =>

"subscriber_id"

This was the solution for our problem and now we can easily access and update any

attributes of this model.

With this association we can retrieve user’s subscriptions with a simple

user.subscriptions() function. This will return an array of subscriptions, which

can be used to extend user’s information. This and some other functions are

automatically available to user model just for adding these associations.

3. Personal information

At this point we’ve done the authentication system, the navigation and the

subscription service. Meantime, we’ve just finished the personal information view

from user’s profile. This means that users are now able to view and edit their

personal information to complete their profile.

The registration process is very simple and requires few details from users

(username, email and password to be precise) so this area is designed to complete

that personal information with other details like birthday, real name or location. It

also gives the possibility to add vehicles and GPS devices to the user profile, which

will be very useful in the future to take full advantage of some unique features from

YouTrace social platform.

These latest features are not yet implemented, given the low priority of each one.

We’re focusing on the major features of the application and will get back to this as

soon as we finish implementing those features.

Implementing an edit view in rails is pretty easy, especially on REST architecture.

We just have to follow these steps:

1. Link to the edit page with edit_user_path(@user)

2. Implement edit and update functions in users_controller

49

3. Implement edit.html.erb view with the form helpers

4. Check if everything is working

With three simple steps, editing capabilities are added to the application. Notice that

edit and update functions are automatically called by HTTP requests (GET and PUT,

respectively) and all you have to do is use the edit_user_path provided by RESTful

Rails.

4. Groups

This feature was implemented in the first semester, but with the changes in the

application it has been removed from the current version. The following information

may be considered for demonstration purpose only, as it is no longer supported by

the YouTrace platform.

Beside all those features from the YouTrace engine, we needed to add some social

interaction to the platform. It’s important that users can locate other people that

share common interests or just help their neighbours tracing their own city, for

instance.

At this initial stage it’s intended to use groups as some kind of (private or public)

channel to communicate with a specific group of people. We believe that’s a good

way to promote user interactions and help users keep their updates organized.

First, we had to create group model with the necessary attributes. We also needed

the group’s controller so we’ve just used rspec_scaffold command to generate

model, controller, views and the appropriate RSpec tests for each one. This is very

useful when you’re starting the development of an application, because it saves a lot

of time by automatically defining the main actions (show, create, edit, update,

destroy) for you. From that point, we’ve added actions to handle the navigation

(traces, members, info) and group subscription (join, leave).

Next we had to associate this model with user’s model. This is a many-to-many

relation so we could have used a has_and_belongs_to_many association, but just

like subscriptions model, we needed some additional information in the join table to

manage access levels to groups. This is used to determine user’s role in each group

starting from simple users to group owners.

50

To accomplish that requirement, we created a new model groups_user just for this

association. The association between users and groups is similar to our subscriptions

example. To the user model we added:

has_many :groups_users

has_many :groups, :through => :groups_users

In the other end, group model had:

has_many :groups_users

has_many :users, :through => :groups_users

Then we finished the association by adding to groups_user model:

belongs_to :user

belongs_to :group

With this association we can access groups from a user by calling user.groups() or

the inverse, get users from a group with group.users(). Adding a user to a group is

also very simple, it’s only necessary to add a new user to users array:

@group.users << @user

Or add a new group to groups array:

@user.groups << @group

Finally, if we wanted to access some custom attribute from the join table we just have

to use group.groups_users or user.groups_users as it works both ways.

In the YouTrace platform, group navigation is very similar to user navigation to

avoid breaking page layout in two distinct areas. This is important to keep users

focused on the content and don’t get that “new site” feeling every time they visit a

group page.

5. Events

Events are a crucial part of the social platform. They represent not only all the

interactions between users, from messages to requests, but also system notifications.

The idea is to have all the information available to users in the form of events, no

matter what type they are.

51

With events, it’s possible to create an activity time-line (or log) with all the

information generated by users displayed in one place. Now we have a dashboard as

the homepage in user’s profile, which aggregates the most important information to

users. This approach is becoming a trend in modern applications and we believe it’s

the correct approach for our social platform, because it makes user interaction much

simpler.

To add events to the existing application, we started as usual by generating the event

model. Once again as we also needed to generate controllers and views to this

model, the rspec_scaffold generator was used. As stated before, this saves a lot of

time by automatically generating model, controller actions, views and RSpec tests.

After creating the table with the respective migration, the first step was to map the

correct associations between models. We’ve been following the initial Entity-

Relationship Diagram described in chapter 5.3 Database.

Events have two one-to-many associations, one with user model and another with

group model. This means that an event can belong to a user, a group or both of them.

This is achieved through foreign keys, which identify each model. So in event model

we have:

belongs_to :group

belongs_to :user

In user and group model the same association is required:

has_many :events

On the controller side only two actions are currently active: create and destroy. The

reason is that all the events are handled by users controller or by automatic system

notification, so it’s not required to have all the actions implemented. Perhaps, in this

situation, scaffolding generation wasn’t necessary, but it’s always good to have tests

already implemented for you.

In user’s profile, events are rendered through a particular partial view for each one

of them. This follows the DRY (don’t repeat yourself) philosophy behind Ruby on

Rails and assures the correct display of each event in every view.

52

6. Traces

This feature represents the bridge between users and the YouTrace engine. Each time

a user uploads GPS traces to the platform, a new trace is created with all the required

attributes.

Creating a new trace is not a simple task as it can be associated with users, groups,

vehicles and GPS devices. On the developer side this means that it’s necessary to

implement a form, which interacts with four different models. But before describing

the implementation, we’ll start with the description of trace model.

As said before, this model is associated with four other models in the platform. For

the user, vehicle and device model it’s only required a simple many-to-one

association. In Rails this is described with the belongs_to association:

belongs_to :user

belongs_to :vehicle

belongs_to :device

On other hand, the association between traces and groups is a many-to-many

relation. This requires a different association, because the same trace can be related to

several groups. In Rails that is represented by a has_and_belongs_to_many

association:

has_and_belongs_to_many :groups

After defining the trace model it’s time to look at the controller and respective views.

Once again we’ve used rspec_scaffold command to automatically generate the

code for the REST actions. Although it generates most of the code, we needed to

implement the correct association between models and how that would be

represented on the new trace form.

Associating a trace with a user is very simple and we only needed to assign user_id

to the current logged user id. The association with groups is obtained through check-

boxes, which we think is the best solution for this problem. A check-box is displayed

for each of the user’s groups so that each of them can be associated with the trace.

Finally, there’s a similar solution for the vehicle and GPS device association, but they

only allow one association per trace. So we used a select box that lists all the vehicles

and devices associated with the current user account, allowing just one selection.

53

With these three different methods we were able to create a new trace with all the

required associations from a single form, simplifying the creation process and having

a more user-friendly approach.

At this time, the prototype is almost ready to be tested.

7. Bookmarks

Bookmarks were introduced after the initial implementation phase and act as a

replacement for the extinct groups feature. In the application we have two types of

bookmarks: user profiles and tag pages. The first are stored using the subscription

table described earlier, the latter is stored in the bookmark model.

This bookmark model is related to each user and describes a tag search page. It is

used to store the list of bookmarks pages for each user, so it is a simple model with

few attributes required.

has_and_belongs_to_many :users

With bookmarks, it made no sense that we used an authorization process like the one

used on subscriptions. Since these pages are in public domain, there is no

authorization required and the tag page is immediately added to user’s bookmarks

upon request.

Given the actual requirements we could replace this model with the tag plugin

described on the next chapter, but we wanted to have more control over this

association. In the future we may have additional security requirements or extended

features and it is important to have this separated model to work with.

8. Tags

In Ruby on Rails there are some plugins to help develop this tagging system, namely

acts_as_taggable, acts_as_taggable_on_steroids and acts_as_taggable_on. These might

seem all the same plugin, and in fact they are mostly based on the first

acts_as_taggable, but they have distinct features and applications. The original

acts_as_taggable plugin introduced the ability of adding tags to a specific model. A

simple approach often used in applications that only requires simple tagging

54

features. Acts_as_taggable_on_steroids includes some extras like smarter tag

assignment or tag cloud calculation. This plugin was the reference in the past couple

of years and it’s one of the most popular rails plugins.

Finally, acts_as_taggable_on is the latest tagging plugin and a really powerful one.

This plugin was built on top of acts_as_taggable_on_steroids so it inherits all its

features plus an entirely new set of useful features. With acts_as_taggable_on we can

tag a model with different contexts. For instance, our traces model can have tags

representing location context and other tags representing group context. This is very

useful if you need to add different meanings to tags within the same model. Also, it

adds ownership to tags and the possibility of finding related objects by similar tags.

With tag ownership it’s now possible to associate users to tags, although at the

moment it only allows one owner per tag, which limits the purpose of this feature.

With related objects, it’s possible to quickly find all the objects tagged with a specific

tag in the given context.

Given this analysis, we’ve opted for the latter plugin: act_as_taggable_on, although it’s

possible that we might have to make some changes to the plugin source to fully

accomplish the requirements of the social platform.

It was really simple to integrate this plugin in the application. We started by defining

the Trace model as a taggable item with the following association.

acts_as_taggabble_on: tags

This method also defines the contexts to which the tags can be applied. It’s possible

to have multiple contexts for the same model, but for the moment it is only required

a single context.

Then we wanted to give the User model tagger capabilities so that we could relate

the tags to its owners. This also requires a simple association in the model.

acts_as_tagger

In this situation we don’t have to define the contexts since users can add tags to all

the contexts.

With these associations we can now access the tag list of a specific trace:

@trace.tags_list

Find all the tags owed by some user:

55

@user.owned_tags

Or even find the traces related to a specific trace tags: list

@trace.find_related_on_tags

To improve the user experience we have also implemented an auto-complete feature

when adding new tags to traces. This is basically an AJAX request to a page, which

responds with a JSON list of the tags that match the given search query.

Figure 6 – Tag list suggestion

56

Annex E Optimizations

1. Front-end

The following chapters describe the optimizations made to the application and what

was the impact of each one.

1.1. Make fewer HTTP requests

From the initial analysis, we detected that most of the requests originated from

images or scripts.

We started by applying the CSS sprite technique to the main navigation in order to

reduce image requests. With sprites, we combine multiple images in a single image

and then, with some CSS styling, we display only the required image section.

However, when people use large CSS sprites, the benefits are reduced because of the

load time of the image. We need to keep the correct balance between reducing the

HTTP request and avoiding large image sprites.

Concerning the script files, we used the cache feature from Rails, which combines all

the javascript files into a single one. The concept is the same as the above, but the

implementation is very different.

We now show some results:

Figure 7 – Weight graphs with fewer HTTP requests for home page

57

Figure 8 – Weight graphs from dashboard page with fewer HTTP requests

With these optimizations, we have removed 8 requests from the home page and 18

from the dashboard page. To have a better perspective on how this will affect the

page load, we analyze the response time chart.

Figure 9 – Response time from home page with fewer requests

Figure 10 – Response time from dashboard page with fewer requests

From the response times we notice that there were already some improvements with

this optimization. The real benefit of reducing the HTTP requests is in removing

some of the load from the server. This will be very important when scaling up the

application to millions of hits per day. However, the page weight is still high so we

need to compress some of the components of the page.

1.2. Compress components with GZip

Compressing the JS and CSS files is a good option to remove some weight from the

page. We can have this type of compressing by using the mod_deflate of Apache web

server.

58

Figure 11 – Weight graphs from home page with GZip compression

Figure 12 – Weight graphs from dashboard page with GZip compression

As expected, there was big weight reduction on the dashboard page, which has

larger JS files. In the home page, there were also some improvements, although most

of the weight is related to having several images in that page.

Using GZip compression in image files is not recommended because they are already

compressed file formats and that algorithm will not reduce the file size.

1.3. Add Expires headers

Once we have made some improvements on the page weight, we need to focus on

client-side caching, which is vital to the application scalability. There are some

control mechanisms on Rails, which can be combined with some configurations on

the Apache web-server.

Figure 13 – Weight graphs from home page with expires headers

59

Figure 14 – Weight graphs from dashboard page with expires headers

With the correct expires headers configuration, we can avoid hitting the server with

a primed cache on the client side. It’s possible to control the maximum time that an

element stays in the client cache. In these examples we have defined the HTML page

with a 10-minute max age and the other elements with 1-month validation.

1.4. Configure etags

Etags are used to attach an unequivocal name to each element on the page. This can

be very useful to improve caching if it’s correctly configured. By default, Apache

servers include the INode stamp on each etag, which can be dangerous if we have

multiple content servers. The INode stamp is specific to each server and we should

remove it from the etag to allow caching of the same element store in different

servers.

This is more of a recommendation and not an optimization task, as later discussed in

one of the upcoming chapters.

1.5. Put CSS on top and JS on bottom

Finally, we took another recommendation and applied it to our application. The

reason behind this task is that JS files should not block the page load, therefore it is

better to have them on the bottom of the code. On the other side, CSS files should be

on top so that content can be styled during rendering.

60

2. Back-end optimization

On the back-end side, it is important to save as much hits as possible, either by using

caching or by optimizing database queries. These optimizations will have a major

influence on the application response times and overall scalability.

2.1. Caching

In the Youtrace Social Platform we have only implemented two types of caching:

action caching and fragment caching. We didn’t use page caching because of the

highly dynamic platform, which is not suitable for this type of caching.

Starting with our two example pages (Home page and User dashboard) it was

immediately clear that only the home page could have action caching. As we started

implementing this feature, we realized that we needed special conditions to make

action caching work.

The problem with the home page is that it can be accessed by both visitors and

logged users. Fortunately, it is possible to cache the action without rendering the

layout, making this action caching work for every user.

caches_action :index, :layout => false

However, in this action, we don’t have any database requests so we cannot take

advantage of the full potential of action caching. Below, we present the result with

page caching enabled.

Processing HomeController#index [GET]

Cached fragment hit: views/dev.youtrace.local/index (2.9ms)

Rendering template within layouts/main

Rendered home/_header (0.7ms)

Rendered home/_sidebar (0.4ms)

Rendered home/_footer (1.0ms)

Completed in 8ms (View: 4, DB: 0) | 200 OK

Without the action caching, the results are nearly the same.

On the other side, in the dashboard page we have some SQL queries from the

activity feed as shown below.

Processing UsersController#show [GET]

Parameters: {"id"=>"braposo"}

61

User Load (1.1ms) SELECT * FROM "users" WHERE ("users"."id" = 1)

LIMIT 1

User Load (1.4ms) SELECT * FROM "users" WHERE ("users"."login" =

E'braposo') LIMIT 1

Event Load (1.5ms) SELECT * FROM "events" ORDER BY created_at

DESC LIMIT 10 OFFSET 0

SQL (0.4ms) SELECT count(*) AS count_all FROM "events"

Rendering template within layouts/logged

Rendering users/show

User Load (0.6ms) SELECT * FROM "users" WHERE ("users"."id" = 1)

Rendered events/_message_item (5.8ms)

CACHE (0.0ms) SELECT * FROM "users" WHERE ("users"."id" = 1)


User Load (0.5ms) SELECT * FROM "users" WHERE ("users"."id" =

14)



21)









20)







Rendered home/_tips (0.1ms)

Rendered home/_profile_menu (2.0ms)



We can clearly see the 7 requests made to the database. This can be a major problem

since this page is hit several times by logged users. We decided to implement

fragment caching on this section to avoid these requests on every page hit.

62

<% cache("#{current_user.login}/events/#{@ts}/#{params[:page]}") do

%>

<% if [email protected]? -%>

<div id="events-list">

<% @events.each do |e| -%>

<%= render … %>

<% end -%>

<%= will_paginate … %>

</div>

<% else -%>

No activity.

<% end -%>

<% end %>

This is the selected block for the fragment caching. As we can see, it is very simple to

do this type of caching.

The caching key for this block is a combination of user’s login, the section name, a

special timestamp and the page to which it refers. The first two elements are plain

simple and are used for describing the cached block. The last two elements are very

important in two different aspects. The special timestamp is used to guarantee that

this block is the most recent one in the cache. In combination with memcached, the

utilization of this timestamp removes the need of cache expiration, as it will only

render the latest block. Finally the page is required because we use AJAX pagination

in this block and this way we can cache all the pages displayed to users.

The following results express the real benefits of using fragment caching wisely.

Processing UsersController#show [GET]

Parameters: {"id"=>"braposo"}

Cached fragment exists?: views/braposo/events/581243474826/1 (2.7ms)

Rendering template within layouts/logged

Rendering users/show

Cached fragment hit: views/braposo/events/581243474826/1 (0.0ms)


Rendered home/_profile_menu (1.3ms)



There is a 90ms improvement (72%) in processing time and no database queries

whatsoever. Besides, this fragment will still be valid until a new event occurs, which

63

means that even if a user logs out and comes back to the application, if the fragment

is still in the cache, it will be renderer as well.

64

Annex F Design

1. Identity

After some months working on YouTrace platform, we have a brand new identity! It

was my opportunity to recall my designer skills and I’m very pleased with the final

result. I have to thank Guilherme Morais from Webreakstuff for the great tips about

the design.

Figure 34 – YouTrace logo

The inspiration for this logo was the placement marks in virtual maps. This clearly

identifies the YouTrace application, as some kind of a “mapping tool” and it’s far

easier to understand than the whole tracing concept.

The blue colour conveys not only importance and confidence, but also calming and

relaxing sensations. It’s also the recognizable colour for our planet Earth, and it

emphasis the globalization and connection that YouTrace application provides. For

the YouTrace platform was used Old Man Winter v.4 colour palette from Kuler.

Figure 35 – Colour palette

65

The typography is very clean, light and just a bit rounded resembling the traces

displayed on the maps. I think it just fits perfectly with the placement mark and the

overall idea for the logo. The font used for this logo was Quicksand.

2. Layout

For the YouTrace platform was chosen a fluid layout instead of a fixed one. With a

fluid layout, the elements on the page are distributed accordingly to the user’s

monitor resolution. This means that the width of layout components is variable and

adjustable to fit every monitor.

Figure 36 – Visitors layout

For the visitors pages was used a 2-column layout including a sidebar on the right.

Both columns have variable widths in the proportions described in the figure.

66

Figure 37 – Authenticated user layout

On the other hand, the authenticated user layout has a 3-column layout with an

180px block on the left and a 2-column grid similar to visitors’ layout. The left block

is used as a menu to navigate through users and groups profiles and has fixed width

because of its specific content. This is the most significant change between the guest

user layout and the authenticated one.

3. Interface

The following figures are screenshots from the main sections of the first version of

YouTrace social platform. This was the base layout for the platform after the

wireframes inspection.

Figure 38 – Sign up

67

Figure 39 – Main: Social

Figure 40 – User profile: Dashboard

Figure 41 – User profile: Map

68

Figure 42 – User profile: Network

Figure 43 – User profile: Info

Figure 44 – General: Add trace

The group profiles are similar to user profiles so screenshots are redundant.

After the Formal Usability Analysis, another version of the application design was

released. This version is close to the final layout and includes all the guidelines

described on the analysis. The following screenshots are taken from the latest version

of the application.

69

Figure 45 – General: Main Page

Figure 46 – User: Dashboard

70

Figure 47 – User: Bookmarks

Figure 48 – User: Public profile

71

Figure 49 – General: Add Trace

72

Annex G Wireframes inspection

1. Introdução

O YouTrace é uma plataforma social que promove a agregação automática de traces

GPS de forma a construir um mapa de estradas global. Para além disso, possui as

principais características de uma rede de utilizadores, como perfis, rede de amigos e

comunidades para partilha de informação.

2. Objectivo

Foi pedido a um grupo de estudo para avaliar os ecrãs para cada uma das acções

descritas em cada um. Em cada ecrã o avaliador tentou responder às seguintes

questões:

• Será necessário adicionar/retirar algum elemento ao ecrã?

• Os elementos estão dispostos da melhor forma no ecrã?

• É possível realizar a acção?

• Há alguma coisa que não seja clara ou que confunda o utilizador?

• Pessoalmente faria algo de outra forma?

• Tenho alguma sugestão adicional?

Caso alguma destas questões suscitasse algum tipo de comentário, o avaliador

deveria preencher a tabela com a informação necessária.

3. Caracterização dos avaliadores

Para melhor compreender as especificidades de cada avaliador foi necessário fazer

um pequeno questionário.

Este tipo de informação permite compreender um pouco melhor as especificidade do

grupo de estudo.

73

# Profissão Exp. Computação Exp. Aplicações

1. Estudante Eng. Informática 5 4

2. Programador 5 5

3. Estudante 5 5

4. Docente do Ensino Superior 5 1

5. Professor Universitário 5 4

6. Estudante 5 2

7. Web Developer 5 2

8. Informático 5 1

9. Estudante 4 2

10. Programador 5 2

Table 1– User description

4. Tabela de Inspecção do Design

De seguida estão os resultados da inspecção e das alterações efectuadas nos wireframes.

Ecrã Problema/Sugestão Notas/Alterações

“How To” poderia estar a seguir a “Communities” e antes de “About”, por forma a haver uma sequência lógica, nos marcadores, de locais onde se pode executar algo na página e os últimos serem informação. Outra hipótese é não haver marcador de “How To” ou “About” e serem links separados.

Aceite.

Alguma incoerência entre a cor dos botões de submit ao longo dos diferentes layouts… umas vezes são azuis, outra vez cinzentos, se calhar há algum motivo para isso que me esteja a escapar…

Para dar destaque em alguns casos particulares.

Não existe layout para a opção “About” A ver.

Alterar o nome de “Communities” para “Groups”. Aceite.

Falta uma coisa que é... download do mapa (para um formato KML, nosso...). Útil para outros fazerem aplicações de navegação, por exemplo...

Estudar viabilidade de descarregar mapa completo, pode ser muito pesado.

1. No “Go to Map” podia ser “Take a tour” ou algo semelhante. A ideia é mesmo ir para o mapa.

Não sei se a maior parte dos users iam entender o search traces por baixo do mapa. Talvez pusesse o search numa tab à parte, e quando ele escolhia um trace, ia para uma pagina de detalhes com mapa grande.

Penso que não é assim tão confuso.

2. Não está claro como se irá fazer a associação de traces com o mapa. Muda a cor no mapa? Aparecem traces sobrepostos?

Aqui seria para mostrar os traces do mapa mundo no geral, sem estar com detalhes individuais de cada trace. Quando é feita uma pesquisa apenas os traces encontrados eh que aparecem.

No tutorial “Download traces from your GPS”, não sei tens isso em mente, mas deve-se incluir um exemplo de uma aplicação que registe os traces (para PDAs e outros dispositivos GPS) e indicar que aplicações do tipo TomTom não servem para o efeito.

Será tido em conta para o conteúdo da página 3.

O tutorial “Create a new account” acho que é demasiado elementar. Se calhar os novos utilizadores chegam mais facilmente ao painel para criar a nova conta do que ao HowTo.

São apenas tópicos de exemplo.

75

Não sei se têm em mente apenas exportar traces, mas porções (zonas quadradas) também seria interessante e depois o respectivo HowTo.

Sim, zonas também são incluídas.

Alterar o nome para Social para incluir também utilizadores e não apenas comunidades. Aceite.

4. Acho que seria interessante deixar ao critério de cada admin de cada comunidade privada, dar a possibilidade ou não desta aparecer na lista das comunidades (claro que indicando que esta é privada). Desta forma as comunidades privadas podem indicar que existem (fazem publicidade) junto dos utilizadores e assim evita-se a criação de comunidades privadas semelhantes.

Aceite.

Existe alguma incoerência, não sei se propositada, entre o aspecto da barra de menu da parte privada e a barra de menu da parte pública da plataforma.

É para indicar que não são a mesma barra.

5. Sendo a acção de adicionar uma nova mensagem mais importante que mostrar a lista de mensagens, devia estar em cima da lista e não por baixo.

Aceite.

Engraçado teres incluído a “cena” da estatística do combustível. Agora a questão é: o mesmo utilizador pode ter mais do que um carro ou outros veículos (mota/camião), e o mesmo acontece com os dispositivos GPS. Talvez ter uma lista para veículos e outros para dispositivos GPS e quando se faz upload de um trace, seleccionam-se os correctos.

Aceite.

“Car details”… Não era suposto o YouTrace estar também disponível para traces de pessoas que andem a pé, de bicicleta, etc?

Sim, com a possibilidade de associar o trace a um determinado veículo teremos essa hipótese.

Falta consumo combinado... era o ideal para fazer contas Aceite

Dificilmente será possível obter localização em tempo real (este site vai ser acedido do PC e não do PDA). Não será melhor simplesmente colocar a janela do mapa à volta da zona onde a pessoa mora (ou do ultimo trace...)?

Geode :P

O "edit" information podia estar mais legível, não e fácil de encontrar para os utilizadores menos experientes. Talvez um botão em baixo?

No design final dar destaque a esta funcionalidade.

Creio que normalmente não se usa como termo de comparação o consumo “offroad”. Na maior parte das vezes o termo de comparação são consumos combinados… são estes os dados que os construtores fornecem…

Aceite. Seria para os 4x4 mas é melhor ser apenas combinado.

6.

Seria talvez interessante dar a possibilidade ao utilizador de introduzir os dados pessoais mas estes só serem vistos pelas utilizadores que se encontram nas mesmas comunidades e os followers. Em último caso, se o utilizador assim o entender, os dados podem ser vistos por todos os utilizadores da plataforma, quer estejam registados ou não.

Aceite.

7. Sex ou Gender? - http://www.med.monash.edu.au/gendermed/sexandgender.html com as modernices de hoje em dia, são coisas diferentes

Aceite.

76

Car details (o mesmo que tinha dito anteriormente) e mais… será que vão conseguir arranjar a lista de todas as marcas e modelos? E vão actualizar sempre que sai um novo modelo para o mercado? Não será melhor deixar o utilizador preencher? O mesmo para o dispositivo de GPS…

Aceite.

Não seria eventualmente mais prático dividir este formulário em vários formulários mais pequenos? Se uma pessoa apenas quiser alterar a password, será submetida e “processada” toda a informação?

Aceite.

Para o "change password", Car details e GPS device eu punha as informaçoes escondidas, e se o utilizador quisesse carregava lá e aquilo abria e pronto. Com botão "ok" para cada grupo que verifica logo se está tudo bem ou não.

Semelhante ao anterior.

E se uma pessoa tiver mais do que um carro ou meio de transporte? Não será melhor ter uma lista de meios de transporte do utilizador e aquando do upload do trace seleccionar aquele em que os traces foram adquiridos?

Já referido anteriormente.

Possivelmente poder-se-ia apenas mostrar uma fotografia da pessoa, nome e quando o ponteiro do rato passasse por cima desta mostrasse os outros dados presentes num pequeno rectângulo. Desta forma conseguia-se mostrar mais pessoas por ecrã e menos informação escrita (isto depende se a ênfase é nas pessoas ou na informação escrita sobre cada).

Mostrar vista de lista ou detalhes.

Usar tooltips nos botões delete e pause. Sim, quando for feita a implementação.

9.

Agrupar users e communities para evitar ter de fazer muito scroll quando quer ver apenas os grupos. Aceite.

Deveria haver algum elemento na interface que indicasse onde a pessoa está (User profile, Community profile, etc. ). Sem isso pode ser confuso… Usar “breadcrumbs” por exemplo. Porque inclusivamente as opções entre as várias partes da plataforma têm o mesmo nome: “home”, “traces”, etc.

Aceite. Estender para todas as páginas

Não se percebe muito bem o q é suposto aparecer na lista (4). Todas as notificações da plataforma.

No topo diz “unread events: messages, traces, requests” mas à direita diz “show: all, messages, updates”. Não se percebe bem o que é que é suposto ser mostrado em baixo.

Aceite. Coerência de eventos. 10.

Em cima fala de messages, traces e requests, no entanto, na caixa de texto em baixo apenas é permitido enviar mensagens. Na minha opinião, seria útil colocar um separador ou uma opção que permitisse também fazer requests (que ainda não percebi o que são).

Não aceite. Requests são pedidos para fazer parte do grupo de followers que são feitos pelo perfil do utilizador.

“Information” sobre o quê? “Information about the community YYYY”, a meu ver ajuda… Aceite.

O "edit" information podia estar mais legível, não e fácil de encontrar para os utilizadores menos experientes. Talvez um botão em baixo?

No design final dar destaque a esta funcionalidade.

11.

Poder alternar entre mostrar localização dos membros e lista destes, similar à que se encontra no ecrã 9. Essa funcionalidade está disponível na secção Members.

77

O access-code para entrar nas comunidades parece-me pouco seguro, mesmo tendo a possibilidade de se alterar o código. Pois alguém pode obter o código legitimamente e passá-lo a terceiros que por sua vez também vão entrar na comunidade. É claro que eles posteriormente podem ser expulsos mas no entanto já “coscuvilharam” o que é que a comunidade anda a fazer. Qualquer coisa que implique a confirmação da entrada por parte de um dos admins seria bem melhor.

Aceite. Inserir confirmação do admin.

A meu ver, o campo de “Description” está um pouco desgarrado do resto dos campos de formulário… da primeira vez que olhei nem reparei nele….

Aceite.

Na minha opinião, colocaria o botão de save changes or take me back no fundo, em vez de o colocar no meio da informação como está agora.

Aceite.

O botão SAVE CHANGES no meio está um bocado confuso. É suposto afectar tudo não é? Para esta parte fazia o mesmo k em cima para o "change password" etc etc

Aceite.

12.

Em várias situações surgem dois botões um com um “X” e um com “O”, para mim, visualmente não é claro o que posso fazer como “O”….

Usar tooltips.

Eu colocaria uma opção de não ver as fotos dos utilizadores de forma a permitir ver um maior número de utilizadores, ocupando menos espaço na lista.

Aceite. Adicionar vista lista ou detalhes. 14.

Existem 23 amigos, mas segundo a listagem existem 4 páginas com amigos… também não dá assim tanto trabalho ser um bocadinho mais rigoroso…

Pois.

15.

Existe algum motivo para esse formulário não aparecer integrado num layout semelhante ao das outras páginas? Assim perde-se um dos conceitos mais importantes em IU… a coerência. O tamanho dos campo de formulário deve dar uma ideia relativamente ao tamanho máximo que se pode lá escrever… geralmente os campos de password são muito mais pequenos…

Secção específica que pode ter vários locais dentro da página.

16. O Upload image ta muito afastado, parece que não faz parte. põe por baixo ou junta mais. Aceite.

17. O mesmo que tinha dito para o 15 relativamente ao layout… Já respondido.

19. Será public, private, friends, community... Aceite. Adicionar preferências de privacidade.

Table 2– Analysis result

Annex H Formal Usability Analysis

1. Analysis instructions

The following instructions were provided to each subject in the beginning of the

analysis. For easier comprehension, we decided to write this guide in Portuguese:

“A análise formal é realizada de acordo com o plano de tarefas enunciado. O

participante deverá seguir a ordem descrita e deverá tentar focar-se no objectivo da

tarefa em concreto.

Durante a análise, o participante deverá falar em voz alta para que se possa

acompanhar o seu raciocínio. Não deverá haver nenhum tipo de diálogo com o

orientador do teste, excepto em casos de total incapacidade de realizar a tarefa

descrita. Em cada tarefa, o participante deverá responder às seguintes questões para

que se possa ter um melhor entendimento das dificuldades apresentadas:

• O que esperava encontrar na vista desta tarefa?

• Que dificuldades encontrei em realizar a tarefa?

• Esperava poder realizar a tarefa de outro modo? Qual?

• O que mudaria na interface para ajudar a realizar a tarefa?

• Outros comentários ou apreciações que estejam relacionados com a tarefa em

questão

As seguintes tarefas deverãos ser realizadas pela ordem em que são apresentadas:

1. Registar uma conta

2. Fazer login na aplicação

3. Actualizar o estado do utilizador

4. Ver mapa do mundo

5. Apagar o estado inserido e actualizar de novo o estado do utilizador

6. Adicionar novo trace com as tags “coimbra”, “formal” e “teste”. Pré-visualizar o

trace antes de submeter.

7. Visualizar detalhes do trace inserido

79

8. Ir para a página da tag “coimbra”

9. Adicionar a página aos favoritos

10. Ver traces do utilizador / mapa pessoal

11. Procurar traces com a tag “formal”

12. Ir para os bookmarks do utilizador

13. Adicionar o utilizador “braposo” aos bookmarks

14. Mudar para a vista do tipo lista nos bookmarks do utilizador

15. Ver o próprio perfil

16. Mover a secção “Details” para baixo da secção “GPS Device” e mover a secção

“Vehicle Details” para a coluna da esquerda

17. Editar perfil do utilizador e mudar a foto

18. Fazer logout da aplicação”

2. Subject background results

Understanding the background of each participant is important to validate the

obtained results. We selected the following questions:

1. What is your computer skills level?

2. What do you expect to find in the application?

3. What is your experience with similar applications?

# Question 1 Question 2 Question 3

1. Intermediate Trace database None

2. Expert View users’ traces None

3. Expert Doesn’t know None


5. Intermediate Doesn’t know None




9. Expert Trace analysis Some

10. Expert Trace database Some

11. Expert Map of the world Some

12. Expert Doesn’t know Few

80

3. Analysis results

For each task we registered the user reactions. We selected four different

classifications to keep the overall coherence of this analysis:

1. Didn’t complete the task

2. Completed the task with difficulties

3. Completed the task without difficulties

4. Completed the task with ease

# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

1. 4 4 2 2 2 3 4 4 2 4 4 4 2 4 3 4 3 4

2. 4 4 2 4 4 4 4 4 4 3 4 4 3 2 4 4 3 4

3. 4 4 4 4 3 4 4 4 4 3 4 4 3 2 4 4 2 4

4. 4 4 3 4 2 4 4 4 4 4 3 4 2 3 4 4 3 4

5. 4 4 4 4 3 4 4 4 3 4 4 4 2 3 4 4 3 4

6. 4 4 4 4 3 4 4 2 4 3 3 4 4 1 4 4 4 4

7. 4 4 4 4 3 3 4 3 3 4 4 4 3 4 4 4 3 4

8. 4 2 2 4 4 4 4 4 4 2 3 4 3 2 4 3 2 4

9. 4 4 3 4 4 4 4 3 3 4 4 4 3 4 4 4 4 4

10. 4 4 3 4 3 4 4 4 4 4 3 4 2 2 4 3 3 4

11. 4 4 2 4 3 4 4 4 4 3 4 4 3 2 4 3 3 4

12. 3 4 4 4 2 3 4 4 4 4 4 4 3 4 4 4 4 4

4. Post-analysis subject interview results

After the analysis, we asked the subjects some questions to summarize their analysis:

1. Do you find this application easy to use?

2. What were the difficulties encountered?

3. What benefits can you take from the application?

4. How often would you use the application?

81

5. Would you pay to use this application?

# 1. 2. 3. 4. 5.

1. Yes No multi-language Location awareness Occasionally No

2. Yes Hidden options None Rarely No

3. Sometimes Different menus, hidden options

None Rarely No

4. Yes Shortcut menu Public map Rarely No

5. Yes Find bookmark shortcut None Rarely No

6. Yes Shortcut menu, hidden options

Share traces with friends Weekly No

7. Yes Shortcut menu Trace database Monthly No

8. Sometimes Hidden options Share traces Monthly No

9. Yes None Car sharing Often No

10. Sometimes Hidden options Share traces Monthly No

11. Yes Hidden options Share traces Often Yes

12. Yes Hidden options None Rarely No

final report appendixrevfcp - universidade de coimbrabraposo/youtrace/final_report_appendix.pdf ·...

Documents