RSS Feed
May 11

The Uncanny Valley of GUI prototyping

Posted on Friday, May 11, 2012 in Uncategorized

The uncanny valley in robotics and computer animation is a …

… hypothesis states that as the appearance of a robot is made more human, a human observer’s emotional response to the robot will become increasingly positive and empathic, until a point is reached beyond which the response quickly becomes that of strong revulsion. However, as the robot’s appearance continues to become less distinguishable from that of a human being, the emotional response becomes positive once more and approaches human-to-human empathy levels

Something similar can be said for GUI prototyping. It is often good to keep it simple and use wireframes. The goal is to study transitions in the software and user interactions, figuring out which interface elements to include and where to include them. Hence, removing distracting detail like color, gradients and other stuff that does not contribute to this goal is necessary. I now state my hypothesis for the uncanny valley of GUI prototyping 🙂 :

As appearance of a GUI prototype is made to look more like the final product, it is generally more liked by the client until a reaches a point where it is missing just enough detail to cause strong revulsion. However, as the prototype further improves, it becomes liked again and it morphs into the final product.

– Coding User


Depending on the purpose of the GUI prototype, you have to choose the appropriate tools for the job. If you are a lone developer who just wants to have an idea how the app should look like, a rough hand-drawn sketch may suffice. If you have a multimillion-dollar contract with a client, you may want to go for professional prototyping tools or even full-fidelity prototypes. Whatever works….! Beware of the uncanny valley though, presenting almost-finished-but-not-final designs may make your client focus on the incorrect hue of the color in the logo.

In the next blog post, I will discuss choosing the Android GUI prototyping tools used for Gnucash.

Jun 28

RailsAdmin Authentication with Authlogic

Posted on Tuesday, June 28, 2011 in Uncategorized

If you have been building a Ruby on Rails application recently, you may have heard of rails_admin which generates an administration backend and allows you to conveniently administer your Rails models. I have found it to be very functional and looks good while doing so.

There is just one issue with RailsAdmin; it is very tightly coupled with the devise authentication solution. Devise is a rack-based authentication solution for Rails based on Warden. RailsAdmin requires you to have the devise gem installed. But before there was devise, there was authlogic, and I was not going to let RailsAdmin’s tight coupling with devise stop me from using it.

RailsAdmin makes provision for you to add your own authentication and authorization scheme. I am going to demonstrate how to do this with authlogic (assuming you have already followed the instructions for installing rails_admin). You will need to create a new file in your config/initializers directory, lets call it rails_admin.rb

Inside this file, we are going to add the following code:

  unless current_user
    session[:return_to] = request.url
    redirect_to login_url, :alert => "You must first log in or sign up before accessing this page."

  redirect_to root_path, :alert => "You are not authorized to access that page" unless current_user.admin?

A few comments to the code:

  1. RailsAdmin will use the code in the first block to authenticate your users (who-are-you) and the code in the second block will check authorization to the admin section (what-can-you-do).
  2. The current_user method returns nil if no user is currently logged in.
  3. I store the request url before sending the user to the login page, because the user session controller can use it to redirect the user back to the admin page after login.
  4. For the authorization block, I assume that your User model has a boolean attribute called admin which can be checked to make sure that the user is an administrator before allowing access.

So there you have it, now restart your application and your /admin page should redirect you to the login page or deny you access if you are not an admin.

Feb 1

Appifying the mobile web

Posted on Tuesday, February 1, 2011 in Uncategorized

There is a lot of talk these days about the rise of mobile applications and app stores and the role of the web. Wired Magazine went as far as to declare the web dead. Appifying the web refers to the growing trend of web sites to create native (mobile) applications which access internet services instead of or in addition to a (mobile-optimized) web site.

There are several different mobile platforms out there: iOS, Android, Windows Phone, webOS, Symbian, Blackberry – just to name a few, and more platforms showing up every other year. To be able to cater for the needs of all potential users when building a native mobile application, it is necessary to build native mobile apps for several different platforms. It is not difficult to see how this can be a daunting task.

The alternative is to build a mobile web application using standard technologies like HTML5, CSS and Javascript. Webkit is proving to be the de-facto standard mobile rendering engine, and the alternatives are not doing badly. So building such a web application once will satisfy a really broad range of customers.

So far, the main arguments for native mobile applications have been the following:

  1. The provide a better and smoother experience from a performance perspective. The application is consistent with the platforms UX guidelines and ‘fits in’.
  2. Native mobile apps allow for background applications. The application can keep running in the background and provide notifications to the user of events.
  3. Native apps are built for a particular device and have more access to the device functionality (e.g. phonebook integration).
  4. Native apps are downloaded and stored on the device. This enables them to work in disconnected mode where they show cached or saved content and synchronize later with a server.
  5. Right now the only way to build great games is through native apps.

There are also strong arguments in favor of mobile web applications:

  1. Cross-platform support. Any smartphone with a decent browser can access the application. That includes a lot of phones today and reduces the maintenance cost of multiple native mobile applications.
  2. Your web application can be updated centrally and quickly. There is no gatekeeper to approve your site and you can release new features on your schedule.
  3. Lower barriers to user-access. A user does not need to get a  specific phone, signup for an account on an app store, download an application just to access your content.
  4. Easier analysis of user behavior using various analytics packages.
  5. Lower entry barrier for developers, since web apps are based on widely-accepted standards which are constantly improving.

Both sides have their strengths and weaknesses, and each business case is different. That said, the third alternative is appified web apps. For many everyday users, it is easier to click CNN icon on their home screen even if it is just a bookmark, than to go to a browser and start typing in about URLs. There are many technologies which are in development to improve the appifying of mobile web apps.

Google’s Native Client (NaCl) project provides a way to run native code safely through the browser. If/When this is ready for mobile devices, I imaging combining this with the standard HTML/CSS/JS to provide more complex applications. Also, WebGL is constantly improving and could eventually harness the steadily rising mobile computing power to enable creation of great games. Apple already has a mobile web apps store and it is also not inconceivable that Google builds a web store for the Android browser similar to that in Chrome. But again, web apps do not need any store for users to access them.

Naturally, native apps will always have their place, but for the rest, an appified web will do just fine.