Shneiderman’s Eight Golden Rules in my words

Strive for consistency -The users should feel familiar and comfortable with the digital landscape to achieve their goals more easily and we can reach this feeling keep standards and consistency in the layouts, icons and etc.

Enable frequent users to use shortcuts. The efficiency of the system can be improved through shortcuts. The users can achieve their goals more quickly.

Offer informative feedback. The system must to provide to the user feedback informations like “where you are” and “what is going on” at all times and these informations should be human-readable.

Poorly designed error messages often show an error-code that does not mean anything to the user. As a good designer you should always seek to give human-readable and meaningful feedback. – Interactin Design Foundation

Design dialogue to yield closure. Always feedback all users actions, telling them if it was successful or something wrong has happened.

Offer simple error handling. Systems should be designed to be fool-proof, but when a error happens, it should provide a simple message with intuitive step-by-step instructions to solve the problem. Don’t cause pain in the users! They don’t like be wrong or feel shame or feel as a fool!

Permit easy reversal of actions. Always permit to the users reset their actions with an obvious way.

Support internal locus of control. The users must to feel in control of everything to be comfortable. They can initiate an action, terminate this action or cancel it to do another thing.

Reduce short-term memory load. Don’t force the short-term memory of the users. Always help them to remember/recognize things through cues that help them reach into the vast memory. Avoid the overload of this kind of memory.

Human attention is limited and we are only capable of maintaining around five items in our short-term memory at one time. – Interaction Design Foundation


Resultado de imagem para Shneiderman
Ben Shneiderman

Interaction Desgin Foundation – UI Design Patterns for Successful Software  (

Two-Panel Selector

MacOS System Preferences background image selector

There are many occasions where the user needs to see a list of options, categories, commands or other related items but when they make a selection they still need the list in view.Two-panel selectors are commonplace in web and application design as they enable users to view the contents of individual files, emails and other content-carrying items in one panel and quickly switch between them in another.


The users don’t need to skip between different sections of the applications in order to gain access to the list of options or individual contents. So, this pattern minimizes the number of necessary intermediate steps and interactions.

A movement from a section, windows or page to another usually demands the users reorient themselves every time they reach a new position, what is a cognitive effort. Using this pattern the spatial location is preserved and the user don’t need to reorient itself in the screen.

Spatial memory is limited, it is estimated that we are capable of maintaining only nine distinct items in an active state; designs that involve movement from one region of the user interface to another interrupt the experience of scanning options and checking their contents, which forces the user to maintain information in short-term memory. – Interaction Design Foundation

Using this pattern, the users don’t need to maintain infromation in short-term memory because everything that they need to reach is in the same section, windows or page. They don’t need to remember where things are because it was never removed from view.

How to Implement

  • Users tend to look from left to right and top to bottom (as per the viewing direction followed during reading), therefore, the list – being the user’s first port of call – should be placed either above or to the left of the panel in which the selected item contents are displayed.
  • To make the interactive and viewing experience as cohesive as possible, the contents of an item should appear immediately in the second panel, following interaction with the corresponding item in the first panel list. Even brief delays can negatively affect user experience, so every effort should be made to ensure the contents appear as quickly as possible.
  • List options are generally arranged vertically and there are often times when the number of options exceeds the available space of the panel so scrolling must be enabled.
  • The selected option in the first panel must also be distinguished from the rest to provide the user with a means of instantly determining which item contents they are currently viewing.



Book  – Designing Interfaces (

Interaction Desgin Foundation – UI Design Patterns for Successful Software  (

Progressive Disclosure

Interaction design dilemma

Users want power, features, and enough options to handle all of their special needs


Users want simplicity; they don’t have time learn a profusion of features in enough depth to select the few that are optimal for their needs.

A user might only want to change the icon name for their computer speakers, whilst another user might want to carry out more detailed changes, such as altering the speaker enhancements to suit their listening environment. How do you provide both users with sufficient means to complete these tasks without flooding the user interface with all the information related to these different tasks?- IDF

 Progressive Disclosure as a Solution

You should must to provide all features but you should to display immediately only what is important, giving to the user an way to move to the not so important features without to have to re-orient itself in the UI.

  1. Initially, show users only a few of the most important options.
  2. Offer a larger set of specialized options upon request. Disclose these secondary features only if a user asks for them, meaning that most users can proceed with their tasks without worrying about this added complexity.

You should ensures the user only has to attend to a confined region of the user interface and, at this region, you should devide the features into distinct, yet instantly accessible,  areas, showing one area at time.

Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone. – Jakob Nielsen

Each area represents a level of the features and the first area or level with the contain most important features and must to be immediately displayed.


Frequency-of-use statistics can help you prioritize the features and chose the most important to display in the first level area. But you have to discern whether a page gets many hits because users want it or because they simply enter the page by mistake.

The first display can’t contain:

  • too many options or you’ll fail to sufficiently focus users’ attention on truly important issues
  • confusing features or you’ll slow down user performance

Don’t forget it must be obvious how users progress from the primary to the secondary disclosure levels. Make the mechanics of this operation simple and label the button or link in a way that sets clear expectations for what users will find when they progress to the next level


  • Gives the user a sense of control over events in the user interface
  • Users see what they want
  • Users will see only the information related to the task that they are performing
  • Save the user from assessing the user interface in an attempt to tease out relevant information from the array.
  • The ability to convey exactly what is important to the user
  • For novice users, this helps prioritize their attention so that they only spend time on features that are most likely to be useful to them.
  • For advanced users, the smaller initial display also saves them time because they avoid having to scan past a large list of features they rarely use.
  • Promotes a better understanding of the system

Step-by-step Progressive Disclosure x All-Category-Options-at-Once Designs

Step-by-step progressive disclosure designs, such as those used when filling out online order forms, begin by showing the user a small set of options. Depending on this initial selection the user is shown further options specific to that first choice; constraining the user to only those options relevant to the current task and in accordance with previous choices. In contrast, all-category-options-at-once designs, such as the speaker settings panel, allow the user to move between different sub-sections as and when they please.

When to Use or Not?

Progressive disclosure must only be used where all of the necessary information for a particular task can be displayed in full view in one section of the user interface and there is no benefit to displaying information from different sections together

One potential pitfall is using progressive disclosure when the user is meant to compare different sets of information. If data sets are placed in different sections of a panel, window or web page, skipping between these locations interrupts the comparative process and forces the user to rely on what they can recall from the previous, now out of view, section. Short-term memory is very limited, with an approximate capacity of 7 distinct items and an estimated duration of 18 seconds.


  • User only has to attend to a confined region
  • Devide the features into distinct, yet instantly accessible,  areas
  • Provide all features but display immediately only what is important
  • The immediately displayed area is the first level with the most important and most frequently used features
  • The secondary levels contains more advanced features and consequently less frequently used features
  • Give to the user an way to move to the not so important features without to have to re-orient itself in the UI.
  • Make applications easier to learn and less error-prone.


Nielsen Norman Group – Progressive Disclosure (

Interaction Desgin Foundation – UI Design Patterns for Successful Software  (

Efficient Android Threading – My Compilation Chapter 1


Linux Process

In  a Linux, each user has its own process and a unique ID. Every user has access to private resources proctected by permission and any user (except the super user) can access another user’s private resource. In Android, the same thing happens, but instead of users we have applications.

By default, applications and process have a one-to-one relationship, but if required, it is possible for an application to run in several process, or for serveral applications to run in the same process.

Starting a process is slow and the comunication between process is slow too. A process allocates memory for its own substantial resources. So, an application that uses more than one process to work need to lead in consideration the loss of performance that will happen.


The Android try to shorten the statup time of the applications, because start the runtime and the Linux process is not light. It does it throught the Zygote, that is a process that has the entire set of core libraries preloaded. Every new process created is a fork from Zygote withou copying the core libraries, because the Zygote share it with all process.


Application Lifecycle

When any application’s component is initiated for execution, the application is started. So, any component can be the entry-point for the application starting.

  1. A component is called
  2. Start Linux process
  3. Create a runtime
  4. Create Application instance
  5. Create the component

Application instance is the first component to be instantiated in a process and the last to be destroyed.

The runtime avoids to destroy all resources of an application when it’s killed because a user may request the same application at any later time. The runtime only destroys the resources when a number of live applications leads to an actual shortage of resources across the system and the system needs to kill the entire process. So, the application is started when one of its components is called, but it’s not completly terminated even when all of its components have been destroyed.

The runtime is responsible for make the lifecycle of the application happens completly, but the Linux process can be killed before the runtime had a chance to call every lifecycle method of the components. It can happen when the system needs located resources. For example, the method onTerminate() of the Application instance cannot be called by the runtime during the application killing because the Linux process was killed by the system before.


Android Gradle Plugin 2.2.0-alpha3 is missing zipalign

Today, I was trying to submit a new version of my app to Google Play and I received this message:


I’ve verified if I was submiting the debug version of my apk and I’ve confirmed that I was submiting the release version generate in Build > Generate Signed APK.  I’ve tried to use the  zipAlignEnabled true in the release buildType on gradle script but it has not worked.

So, why is it happening?

Simple, Its a problem in gradle plugin version 2.2.0-alpha3… This version doesn’t work well with the zipAlign. I’ve made some testes to check if this post that I’ve found is valid and it is.

With gradle 2.1.2 ZipAlign works fine;
With gradle 2.2.0-alpha2 ZipAlign works fine;
With gradle 2.2.0-alpha3 the APK is not zipaligned.
With gradle 2.2.0-alpha4 ZipAlign works fine, but it's still incompatible with AS2.2

Today was release the alpha4 version and the problem with the ZipAlign has desapeared, but when I debug my app I receive a warn about another problem :  It’s still not compatible with Android Studio 2.2 preview 3.

That’s another good post about this problem.

DialogFragment/AlertDialog dismiss automatically on click button

I was dealing with the case of use an EditText inside my AlertDialog that is created inside an DialogFragment last week and I remembered that I could write a tip about some problems of it. What problems?  It’s simple…An EditText…inside an AlertDialog…Ok, but how to avoid the dismiss of the Dialog when the user click in a positive of negative button? Imagine that the user clicks on the positive button and, when your  button’s listener checks the EditText value, it figures out that the value is invalid. Your code will warn the user that the value is invalid, but, your dialog suddently is dismissed even without you command it after the warn. Why?

Yes, positive and negative buttons will always dismiss the dialog, even without your order. How to avoid it? I’ve found a great answer on stackoverflow that will help us.


What happens with AlertDialog’s setButton() method (and I imagine the same with AlertDialogBuilder’s setPositiveButton() and setNegativeButton()) is that the button you set (e.g. AlertDialog.BUTTON_POSITIVE) with it will actually trigger TWO different OnClickListener objects when pressed. The first being DialogInterface.OnClickListener, which is a parameter to setButton(), setPositiveButton(), and setNegativeButton(). The other is View.OnClickListener, which will be set to automatically dismiss your AlertDialog when any of its button is pressed – and is set by AlertDialog itself.

What you can do is to use setButton() with null as the DialogInterface.OnClickListener, to create the button, and then call your custom action method inside View.OnClickListener. For example,

public Dialog onCreateDialog(Bundle savedInstanceState) {
  AlertDialog alertDialog = new AlertDialog(getActivity());
  // set more items...
  alertDialog.setButton(AlertDialog.BUTTON_POSITIVE, "OK", null);

  return alertDialog;

Then, you may override the default AlertDialog’s buttons’ View.OnClickListener (which would otherwise dismiss the dialog) in the DialogFragment’s onResume() method:

public void onResume() {
  AlertDialog alertDialog = (AlertDialog) getDialog();
  Button okButton = alertDialog.getButton(AlertDialog.BUTTON_POSITIVE);
  okButton.setOnClickListener(new View.OnClickListener() {
    public void onClick(View v) {
      // Do your stuff here

You will need to set this in the onResume() method because getButton() will return null until after the dialog has been shown! This should cause your custom action method to only be called once, and the dialog won’t be dismissed by default.

Message.obtain() and new Message() – TIP

Is not possible send the same Message instance several time, only once. So we always have to create a new instance. Better than that, instead of create a new instance (new Message()), we can use the method obtain (Message.obtain()) that will return a recycled instance of Message from the pool of recycled objects, what is less expensive than the first option.

While the constructor of Message is public, the best way to get one of these is to call Message.obtain() or one of the Handler.obtainMessage() methods, which will pull them from a pool of recycled objects.