Final Report MainRevComplete - Universidade de Coimbrabraposo/youtrace/Final_Report_Main.pdf ·...
94
Master in Informatics Engineering MSc. Thesis YouTrace Social Platform Bernardo Montezuma de Carvalho Planas Raposo [email protected] U.C. Supervisor: Francisco Camâra Pereira, PhD. 25 th of June of 2009
Transcript of Final Report MainRevComplete - Universidade de Coimbrabraposo/youtrace/Final_Report_Main.pdf ·...
Master in Informatics Engineering
MSc. Thesis
YouTrace Social Platform
Bernardo Montezuma de Carvalho Planas Raposo
U.C. Supervisor: Francisco Camâra Pereira, PhD.
25th of June of 2009
Abstract
This dissertation describes the work accomplished during the internship integrated
in the Masters in Informatics Engineering of the Science and Technology Faculty of
the University of Coimbra. The described content is focused on the study and
development of a web application, including the description of processes,
methodologies and produced results. These elements will help to understand the
characteristics of the project and how it will improve the student’s academic
education.
The purpose of this project was to develop a social platform that, integrated with the
YouTrace engine, can produce a World map from the traces submitted in the
application. The social aspects of the application were also in focus during its
development and a significant part of this thesis is related to these aspects.
The work described in this thesis can be divided into four areas of interest: analysis;
development; usability and optimizations.
The analysis phase included all the research performed for this project. This study
was mostly carried out in the first semester and focused the study of collaborative
mapping, social networking, web development frameworks and, recently, web
mapping application. The analysis on each one of these topics was very important to
the following development phase.
The development of the social platform was the task where we spent most of the
time of this project. It goes from the planning phase to the implementation of the API
and explains in detail all the different components of the application.
Usability was always a big concern during this project and we dedicated a lot of our
attention to it. Besides the wireframes inspection and the formal usability analysis,
we also focused on the user experience improvements.
Finally, we reserved some time to work on possible optimizations for the application.
This included a complete analysis, front-end optimizations and server performance
tweaks, with particular emphasis on the caching features.
3
Table of Contents
Abstract ........................................................................................................................2
Table of Contents.......................................................................................................3
List of figures ..............................................................................................................7
List of tables ................................................................................................................9
Glossary .....................................................................................................................10
1. Introduction ..........................................................................................................12
1.1. Contextualization...................................................................................................... 12
1.2. Motivation and Objectives ..................................................................................... 13
1.3. Work Plan................................................................................................................... 14
1.4. Work Methodology .................................................................................................. 14
2. State of the Art......................................................................................................16
2.1. Collaborative mapping ............................................................................................ 16
2.1.1. Open Street Map ................................................................................................. 16
2.1.2. Google Map Maker ............................................................................................. 17
2.1.3. TomTom Mapshare ............................................................................................ 18
2.1.4. Conclusions.......................................................................................................... 19
2.2. Web Mapping ............................................................................................................ 20
2.2.1. Map services ........................................................................................................ 20
2.2.2. Custom map applications.................................................................................. 22
2.2.3. Browser UI libraries............................................................................................ 24
2.2.4. Map servers ......................................................................................................... 25
2.2.5. Conclusions.......................................................................................................... 25
2.3. Social networks ......................................................................................................... 28
2.3.1. Facebook............................................................................................................... 29
2.3.2. MySpace ............................................................................................................... 30
2.3.3. LinkedIn ............................................................................................................... 31
2.3.4. Digg....................................................................................................................... 32
2.3.5. Flickr ..................................................................................................................... 32
4
2.3.6. Conclusions.......................................................................................................... 33
2.4. Framework Analysis ................................................................................................ 34
2.4.1. Object-Relational Mapping ............................................................................... 34
2.4.2. Migrations ............................................................................................................ 35
2.4.3. Security................................................................................................................. 35
2.4.4. Caching................................................................................................................. 35
2.4.5. Form Validation .................................................................................................. 35
2.4.6. Conclusions.......................................................................................................... 36
3. Planning.................................................................................................................38
3.1. Introduction ............................................................................................................... 38
3.2. Scenarios..................................................................................................................... 38
3.3. Requirements analysis............................................................................................. 39
3.4. Use cases ..................................................................................................................... 39
3.5. Wireframes ................................................................................................................. 41
3.6. Conclusions................................................................................................................ 42
4. YouTrace Web Platform......................................................................................44
4.1. Introduction ............................................................................................................... 44
4.2. Changes in the application ..................................................................................... 44
4.3. Application architecture .......................................................................................... 46
4.3.1. Models .................................................................................................................. 47
4.3.2. Controllers ........................................................................................................... 47
4.3.3. Views .................................................................................................................... 49
4.4. Database ..................................................................................................................... 49
4.5. YouTrace engine integration .................................................................................. 50
4.5.1. Engine input ........................................................................................................ 51
4.5.2. Engine output ...................................................................................................... 52
4.5.3. Remote calls ......................................................................................................... 52
4.6. Implementation......................................................................................................... 53
4.7. Application Programming Interface ..................................................................... 54
4.7.1. KML Export ......................................................................................................... 54
4.7.2. Semantic Web integration.................................................................................. 56
4.7.3. Adding points to traces...................................................................................... 57
4.8. Design ......................................................................................................................... 59
4.8.1. Initial design ........................................................................................................ 59
5
4.8.2. Alpha version design ......................................................................................... 60
4.8.3. Identity ................................................................................................................. 60
4.9. Testing......................................................................................................................... 61
4.9.1. Behaviour-Driven Development (rSpec) ......................................................... 61
5. Usability and User Interface ..............................................................................64
5.1. Introduction ............................................................................................................... 64
5.2. Wireframes inspection............................................................................................. 64
5.3. Formal usability analysis ........................................................................................ 65
5.3.1. Tools...................................................................................................................... 65
5.3.2. Analysis procedure............................................................................................. 67
5.3.3. Results and conclusions ..................................................................................... 67
5.4. User experience ......................................................................................................... 69
5.4.1. Modal windows .................................................................................................. 69
5.4.2. AJAX pagination with keyboard shortcuts..................................................... 70
5.4.3. Tooltips and helpers ........................................................................................... 72
5.4.4. Drag & drop grid ................................................................................................ 72
5.4.5. Final thoughts...................................................................................................... 73
5.5. Conclusions................................................................................................................ 74
6. Optimization analysis .........................................................................................75
6.1. Initial analysis ........................................................................................................... 75
6.1.1. Home page........................................................................................................... 76
6.1.2. User dashboard ................................................................................................... 77
6.2. Front-end optimization............................................................................................ 78
6.3. Back-end optimization............................................................................................. 79
6.3.1. Caching................................................................................................................. 79
6.3.2. Cache storage....................................................................................................... 80
6.3.3. Database optimization ....................................................................................... 82
6.3.4. Conclusions.......................................................................................................... 82
6.4. Server performance .................................................................................................. 83
6.4.1. Average load test ................................................................................................ 83
6.4.2. Internet simulation test ...................................................................................... 84
6.4.3. “Slashdot-effect” test .......................................................................................... 84
6.4.4. Stress test.............................................................................................................. 85
7. Conclusions...........................................................................................................87
6
7.1. Future work................................................................................................................ 88
8. References..............................................................................................................89
7
List of figures
Figure 1 - YouTrace platform global vision ...................................................................... 13
Figure 2 – TomTom Map Share interface .......................................................................... 18
Figure 3 – Map stack............................................................................................................. 23
Figure 4 – OpenLayers with Google Physical Layer view.............................................. 27
Figure 5 – Map service application .................................................................................... 28
Figure 6 – Social section use case diagram........................................................................ 40
Figure 7 – Social section wireframe.................................................................................... 42
Figure 8 – Platform page flow............................................................................................. 46
Figure 9 – Database view..................................................................................................... 50
Figure 10 – Engine input process........................................................................................ 52
Figure 11 – Trace visualization with KML layer .............................................................. 55
Figure 12 – Social section design ........................................................................................ 59
Figure 13 – Social section final design ............................................................................... 60
Figure 14 – Youtrace identity .............................................................................................. 60
Figure 15 – Silverback video output .................................................................................. 66
Figure 16 – Generated heatmap from dashboard page................................................... 66
Figure 17 – New search shortcut ........................................................................................ 68
Figure 18 – New action menu inside main tab ................................................................. 68
Figure 19 – Hidden options icon on the right corner ...................................................... 68
Figure 20 – Modal window ................................................................................................. 70
Figure 21 – Pagination in activity feed .............................................................................. 71
Figure 22 – Action tooltip .................................................................................................... 72
Figure 23 – Javascript grid................................................................................................... 73
Figure 24 – YSlow analysis for home page ....................................................................... 76
8
Figure 25 – YSlow weight graphs for home page ............................................................ 76
Figure 26 – Response time for home page ........................................................................ 77
Figure 27 – YSlow analysis for dashboard ........................................................................ 77
Figure 28 – YSlow weight graphs for dashboard............................................................. 78
Figure 29 – Response time for dashboard ......................................................................... 78
9
List of tables
Table 1 – Collaborative Mapping applications comparison........................................... 19
Table 2 – Map services comparison.................................................................................... 26
Table 3 – Social networking websites comparison........................................................... 34
Table 4 – Testing coverage................................................................................................... 63
Table 5 – Home page optimization comparison .............................................................. 78
Table 6 – Dashboard optimization comparison ............................................................... 79
10
Glossary
Term Description
AJAX Asynchronous JavaScript and XML
API Application Programming Interface
CMS Content Management System
CRUD Basic operations on a database (create, read, update, delete)
DOM Document Object Mapping
Framework Conceptual structure used to support the software development
Git Version control system
GZip Software application used for file compression
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IDE Integrated Development Environment
I/O Input / Output
Java Object oriented programming language
JavaScript Scripting language mostly used on HTML documents
jQuery Popular Javascript library
KML XML-based language schema for expressing geographic annotation
Microformats Web-based approach to semantic markup
MVC Design pattern Model-View-Controller
Open Source Approach to design, development, and distribution offering practical accessibility to a product's source
ORM Object Relational Mapping
Perl Dynamic programming language
PHP Dynamic programming language widely used on web applications
Plugin External software integrated in the application
Python Programming language with a minimalist syntax
Rails Common term for the framework Ruby on Rails
REST Representational State Transfer
RDFa Specification for attributes to express structured data in any markup language
RoR Common term for the framework Ruby on Rails
RPC Remote Procedure Call
11
SOAP Simple Object Access Protocol
SQL Structured Query Language
TDD Test Driven Development
Template Tool for generic programming
URL Uniform Resource Locator
Web Common term for World Wide Web
Web 2.0 Current tendencies in web design and web development. Also known as 2nd generation web application.
XHTML eXtensible HyperText Markup Language
XML eXtensible Markup Language
YUI Yahoo User Interface
12
1. Introduction
1.1. Contextualization
The YouTrace platform was originally created to act as a social platform, allowing
users to collaborate in the construction of a map of the world. In the beginning of this
thesis, the work was only focused on the Map Generation engine, because of its
importance on the platform. The engine was developed by Hugo Costa and Nuno
Pereira in the last two years, and is still a working project.
The vision for YouTrace platform can be divided in two areas: provide a social
platform where users can interact with each other and share their traces; and
generate a map of the world with a considerable degree of precision.
This will allow dynamic map generation, which can lead to the creation of some
innovative services like alternative routes with public transportation or decision
making advisory. The collected traces can also be a source for efficient route
planning, keeping information about road usage, average speeds and alternative
roads.
The YouTrace platform can also be applied to the study of people mobility and city
dynamics. With this platform, a continuous stream of data collected from real life
situations is available to researchers. These methods will generate more valuable
information than the traditional ones, such as field studies, counting or location
devices.
13
Figure 1 - YouTrace platform global vision
This project will focus on the development of the remaining YouTrace platform
components, with particular attention to the social platform and traces database. The
development of the Map Generation engine will follow the needs of the platform, but
will be done by other elements on the team.
1.2. Motivation and Objectives
Working on a scientific project is always exciting and gives the opportunity to
explore new paths and work with state-of-the-art technologies. Being part of the
development of a new application is a great motivation for this project, not only for
educational purposes, but also for the enrichment of the University’s legacy.
The objective of this project is to build a complete social platform, which will
integrate the existing Map Generation engine with all the main features of modern
social networks. This means that the work will mostly focus on two main areas:
social network and map rendering.
14
1.3. Work Plan
The internship was divided in two different phases, the first started on the 4th of
September 2008 and finished on the 21st of January 2009, corresponding to a full
semester. For the initial phase, the planning was based on a 16h per week working
schedule and it included all the sub-phases from contextualization to prototype
implementation.
The second phase took place on the second semester and was planned to a 40h per
week schedule. This phase started on the 10th of February 2009 and finished on the
20th of June 2009.
On the project plan, the work was divided in five phases:
1. Defining and planning the project
2. Development of prototype
3. Building phase
4. Testing phase
5. Deployment and launching
The first two phases were assigned to the first semester and the remaining phases to
the second semester. However, most of the work in the second semester was focused
on the building and testing phases. We are now entering in the deployment phase of
the private alpha version of the application.
For consulting purposes, a detailed plan with the work plan comparison is available
as Annex A.
1.4. Work Methodology
As an academic project, the work methodology is different from the enterprise
world. To this is added the fact that there is no client and we make most decisions on
the development process, having in mind the suggestions of the supervisor. This
gave considerable room for creativity and experimentation, but also required self-
control and a precise work plan to avoid project drifts along the process.
In the first semester, we had weekly meetings where some aspects of the application
were discussed and made a quick review of the work done in the preceding week.
15
When it was not possible to have the meetings, we tried to have online meetings on
other schedule to keep things updated.
With the departure of my supervisor to the USA in the second semester, we were
forced to keep strictly online meetings. This situation had no impact on the workflow
and we managed to keep an updated status of all the tasks in progress.
There is also a blog with up to date information about the development of the
platform. These posts are mostly technical, but are a good resource to check the
project status and be aware of the challenges encountered along the process. The
blog is available at http://nowiknow.wordpress.com
All the code generated from the implementation of the YouTrace platform is under a
version control system called git [1]. This system keeps a detailed log of all the
modifications in the source code and provides some tools to manage that
information. With git it is possible to have different people working on the platform,
without breaking the system’s integrity and maintaining files up to date.
16
2. State of the Art
2.1. Collaborative mapping
“Have you ever wondered why some parts of the world don’t have great maps and thought
how nice it would be if they did? Building a map is an exceedingly complex process, and it is
a challenge to reach all parts of the world.”[2]
This excerpt from Google Maps team’s blog can summarize the motivation behind
collaborative map making and the necessity of user interaction in modern maps.
There is no reliable way of displaying accurate information about roads, streets or
simply paths from all over the World. It is possible to have this kind of information
in specific areas that, for some reason [3], need a detailed view, but for many places
on Earth there is little information.
The lack of geographical data isn’t the only problem when developing mapping
applications, there is also the restrictions that some mapping agencies impose to
users. Most of geo data is licensed to these agencies and users have to pay to use it.
That is where collaborative mapping takes an important role, gathering user data to
build new maps. In that domain we can find two major applications (or tools), Open
Street Map and Google Map Maker. The first is the “father” of collaborative
mapping, an open source project with thousands of contributors. The second is the
Google’s approach to collaborative mapping, in an enterprise way and maintaining
the same restrictions of their Map API.
At this point is important to analyse these approaches and their main characteristics.
2.1.1. Open Street Map
Open Street Map (OSM) [4] is the de facto collaborative mapping platform. Every
single bit of data is available to anyone in a Creative Commons Share-Alike licence,
which means that you are free to use, distribute and adapt everything from OSM. On
this subject, OSM is considering changing [5] their licence to protect themselves (and
contributors) from big mapping companies, but the bottom line is that data from
OSM will always be free to everyone.
17
OSM uses a wiki style approach where everyone is able to edit anything, including
traces from other users. The system reliability is guaranteed by a revision system,
making possible to go back and forth in changes list. This structure is extremely
useful to manage all the modifications inserted by users, without jeopardizing the
previous community data.
To add new data to OSM, a five-step process is required:
1. Collect data
2. Upload data
3. Create/Edit OSM data
4. Add details
5. Render map
The first two steps are very simple and are only required when adding new
information to the map. Users use their traces as a base layer to edit map data.
After this ‘collect and upload’ step, users have to attach the submitted trace to the
existing map. They can also edit their own trace to correct any error caused by GPS
deviation. When everything is correctly edited, it is time to add some more
information to the trace, like add road type, POI’s, surrounding areas, etc. The final
step is to submit all this data to OSM and wait for the new version of the map.
It is important to notice that OSM doesn’t render updates in real time, this is a totally
separated process that runs in the background. Updates are queued for database
insertion to avoid system overload when contributors upload lots of (large) updates.
In this list we can observe that the first four steps require human interaction, making
this process boring and not so much user friendly, although people seem to be very
interested in OSM and the community keeps increasing every month.
2.1.2. Google Map Maker
Google Map Maker (GMM) [6] has a completely different approach on collaborative
mapping. Their service was built with a precise objective: to gather data from poorly
covered countries in Google Maps. And that is why they just enabled GMM features
to a specific group of countries [7], leaving other countries in the bench for
undetermined time. It is not known if the web giant will maintain this exclusivity for
long time, but is expected that in the future they will open the GMM worldwide.
18
In GMM, the process of adding new data is much more simpler than OSM, but has
some disadvantages. On the up side users don’t have to collect and upload their
data, on the down side they have to create and edit all the data by hand. This can be
an extremely demanding task when editing large areas and roads.
Another (very important) aspect is the licence on submitted data, which is very
restrictive. What Google says is that users are free to add new data to maps, but all
that data will be only available to Google. This clearly differs from OSM, but it is
likely that in the future some of this data will be available in some way to the public.
[8]
2.1.3. TomTom Mapshare
The TomTom Map Share [9] (TTMS) is perhaps the most popular collaborative
mapping software available in the market. With about 5 million updates [10] since the
release of the software, Map Share has become more and more popular among GPS
users, which can also indicate that users are willing to add relevant information to
their GPS devices and share it with others.
As a private and commercial application, TTMS clearly sets apart from the reviewed
applications and, although being a collaborative mapping application, its objectives
are completely different.
Figure 2 – TomTom Map Share interface
Map Share was created with the purpose of enabling user edition to existing routes.
Users have 8 predefined actions to interact with their maps:
• Block/Unblock street
• Reverse traffic direction
• Edit street name
19
• Add missing Points of Interest
• Edit Points of Interest
• Edit Speed limits
• Change turn restrictions
• Report other error
As we can see, all of these actions act on routes that already exist on TomTom’s
database and there is no possibility to add new streets to the map. This is the main
difference between TTM and all the other applications and puts TTM in a different
category of collaborative mapping.
It is possible that in the future TomTom decides to upgrade Map Share to a map-
building tool, but right now the available features make it impossible to build new
maps. Also, even if Map Share had the capabilities to become a truly collaborative
mapping application, it would only be available to TomTom devices and most of the
global community benefits would be lost.
2.1.4. Conclusions
To summarize, we have a simple comparative table with some selected features,
which we believe to be critical in collaborative map making.
Open Street Map Map Maker Map Share Youtrace
Editing tools
Edit public data
Open Licence
Worldwide availability
Import/Export data
Automatic aggregation
Map building
Table 1 – Collaborative Mapping applications comparison
We can see that OSM is the truly collaborative platform, while GMM has only few
features available. TTMS, as expected, has all the important features in map editing
but lacks most of the other features. In other hand YouTrace platform takes a
20
different approach and tries to bypass all that boring editing process by
automatically aggregating traces to maps. It lacks editing features, but there is room
for improvement in the future.
The distinguishing factor between YouTrace and other applications is the automatic
aggregation of traces. This feature will push away the need of human interaction on
map editing and make the process of adding new data simpler and less boring.
In conclusion, Open Street Map is a powerful and popular application, but has a
demanding process of adding new data. In other hand Google Map Maker is much
simpler, but lacks all the remaining features. TomTom Map Share is a good editing
application and is growing in popularity, although being only available in the latest
TomTom devices. Finally, YouTrace has some features that make it a valuable
application, but not having editing tools could be enough to push away some
potential users.
2.2. Web Mapping
Mapping features are becoming a requirement in modern web applications. The
recent improvements on geolocation services allowed the creation of rich Internet
applications.
When people think of adding these features to their application, there are two main
options: they use an all-in-one map engine embedded on their pages or they choose
to build a custom engine. We are going to analyse these two approaches in the
following chapters.
2.2.1. Map services
Map services are mostly proprietary frameworks, which allow third-party
applications under certain conditions. These services are very complete and have
exclusive features, but they also force developers to play by their licence agreement
rules. They also provide all the necessary tools to embed maps on the applications.
We will describe the three major proprietary frameworks and a special one based on
open source data.
Google Maps
21
Google Maps [24] is the reference in web mapping engines. Its simplicity and
extensive documentation makes it perfect for all kinds of applications, from simple
embedded maps to complex applications.
Google Maps has also some key features that set it apart from the other engines.
These features include the integration with other Google services and the Street
View, which is under heavy development.
The recently introduced third version of Google Maps API [25] revealed some new
features like the improved mobile support or the MVC architecture model. It is also a
sign that this is an API in constant development, which is very important for future
improvements on the applications.
Yahoo Maps
Yahoo Maps [26] is also a proprietary map service with a clean interface. Its interface
is probably its best feature comparing with other similar services.
However, in the developer’s perspective Yahoo Maps has fewer resources available.
This can be a big problem when you think of implementing an application with map
integration and need some important features.
For our platform, it is a requirement to have KML import and export features, which
aren’t available in Yahoo Maps. This and other limitations can be a problem if we
decide to use this map service.
Microsoft Bing
Microsoft has another competitor for the web mapping market, as expected. The
powerhouse launched Live Local, which was recently rebranded as Bing Maps [27], in
an attempt to rival with Google and Yahoo.
Microsoft Bing has some interesting and unique features like the Bird’s Eye view or
the integration with Virtual Earth. The Bird’s Eye view is the equivalent for Google
Maps’ Street View, although it uses a different approach. In this case, the rendered
view is an orthogonal projection of the map with a high level of zoom. One
important detail is that KML and other vector elements are also displayed in Bird’s
Eye view, which isn’t the case with Street View.
On the down side, there are lots of limitations imposed by Microsoft and the API
code isn’t as friendlier as Google Maps’ code.
CloudMade
22
Besides these proprietary map services, there is a free service with some interesting
features. Two members of OpenStreetMap founded CloudMade and it is basically a
map service built on top of OpenStreetMap data. Therefore, all the data can be used
freely with a Creative Commons Attribution 2.0 License. [28]
The map service has several APIs, web libraries and some services like routing or
geocoding. These services can be integrated in other applications so they aren’t
exclusive to CloudMade maps.
CloudMade is a good alternative to all the other map services and its ability to
integrate with other services and browser libraries can be very useful
2.2.2. Custom map applications
Modern online mapping services like Google Maps are very popular and have
several applications in different areas. However, it is possible to build a similar
mapping service with open-source tools [29]. This solution is very useful when
developers want to have complete control or need special features, which aren’t
available in the common online services.
Before analysing the available tools, we have to describe the architecture of the
application. This is often called as map stack and is followed by all the major online
services.
23
Figure 3 – Map stack
The visible section on the map stack is the browser UI, this will be the interface of the
entire application and connect directly to the tile server or the application server.
This interface is usually implemented in a javascript library that receives user events
and makes the correspondent requests to the map server.
The tile server is a server placed between the browser and the server. It is used to
cache the tiles generated by the server in order to improve the performance of the
application. When the UI requests a specific tile, the tile server checks and returns it
if it is in the cache or request a new tile from the map server, saving it for future
requests.
Finally there is the map server, which takes the geospatial data and renders the
graphical output. With this map server it is possible to customize the elements of the
generated maps, such as stroke colour, width and other styling options.
In the following chapters we will describe the available tools for each of these layers
in the map stack.
24
2.2.3. Browser UI libraries
The browser UI library is the interface of the map engine and it interacts with both
the user and the map server. All the map services described above have a built-in UI,
but it is possible to have a custom UI that accesses one of those map services or a
local map server.
These libraries can also be used as an abstraction layer, displaying the same data on
different map services. This approach eases the difficulty of changing map services
in the middle of a project and permits a more versatile application.
Mapstraction
Mapstraction is a UI library that interacts with all the major map services available.
This library is meant to act as an abstraction layer, allowing fast switching from one
service to another.
However, there are some limitations when using this library and not all the features
from the map services are available to the developer. [30]
This can be very useful when implementing simple applications that don’t require
some specific features from the map services. In general this library has the most
important features like markers, polylines and KML import, so the majority of the
applications can use this library without limitations.
OpenLayers
OpenLayers [31] isn’t just a UI library, but a pure JavaScript API for the creation of
web mapping applications. It also supports several standardized formats like OGC
WMS, KML or GeoRSS, which are integrated as layers into OpenLayers.
OpenLayers was created in 2005 by MetaCarta and released as an open-source under
a BSD-style license [32], which means that everyone is free to use and improve the
API.
This open mentality allowed a constant development and the addition of lots of
features. In fact, OpenLayers is a complete API that can act as an abstraction layer
and integrate with other map services, or can connect directly to a custom map
server or a tile cache.
25
The API is well organized in multiple classes and has detailed documentation for the
developers [33]. Another important section is the examples page, with around 140
practical examples with complete source code. [34]
OpenLayers is totally customizable and perfect for integration in the applications’
design. This is an important feature, because sometimes the default controls and
markers may not fit aesthetically in the overall page layout.
Finally, there is an interesting feature in OpenLayers, which is the integration with
CloudMade API. This works in both ways, so it is possible to use OpenLayers as
CloudMade’s Maps UI or implement the map with OpenLayers and use CloudMade
as the map source.
2.2.4. Map servers
The map servers are in the bottom of the map stack, but are also the most important
part of a map service. These servers must generate all the map tiles required by the
application, having in consideration the selected preferences.
Typically, the map server works as scripts that receive the input data and produce an
output image of that data. We will describe the most popular options available in the
market.
Mapnik
Mapnik [35] is the most popular map server and it is entirely free. Written in C++ with
some Python bindings, it is very fast and oriented to agile development. This makes
Mapnik the choice for many applications, including OpenStreetMap.
It has an extensive documentation and several practical examples to work with.
There are several plugins that extend Mapnik’s functionalities, such as cascading
stylesheets for the maps with Cascadenik. [35]
2.2.5. Conclusions
After this analysis we have to decide which is the best solution for our project based
on certain conditions. First of all it is important to compare all the described map
tools. For this task we have selected some of the most important features to integrate
these tools with the platform.
26
Google Yahoo Microsoft CloudMade Mapstraction OpenLayers
Integrated map service
Multiple map services
Custom controls
Custom lines and markers
Custom layers
KML/GeoRSS support
Street zoom level
External map server integration
Free License
Open-source
Table 2 – Map services comparison
Google and Microsoft have similar web mapping services, both have the necessary
features but Google’s code simplicity and documentation makes it the weapon of
choice in proprietary map services. CloudMade has almost the same features as these
two services, but its ability to integrate with OpenLayers can add some extra features
to this API. It is a very interesting alternative and all the data is free, which might be
a need in some applications.
On the browser UI libraries side, OpenLayers and Mapstraction are very similar as
abstraction layers, but OpenLayers has powerful tools to fully customize the
interface and integrate it to a dedicated map server. This is very important, because
with large amounts of data a dedicated server is a requirement in terms of
performance.
In the YouTrace platform, we have two types of map requirements that can have
different implementations. First, there are trace visualizations and personal maps
that just require simple maps and don’t have much data to process. Then we have
the world map that displays the generated map from all the traces submitted by the
users. This requires special attention to the large amount of data processed by the
map application.
27
There is no need of a dedicated server for the personal maps so we will use
OpenLayers as the UI combined with one of the existing map sources. The Web Map
Service from the Open Geospatial Consortium is a good base layer because it
provides a clean version of the World map, which might be useful to display the
traces. However, there should also be other layers like the Google Maps’ Satellite
view or the OpenStreetMap view to help users locating their traces on the map.
Figure 4 – OpenLayers with Google Physical Layer view
The world map, on the other hand, needs a dedicated map server structure to avoid
performance problems in the future. This is the same approach used by
OpenStreetMap and other applications that have to deal with large quantities of data
[37] .
OpenLayers is still the choice for UI as we can keep the same design although using
different data sources. Then, we will have a TileCache server, which will
communicate with the Mapnik server.
28
Figure 5 – Map service application
The data generated from the YouTrace engine is saved in the database. With this
data, the map server renders the tiles, which are saved in the tile cache and then
displayed by the browser UI as the base layer of the mapping application. On top of
the base layer, it is possible to have some markers or lines renderer by the UI so it
needs access to the database as well.
This will be the workflow of the map service application that will build the world
map of the YouTrace platform. Perhaps in the future there will be other solutions,
but for now we will implement this architecture, which has been tested with success
in several applications.
2.3. Social networks
In recent years the World Wide Web is changing to the so-called Social Web [11]. The
reason behind this change in the way which people use the Internet is the massive
grow of social networks.
In fact, looking at the last two years, we find that the fastest growing websites are in
the Social Media realm [12]. Sites like Facebook, MySpace, Digg or Flickr have entered
into the daily routine of millions of users worldwide [13], and it is expected that these
numbers keep rising in 2009.
29
A social network has some distinctive characteristics, such as individual user
profiles, communities or groups, relationships between users and individual
customization. To sum up, they all focus on sharing content and promoting
interactions between users.
There are many different ways of socialization in the web and every website
represents each one of them. Some target the same kind of socializing, but others
have a specific type. The following analysis will take a detailed look on the most
relevant social networks.
2.3.1. Facebook
With nearly 200 million unique visitors [13], Facebook [14] is the reference of social
networks. Born in 2004 as a private network for Harvard’s students, soon it became
so popular in the University circle that founders decided to gradually open the
application to other institutions. Today, it is a completely open network, although
retaining the original objectives of sharing personal profiles, messages and media
content between friends. [15]
In the application, each user is identified by an individual profile, which can be
customized with privacy preferences, favourite applications, personal data, photos
and many other modules available. With these features, users can have a
personalized profile that acts like their passport in the application.
Facebook tries to simulate real relationships by letting users describe the type of
relationship with other users. In this way, it is possible to distinguish family from
friends or colleagues. In Facebook, users can only be related with others after
confirmation.
The way that Facebook groups users is completely different from every other social
network, because it includes schools, universities, enterprises, cities, regions,
countries, fan groups, themed groups and every other kind of imaginable groups.
The first kind of groups adds important academic and geographic information to
user profiles and it is very common to associate profiles with teaching institutions.
After all, that was one of the original purposes of Facebook.
Users are stimulated to interact with their network in every page of the application.
It is frequent to find message boxes and friend suggestions while browsing and it is
30
possible to comment in virtually any section of the application including user
profiles, photos, groups, etc.
A unique feature of Facebook is the application platform, which permits the
deployment of external applications that extend Facebook’s functionalities. This is
very important not only to bring other companies and developers to the application,
but also to maintain a constant pace of updates with minor effort. Users can easily
integrate these third-part applications in their profiles and access
In conclusion, Facebook’s key factors are the similarities with real life found along
the application, which helps users easily connect and work with the application, and
the Facebook Platform, which ensures constant development of new and richer
applications.
2.3.2. MySpace
Along with Facebook, MySpace [16] is one of the most used social networks with
about 126 million unique visitors in 2008. [13] Originally created to enable content and
news sharing among friends, MySpace evolved to a social network focused on the
music business. [17]
This change on the target audience was a reflex of the addition of a media player to
each user profile. With this player, users were able to upload their own music and
share them with everyone. Soon, minor artists started to promote their songs over
MySpace and the application became one of the most important tools to discover and
promote every kind of music. In fact, nowadays, major artists also have a MySpace
profile where they can interact directly with their fans and promote their latest
songs.
Like Facebook, in MySpace a user has a personal profile highly customizable. But in
MySpace users can change the entire aspect of their profile, making it feel like a
completely different site. This lack of coherence in user’s profiles is one of the most
debated issues of MySpace, but maybe it is also one of the distinctive characteristics
of this application.
In MySpace user profiles are also group profiles (music bands, fan groups,
organizations, etc.) so there is just one kind of relationship in the application: friends.
In many cases, being a friend of a specific profile just means that the user is a fan or a
31
member of whatever is represented by that profile. The relations are more virtual
and don’t represent real life relations.
The social interactions are more like an extension of the application rather than a
purpose. With the launch of MySpace Music, the company clearly stated what would
be the direction of the social network, confirmed by the creation of an independent
record label just for MySpace music. [18]
Finally, there is also a well-developed API that permits the deployment of external
applications, just like Facebook, although not so popular.
2.3.3. LinkedIn
LinkedIn [19] is a business-oriented social network, launched in 2003 and mostly used
by professionals in many different industries. With around 30 million [x] registered
users, LinkedIn had a steady growth in the past years.
As a business application, user’s profile allows some professional information like
profession, employer, academic path, projects, etc. With this kind of information is
possible to have an advanced search system and find, for instance, all the present
and past employees of a specific company.
The unique features of LinkedIn are their private job board and Query & Answer
(Q&A) forum. With these tools, companies can post new job spots and users can
apply to them. Also, companies can start partnerships by exchanging contacts within
the application.
The Q&A forum is an important feature of the application, as it takes advantage of
all the knowledge from users to build a rich repository and encourage user
interactions.
Users can join groups and connect to each other, although these kinds of relations are
more business-like and not so personal as the previous social networks. In many
ways LinkedIn is very similar to Facebook, but it is clearly business-oriented and has
a different audience.
32
2.3.4. Digg
The Digg application [20] can be seen as a social newspaper instead of a social
network. Launched in late 2005, Digg still has the same initial purpose: sharing and
voting online content.
This application is mostly focused in online content and has lots of features to
interact with it. The profiles created by users allow them to submit new stories to be
voted by the community. Whenever a user finds an item that he likes, he can “digg”
that item and the overall count will be updated. Then the top items are displayed in
the front page of the application, gaining more visibility.
This is the basic system behind Digg and it emphasizes the community feeling
around the application. As an opposite of the previous social networks, Digg works
with a global community and there are no groups in the platform. Everyone can
submit, vote and comment on any story they like and the system will automatically
select the most important stories at a given moment.
It is possible to add friends to user profile, which will populate the friends’ activity
stream and notify users of any update from those users. Is not intended to stimulate
user interactions, but more like a following system that keeps users updated with the
latest news from their friends.
Digg’s minimalistic interface makes it very user friendly (actually users might only
use the basic actions provided by the application) and so popular. Today, it is one of
the primary sources for every kind of news and an important resource on Internet
users likes. In fact, the submission and voting system used in Digg has been used in
lots of other applications in many different contexts.
2.3.5. Flickr
Like Digg, Flickr [21] also has a specific target group: photography lovers. In 2004
Flickr was launched as a simple photo sharing service, becoming a complete social
network with the constant addition of new features. Flickr is a powerful application
hidden behind a simple interface. It has lots of features like tagging, auto-complete,
rss feeds, groups, sets, and more.
By creating new accounts, users have the possibility to upload photos to their
profiles (with some size limitations), comment on other photos, join groups or add
33
new friends. They can also set their photos to be public or only accessible by friends
or group members.
This is one of the advantages of using the friend system, protecting user’s photos
from public view. With this system it is also possible to view the latest friend’s
uploads.
In Flickr it is possible to join many groups with the same interests. These groups
have a common photo pool with all the photos selected by group members and it is a
good resource to discover new photos from users with the same tastes.
Flickr has also lots of tools to help users uploading their photos to the application.
The web interface is well implemented and allows multiple file upload, which is a
critical feature in a photo sharing application like this one. There are also standalone
applications developed to make this process more automatic.
In conclusion, everything on Flickr is photo-oriented and the social network was
developed to add more tools and provide a better user experience for users. Like
Digg, Flickr is one of the primary sources for photography content on the web.
2.3.6. Conclusions
To summarize this analysis, we have selected the most important features in social
networks and made a comparative table. The YouTrace column was written from the
current projected features, which can change in the final version.
Facebook MySpace LinkedIn Digg Flickr YouTrace
Profile customization
Friend/Follower system
Groups/Communities
User suggestion
Free registration
Advertisements
Privacy settings
Internationalization
Third-party Applications
34
API
Table 3 – Social networking websites comparison
As seen on this table, Facebook is the most complete social network, followed by
LinkedIn and MySpace. In other hand Digg and Flickr dropped some features to
focus on the needs of a specific groups. YouTrace has the most important features of
a social network and it is possible that in the future some new features will be added
to the application.
There are lots of social networks [22] and it was impossible to analyze each one of
them. We have selected the most popular and relevant to this project and made an
extensive analysis in order to highlight the main characteristics of a social network
and find the mandatory features to build next-generation social networks. [23]
2.4. Framework Analysis
Frameworks usually support the development of modern web applications. These
frameworks supply many tools to ease the development process, which include
libraries for database access, templates for views, session management and many
others. [24]
A web application framework is associated with a specific programming language so
it is important to have those languages in mind when choosing a framework to work.
The following analysis will focus on the most popular frameworks at the moment,
which are associated with the most popular programming languages. [39] We have
selected Ruby on Rails, CakePHP, Django, ASP.NET and Spring frameworks.
To summarize this analysis we have selected five categories, which we think are the
most relevant in a web application framework: Object-Relational Mapping,
Migrations, Security, Caching and Form Validation. In Annex B is available the
detailed analysis on each framework.
2.4.1. Object-Relational Mapping
• Ruby on Rails has true Object-Oriented mapping
• CakePHP simulates ORM with Arrays
35
• Django has true ORM with different engines
• ASP.NET needs ADO.NET Entity Framework
• Spring works with Hibernate, iBatis or JDO
2.4.2. Migrations
• Ruby on Rails has working migrations
• CakePHP has migrations, but not really integrated (YAML, PEAR, MDB2)
• Django has no schema evolution
• ASP.NET has no schema evolution
• Spring has simple migrations with Hibernate
2.4.3. Security
• Ruby on Rails has security plugins like Authentication, Role Requirement,
Active ACL
• CakePHP has ACL, Security and Auth components
• Djando is ACL based, has built-in Auth model and provides Cross-Site
Request Forgery and Cross-Site Scripting solutions
• ASP.NET has Login/Register controls, Membership and Roles built-in
support
• Spring works with Acegi
2.4.4. Caching
• Ruby on Rails includes modules: Pages, Actions, Fragments, Sweeping,
SqlCache
• CakePHP has only view caching
• Django provides view, database and filesystem caching
• ASP.NET has lots of caching components
• Spring allows declarative caching
2.4.5. Form Validation
• Ruby on Rails accept validation rules on Models retrieving error messages;
custom validation is also available
36
• CakePHP accept validation rules on Models retrieving error messages;
custom validation is also available
• Django has default validation rules and error messages for each datatype;
custom validation is also available
• ASP.NET has Validation Controls
• Spring displays error messages
2.4.6. Conclusions
From this analysis we can take some conclusions about the studied frameworks.
Ruby on Rails is, without question, the reference framework for most of the studied
frameworks and has great documentation to help developers, with many books and
tutorials. In other hand, Ruby is the least popular language, but is gaining more and
more fans over the years.
CakePHP is a good port from Ruby on Rails and takes a big advantage of the
popularity of PHP language. On the other hand, the way that PHP handles objects
(as arrays) has a terrible performance when having to deal with large models and
lots of requests. Also, the lack of good documentation could be a problem to
beginners.
Django has the advantage of using Python, which is popular and faster than Ruby.
These characteristics reduce the implementation time, making this framework a
powerful tool to develop quick and simple web applications. But Django still suffers
from maturity problems and the lack of migration can be a problem in the future.
ASP.NET has a big powerhouse behind, with all the benefits of the Microsoft support
to the entire .NET framework. This framework is the only to have a graphical
interface, which is a plus for beginners but can be very limitative to experienced
developers. Because of the automatically generated code, and having in mind that it
generally doesn’t follow the web standards, the HTML produced is almost
unreadable. ASP.NET is also dependent of Microsoft services like SQL Server or IIS
web server.
Finally, Spring has a rich set of service abstractions with some unique features that
use all the power of Java language. But this framework has lots of components and
doesn’t have good documentation to assist the development process. It isn’t exactly a
lightweight and simple framework, which requires lots of time to learn.
37
After reviewing the analysis made to the frameworks, it was decided to use Ruby on
Rails in this project. The characteristics of the framework, the orientation for agile
development, the excellent documentation and the REST philosophy were key
factors for this decision.
38
3. Planning
3.1. Introduction
In every project, the planning stage is one of the most important of all the
development process. When planning a web application, it is important to know the
purpose of the application, the target audience and the unique features that will
distinguish the application from the others. [43]
The creation of some hypothetical scenarios and making requirements analysis based
on them is a good starting point to understand the objectives and different uses of
the application. This analysis doesn’t have to be very specific at this stage, but it
must contain all the main features expected in the application. In other words, is not
required to have every possible user action described in the analysis, but it is vital to
know the key sections that must be included in the application.
From the result of the requirements analysis were produced some use case diagrams
to give a visual interpretation of the findings. Then it came to the final step of the
planning phase: Wireframing.
This is a crucial step because these wireframes will be the main reference for
application design. Also, a usability test was conducted on those wireframes to
improve the user interface and avoid some mistakes before the development phase.
3.2. Scenarios
Writing scenarios is usually the first step in the planning phase of an application.
They have some relevance on the process because they describe real situations where
the application could be applied. These stories include information about user
interactions, common actions and possible outcomes of the application.
Scenarios are often written in plain language, avoiding technical terms, so that
everyone involved in the project can understand the given examples. For this project,
it was asked to the members of YouTrace team to write some scenarios describing
how they would imagine using the YouTrace social platform.
39
These scenarios were written in Portuguese and the following excerpt describes one
of the possible uses of the subscription and messaging system in the YouTrace
platform:
“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
utilizadores apesar da sua mensagem aparecer para todo o grupo, deixando uma
notificação automática no perfil da pessoa a quem se dirige. (...)”
The remaining scenarios can be consulted in Annex C.
3.3. Requirements analysis
The requirements analysis can be described as a summarized version of the
scenarios. The process behind this analysis is very simple and it generates a list of all
the users needs gathered from the scenarios.
These lists are important to identify the main sections of the application and
distribute the requirements accordingly. It is also possible to have some
requirements that won’t be implemented, but they should be kept in the analysis for
future reference.
The requirement analysis is available in Annex C.
3.4. Use cases
Use case diagrams are a specific type of UML diagrams for graphical representation
of system functionalities. After the requirements analysis, it is important to have this
40
kind of visual description on the extracted functionalities and how they interact with
each other.
These diagrams are very useful to identify functionalities that can be separated as
modules, represented with “include”, “extend” or “generalization” relationships. It
is also possible to identify different roles in the system, represented as actors, which
are linked to the cases. In other words, Use case diagrams are used to show how
users can interact with a specific system.
In this planning phase, some use case diagrams were produced to illustrate the
principal actions in YouTrace social platform. One of the most important sections in
the application is the social section of user’s profile.
Figure 6 – Social section use case diagram
First of all, this social section is only available to registered users and they can access
it through their personal profile. In this section, users can view and manage their
contact network. The main screen includes three different lists: user’s subscriptions,
user’s followers and user’s groups. The search module present on this section adds
searching functionalities and retrieves a list of users or groups.
In every listing, it is possible to view the detailed profile of a single item (user or
group) and pause, unpause or delete that item from user’s network. If a user is
viewing other’s user or group profile, he can subscribe that user/group if they aren’t
already on his network.
41
The entire collection of use case diagrams is available in Annex C. Please note that
some of the studied features are no longer available in the application and these
diagrams should be considered deprecated.
3.5. Wireframes
Wireframes are simple illustrations that describe the contents of a screen. It’s not
supposed to have a detailed design on wireframes, but a simple draw that clearly
identifies the principal elements of a page. [44]
The purpose of a wireframe is to communicate initial design ideas and they are
mostly used in usability testing and prototyping, although recent innovations in
software development suggest that the use of wireframes should be avoided, moving
straight from requirements to functional prototypes. [45]
In this project it made sense to use wireframes to have a better understanding of the
global perspective of the application. Also, it was possible to make some usability
testing to proof those wireframes and eliminate some flaws of user interface before
the development phase.
To accomplish this task the OmniGraffle [46] application was used with custom
stencils from the YUI (Yahoo User Interface) team. These stencils follow the design
pattern guides [47] from Yahoo and are a standard in modern design of user
interfaces.
The wireframes built for the YouTrace application are very detailed and have precise
information about the most important elements in every screen. Given the large size
of each wireframe, the following figure is just an example of the produced
wireframes. In this case, we will analyze the same social section shown in the
previous use case diagram.
42
Figure 7 – Social section wireframe
From this wireframe it is possible to identify the four main actions illustrated in the
use case diagram: user’s subscriptions list, user’s followers, user’s groups and the
search box. The first three elements are displayed in a tabbed view (3) to avoid too
much scrolling from users and aggregates all the information in the same element
container. Pagination will also be available if required.
The search box (2) is placed in this screen to help users finding other related users
and groups to extend their network.
All the wireframes with detailed descriptions can be consulted in Annex C.
3.6. Conclusions
The planning phase took about one month and a half to complete, including the final
wireframes reviewed after the inspection (see Chapter 7.2 Wireframes inspection).
The objective of this phase was to build a knowledge base for the following phases,
which was achieved.
Having those resources ready, it was time to start the development phase, applying
the knowledge created on this phase. The development phase and the planning
43
phase will always be intimately related and there will be several references to this
section along the report.
The next chapter will be focused on the development of the prototype and
application architecture.
44
4. YouTrace Web Platform
4.1. Introduction
The development phase is where most of the platform’s coding is done. In this phase,
the documents produced in the planning phase are used as a reference to support the
incremental development of the YouTrace social platform.
The platform was developed in Ruby on Rails framework, which provides lots of
tools to assist developers, but has some specifications that developers should be
aware of (see 3.2 Ruby on Rails).
Ruby on Rails is commonly associated with agile development methodologies, which
promotes constant inspection and adaptation in small increments, providing
deployable and tested versions of software in a short amount of time. These
methodologies also emphasize collaborative work and are suitable to environments
where changing is a constant. [52] With this kind of methodology, the traditional
deliverables are replaced by different versions of working software. [53]
Although being mostly used in teams, this agile development was chosen for this
project due to its ability to integrate changes (even the big ones) in late stages of the
development.
4.2. Changes in the application
After the intermediate evaluation we had some major changes to the workflow of the
social platform and a massive interface redesign to support those changes. In the
next paragraphs, we will describe all of those changes and how they were
implemented in the application.
On the workflow side, we have decided to remove the navigation in the public
profiles, making it act as a virtual passport. This reorganization of public profiles
comes with our concern on users privacy and interface simplicity. Now, users only
show to the public exactly what they want and in the way that they meant it to be.
We have added some interface helpers like drag and drop capabilities,
45
collapse/expand sections and many other features. We believe that this is an
important evolution of the social platform, which will hopefully make it easier to
work with.
With the same purpose of making things simpler to users, we have also decided to
remove the possibility of creating groups. Instead, we have added tagging abilities to
the platform. In this first phase, tags can only be applied to traces, but in the future
we will open it to almost everything in the application, from users to events. We
think this will be extremely helpful and we are very excited to explore all the
possibilities of tagging within the social platform.
Once we had tagging capabilities in the platform we were able to replace the group
pages by tag pages. These pages aggregate traces with the same tag and users, which
have tagged those, same traces, also displaying the aggregated map. With the
changes made on public profiles, we now have two different types of “static” pages:
the private profile and the public profile. Having that in mind, we have decided to
make some modifications to the subscription service, specifically the way users are
connected to each other.
In the initial version of the application, users could subscribe and/or be followed by
other users. This friendship system based on followers raised some concerns in user
privacy as it could give the wrong idea to users. After some deliberation, the act of
following a user was transformed to the act of bookmarking a user profile. In this
way, users can add other user’s public profile to their bookmark page and only
access what they make publicly available.
Since we already implemented bookmarking to user profiles, we thought of
extending the functionality to tag pages. So, users are now able to bookmark user
profiles or tag pages and can easily manage them in their bookmark section. They
will also receive update events from the bookmarks on their activity stream.
It is very important to us that users spend as minimum time as possible learning how
to use the application. These changes take that in consideration plus the also crucial
aspect of user privacy. This will always be a requirement in the application and it is a
major concern when approaching new features that might conflict with user privacy.
As said before, the user interface was also target of an intense redesign. It wasn’t a
complete redesign, because we still had to follow the guidelines of the wireframes
46
inspection report. The layout is essentially the same, but with significant visual
changes and optimizations.
We were very pleased with the result of this redesign, which is very close to the final
product. The result of this redesign is available in Annex F.
4.3. Application architecture
Developing a Ruby on Rails application requires an MVC architecture, which
separates the code in three sections: one to deal with database requests (models), one
to process data (controllers) and another to display the processed information
(views) (see 3.2 Ruby on Rails). Before listing the components of each section, it is
important to have an overview on the YouTrace social platform page-flow. This will
be described using Garret’s visual vocabulary for Information Architecture, which is
commonly used to describe web applications or page flows. [54]
Figure 8 – Platform page flow
47
From this figure it is possible to identify two major areas, corresponding to the main
page and the user profiles. The main page is accessible by anyone, but user’s profiles
are only visible to authenticated users. That is a requirement to protect user data and
other sensible information in the application.
4.3.1. Models
• Bookmark
• Point
• Subscription
• Trace
• User
• User_mailer
• User_observer
• Vehicle
The “user_mailer” and “user_observer” are auxiliary models automatically
generated by the authentication plugin used in the application. In other hand the
“subscription” is a custom join table model that required implementation.
4.3.2. Controllers
In the controllers section are defined the actions that users can request. Those actions
include the default REST actions (new, create, show, update, edit, destroy), which are
automatically generated by Rails helpers. To those actions, some custom functions
are added if required, making the following controllers listing:
• Events
o Create Create an event
o Destroy Delete event
• Home
o Index Navigate to homepage
o Map Navigate to map
o About Navigate to about section
o Howto Navigate to How to section
o Social Navigate to social section
• Sessions
48
o New Show login view
o Create Login
o Destroy Logout
• Traces
o New Show create trace view
o Create Create trace
o Show View trace info
o Update Update trace info
o Edit Show edit trace view
o Destroy Delete trace
• Users
o New Show register view
o Create Register account
o Show View user profile
o Update Update user profile
o Edit Show edit user profile view
o Destroy Delete user
o Traces Navigate to user traces
o Network Navigate to user network
o Info Navigate to user info
o Prefs Navigate to user preferences
o Activate Activate user
o Bookmark_profile Request user profile bookmark
o Bookmark_tag Bookmark tag search page
o Delete_profile Remove user profile bookmark
o Delete_tag Remove tag page bookmark
o Authorize Authorize bookmark request
o Delete Remove authorized bookmark
In the controller is possible to find functions that process users requests, handle
interface navigation or are just private functions used by other actions. In fact, only
the actions mapped in the routes file are accessible to users.
49
4.3.3. Views
With MVC architecture, it is very easy to attach views to the respective actions
described in controllers. This means that most of the actions described in controllers
have a corresponding view, which was independently implemented.
The big advantage of using views is the possibility to use partials, which are
independent chunks of code that can be reused by any other view. For instance,
having a partial that displays a message item, that same partial can be used wherever
is a listing of message items. This is a good example of the DRY philosophy
associated to Ruby on Rails development and, most of all, guarantees code
consistence in the entire application.
There is no relevance in describing each on the implemented views, but they follow
the layout of the wireframes (see 4.5 Wireframes) and all the related design process
is explained in chapter 4.6 Design.
4.4. Database
A popular feature in Ruby on Rails framework is the use of migrations. Actually,
migrations act as a version control system for the database and completely remove
the need to use an external database manager. Also, with this kind of database
update log, it is possible to reconstruct the database in other systems. This is very
important to maintain the data consistency and avoid database failures when
working with multiple developers.
In this project, most migrations were automatically generated with the framework
helpers, but some of the tables had to be described separately, namely the join tables
used in many-to-many relations.
50
Figure 9 – Database view
This is the current database view, with join tables in light orange. Some of those
tables are automatically mapped in Rails application, without the need of creating a
specific model. In fact, only the “subscriptions” table have an implemented model to
access their custom attributes.
The “Taggings” and “Tags” tables, coloured in pink, are automatically created by the
acts_as_taggable_on plugin and it is used to store all the tags in the application and
their association with the existing models.
4.5. YouTrace engine integration
One of the main goals of building the YouTrace social platform is integrating it with
the existing YouTrace engine. Other team members have developed the engine over
the past year and it is now close to be integrated in the social platform.
We have been discussing the best way to handle this integration, since the social
platform is developed in Ruby on Rails and the engine in C++. We came to a
conclusion that seems to be the right approach taking all the factors in consideration.
51
In this integration there are two independent issues to take care: the input of traces to
the engine and the output to a map from the engine. Both of them are related to the
social platform, but each one will have a different process to achieve the expected
result. In the next chapters we will explain in detail what are those methodologies
and how will we implement them in the application.
4.5.1. Engine input
When we started developing the social platform, the YouTrace engine was already
implemented and almost fully functional. However, the input process was simplistic
and it just read all the NMEA files from a given path. This might work in a testing
phase, but it was clear that we needed a richer input process. There were two
requirements that we needed to fulfil: instant conversion to KML for quick
visualization in the platform and an asynchronous file processing to generate the
aggregated map.
To make the instant conversion to KML, we first thought that it would be only
necessary to make some custom functions in the engine, as this feature was already
implemented in the library. But soon we realized that this solution added
unnecessary workload to the engine. Besides, we still had no control over the KML
generation in the application. So we decided to break this input process in small
steps and generate points instead of the entire processed KML. In the application
database, we already had a table with the trace details and another table with the
associated tags, so we needed to create a third table to store the generated points.
These points are the result of a quick conversion performed on the NMEA file, which
is then transformed by a set of filters to prevent erroneous data from being
processed.
With the points stored in the database, all the information needed for both
requirements is immediately available by doing a simple database query. To
generate the KML we bind the request to the respective processor and it will
automatically build the KML file. This is an important feature in a RESTful Rails
application, which gives us this flexibility in the data-types retrieved from the
requests. For instance, to get the KML file from a specific trace, users (or other
applications) only need to make a request to /traces/<id>.kml and the response
will be the generated KML file. Of course, we will have to use some caching
techniques to avoid generating the same file each time there is a request.
52
We also wanted to keep the control of this process in the application, so the insertion
of new points in the database is made through an API. When the engine processes
the trace and gathers all the existing points, it calls the API function to insert those
points with the necessary information attached. With this method we can validate
the submitted data and trigger the respective events in the application.
Finally, when the engine starts to generate the map of the world with the new traces,
it will only select the points already stored in the database. This will optimize the
map generation process as all the parsing is done in advance.
The following figure is a representation of the entire input process described above.
Figure 10 – Engine input process
4.5.2. Engine output
The engine output is still under development by other team members and it is a bit
soon to describe the methodology used in this process. At this moment, the engine
produces a KML file containing the information of the entire globe, but obviously
that is not reasonable to use in a large-scale environment. The idea is to store the
map points and ways in the database and then render that information in a custom
built visualization tool.
4.5.3. Remote calls
We have already referred the integration of Ruby on Rails with C++, but we haven’t
explained how the methods are called from each component.
53
On the platform side, we are exposing the necessary functions through the REST
API. Calling these functions is as easy as making a request to a given URL. The
application will then send the appropriate response. This was very simple to
implement in the engine code and is now used to handle all the communication from
the engine to the platform.
As the communication is meant to be in both ways, we needed a way to call engine
methods from the platform. The immediate solution was ruby’s standard dynamic
linker extension, but it has lots of bugs and poor documentation. So we searched for
a good alternative and found FFI, i.e., Foreign Function Interface. FFI is a ruby
extension, which allows programmatically loading of dynamic libraries, binding
functions within them and calling those functions from Ruby code. With this
extension it was possible to implement a module that attached the necessary
functions from the engine library and made them available to be used in the
application.
require 'ffi'
module YouTrace
extend FFI::Library
ffi_lib "libyoutrace.so"
attach_function :convertFileToKML, [:string], :string
end
This is just a sample code to illustrate the simplicity of attaching engine functions to
the social platform.
In conclusion, the integration of independent modules is always a challenge, even
more when we try to integrate two different programming languages with specific
requirements.
4.6. Implementation
As we said before, the platform was built in Ruby on Rails and there are some
aspects of the implementation that worth being mentioned. We have made a detailed
description of the implementation process, which is available in Annex D.
This section is mostly technical and describes some of the problems and benefits
found when using this framework. It is important to understand some of the work
54
done during the internship and can also be used as a reference for future
implementations of similar applications.
4.7. Application Programming Interface
The application interface is not only focused on the visual aspects. It is very
important to have an interface that also allows the interaction with third-party
applications. Besides, this kind of interface can be very useful to integrate other
components of the platform like the YouTrace engine.
This is why the application-programming interface (API) should be included in the
development process. In our platform, the API includes several resources with
different approaches, which will be explained in the following chapters.
The development of the API is still in the beginning and it is mostly related with
integration issues or visualization purposes. However, the REST philosophy used
along the development of the platform is very useful when implementing an API, as
we will see later.
4.7.1. KML Export
The first feature of the API that requested our attention was the KML export. This
might be the most used feature in the application so we needed a clean and simple
method to get the KML representation of a given trace.
In RESTful Rails we have the ability to define the renderers used by the application
for each request format. In other words, we can have different outputs depending on
the type of the request made. By default, the framework supports several formats
like the most common HTML, JavaScript or even XML and JSON. For each one we
can build a different template to handle the request and produce the necessary result.
respond_to do |format|
format.html #show.html.erb
format.js #show.js.erb
format.xml #show.xml.erb
format.kml #show.kml.erb
end
55
The KML format is not supported by default, but we can easily add new formats by
editing the mime-types configuration file.
Mime::Type.register 'application/vnd.google-earth.kml+xml', :kml
With this command, we can now use the KML format in the application and define
the template for this request. Just like the HTML format, we can have multiple
templates for the KML, depending on the actions requested by the users.
First of all, we wanted a direct representation of a trace so we have implemented the
template for the show action in the Trace controller.
<name><%= @trace.name %></name>
<description><%= @trace.description %></description>
<LineString>
<extrude>0</extrude>
<tessellate>1</tessellate>
<coordinates><%= @trace.points.to_kml %></coordinates>
</LineString>
This is an excerpt of the KML template where we can find the line string that will
represent the trace in the visualization tool. The trace details are taken from the trace
model, but the points are stored in the Point model, which is associated with each
trace as we mentioned earlier in the chapter 4.5 YouTrace engine integration.
The KML export feature is used in the application by the preview map on each trace.
When a user goes to the trace details page, the application requests the KML
representation of that trace and displays it as an overlay in the preview map.
Figure 11 – Trace visualization with KML layer
56
In RESTful Rails we can have the KML file by simply adding the .kml extension to the
URL. The application will process that request and display the KML template instead
of the default HTML.
http://dev.youtrace.local/traces/4.kml
As we can see, it is very simple to extend the functionalities in a Ruby on Rails REST
application. In the future it is possible that other export formats are also
implemented, like JSON or GeoRSS.
4.7.2. Semantic Web integration
The Semantic Web [55] is growing in popularity with Google’s latest news about
Microformats [56] and RDFa [57] support in the search engine [58]. The idea is to give
meaning to the code in a transparent approach to the user, i.e., produce code that can
be read by humans and machines with no effort.
The concept of Semantic Web can be a bit difficult to understand in the beginning,
but we will try to explain it and demonstrate how it can be applied to our
application.
First of all we have a simple data model called Resource Description Framework
(RDF) [59], which is used to store metadata. It is similar to the Entity-Relationship
Diagram used to describe the database, but is defined by nodes, links and objects.
These three elements are called the triplets and are the base of the semantic web.
RDF becomes really useful when we use its serializations to work with the stored
data. In our case, the most important serialization is RDFa, which provides a set of
attributes to carry metadata. RDFa can be embedded in HTML to give that extra
meaning to the code.
The RDFa serialization is very flexible and it is possible to define any vocabulary and
use it in the applications. However, there are some vocabularies that are considered
as standards like the Dublin Core [60] for describing documents or Friend-of-a-Friend
[61] for describing relationships.
There are also some simple variations of RDFa called Microformats. There are
several Microformats available, each one with a precise function, which can be
embedded in the HTML code. The most important ones are hCard for people,
hCalendar for events, XFN for relationships and rel-tag for tags.
57
Google currently supports four different vocabularies in their search engine: Reviews
(hReview), People (hCard), Products (hProduct) and Organizations (hCard) [62]. They
support both of their RDFa and Microformats representation, which facilitates the
implementation of any of these vocabularies.
In the YouTrace platform we have two major candidates to include semantic
markup: bookmarks and tags. In the first one we can define an hCard to represent
each users’ information.
<div class="item vcard fr">
<img class="fl photo" height="40" width="40"
src="/images/users/thumb/1.png?1242674903" alt="avatar"/>
<a class="nickname url" rel="friend"
href="/users/braposo">braposo</a>
<small><span class="fn">Bernardo Raposo</span></small>
</div>
This is the HTML code generated for each bookmark on the bookmarks page. We
added hCard notation to the class of each block
With the tags, it was just necessary to define the type of relation of the given link.
<a rel="tag" href="/tag/coimbra">coimbra</a>
The real benefit of using semantic mark-up in the code is when other applications
interact with ours. Nowadays, the integration with search engines is very important,
but there are other applications that can improve the user experience using the
semantic web.
For instance, it is possible to relate a tag in our application with a tag in other
applications like Delicious (for bookmarks). It is also possible to export a bookmark
directly to a contact manager, without the need of adding that information manually.
There are some tools that can extract Microformats from pages and use that
information to perform specific actions. This can be a good solution to import user
details from other applications and automatically add them to our own application.
4.7.3. Adding points to traces
In the YouTrace engine integration chapter we said that the engine, which uses the
platform to add the filtered points to the trace, processes all the traces submitted in
58
the application. So we need to implement the interface to handle the requests from
the YouTrace engine.
Just like we did with the KML export, we had to implement an action to handle the
requests made to a specific URL. This follows the REST philosophy in the application
and it is a simple solution for our integration problem.
For this feature we created the addpoint function in the Trace controller, which was
mapped to the trace URL.
http://dev.youtrace.local/trace/4/addpoint
This action only processes POST requests to this URL and can receive the following
parameters: latitude, longitude, altitude, heading, speed, dop and avgSnr. The first
two parameters are mandatory and the remaining mostly related to the engine
processing.
It is very simple to add new points to a trace and the Point model can handle all the
validations with no effort.
def add_point
point = Point.new(params[:point])
trace = Trace.find(params[:id])
respond_to do |format|
if point.save
trace.points << point
format.xml {render :xml => point, :status => :created}
else
format.xml { render :xml => point.errors, :status =>
:unprocessable_entity }
end
end
end
This function returns a XML response (which can be changed to other formats if
necessary) according to the result of the action. This response can also be processed
by the server for validation purposes.
Future API methods should be based on this approach, which can also include other
data formats like JSON.
59
4.8. Design
Developers often underestimate the design of an application, but it has a major
relevance to users. The importance of having a good user interface and providing
great user experiences may be the key to a successful application [48]. This design
philosophy is the principle of User-Centered Design [49], which will be adopted as the
design process for this application.
This process was based on the latest design principles [50] and design patterns [47],
which ensures good usability and modern user interfaces. It was also used the YUI
CSS Grid framework [51] to help creating the layout grid, which supports all the
elements displayed in the page. These tools provide standard references in interface
design and are very important to assure layout consistency in every page.
4.8.1. Initial design
For demonstration purpose, we have selected the social section interface. This was
the first version of the design, which has changed significantly after the changes
introduced in the application.
Figure 12 – Social section design
At this point, the interface looked a bit different from the wireframes, but it was still
possible to identify the main elements of this screen. The absence of the search box is
justified by the low priority given to this element in the development process, which
means that it will only be implemented in future versions of the application. In other
hand, the tabbed navigation isn’t yet available because it requires AJAX functions
that aren’t implemented at this preliminary phase.
In Annex F are available some screenshots of the application design, which can be
related to the wireframes described in Annex C.
60
4.8.2. Alpha version design
We have mention earlier that the platform design had several modifications because
of all the changes on the application. Then, we added the result of the Formal
Usability Analysis and produced the alpha version of the application. This is the first
public version, so we needed a clean interface.
Figure 13 – Social section final design
The difference is significant and we believe that this design is coherent with the
application needs. It is possible that in the future small changes might occur, but this
will be the base design for the YouTrace social platform.
The complete overview of the application design is available in Annex F.
4.8.3. Identity
Besides the application interface, it was also created the identity of the YouTrace
social platform, although it was not in this project scope initially, but was a good
opportunity to exercise designer skills and add some value to this project.
Figure 14 – Youtrace identity
61
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 is far
easier to understand than the whole tracing concept.
The entire design process, including inspiration, colour palette and typography
selection is described in detail in Annex F.
4.9. Testing
Testing is a crucial task of the development as it ensures good quality code and
prevents errors of future implementations. Usually these tests are made after code
implementation and sometimes they don’t cover the entire application. To avoid
these mistakes, which can cost a lot of time and resources, developers started
planning things first and then implement the code needed for each test.
That is what Test-Driven Development (TDD) is all about, a development technique
that emphasizes testing over implementation. This technique relies on the “red,
green, refactor” philosophy in which developers start by implementing the tests
which will fail when run (red state), then implement the code needed to pass these
tests (green state) and finally optimize the code implemented before (refactor state).
TDD has other benefits like providing cleaner code by forcing developers to think
ahead and act like users to implement the tests. This will prevent lots of useless code
and will keep developers focused on optimizing code to pass the tests. Also, TDD
helps developers build smaller blocks of their application, improving productivity
and ensuring that every piece of code is covered by tests. To keep the integrity of
these blocks, mocks can be used to simulate other objects that aren’t yet
implemented.
4.9.1. Behaviour-Driven Development (rSpec)
Behaviour-Driven Development (BDD) is basically the same as Test-Driven
Development (TDD), but with a little (and vital) twist. There is a shift from
describing specific functions to describing what those functions are supposed to do.
Imagine a developer implementing tests for functions that don’t exist and that he
knows nothing about them besides knowing what they should do. Wouldn’t be
much easier if he could just implement test for what he is expecting to happen when
62
certain things happen? “A new registered user should have a confirmation message
sent to his email.” it is just as simple as this.
BDD is not only more user friendly, but also helps to a better understanding of the
code purpose. Actually, everyone can read the tests and understand the
functionalities described. This can be very useful to close the gap between
developers and clients, making them participate in the process and avoiding late
drawbacks and delays.
In Ruby, the most popular BDD framework is rSpec. Working with this framework is
really simple and it has lots of scripts to help developers with test implementation.
For demonstration purpose we have selected a code snippet that illustrates rSpec
usage in Ruby on Rails framework:
it "should be invalid without a name" do
@group = Group.new(@valid_attributes.except(:name))
@group.should_not be_valid
@group.errors.on(:name).should eql("is required")
@group.name = "group name"
@group.should be_valid
end
As described in the first line, this snippet is used to validate the requirement of a
name for Group model. In the beginning, the model’s instance should be invalid
without a name and should throw the desired error message. Then, with a new name
defined, the model’s instance should be valid and the test will pass. Notice that with
rSpec even the error messages can be validated.
We wanted to spend more time with testing, as it is a very important aspect of any
application, but unfortunately we had other issues that required our attention.
Nevertheless, the application should have a complete set of tests before the
deployment of the public beta.
63
Table 4 – Testing coverage
64
5. Usability and User Interface
5.1. Introduction
A good application must focus on users and especially on user experience. [63] The
best way to develop a user-centred web application is by including usability analysis
in the development process. There are many reasons to worry about usability [64] and,
like design, sometimes usability is also undervalued and only taken care late in the
process.
It is important to include usability analysis from the beginning of the project to keep
a constant focus on user vision and avoid late changes that can cost time and
resources. Besides, usability has an important role in the “experience versus
function” paradigm [65] as it provides valuable resources to the design process. In
short, a good design starts with usability [66]. Ultimately, usability analysis techniques
converge to a single objective: improve user experience.
When people talk about usability testing, they often associate it with expensive
analysis and lots of complex resources, but that is a misconception. In fact, according
to the usability specialist Jakob Nielsen [67], it is possible to achieve the same results
with no more than 5 users and performing small and affordable tests.
Usability testing was and will be used in several phases of this project, essentially
whenever is required to validate user interface components, such as wireframes or
prototype. This chapter is a compilation of all those tests performed along the
development process.
5.2. Wireframes inspection
The first task in usability testing was the wireframes inspection. For this task it was
selected a group of 10 people with different backgrounds and skills. It is important to
have a heterogenic group, because it will intensify the discovery of different issues
during the inspection.
65
To each member of the inspection group, was given a questionnaire and the
wireframes produced in the planning phase (see 4.5 Wireframes). The questions
were mostly guidelines to enlighten them about the purpose of the inspection and
what was the expected result of their inspection. Every time they noticed something
that wasn’t accordingly to their standards, they took a note on the inspection table.
When the entire inspection group finished their evaluation, all the notes taken were
aggregated in one single table. Then, the development team (in this case, myself)
reviewed each entry on the table and decided the respective outcome. Some
suggestions were simply ignored, others taken in consideration and most of them
made some changes to the final version of the wireframes.
The results of the wireframes inspection can be consulted in Annex G, although it is
only available in Portuguese.
5.3. Formal usability analysis
Formal usability testing is perhaps the most important task in all usability analysis.
This test puts users interacting with a real application prototype and performing
some specific tasks previously selected. It is a complicated and meticulous process as
it is intended to cover most of the possible user actions.
To achieve better results from this analysis we needed a good media support, namely
video and audio recording, and a data visualization tool from users clicks on the
application pages. We have selected Silverback [68] and ClickHeat [69] as our analysis
tools, as they provide us the required features for this task.
5.3.1. Tools
Silverback is a video and audio recording program that records both screen and
camera input. The data can be exported in video so that it could be reviewed and
analyzed in depth.
With this program, we had a detailed insight of all the mouse moves, facial
expressions and comments from users during their testing. This was very important,
and we believe it is an innovative testing method for small projects like this. With
few resources we could have a complete and detailed analysis.
66
Figure 15 – Silverback video output
The other tool is ClickHeat, which creates heatmaps from user clicks on the selected
application pages. This tool is targeted to a more general analysis and is very useful
to instantly recognize which areas on the pages have users attention.
The created heatmaps are very useful to discover unwanted clicks on certain tasks,
which represent sections on the application that are misleading the users. However,
this was a very specific analysis and the resulting heatmaps did not have much
relevance to the final result. This tool should be used in public versions of the
application to take the most advantage of the diversity of the users.
Figure 16 – Generated heatmap from dashboard page
67
5.3.2. Analysis procedure
For this analysis we took a group of 15 subjects to perform the test. To each one of
them was given a set of instructions and a list of tasks to accomplish.
Before the test we asked a few questions to determine the background of each
participant. We also conducted a post-test questionnaire to summarize the strengths
and weaknesses found in the application during their analysis.
The tests were supervised by one of the team members, which described the tasks
and helped the participants during the tests. This supervisor had a passive role in the
test and only interacted with the subjects in case of complete frustration.
The set of instructions and tasks, as well as the results from both questionnaires are
in Annex H.
5.3.3. Results and conclusions
From the results of the formal usability analysis (available in Annex H) we could
make some decisions about the user interface of the application.
First we will have to notice that almost all the participants had no trouble creating
new accounts and logging in the system. This is a very important aspect of the
application as it should be a very simple process to first-time users. However, during
the analysis, some users commented on the lack of information when created a new
account. We have decided to have a more complete signup page, without being
contained in modal window. The modal window for the login form is still available,
as it only requires a simple interface.
Other task that didn’t raise any problem to users was the search trace feature. This
tells us that it is important to users that this feature has its own shortcut button and
also that users immediately connect the task to the respective button. Taking this in
consideration we have decided to upgrade the existing search features with some
advanced search elements.
68
Figure 17 – New search shortcut
On the other hand, there were some tasks that caused difficulties to the test subjects.
Particularly the tasks involving the shortcut bar (Task #13 and #17), the hidden
options available on each box (Task #14) and the user status concept (Task #3).
The problem with the shortcut bar was not only related with its similarities with a
breadcrumb bar, which users often ignore, but also with the fact that some actions
only appeared in specific view of the applications without being noticed by users.
We have decided to completely remove the shortcut menu bar and relocate the
specific actions inside the main tab, whenever they were needed.
Figure 18 – New action menu inside main tab
With the hidden options, it was interesting to notice that a lot of users had trouble
finding these options in first place (Task #14), but after that they naturally found the
other available options (Task #16). This suggested that these options shouldn’t be
removed, but highlighted with an options icon or a tooltip helper.
Figure 19 – Hidden options icon on the right corner
69
Finally, we have decided to abandon the user status idea and enhance the possibility
of commenting on other users profiles. We think that users won’t come to YouTrace
to announce what are they currently doing. Also, the events automatically generated
when interacting with the application, such as adding new traces or bookmarking
user profiles, will be a relevant source of information about the user.
5.4. User experience
In a web application, user experience can be enhanced with javascript frameworks
like jQuery [70]. In the next paragraphs we will explain which features we have added
to the application and how they were implemented.
5.4.1. Modal windows
Modal windows are very useful to prevent redirecting users to frequently used
pages like login. This way, the login form is available in any section of the
application, making the act of logging in a simple and unobtrusive step in the
application. We have used a jQuery plugin called SimpleModal [71] that had just the
features that we needed. There are lots of other plugins to help building modal
windows, many of them with much more features than the plugin used, but we
wanted to keep it simple and only use what was really necessary.
$('a.modal').click(function (e) {
e.preventDefault();
$.get($(this).attr("href"), function(data){
$('.login-content',data).modal({
close: false,
position: ["15%",],
overlayId: 'login-overlay',
containerId: 'login-box',
onShow: login.show,
});
});
});
70
Figure 20 – Modal window
5.4.2. AJAX pagination with keyboard shortcuts
Sometimes it is necessary to use pagination to avoid large amounts of information
displayed in the same view. That is the case of the activity feed in user profiles. In
this section, we didn’t want to have just simple pagination that required page refresh
every time users flipped a page. We needed live, dynamic pagination with a touch of
awesomeness. Implementing this live update pagination was easy and we just
needed to use already built-in functions of jQuery.
$('div.pagination a').live("click",function(e) {
e.preventDefault();
$.ajax({
url: this.href,
data: { type: 'js'},
dataType: 'html',
success: function(html) {
$('#events-list').html(html).effect("highlight", {
color: '#FCFFE7' }, 2000 );
}
});
);
71
To add that extra spice, we thought it would be very useful to have keyboard
shortcuts to navigate through pages. This kind of feature is used in several
applications like Google Reader or FFFFOUND! and it is very important to enhance
application usability. It is just a small improvement, but it can add a lot to user
experience.
In order to implement this feature we used a jQuery plugin called HotKeys [72], a
simple and effective keyboard shortcut plugin. The chosen keys were ‘j’ and ‘k’ as
they represent similar actions in Google Reader and we wanted to take advantage of
this established perception. Every time these keys are pressed down in the user
profile view, the corresponding action link is triggered and the above function is
called.
$(document).bind('keydown',{ combi:'j', disableInInput: true },
function() { $('a.next_page').trigger('click'); });
$(document).bind('keydown',{ combi:'k', disableInInput: true },
function() { $('a.prev_page').trigger('click'); });
Figure 21 – Pagination in activity feed
72
5.4.3. Tooltips and helpers
Icons are often used in applications to visually represent actions, but once in a while,
users get confused by the design and don’t understand which icons represent which
actions. That is when tooltips become handy and have an important role in clarifying
possible confusing actions. Tooltips can also be used to notice hidden features in the
interface or provide some help to new users that aren’t experienced in the
application. Fortunately, there is an amazing jQuery plugin called qTip [73] to help us
build these tooltips with no effort at all.
$('.box-options img[tooltip]').each(function() {
$(this).qtip({
content: $(this).attr('tooltip'),
style: {
name: 'dark',
tip: {
corner: 'bottomRight',
size: { x: 10, y: 5 }
},
border: { width: 1 }
},
position: {
corner: {
target: 'topMiddle',
tooltip: 'bottomRight'
}
}
});
});
Figure 22 – Action tooltip
5.4.4. Drag & drop grid
One of the most important features in user experience within the social platform is
the ability of changing the interface according to user preferences. This feature
73
enhances the dynamic aspect of the interface and makes it suitable to any user. The
entire user profile was designed taking this in consideration and that is why we have
built page sections as independent blocks so that users could move them and change
the interface to their likes.
This might sound very complicated, but it was actually very simple to integrate
jQuery functions with the YUI CSS Grid that we have been using in the application.
We just had to use the sortable function in jQuery-UI and apply it to the yui-u element
of the CSS grid. The rest is just jQuery magic.
$('.yui-u').sortable({
items: '.box',
opacity: '0.5',
connectWith: $('.yui-u'),
handle: '.box-header .box-options img.move',
placeholder: 'drop-hover',
cursor: 'move',
cursorAt: { top: 20, left: 260 },
scroll: false,
tolerance: 'pointer',
helper: 'clone',
revert: true,
start: function(e,ui) {
$('.box-content', ui.helper).hide(); ui.helper.css({width:
'300px'});
}
});
Figure 23 – Javascript grid
5.4.5. Final thoughts
All of these little features complement the user interface, but also improve the
experience that users get from the application. That is beyond interface design and
74
for this task we focused essentially on users and how we could improve their
interaction with the application.
5.5. Conclusions
Usability testing is an important resource when developing a web application and
should be included in the process right from the start. This project was no exception,
integrating wireframes inspections in the planning phase and formal usability testing
in the development phase.
We believe that this analysis helped us improving the application interface, as well
as the overall experience when using the application. However, these tests should be
completed with a real life scenario after the launch of the public version of the
application. The platform should evolve to fulfil the needs of the users, so the
usability analysis is never complete and should be an ongoing task along the
development of any application.
75
6. Optimization analysis
Optimizations are often underestimated in the development process of an
application, but they have a crucial role in the improvement of user experience and,
more important, in the scalability of the application.
There are several optimizations, but it is possible to separate them in two large
groups: the front-end optimizations and the back-end optimizations. The first are
related to the improvements on the client-side, which include caching, HTTP
requests and image optimizations. The back-end optimizations are focused on
improving server performance by implementing caching mechanisms or reducing
database queries, among others.
The following chapters describe the optimization analysis process of the existing
application and explain some of the optimizations applied to it. This is the summary
of a complete analysis available in Annex E.
6.1. Initial analysis
First of all it is important to have a performance analysis on the initial version of the
application. This analysis will focus on the two most used pages: home page and
user dashboard.
To gather the required information we used the YSlow [74] tool combined with the
developer tools of Firefox and Safari. These tools provided an extensive report about
the page components and their respective weight on page load.
The main reason behind YSlow’s utilization for this analysis is the fact that it
incorporates Steve Souders’ rules for high performance web sites [75]. These rules are
the leading reference in optimization analysis and can be a helpful resource.
76
6.1.1. Home page
The home page of the application is the most hittable page in the application and
should be correctly optimized. We will start by displaying the results from the YSlow
analysis.
Figure 24 – YSlow analysis for home page
The YSlow analysis already includes some of the rules taken from Steve Souders’
book, but it is possible to take this analysis further and look at other performance
indicators.
Figure 25 – YSlow weight graphs for home page
From this figure we see that there are 26 HTTP requests made every time the page
reloads, even with the primed cache. This means that it is possible to reduce the page
77
load time by also reducing the number of HTTP requests and by using the cache
efficiently.
Figure 26 – Response time for home page
Concerning the response time, we can conclude that most of the time is spent loading
the images on the page. This can also be improved using some techniques, which we
will describe later.
6.1.2. User dashboard
The user dashboard page is the main page for a logged user. This means that every
time a user is authenticated in the application, he will be redirected to this page. We
will start again with the YSlow results.
Figure 27 – YSlow analysis for dashboard
The results are worst than the main page. This is mostly because the several HTTP
requests made by this page.
78
Figure 28 – YSlow weight graphs for dashboard
First, we immediately notice the 47 HTTP requests. From these 47 requests, 33 are
image requests, which can be easily improved with some other techniques. However,
these images are very small and most of the page load weight is in the javascript
files. In the next chapter we will see how this can be optimized.
Figure 29 – Response time for dashboard
Regarding the response time, we have the confirmation of the previous analysis.
Most of the load time is spent on images and script files, so we should focus our
front-end optimization on these elements.
6.2. Front-end optimization
The YSlow tool is very useful to rank certain pages accordingly to the Steve Souders
rules for front-end optimization. We applied some of these rules and studied the
impact of each one in the application. The detailed results are available in Annex E.
YSlow Weight (Kb) Response (ms)
Baseline 66 408.4Kb 352ms
Final 98 327.1Kb 305ms
Improvement +148% -20% -14%
Table 5 – Home page optimization comparison
79
In the home page, we almost achieved a perfect score of 100. The problem was in the
rule “Don’t scale images in HTML”, which conflicted with our fluid layout images,
but was not a major problem anyway. The weight and response time improvements
were marginal, because most of the page weight is on the three big images and we
were unable to optimize them.
YSlow Weight (Kb) Response (ms)
Baseline 59 537.8Kb 803ms
Final 96 177.4Kb 584ms
Improvement +163% -67% -27%
Table 6 – Dashboard optimization comparison
The dashboard got an excellent score also and just had problems with the many
requests made to build the layout. Due to the fluid layout we were unable to
optimize this requests by using CSS sprites. This technique was the main responsible
for the 67% reduction on page weight.
More important than these results is the fact that we now have fewer HTTP request
and an efficient use of client-side caching, which allows major reductions from server
load.
With these optimizations we have prepared the front-end for the upcoming back-end
optimizations. These will mainly focus on the server-side caching and the
configuration of max age and etags from the cached fragments.
6.3. Back-end optimization
For this project, the objective in back-end optimization is assuring that the
application is scalable and that it keeps the load weight out of the server. The best
way to achieve this was to focus on caching mechanisms and optimizing database
queries.
6.3.1. Caching
In Ruby on Rails, we have three different ways of caching elements in the pages. We
have Page Caching, Action Caching and Fragment Caching. Then we can also
configure the storage type for this caching, but we will discuss that later.
80
Page Caching is the most effective type of caching, but also the least flexible. With
page caching it is possible to keep the entire page stored in the filesystem, which will
be served to the client without even touching the application. This option is ideal for
static pages, but it is impossible to use with very dynamic pages. In the YouTrace
platform we can’t have this kind of caching because the majority of the pages has
dynamic content. Nonetheless, using page caching might be a possibility if combined
with AJAX request on certain pages.
So, we started to look at Action Caching and its possible applications in the platform.
With action caching, we can cache a single action instead of the entire page. This
gives us a little more flexibility than page caching, especially when we have pages
that only depend on certain filters like authentication. With action caching it is
possible to bypass the problems of caching the entire page content. In our
application, we found that main sections like “Home”, “How to” and “About” were
good candidates to this type of caching. However, a logged user can also access these
sections so we had to restrain the caching to visitor’s page only.
Finally, there is also Fragment Caching. This type of caching is mostly used to cache
specific blocks in the views. This was a much more helpful caching, as we could
cache precise content inside the displayed page. Good examples of possible blocks
for fragment caching are the main navigation and the footer. In Annex E there is a
detailed description of how we implemented Action and Fragment Caching in the
application and what was the impact on page requests.
6.3.2. Cache storage
There are five built-in cache storages in Rails, each one with different approaches to
this question:
• File store – uses individual files to store cached elements
• Memory store – uses a simple hash to store values
• Database store – the same as Memory store, but uses a DRb server instead
• Memcached store – uses memcached to store values in a shared memory
cache
• Compressed memcached store – works just like regular memcached store, but
uses GZip to compress the data
81
By default, Rails applications use the File store for caching, but it is very simple to
change this configuration. In fact, we just have to declare in the configuration file
which cache store we want to use and Rails will do the integration work for us.
config.cache_store = :mem_cache_store
In this project we changed to a Memcached store. Memcached was originally created
to improve the speed of LiveJournal, but soon other companies realized its benefits
against other cache stores [76].
Memcached is a high-performance, distributed memory object caching system,
which can store anything from database queries to entire views. Basically is a hash
table in memory that can be accessed by multiple instances. This feature is crucial to
large, distributed applications and it has an important role in the scaling of Ruby on
Rails applications.
This cache store can be used as object store, caching database objects, or as a
fragment cache store, caching rendered blocks. We have used both in the YouTrace
social platform and there are detailed examples in Annex E, which demonstrate how
did we implement the caching mechanisms in the application.
The problem of cache expiration is, perhaps, the biggest concern with caching. In
Rails we have some cache expiration methods that can be combined in a Sweeper.
These sweepers will observe a specific model and whenever there is a database
action on that model, it performs a cache expiration request. While this might work
on small applications, it is very difficult to correctly expire every cached block on
larger application, leading to unwanted cache inconsistencies.
Once again, with Memcached it is possible to bypass these problems with two
different approaches. First, we have the expires_in condition that can be set to every
cache entry. We can explicitly say that a specific block will expire in 10 minutes, for
example.
The other method, and the most popular one, is using intelligent hash keys to control
cache expiration. For instance, we can use a key like users-braposo-events to store the
events array of a user. But this key will always be the same even if this event list gets
updated, so we end with the same expiration problem. Using an intelligent key will
solve this problem as we can use something like users-braposo-events- 581243474826 as
our cache key. The timestamp in the key is a combination of the array size and the
updated_at value of the last element on the array. This way, every time this list gets
82
updated a new timestamp will be generated and the older cache entry will be
deprecated.
This technique raises the immediate question of how are these deprecated entries
erased from the cache. Once again, Memcached automatically replaces the older
entries with new ones whenever it is needed. The combination of intelligent keys
with smart memory management is the ideal solution to the cache expiration issue.
However, the Memcached store is better suited for big distributed system with
several server instances. In small application, the advantages of using this store
aren’t significant and it may even reduce the performance of the application.
6.3.3. Database optimization
In Rails, most of the database requests rely on the ActiveRecord, which is very useful
to simplify the process of mapping the database tables as application objects.
However, behind the hood of ActiveRecord we find complicated, and sometimes
unnecessary, queries. This can be improved by re-implementing some of these
queries or using some advanced options to optimize the queries.
Another database optimization is counter caching. This can be easily implemented in
the application by adding a new column to the designated tables. This column will
maintain an updated count value to be used instead of the count requests. This is
very useful to optimize pages where a count is needed, like the number of
bookmarks from each user or number of pending requests.
At this moment, we haven’t started looking deeper into the queries made by the
application, but it will be analysed for sure. Although, we had some concerns about
reducing database hits with the use of fragment caching and memcached.
6.3.4. Conclusions
From the results shown on Annex E we can conclude that caching is a must-have in
any application designed to have multiple users and lots of dynamic data. However,
it is important to implement it wisely to avoid unnecessary trips to the cache.
Another important aspect to have in mind is the cache expiration. It is mandatory
that all the cache hits return valid data so this has to be a constant concern when
implementing the caching mechanisms.
83
6.4. Server performance
In this project we also tested the server performance in order to have some extra
information about the importance of caching mechanisms and how would the server
react under heavy load.
For this purpose we used three different benchmarking tools: ApacheBench [77],
httperf [78] and Siege [79], with the latter being our main tool. We weren’t able to test
the production server so this section should be interpreted as a guide for future tests.
6.4.1. Average load test
Using ApacheBench, we created 20 concurrent clients with 1000 total requests,
making 50 requests per client. This test is intended to evaluate the server response on
average load so it should be targeted to one of the heaviest pages of the application,
like user profiles. It is a simple test and a good comparison base for the other tests.
ab -n 1000 -c 200 -t 5 http://dev.youtrace.local/
In the results, it is important to compare the values of the requests per second and
the time per request. These two indicators will determine the capability of server
response on average load.
Server Software: Apache/2.2.11
Server Hostname: dev.youtrace.local
Server Port: 80
Document Path: /
Document Length: 6335 bytes
Concurrency Level: 20
Time taken for tests: 77.764 seconds
Complete requests: 1000
Failed requests: 1
(Connect: 0, Receive: 0, Length: 1, Exceptions: 0)
Write errors: 0
Non-2xx responses: 1
Total transferred: 6986140 bytes
HTML transferred: 6329200 bytes
Requests per second: 12.86 [#/sec] (mean)
84
Time per request: 1555.287 [ms] (mean)
Time per request: 77.764 [ms] (mean, across all requests)
Transfer rate: 87.73 [Kbytes/sec] received
6.4.2. Internet simulation test
For this test, we used Siege to create 50 clients, each of them making 20 random
requests from a set of URLs at random intervals between 0 and 3 seconds. This is
perhaps the most elucidative test as it simulates what we can call a regular
application usage of 50 concurrent clients.
With Siege it is possible to test POST actions and even enable caching as if it was a
real browser. This permits several testing scenarios and it is a very useful tool to test
every aspect of the application.
siege -r20 -c50 -i -f dev.txt
Once again it is important to compare the transaction rate, the response time and the
amount of transferred data. This last indicator is useful to measure the impact of
caching in the application.
Transactions: 1000 hits
Availability: 100.00 %
Elapsed time: 30.55 secs
Data transferred: 1.97 MB
Response time: 0.88 secs
Transaction rate: 32.73 trans/sec
Throughput: 0.06 MB/sec
Concurrency: 28.97
Successful transactions: 1000
Failed transactions: 0
Longest transaction: 1.33
Shortest transaction: 0.03
6.4.3. “Slashdot-effect” test
Sometimes, the power of social media sites like Slashdot or Digg hits the server with
thousands of requests per second. This is a feared situation and it is good to be
prepared in advance for this situations.
siege –r5 –c350 -i -f dev.txt
85
To simulate this kind of effect, we created 350 concurrent clients with Siege. Each
client with 5 requests at random intervals. Two important indicators are the server
availability and the number of successful transactions.
Transactions: 959 hits
Availability: 54.80 %
Elapsed time: 39.63 secs
Data transferred: 0.19 MB
Response time: 1.66 secs
Transaction rate: 24.20 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 40.22
Successful transactions: 416
Failed transactions: 791
Longest transaction: 10.51
Shortest transaction: 0.00
6.4.4. Stress test
Finally is also good to test how many requests the server can handle in a certain
period of time. In this test, we used httperf to generate 150 new requests per second
in a total of 10000 requests. The idea was to see how many of them have a successful
response in less than 5 seconds.
httperf --server dev.youtrace.local --num-conn 10000 --num-call 1 --
rate 150 --timeout 5
In the results have in mind the request rate and the total number of requests/replies.
From this information it is possible to see how the server handles the large number
of requests.
Total: connections 10000 requests 9725 replies 8773 test-duration
66.661 s
Connection rate: 150.0 conn/s (6.7 ms/conn)
Connection time [ms]: min 0.1 avg 175.8 max 5273.1 median 0.5
Connection time [ms]: connect 190.6
Connection length [replies/conn]: 1.000
Request rate: 145.9 req/s (6.9 ms/req)
Request size [B]: 71.0
86
Reply rate [replies/s]: min 38.0 avg 131.1 max 151.8 stddev 41.1
Reply time [ms]: response 146.6 transfer 0.2
Reply size [B]: header 302.0 content 817.0 footer 0.0 (total 1119.0)
Reply status: 1xx=0 2xx=402 3xx=0 4xx=0 5xx=8371
CPU time [s]: user 9.12 system 24.80 (user 13.7% system 37.2% total
50.9%)
Net I/O: 154.1 KB/s (1.3*10^6 bps)
Errors: total 1227 client-timo 657 socket-timo 0 connrefused 0
connreset 570
87
7. Conclusions
We believe that most of the objectives for this project were achieved. At the end of
this year we have built a social platform from the scratch, integrated the existing
engine with the platform and made some important research on different
characteristics of the application.
One of the most important aspects of this project was the knowledge acquired form
the study and development of the application in the Ruby on Rails framework. This
learning process was gradual, as new requests and features required a deeper
analysis on the framework solutions.
The framework specifications, as well as the problems and solutions encountered
during this project, are described in detail in this dissertation and it can be used as a
valuable resource for future developments of similar applications in other projects.
The main characteristic of this project was its diversity of the studied subjects. All
these different topics highlighted the learning purpose of this project, which made
the connection between the theoretical study and its practical applications. In this
project, we could apply a lot of the knowledge acquired in the previous courses, but
also learn new concepts and methodologies.
We tried to focus on many aspects of the application, event those who are often
disregarded in the development of the application, such as the extensive usability
and optimization analysis, the application of semantic web in the API
implementation, and all the research on design and user experience.
There were things that didn’t evolve as expected initially, such as the testing of the
application or the implementation of the map server application. However, these
topics were analysed in this dissertation, and the path is open to properly achieve
these goals in near future.
In conclusion, this project was a worthy experience and helped with the
development and consolidation of several engineering competences. Besides, the
result of this project will be crucial to the evolution of the YouTrace application and,
therefore, to the enrichment of the Department’s legacy.
88
7.1. Future work
In spite of all the features described in this dissertation, the YouTrace Social platform
is not ready for public launch at this moment. There are some important aspects that
should be considered before launching the application:
• Complete the remaining testing cases
• Implement the map stack for the world map renderer
• Continue the development of new features of the API
• Extend the import and export of traces to other formats
• Perform production server benchmarks and optimizations according to the
guidelines of this dissertation
• Analyze the impact of database optimizations
• Improve the privacy settings of the application
• Assure that the entire application is safe from forgery attacks and all the
personal data is secured from unwanted requests.
• Implement the administration area
• Add internationalization to allow multiple languages in the application
• Refine the usability analysis with real user experience (improved heatmaps
and other personal feedback)
• Research on game mechanics and possible application in the platform
Some of these items are mandatory to successfully deploy a robust application, but
others are just a complement of the work done in this project.
89
8. References
1. YouTrace social platform GitHub’s repository –
http://github.com/braposo/youtrace/tree/master
2. Katragadda, L.; Jain, S., “Making your mark in the World”, Google Lat-Lon Blog,
2008 – http://google-latlong.blogspot.com/2008/06/making-your-mark-on-world.html
3. Flickr used OSM data for street-level view in the 2008 Beijing Olympic Games –
http://blog.flickr.net/2008/08/12/around-the-world-and-back-again/
4. Open Street Map – http://www.openstreetmap.org/
5. Fairhust, R., “The licence: where we are, where we’re going”, OpenGeoData, 2008 –
http://www.opengeodata.org/?p=262
6. Google Map Maker – http://www.google.com/mapmaker
7. Countries editable in Google Map Maker –
http://www.google.com/mapmaker/mapfiles/s/launched.html
8. Forrest, B., “Google's GeoData, Open Street Map and Tele Atlas”, O’Reilly Radar, 2008
– http://radar.oreilly.com/2008/07/google-mapmaker-open-street-map-data.html
9. TomTom Map Share – http://www.tomtom.com/page/mapshare
10. “TomTom announces five millionth Map Share™ improvement report”, TomTom Press
Release, 2008 – http://business.scoop.co.nz/?p=1771
11. Social Web, Wikipedia – http://en.wikipedia.org/wiki/Social_web
12. Meattle, J., “Top-50 Websites – Ranked by Unique Visitors”, Compete, 2007 –
http://blog.compete.com/2007/10/30/top-50-websites-domains-digg-youtube-flickr-
facebook/
13. Schonfeld, E., “Top Social Media Sites of 2008 (Facebook still rising)”, TechCrunch,
2008 – http://www.techcrunch.com/2008/12/31/top-social-media-sites-of-2008-facebook-
still-rising/
90
14. Facebook – http://www.facebook.com/
15. Facebook, Wikipedia – http://en.wikipedia.org/wiki/Facebook
16. MySpace – http://www.myspace.com/
17. Sellers, P., “MySpace cowboys”, CNN Money, 2006 –
http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/index.htm
18. “MySpace launches record label”, Associated Press, 2005 –
http://www.usatoday.com/life/music/news/2005-11-03-myspace-records_x.htm
19. LinkedIn – http://www.linkedin.com/
20. Digg – http://www.digg.com/
21. Flickr – http://www.flickr.com/
22. List of Social Networking Websites, Wikipedia –
http://en.wikipedia.org/wiki/List_of_social_networking_websites
23. Gohring, N.,“Researchers help define next-generation social networking”, Macworld,
2008 – http://en.wikipedia.org/wiki/List_of_social_networking_websites
24. Google Maps API v3 documentation –
http://code.google.com/apis/maps/documentation/v3/
25. Kataria, M., “Announcing Google Maps API v3”, Google Geo Developers Blog, 2009
– http://googlegeodevelopers.blogspot.com/2009/05/announcing-google-maps-api-v3.html
26. Yahoo Maps documentation – http://developer.yahoo.com/maps/
27. Microsoft Bing Maps documentation – http://www.microsoft.com/maps/developers/
28. Creative Commons Attribution 2.0 License –
http://creativecommons.org/licenses/by/2.0/
29. Smith, P., “Take Control of Your Maps”, A List Apart, 2008 –
http://www.alistapart.com/articles/takecontrolofyourmaps
30. Mapstraction features matrix – http://mapstraction.com/features.php
91
31. OpenLayers – http://www.openlayers.org
32. OpenLayers BSD-like license – http://svn.openlayers.org/trunk/openlayers/license.txt
33. OpenLayers API documentation – http://dev.openlayers.org/releases/OpenLayers-
2.7/doc/apidocs/files/OpenLayers-js.html
34. OpenLayers examples – http://www.openlayers.org/dev/examples
35. Mapnik – http://www.mapnik.org
36. Cascadenik – http://code.google.com/p/mapnik-utils/wiki/Cascadenik
37. Smith, P., “About our maps”, The EveryBlock Blog, 2008 –
http://blog.everyblock.com/2008/feb/18/maps
38. Web application framework, Wikipedia –
http://en.wikipedia.org/wiki/Web_application_framework
39. “TIOBE Programming Community Index for January 2009”, TIOBE Software, 2009 –
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
40. Ruby language – http://www.ruby-lang.org/en/about/
41. Koz, “RailsConf Recap: Skinny Controllers”, The Rails Way, 2007 –
http://www.therailsway.com/2007/6/1/railsconf-recap-skinny-controllers
42. The PHP Programming Language, Tiobe Software, 2009 –
http://www.tiobe.com/index.php/paperinfo/tpci/PHP.html
43. Bowlby, S., “6 Phases of the Web Site Design / Development Process”, I Design
Studios, 2008 – http://www.idesignstudios.com/blog/web-design/phases-web-design-
development-process/
44. Brown, D., “Communicating Design: Developing Web Site Documentation for Design
and Planning”, New Riders, 2006, Chapter 10.
45. Verba, D., “Sketching in Code: the Magic of Prototyping”, A List Apart, 2008 –
http://www.alistapart.com/articles/sketchingincode
46. Omnigraffle – http://www.omnigroup.com/applications/OmniGraffle/
92
47. “Yahoo Design Pattern Library”, Yahoo – http://developer.yahoo.com/ypatterns/
48. Campbell, C., “The importance of Design in Business”, Particle Tree, 2007 –
http://particletree.com/features/the-importance-of-design-in-business/
49. Katz-Haas, R., “User-Centered Design and Web Development”, Society for Technical
Communication, 1998 –
http://www.stcsig.org/usability/topics/articles/ucd%20_web_devel.html
50. “IBM Design Principles”, IBM –
https://www.ibm.com/software/ucd/designconcepts/designbasics.html
51. “Yahoo! UI Library: Grids CSS”, Yahoo – http://developer.yahoo.com/yui/grids/
52. Bowles, C., “Getting Real about Agile Design”, A List Apart, 2008 –
http://www.alistapart.com/articles/gettingrealaboutagiledesign
53. Agile software development, Wikipedia –
http://en.wikipedia.org/wiki/Agile_development
54. Garret, J. J., “A visual vocabulary for describing information architecture and interaction
design”, 2002 – http://www.jjg.net/ia/visvocab/
55. Semantic Web, Wikipedia – http://en.wikipedia.org/wiki/Semantic_Web
56. Microformats wiki – http://microformats.org/wiki/Main_Page
57. Adida, B., Birbeck, M., “RDFa Primer”, 2008 – http://www.w3.org/TR/xhtml-rdfa-
primer/
58. O’Reilly, T., “Google's Rich Snippets and the Semantic Web”, 2009 –
http://radar.oreilly.com/2009/05/google-rich-snippets-semantic-web.html
59. Resource Description Framework, Wikipedia –
http://en.wikipedia.org/wiki/Resource_Description_Framework
60. Dublin Core Metadata Initiative Terms – http://dublincore.org/documents/dcmi-
terms/
61. Introducing FOAF – http://www.foaf-project.org/original-intro
93
62. Marking up structured data –
http://google.com/support/webmasters/bin/answer.py?hl=en&answer=99170
63. “Google Company’s philosophy”, Google –
http://www.google.com/corporate/tenthings.html
64. Maier, A., “4 Reasons your product needs to be usable”, UX Booth, 2008 –
http://www.uxbooth.com/blog/4-reasons-your-product-needs-to-be-usable/
65. Dimitry, “Experience vs. Function – a beautiful UI is not always the best UI”, Usability
Post, 2008 – http://www.usabilitypost.com/2008/10/13/experience-vs-function-beautiful-
ui-not-always-best-ui/
66. Irizarry, A. M., “Defining User Experience Pt. 1”, This is Aarons Life, 2008 –
http://www.thisisaaronslife.com/defining-user-experience-pt1/
67. Nielsen, J., “Why you only need to test with 5 user”, Alertbox, 2000 –
http://www.useit.com/alertbox/20000319.html
68. Silverback usability testing software – http://silverbackapp.com/
69. Clickheat visual heatmap of clicks – http://www.labsmedia.com/clickheat/index.html
70. jQuery javascript library – http://jquery.com/
71. Simplemodal plugin – http://www.ericmmartin.com/projects/simplemodal/
72. HotKeys plugin – http://code.google.com/p/js-hotkeys/
73. qTip plugin – http://craigsworks.com/projects/qtip/
74. YSlow performance tool – http://developer.yahoo.com/yslow/
75. Souders, S., “High Performance Web Sites: Essential Knowledge for Front-End
Engineers”, O’Reilley, 2007.
76. Memcached storage – http://www.danga.com/memcached/
77. ApacheBench benchmarking tool – http://httpd.apache.org/docs/2.0/programs/ab.html
78. Httperf benchmarking tool – http://www.hpl.hp.com/research/linux/httperf/
94
79. Siege benchmarking tool – http://www.joedog.org/index/siege-home
