Thursday, June 19, 2008
We Are Up Again
WE had the server down during two weeks thanks to Yahoo (please do NOT register your domain with Yahoo Small Business at least you don't need it). Now, it's up again.
Keep tuned, news are coming... (slowly, but coming).
Labels: Himalia
Monday, February 11, 2008
Can UX be a Boomerang?
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
Thursday, January 31, 2008
ENSO, MIX08, Usernames-vs-UX and Aggregated UX
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.
Sunday, December 09, 2007
Bad Changes In The New GMail Version
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
Thursday, December 06, 2007
Lets Build An API
Are you feeling a déjù vu? As always, we need to watch not only the picture but the full movie to understand what is going on.
As Jared Spool said, every market goes through four steps (in this order): Technology, Features, Experience and Integration.
We are now in the Experience phase. Web 2.0 is all about user experience, tell that to 37Signals. However, in the software industry there is an always subjacent war about platforms. Windows, Mac, Office, Google, SAP, Facebook, Data, Html, Browsers... everyone want to be the winner platform, and in this way, they have to open the doors for developers to empower their position, and so, they make a public API. Each day, someone else is entering in the API game, and this is good for all of us.
But the real interesting point are the assumptions in the background.
If you build an API and someone else can replicate your software... which is your competitive advantage? You get the database, the raids, the data center, and the 24x7 problem and the third party the advertisement? Actually, in my modest opinion, there are two very interesting assumptions: the URL fidelity and that data remains in your side. And you know, Facebook is living from its three-tables-database (Users, Friends and Applications) and the gift-card they received from Microsoft to send a message to Google. For this reason, you and many engineers in these companies may think: "we won't put this data available through the API because this is our key data".
The URL fidelity is a very interesting topic. 15 years ago nobody knew about urls and now you can't get a decent one. What will happen in 10 years with urls? Who cares? In 10 years we will be in Web 7.0.
However, the point about the data isn't so clear anymore. This was ok until someone wrote a robot capable of stealing all your data (slides), and now, you can steal and then store it somewhere (it would be very funny to take amazon data and save it back in the EC2, would you join the project?).
But here is the funniest part of the history: they don't need a public API. They are using HTML as your public API and taking all the data they need, to do whatever they want. You can also use this robot and be sure I will be doing it in the future. Hey! It should be illegal! Don't tell me, and what do you think Google has been doing from the beginning? Ok, they call it crawl (not steal) and don't save it in a relational database but in a home-made File System, but this is just tech-stuff.
You know my point of view, users should own the data, or at least, not just [Put Your Favorite Company Here]. I would love to hear your opinion...
Labels: Internet, Platform, Technology
Friday, November 09, 2007
Models @ Runtime
Talking with Daniel Görlich during the MDUCDE 2007, he told me about the new workshop he was organizing in the context of MODELS, "Model Driven Development of Advanced User Interfaces". Digging into the conference, I found this other workshop that also sounds interesting: Models @ Runtime. For me, it's funny because every time I present Himalia, the question about code generation -vs- runtime interpretation is on the table.
What I actually think is that it shouldn't be a public discussion. The user need to obtain good response times, fair processor consumption, etc. but how you provide that shouldn't be his problem. For example, I don't care if SQL Server or Oracle are generating specific code for each database definition or if they are interpreting each DB model in each query. And that's good, it should behaves as a black box for me.
I think there are basically 4 things to take into account:
1. It is really one faster than the other one? People would usually think that the interpretation strategy is slower, but I think it highly depends on the quality of the generated code versus the quality of the runtime and the performance advantages you could take of having the model live @ runtime (for example, DBMS use optimization techniques as learning from the queries at runtime to obtain better response times).
2. In the resources consumption field I think interpretation is better, because you don't need to replicate everything each time, and so, you can let the underlying layers do their optimization work in a better way.
3. Extensibility/Flexibility is the only field -as far as I can see- where generating code could be the better approach. In the DSL Tools book there is a very interesting discussion about what they called the "Customization Pit" and what kind of things you need to take into account when you support code-generation scenarios. Basically, if you are not providing the right hooks in your high-abstraction language, you should provide the ability to inject the customization somewhere in the process, and so, code-generation and partial classes could be the answer if you don't know which customization scenarios would you need to provide.
4. Before of partial classes, maintainability was a big problem for code-generation tools. Nowadays I think there is no big difference between both approaches.
Finally, sometimes, you just need the model live @ runtime, and so, if you decide to generate code you are at least duplicating the effort. For example, you may need it to modify it, to learn from it, adapt it, etc.
With Himalia, I followed the runtime approach. Why? Because I think that in the long run, having the model live @ runtime will be far better in order to: let the end-user modify his user interface, learn from the model, etc. Obviously, as I don't want to be hoisted by my own petard, I have to dig very well into the customization scenarios and support the required hooks.
Luckily, this is the first time in a long time I found many people converging into this point, as more and more frameworks are being interpreted, and now, there is a conference about the topic :)
Labels: Conference, DSL Tools, Himalia, MDUCDE, Runtime
Wednesday, October 24, 2007
Usability Cookie - Did Hamilton lose the F1 Championship because of bad user interaction?
There are rumors out there saying that Lewis Hamilton lose the F1 Championship, last weekend in Sao Paulo, because he pressed the "wrong" button (the Start button) that "restarted the system".
I prefer to believe that is just a Hamilton's perception, maybe he pressed the button while another error was taking place in the background...
I can't believe such a terrible user interaction design in a F1 car! Why would someone want to restart the system during a F1 race? In any case, it should be a very-very-very-difficult-to-press button, something you should press very hard during 30 seconds with both hands and your head, not a yellow one in the steering wheel.
What is sure, is that all the F1 fanatics are talking about this yellow button all around the globe. So, we should take this lesson: good interaction has no publicity, bad interaction does, and you should avoid it.
Apparently, the team is now denying this information and assigns the episode to an hydraulic fault. Anyway, do you believe are they going to admit such a design error? Who knows?
Labels: F1, Technology, Usability cookie
