himalia.net | community blogs

I kept thinking about the Jared's point of view about another security -vs- user experience trade off.

In this case, Jared stands that you can't require the same security for a "Magic tricks Forum" and for a "Bank website". I agree with that. I  really hated when Mingle asked me for an ultra secure password for a trial version I wanted to use in my network. Everyday I wanted to login into the system I had to try several password... Well, at least I was feeling lucky® they decided no to block my account in the process :)

However, I think you can't put everything in the same bag. He was using this argument to say that applications should specify what was wrong when the login has failed (was it the username or the password?). The usual behavior is a message similar to this one: "Either your username or password is wrong, try again! Did you forget your password? ".

This kind of messages goes against the UX because it's imprecise. If you are more precise you can help him (and others trying to log in) to solve the problem. But, it's also true what me and others argued about how we -as users- manage usernames and passwords everyday. To make it short, users have the same passwords and usernames all over web, in different sites. I do that and many people I know do also. Ok, my bank web site password is not the same that the blogger's one.. but I cannot be sure about other "not-critical" sites. I can't even remember all the sites I am registered in!!! Can you?

The point is: can you forget security issues if you are designing the "Magic tricks Forum" when you know it is the actual behavior of your users? Lets put it in another way. What happen if some of your user's account is hacked (sometimes all they need is the username because it's a valid email), and this information is used to steal more important data of him in other site? Ok, it's not totally your guilt, but, couldn't you avoid it? Can you just blame your user because of his uninformed behavior? I don't think so. How will your user feel about your site? Do you think he will just guilt himself or will your site also pay the penalty? The second one is more probable and for sure your team will look incompetent.

You know, sometimes UX is indirect. You can just try to improve it but you may end provoking a terrible headache for your user in name of it. Although in this case you may share the guilt with your user, if something happens, you can be sure you will pay for it because -as always- bad UX has more publicity. 

If I were you, I would stay defensive to avoid boomerangs.

Labels: Internet, Technology, Usability, UX

# posted by leovernazza : 2/11/2008 01:58:00 AM  0 comments links to this post

I downloaded Enso last week and now I can't live without it. I have to say that I loved it from the website description.

They guys from Humanized were bought by Mozilla and will be working in their Labs. It's highly probable that you start seeing these kind of things in the next version of the open source browser.

I am happy. They share my vision about how web/desktop software must inter-operate, putting users first. Will browsers start to be a little more semantic? I will take the bet.

----

If you are a good observer (see the right pane, stupid!), you may have discovered I am going to MIX'08 in Las Vegas. If you are going there, I will be glad to met you to talk about any topic, if you drop me a line. I can't believe I will see Guy Kawasaki and Steve Ballmer. I just bought two of his books last week. It was a signal :)

----

I know that the second part of the GMail review is pending. I have already written it (actually, I wrote it with the first part), but I am just waiting to post it with a little surprise ;)

----

I started a discussion in the Jared Spool's blog. This is a honor for me :)

He responded with another post. What do you think about usernames and the user experience? Can we really improve it?

Do you believe in the global/aggregated user experience concept? Who should care about it?

----

This is an atypical post.

Labels: Usability, UX

# posted by leovernazza : 1/31/2008 12:55:00 AM  2 comments links to this post

Google has launched a new version of GMail with some good new features.  However, what really surprised me were the very bad changes in the user interface of the contacts "subsystem". Google has a very deserved prestige in providing dead simple and very well designed user interfaces. However, I think they couldn't repeat themselves this time. Luckily I am not the only one this time; users care about usability and as always, problems have more repercussion.

I was not going to post about this, but then I thought it could be a very interesting example to show how the right models/tools can help to avoid this kind of errors. Last but not least, I strongly believe you have to fall into a lot of mistakes in the process of creating a great user interface, but if you use the right tools and you are describing things at the right abstraction level, they become evident, and you can quickly walk through the continuous prototyping process to achieve a successful design.

What's Wrong With The Contacts Design In The New Version Of GMail ?

The main problem is it has a bad layout. Layouts should be simple and Google knows it more than anybody. Not only simple, they have also to be familiar, recognizable (yes, copy them from other user interfaces). Layouts aren't an innovation area and simple layouts have been all already invented.

So, What's Wrong With The GMail Layout?

Well, first of all it has too many areas. An area is the part of the screen where you will present a UI concept. Actually, you should have so many areas as concepts you want to present on screen at the same time. And you don't want to expose your user with dozen of concepts at the same time, so you don't want too many areas. In the new version of the contacts subsystem they have 5 areas (just in that part).

However, five areas wouldn't be a problem is they weren't so poorly orchestrated. Area orchestration, or Layout Behavior (as I lately redefined it) is the way you assign a hierarchy to the different areas on the screen. The main pattern you should know in this field is called Visual Framework. I will translate it in this way: "Try to keep the area hierarchy always, never mind which concepts are you presenting at each time in each area". 

The Layout Behavior can be defined using with transitions that are represented as arrows (this is a very natural representation). Each arrow means that the target will be refreshed when any action is fired in the source. Typically you expect that top menus refresh second layer menus, left or right bars refresh the content area and so on. This approach is very interesting because you don't need to think it in terms of events and other programming-related stuff. Just answer: when an action is fired in one specific area, which area(s) will be refreshed? If you can find a simple and recognizable orchestration for your areas, it will be good enough.

Back to GMail, have you seen this kind of orchestration in some other place?

Other problem with the chosen transitions are the transition jumps. The one from FirstTopArea to the RightArea is anti-natural because broke the logic sequence. The same happens with the transition from LeftArea to RightArea, but in this case you should add that it provokes a a little inconsistence because there is another transition from LeftArea to CenterArea.

Other good advice to take when possible is to define the transitions targeting contiguous areas, in order to facilitate the focus flow of your user. Why jumping to the other side of the screen?  Users don't want to guess where to look after clicking something. In this case, the user is forced to jump his focus from the left to the right in one jump. When you press something, the refreshed area should be the one the user is expecting to be, and users don't expect to move their heads all around like playing Simon in a big wall.

Also, there is a very ironic problem, the very strange behavior in the search box. When you search a contact, a new item is added in the left list (groups and other stuff list), while the results are added in the center list at the same time. Why? What's the purpose of the left list with two fixed items, all the groups and an intermittent search result item? Why adding that item there? Why just not showing the results as Google taught us in a dead simple way?

Finally, probably the most annoying error is the inconsistence. Consistence is THE fundamental behind all great designed user interfaces. When you press the "New contact" button you are directed to the RightArea, but when you press the "New Group" button (placed just at it side) a popup appears on the top left corner of the screen, while  other popup's appear centered on the screen. Added up, it provides a baffling experience for the user.

Random isn't a good friend of user interfaces. Actions presented in the same style and grouped together, are expected to produce the same kind of feedback in the user interface. If they are going to provide different experience they should be separated or presented with a different style (see examples below).

So, now you may be thinking: ok, user interface guru-wannabe, how would you improve this? But I will answer it the next post, because it is already quite long ;)

Labels: Himalia, Patterns, Prototyping, Usability, UX

# posted by leovernazza : 12/09/2007 04:15:00 PM  1 comments links to this post

I get very frustrated using the LAN entertainment system because of a stupid failure in the design of its Navigation Model. I want to share it with you, because little things like this are the ones that make the difference between great and bad experiences. In this case, the difference between entertainment and a post with bad-publicity for the company ;)

Interaction with the entertainment system.

I was just looking for some music to help me overtake the 11-hours flight from Los Angeles to Santiago, so I turned on the individual entertainment system I had in front of me. It presented a friendly menu where I selected Audio and then Library. Then it showed an index of categories, and the albums by category at the right pane. As the display wasn't too big (around 10'') the right pane just presented 6 albums, and you had to use the page controls to explore each category in depth. I selected a Massive Attack album that was in the 13th (of 24) page, so, I had to pass 12 pages...

Suggestion #1: The average category had 10 pages and the only way of exploring them was just with a next/previous page control. A scrollbar was best suited for that case (a user that knows where is going can move faster); other solution could be to add a page index (like the one in the Google result page).

But I couldn't listen to the music because after my choice I received a "This selection is currently unavailable. Try again later" error message. 

Rule #1: Be proactive; don't wait for the selection to show the "unavailable" message. If you can, remove (or disable) the unavailable elements before the user have to try them.

After such an imprecise error message I couldn't realize what the problem was, but anyway I was ready to try with another album. But for my surprise, after the message I had to start from scratch again because I was redirected to the Home screen!!! Why? Is this a kind of penalty for trying to listen to Massive Attack? Well... ok, I made the whole process again and selected the Jack Johnson's album In Between Dreams... but I had the same problem again. So, I desisted and continued with the book.

Rule #2: Never redirect your user to the home page unless there is no other choice. Try to conserve the context always.

It this case, the obvious decision is redirecting the user back to the album selection screen remembering the category and the page (that is, doing a good BACK). I didn't count the clicks I needed to get frustrated but they were surely around 30. In this case, 15 clicks in average each time you want to pick a song added to a intriguingly high response time... seems a little expensive for an application with a so bounded functionality.

Navigation Modes. Above is the suggested, below the current.

From my point of view, the problem that derived the current design of the system is obvious: it is a clear case of a stupidly-use-case-driven-application. I can see the analyst writing the Play Album Use Case: "...if I can't play the album, show error. Then, end".

Rule #3: Think always in the step after the end of a use case, both in success and failure scenarios.

Actually, this rule is the opportunistic link pattern put in other words. For instance, after you complete the buy process in Amazon, they provide you similar items to continue buying. The opposite is to present a "Thank you for buying in Amazon message" where the only choice for the user is to close the browser, that is what the entertainment system does.

There are many examples out there of stupidly-use-case-driven-applications, one that always surprised me during my university days was the Beadleship's site where you had to log into the system twice if you wanted to inscribe for two courses... the use case should be something like: the user select Inscriptions from the menu, then enters his user and password, then select the course, end.

Labels: airplane, Travel, Usability, Usability cookie

# posted by leovernazza : 9/09/2007 10:56:00 AM  1 comments links to this post

Fisher-Price has launched the Easy Link Internet Launch Pad. The kid can interact with the computer safely by introducing different figurines in a USB hub. For each character a different website is loaded into the browser.

It is another case of reducing the power of a platform for a very focused niche, or the less is more principle.

Labels: HCI, Usability, UX

# posted by leovernazza : 8/06/2007 04:58:00 PM  0 comments links to this post

I am really tired of listening about "new user interfaces paradigms" when people is just adding tabs to the existing and old paradigm (i.e. Mozilla, Internet Explorer, etc.). But I know, I can still understand the difference between promotion and paradigms...

No Food Here is a "futuristic search engine" that changes the old search engine user interfaces, incorporating (guess what) tabbed searching...

Anyway, adding tabs looks like a good idea also here.

Labels: Usability

# posted by leovernazza : 8/05/2007 04:44:00 PM  2 comments links to this post

I think the Google Analytics Team did a very good work with the new version of their toy. However, I have a list of 6 usability problems I have found:

1. Like most of the ajax applications out there, the back button doesn't work consistently. For example, it never remember if you have changed the graphic kind. For instance: change the graphic from visits to pageviews, drill down in any other information, go back, the graphic is again set in visits.
   

    

2. The date-range is consistently being lost. When you define a data-range it is lost while you navigate through the different reports. I can't remember a path to reproduce it, but it has probably to do with the ajax stuff too.
   

    

3. Google commonly doesn't add scrollbars to their applications and uses just the browser ones. This is right in many situations, but when you are watching a lot of  data in a grid, you need to fix the titles. You can't guess the columns titles at the bottom of the list. To solve this, they would need to add scrollbars to the grid at the content level.
   

    

4. Most of the graphics looks pretty well, but some of them make no sense. For example, in the content by title section, why are they showing me the total visits in a timeline? What do I need to see there? I don't know, but something showing me content by title isn't a bad idea. The same happens in languages, etc. They just inserted the same graphic all over the website, without caring about if it makes sense or not in each specific context.
   

    

5. You can not set the time frame in reverse way. This was the first issue I found. I usually know the last day I want to see and then I start going back in my mind to estimate the starting date: so, I put the last day first. But then, when you click a the new starting date, the final date is removed and you have to start again. It could make sense, but I have still an apply button. So? Why don't they put the validation there? Came on!
   

    

6. Pie charts are very informative and they use them to show you referral sources, for example. One thing I don't understand is why are they highlighting the pie chart sections if nothing happens when you click them... This is like "deceptive feedback". What I want? To navigate, and view in detail that specific pie chart section.

Do you have your owns?

Labels: Internet, Usability

# posted by leovernazza : 6/16/2007 12:11:00 AM  0 comments links to this post

Google Analytics is now providing a new user interface.

Although it was unveiled yesterday, they will be turning it on for each account (yes, one by one) during the next two months. I loose that lottery so I have to wait to see it in action. I don't understand the reasons why are they making something like that, but I can imagine the guy behind scenes making some magic tricks by hand ;)

Once again, only those who have a lot of cash can afford a complete year just to remake a user interface, real world software developers should add some functionalities in the meanwhile too. The Office Team did the same for two years... Could you estimate the investment of that? 

But this throw light on one of the directions the industry is putting the focus: good user interfaces. It is our argument after all, software developers will need to remake their user interfaces in the following years and someone (guess who?) should provide an easy way to do that, and make their life simpler.

BTW, the demo looks great. I am wondering if they have a public API to interact at a data-level. I don't know nothing like this for the Desktop, and I think we could integrate it very easily... I will ask the guys from Urchin Software for that and keep you in track.

Labels: Internet, Usability, UX

# posted by leovernazza : 5/09/2007 10:52:00 AM  0 comments links to this post

Telerik has announced their Cube demo...

I know that with WPF the designers can free their minds, but... came on! I don't want to push the faces of the cube with my mouse! This kind of crazy-graphic-designer-made controls are only giving more arguments to Jacob Nielsen against the 3D (see 2D is Better Than 3D and Top 10 Bloopers for two examples, or look for "3D" in UseIt.com if you want more).

Some time ago, last year, while searching for early WPF controls, I found this cube calendar (Selector3D) made by Ricciolo. I didn't want to be less, so, I developed a control for Himalia using this free cube control. Now, is time to show it.

The control works like a 3D tab, just this, when you press the links the content moves in a cube-like to show the next content, but it's SO COOL when you play with the back and forward buttons! I must confess that I spent like 20 minutes just going forward and backwards the first time I ran it ;)

Believe me, you can't stop of pressing Back and Forward. And that goes even worst, when you notice that got all this stuff with just one drag & drop in the designer, and that it's full reusable, and...

Just in case, the Navigation and Layout models for this example are the following:

The container control is the "red hollow rectangle" in the navigation model, and it means that all the elements within it will be presented using one only control. In this case, we selected the Cube control to do this task. Obviously, the control should know how to present that navigational path, but it is defined in its contract.

But don't be anxious, we will include this control in the next release...

Labels: Controls, Himalia, Usability, WPF

# posted by leovernazza : 4/28/2007 09:46:00 PM  0 comments links to this post

Reading this Joost Willemsen post I found myself thinking once again about the same thing: what is a page?

He tell us that single-page user interfaces are better than multi-pages ones. But.. how to understand it? Is a (Win)Form a page in a Desktop application?  What if you design each task in a different form? Didn't it has the same problems?  At the same time, using frames, you can see n pages at the same time... so?

The problem, from my point of view, is that the user doesn't know about pages. Pages are a platform related artifact, just like php archives, or java classes. Pages live in the implementation world, and NOT in the user world. The hypermedia paradigm tell us that users "know" about the hyperspace (something like the internal representation the user makes of the user interface).  Using this terminology, a navigational element represents an hyperspace concept, like an Amazon "Book".

User interface designers need to make conclusions about how to show related concepts in the screen at the same moment, but not about how to code html.

The Back/Forward problem

One of the most interesting problems related with pages are the Back/Forward commands. The Browser's Back/Forward is a page-based implementation. It was expected, because Browsers are themselves page-based.

However, it causes a lot of problems for the user because "going back" is not the same than "go to the previous page" in most of the cases. Particularly, we had this problem in an intranet application where we loaded some charts using a web services from the client side. I am sure that most of the AJAX applications out there have the same problem today, because you need to interact with the Back/Forward by hand to avoid it. Now, the Avalon Navigation support will have the same problem again, because it was implemented XAML-file based. Of course, you can subscribe to the Journal.. but... will be everyone handling it in the right way?

So, I think it is time to forget pages and start talking about concepts, hyperspaces and navigation elements. There are the real patterns.

Labels: Browsers, Himalia, Hypermedia, Usability, WPF

# posted by leovernazza : 11/26/2006 05:12:00 AM  0 comments links to this post