May 18, 2014

Native, Web and Hybrid Apps

The explosion of mobile applications has caught the attention of many companies for developing their own applications. The idea of having another way of interacting with the customers is very tempting. For example, banks have found that allowing basic banking operations using an application attracts customers that already use a mobile device. However, developing an application is not easy as it sounds. There are different approaches one can take depending on the requirements and the needs of the company. In general, there are three popular approaches: Native Applications, Web Applications and Hybrid Applications.

What are Native Applications?

They are applications developed for running only in only one platform. Currently, the platforms that capture more subscribers are iOS from Apple and Android from Google with 52.1% and 41.2% respectively. Far away from those numbers come other mobile platforms with less “followers” like Blackberry 10 from Blackberry Ltd and Firefox OS from Mozilla Foundation.

In general, mobile applications are downloaded from common markets or stores, like Apple’s App Store or Google Play Store (before was called Android Market) and then installed on the device. The applications are offered in two ways: as free or as pay. This is one way in which developers and stores earn money. One part develops the application and the other distributes it by means of the store.  The other way is by mean of ads in the application and websites. This is how Google Play Store for example, get most of their profits.

Revenues and Downloads

In 2013, Apple reported that their customers spent over $10 billion on their App Store with almost three billion downloads in December. On the other side of the street, Google Play Store’s revenue share has been growing at a moderated but firm pace compared with Apple. Apple’s App Store is mostly fed by China and US and to a lesser extent by Vietnam and South Africa.

In the battle of apps downloads, the current champion is Google Play Store with a difference near 45% over Apple’s App Store. This incredible volume of downloads is in part due to the emerging markets such as from Mexico and from Turkey where the adoption of Android devices is booming. Also, downloads were strong in countries like Brazil and Russia. Moreover, the already established markets (US and UK) are helping to shorten distance in the revenue field. The projections indicate that Google will continue narrowing the revenue gap with Apple and leading downloads in during 2014.

What are the Pros and Cons of developing Native Applications?


  • Native applications use built-in features of the device and perform faster. Some of the most common features are the camera, the GPS, the accelerometer and the compass.
  • These applications get support from the app stores and marketplaces. Users can find and download what they want from the stores.
  • A native mobile app can produce the best user experience. High performance and fluid interaction can squeeze out all the built-in features and hardware in benefit of the user.
  • Stores have strict audit procedures for ensuring that new apps follow the security standards (most of the markets). Therefore, users can download applications safely.
  • Native applications suit better for developers because platforms provide SDKs and other tools for developing applications faster and easier.


  • A Native application approach can be expensive since they must be developed in each platform one by one. 
  • Programming skills are required for each platform. 
  • The cost of maintaining native applications is higher, especially if the application supports more than one mobile platform.
  • The process of approval for publishing an application on a marketplace can be long, as the requisites are high. Also, there is no guarantee that the application will be accepted. Even more, that the application will be top listed.
  • If there are different versions of the same app, it will be difficult to maintain and offer support.

What are Web Applications?

They are websites that may look and feel like native applications but under the hood are not the same. A web app is simply HTML5 (or simply HTML), JavaScript, CSS rendered by a browser. The web browser renders the web application like any other regular webpage. There is no need to download the application in order to access to it, only is needed the URL and that is all. 
Some elements typically present in native application are emulated by the application such as swiping horizontally to change the section or similar design as seen in Android or iOS applications.

What are the Pros and Cons of developing Web Applications?


  • They are easy to maintain as they share the same source code for multiple mobile platforms.
  • Web Apps can be compatible with almost any old device (with browsing capabilities).
  • These apps do not require passing through a rigorous approval process, just saving the URL.
  • There are no restrictions of time or design for releasing the application. The developers publish the application when is necessary.
  • All updates are transparent to the users as they only enter to the URL and execute always the last version available.


  • Web apps only can access a subset of the features available in the devices.
  • The cost of supporting multiple platforms is high, as well as the maintenance too.
  • The wide variety of devices makes difficult to offer support and study the usage patterns.
  • The visibility of the application is reduced, as it is not listed in an app store.
  • There are no standardized quality procedures for web apps, for this, quality and security of the app is not guaranteed.

What are Hybrid Applications?

These applications take a native wrapper and put inside a web application. That is, the native wrapper is a native application from the outside while the content is HTML, JavaScript and CSS. These kinds of applications are distributed by app stores, just like native applications. Although there are differences, users in general cannot distinguish between native applications and hybrid applications.


  • They are faster to develop since the development process is the same as follow by web development and small amount of native coding is necessary.
  • The tools for developing hybrid applications are evolving and maturing rapidly getting closer to native tools.
  • Hybrid Applications can be deployed in app stores.
  • They provide the best of both worlds, native apps + HTML5.
  • These applications can work without Internet connection.


  • They are not native apps despite of being packed by a native wrapper. The web engine is the one provided by the platform and so the performance is not the same as a native app.
  • No frequent updates (in the case of offline caching).
Lastly, at the moment of deciding what type of application is needed for your business there are some aspects should be considered carefully.
  • Deciding how important is speed and performance.
  • Determining if Internet access is necessary.
  • Allocating the necessary budget for developing the application.
  • Choosing between using device’s built-in features or not.
  • Adopting an advertisement strategy (monetize the application).
  • Focusing on your target users (specific market/platform dependent).

Some sources:

May 11, 2014

Interaction Design Guidelines for Home Automation

In the last years, home automation became a reality as a result of an increased availability of different commercial solutions. Some examples of these options can be X10, UPB, Insteon and Z-Wave. Also, the fact that costs decrease day by day making this type technology widely accessible to almost every home.

The idea of smart home, which is controlled by themselves, understands the context and performs actions, has provided new research fields and opportunities. In spite of that, there are still controversial opinions toward how can smart homes improve the life and care of the elderly or of people with different disabilities.

Among the different disabilities, people with impaired motor abilities can take advantages of eye tracking methods to control their homes. This kind of tracking strategies can exploit this limited ability to build a communication channel for interaction and as a result opening new possibilities for computer-based communication and control solutions. Home automation can be the link between software and tangible objects, enabling people with motor disabilities to effectively and physically communicate with their environment.

The European Network of Excellence, COGAIN (Communication by Gaze Interaction), studied in 2004 the advantages and drawbacks of using eye-based systems in the home automation field. Their results identified that there weren't advanced functionalities for controlling appliances and neither interoperability between them. Also, the execution of actions was an issue for the existing eye-tracking mechanisms.

A few years later, members of COGAIN proposed 21 guidelines to promote safety and accessibility in eye tracking methods for environmental control applications.
One of the first applications of this set of guidelines was the DOGeye project, a multimodal eye-based application for home management and control, based on tracking and home control.

COGAIN Guidelines

The COGAIN project was launched in September of 2004 with the goal of integrating vanguard expertise on gaze-based interface technologies for the benefit of users with disabilities. The project was quite successful as it gathered more than 100 researchers from different companies and research groups; all related with eye tracking integration with computers and in assistive technologies.

In 2007, the members of project published a “Draft Recommendations for Gaze Based Environmental Control”. This document proposed a set of guidelines for developing domotic control interfaces based on eye interaction. These guidelines were developed from real uses cases where people with impairments perform daily activities in domotic environments.
The document divided the guidelines into four categories:
  • Control Application Safety:  guidelines that determine the behaviour of the application under critical situations such as emergencies or alarms.
  • Input Methods for Control Application: guidelines about the input methods that the application should support.
  • Control Application Signification Features: guidelines impacting the management of commands and events within the house.
  • Control Application Usability: guidelines concerning the graphical user interface and the interaction patterns of the control applications.
Each guideline has a priority level compliant with the W3C style:
  • Priority 1: indicates that must be implemented by the applications as it is related with safety and basic features.
  • Priority 2: indicates that should be implemented by the applications.   

There are three important issues that control interfaces must deal with:
  • Asynchronous Control Sources: the control interface needs to continuously update the status of the house (icons, menus, labels, etc.) according to the home situation.
  • Time Sensitive Behaviour: in critical conditions, like an emergency, eye control may become unreliable. In these cases, the control interface must offer simple and clear options, easy to select and must be able to take the safest action in case that the user cannot answer on time. This kind of behaviours offer automated actions triggered by rules. For instance, if it is raining, close the windows. In any case, the user should be able to cancel the automated action and also be aware that it is been executed.
  • Structural and Functional Views: control interfaces can organize the information into structural or functional logic. The first one displays the information in a physical fashion, similar to the real disposition of elements in the house. The second option suits best with actions that doesn’t have a “localized” representation, like turning the anti-theft system on. Good interfaces should find a balance between these two views.

The a summary of the guidelines follows:


Priority Level
Provide a fast, easy to understand and multi-modal alarm notification.
Provide the user only few clear options to handle alarm events.
Provide a default safety action to overcome an alarm event.

Provide a confirmation request for critical & possibly dangerous operations.
Provide a STOP Functionality that interrupts any operation.
Provide a connection with the COGAIN ETU-Driver.
Support several input methods.
Provide re-configurable layouts.
Support more input methods at the same time.
Manage the loss of input control by providing automated default actions.
Respond to environment control events and commands at the right time.
Manage events with different time critical priority.
Execute commands with different priority.
Provide feedback when automated operations and commands are executing.
Manage Scenarios.
Communicate the current status of any device and appliance.
Provide a clear visualization of what is happening in the house.
Provide a graceful and intelligible interface.
Provide a visualization of status and location of the house devices.
Use colors, icons and text to highlight a change of status.
Provide an easy-to-learn selection method.


DOGeye was planned as a solution to fill the blank of a home control application in compliance with COGAIN guidelines, through multi-modal interaction with special attention on eye tracking technologies.

DOGeye communicates with Domotic OSGi Gateway (Dog) through a XML- RPC connection. This connection allows information exchange and controlling other devices inside the smart environment. This home control application can be controlled by gaze, by communicating with the eye tracker through a universal driver (ETU-Driver) or by external elements such as keyboard, mouse or touch screen devices.
Dog, an ontology-based domotic gateway, provides the interaction with smart homes. This gateway is able to integrate and abstract functionalities of different domotic systems, offering a uniform high-level access to the home technologies.
The interface was designed through an iterative process, starting from a scratch layout and iteration by iteration refining the design until the final design was reached compliance with COGAIN guidelines. A capture and video of the interface follows. 

DOGeye Interface

There are 8 main elements in the interface disposed in a top menu bar. Each element, when activated, displays a tab with the main details of that element.
  • Home Management contains the basic devices present in a house. These are the devices that belong to the mains electricity wiring such as shutters, doors, lamps, etc.
  • Electric Device contains the electrical appliances not belonging to the entertainment system, such as a coffee maker.
  • Entertainment contains the devices for entertainment, such as media centers and TVs.
  • Temperature allows handling the heating and cooling system of the house.
  • Security contains the alarm systems, anti-theft systems, etc.
  • Scenarios handles the set of activities and rules defined for groups of devices.
  • Everything Else contains devices not directly falling in the previous tabs, e.g., a weather station.
  • Settings shows controls for starting, stopping and configuring the ETU-Driver. 


If you wanted to turn on the lamp in the kitchen and warm coffee, you should follow the following steps. 

  • First, look briefly at “Home Management” to activate this tab. The map of the kitchen will appear rapidly. 
  • Then stare at the “Enter the room” tab for a time. After doing that, you will see the list of all devices present in that room. 
  • To select the lamp you would look at it and then stare at the “On” button presented in the command area. 
  • Finally, to warm the coffee look at “Electric Device” tab and use the same procedure.

Usability Testing of DOGEye

Previous to the testing, a short introduction to the study and the collection of demographic data was done. Afterwards, a static DOGeye screenshot was shown to the participants to gather a first impression on the interface.

The usability testing was divided into three main phases: warm-up, task execution and test conclusion.

The warm-up phase was executed after calibrating the eye tracker with the participant’s eye. Next, the participant played a simple game for getting used to the eye tracking interaction. This phase was considered finished after achieving a pre-established number of points in the game.

In the task phase each participant was told to complete a set of nine tasks, one at a time.  For two of them, the participants were asked to use the think-aloud protocol, to verify the actions performed.

In last phase, test conclusion, participants were given a questionnaire and asked to rate DOGeye in general, and to rate their agreement with the same sentences proposed earlier, just after seeing the screenshot of DOGeye.

The duration of the entire experiment was dependent on eye tracker calibration problems and on how quickly participants answered the questions, but it ranged between 20 and 30 minutes.

For testing this application, 8 participants (5 female and 3 male, aged 21 to 45) used DOGeye in a controlled environment. These participants performed nine tasks each, with Dog simulating the behaviour of a realistic home. The quality of the eye movement of each participant was not taken into account for the study, since eye tracking is only the input modality.
The tasks were the following ones:
  • Task 1: Turn on the lamp in the living room.
  • Task 2: Plug the microwave oven in the kitchen.
  • Task 3: Find a dimmer lamp, turn it on and set its luminosity to 10%.
  • Task 4: Cancel the alarm triggered by the smoke detector.
  • Task 5: Turn on all the lamps in the lobby.
  • Task 6: If the heating system in the bedroom and in the kitchen is off, turn 
it on.
  • Task 7: Set to 21 degree the heating system for the entire house.
  • Task 8: Send a general alarm to draw attention in the house.
  • Task 9: Read the smoke detector status and expand the video of the room to full screen.

Result of the Usability Testing

The result of the usability testing was positive and provided useful insights on the application explicitly designed for eye tracking support.
A short summary of the findings follows:
  • Some of the users suggested refactor the top menu. Like splitting the “Home Management” into two different tabs, “Lighting System” and “Doors and Windows”. Also, “Everything Else” tab should be removed because the participants could not understand the meaning.
  • None of the participants used the “multiple selection” feature. Each of them used “single selection”, therefore the feature was removed from the application (except from temperature since it is the only viable modality for multiple selection in this tab).
  • The users appreciated the vocal feedback and the tab divisions.
  • The presence of a camera in the “Security” tab was something that they found  marvellous.
The study concluded with very good feedback from participants, pointing out some errors in the design and motivating the developers to progress in the field and continue enhancing the product. Also, it is the kick off for helping and improving life quality for people with motor impairments from a common starting point.


  • De Russis, Luigi, Emiliano Castellina, Fulvio Corno, and Darío Bonino. "DOGeye: Controlling Your Home with Eye Interaction." PORTO Publications Open Repository TOrino. Politecnico Di Torino, 16 June 2011. Web. 10 May 2014.

Just an Empty Post...