leovernazza [at] himalia.net

We Are Up Again

2008-06-19T16:19:00.000-03:00

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).

Can UX be a Boomerang?

2008-02-11T01:58:00.000-02:00

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.

ENSO, MIX08, Usernames-vs-UX and Aggregated UX

2008-01-31T00:55:00.001-02:00

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.

Bad Changes In The New GMail Version

2007-12-09T16:15:00.001-02:00

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 ;)

Lets Build An API

2007-12-06T00:30:00.000-02:00

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...

Models @ Runtime

2007-11-09T13:20:00.001-02:00

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 :)

Usability Cookie - Did Hamilton lose the F1 Championship because of bad user interaction?

2007-10-24T21:58:00.001-02:00

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?

Continuous prototyping

2007-10-15T23:17:00.001-02:00

From a long time ago I wanted to post about this topic because it is one of the features I love about the way we can build the user interfaces with Himalia.

Iterating From Paper

Many studies have shown the importance of early prototypes. Actually, recent articles point to paper prototyping as one of the best tools for the development of user interfaces, in a cost-benefit point of view, because it helps to point the UI in the right direction from the beginning at a very low cost (if you don't use it, you may be very wrong, too late).

But paper prototyping has some problems, most of them related to accuracy and imagination:

you can't test interaction in a reliable way
what you see is not what your get; but mainly, is not what the user see
once you have started with the development, paper-prototyping becomes more and more expensive
once you have prototyped, you have to translate it to code (and you know that translations produce errors)

I think it's similar to the problem we used to have with integration of software before Continuous Integration, so, a similar solution could make sense also here. Note that what makes continuous integration possible, is the fact we have a tool who knows the process used to create software. That is, our integration server knows about check-ins, tests, fails, people, etc and use them as first-class citizens in the process. I think that more and more tasks in software development should be made as frequent as you can, and automatically when it's possible.

If we wanted to take this approach in the user interface field, I would like to have a tool who knows about prototypes, and let me:

start with a little one
load most used layouts and patterns from a repository
change the initial prototype through many steps
test interactivity from the beginning and in each step
iterate in seconds from the changes to the user-feedback
build the final version as an evolution of the initial prototype (I don't want to throw more paper to the bin)

Getting feedback

One main aspect that should be considered, is that the prototyping task is not finished once you release your application. In other words, usage analysis and statistics have changed the way web applications are built today (and probably part of the commerce' history), turning marketing into a tangible discipline. World-class web enterprises are already doing "continuous prototyping", regardless if they use this term or a specific tool in the process. Sites like Netflix, Amazon and Facebook are continually modifying the user interface in order to better adapt it to the user needs or/and add new functionalities.

I think it is obvious, but I will say it anyway: not only web user interfaces should adapt itself from users. The user is the same, regardless he is watching the application inside a browser or not. However, while in the web we can just add a simple javascript to all the pages and get a good analysis, you can't achieve it easily in the desktop (mainly because it lacks of the "addressability" concept).

Putting All Together

So, in order to accomplish both things, we need not only a good tool in the developer side but also a good framework in the user side to make the full story available for us, because feedback is -at least- as important as early-prototypes.

Prototyping should not be seen as the task involved in building an artifact, but as the continuous process of adapting the user interface to the users needs.

In this way, everything we can do to reduce the time from the development to the user feedback, is going to give us more time to do more iterations, and as with continuous integration, each iteration will increase the quality of our "final" product.

Abstraction -vs- Testing

2007-10-02T18:52:00.001-03:00

During the MDUCDE 2007 in Seoul, just before my presentation, Asaf Degani did a great presentation about his work on UI correctness. Basically, he exposed how inconsistencies between the user model (what the user thinks about what the application does) and the user interface model can produce very frightening problems. The example he presented was a inconsistence in the aircraft autopilot... (I have the full paper in my notebook but I couldn't find it online).

"The conceptual approach for generating correct and succinct user-models is based on the fact that not all the system’s internal states need to be individually presented to the user".

That is, the user interface is a projection/view of the application. So, the user model is different from the user interface that is also different from the application/machine. Asaf modeled the user model from the user manual and he found that with the aim of reducing information overhead sometimes what the manual teach is not what the application/machine actually does.

Suppose the plane is planning at 5000ft, if the pilot enters 10000ft in the autopilot interface, then the plane will climb until that height.

Then if the pilot set a new lower height after the airplane has passed a special point, then the airplane turns into an undetermined state, and continues climbing indefinitely. The problem arises because the pilot thinks (because the user manual tells him) this special point is calculated in a way that is not the real way. From the pilot point of view, the machine is behaving in a non-deterministic way: sometimes it works as expected, sometimes it doesn't but he doesn't know why. Why did they write the manual in this way? Well... because with the information available in the user interface, the pilot couldn't calculate the real special point, so they decided to avoid "the details" [1].

Obviously, Asaf concluded that the UI is incorrect because it doesn't give the user all the information he needs to do the task. Maybe the manual is incorrect too, but what actually matters is that they are inconsistent.

From my point of view, this is a particular case of a wider topic that came again and again during the conference, in all the forms you can imagine (from cars to aircraft autopilots and smart factories). When you use different languages for each world you have to do a lot of extra work in testing to ensure you are keeping it consistent, because basically, what you are doing is to add more translations. The bigger the difference between the languages, the bigger is the probability to produce translation errors between them. In some fields, it may be still too difficult to unify both worlds in one only language, but in others, we are just not taking the right approach to solve the problems.

However it also happens in other models: software design, implementation, etc. If we were able to merge them, we could avoid testing the translations.

Some time ago I had a similar conversation with Andrés about this topic (he had written a post about it). We agreed that when you express things at the right abstraction level, testing is useless, because it becomes a tautology. Would you test that the += operator is working properly in C# or Java?. I wouldn't.

To put this in the context of Asaf's work, if the aircraft autopilot and the manual are made with the same language, his work would be useless. You wouldn't need to prove the UI correctness because it will always be consistent with the user model [2].

Obviously, taking this approach ought you to test your high-abstraction language... it is a trade-off, but in most of the cases this is a far simpler and better limited task than testing all the user interfaces, and sometimes it can also be "outsourced for free" as we do with the += operator.

I think Eugenio Pace said exactly this in a different way a week ago, talking about SaaS in the Genexus Meeting. He proposed something like the Law of Conservation of Mass for complexity and software. He said: you can't avoid complexity, but you can redistribute responsibilities and that is what SaaS is about.

I think it is also what DSLs are about, translating complexity until some day, when magically a lot of testing and translations disappear and you can focus on what is really important for your business.

[1] Yes, this is how an aircraft autopilot works today, but don't panic, it is a very strange situation and I believe they can take the airplane control again in any case. I can't remember the special point name, and the exact calculation, but it's not the important thing here.

[2] Asaf is currently working on how to automatically generate the UI from a reduced user model and avoid the testing by producing correct user interface by design.

How To Solve A Conditioned-Air Bug?

2007-10-02T14:18:00.001-03:00

Ingredients: An elastic eyes-cover and food aluminum paper.

It worked for 10 hours avoiding the cold air directly in my face ;)

Update your feed

2007-09-27T02:01:00.001-03:00

Please, update your feed to point to http://feeds.feedburner.com/leovernazza.

I also categorized all my old posts and added a "Labels" menu on the right pane.

I would like to put it as a tag cloud but I will need to fight against Blogger or move to another publisher.

(It's not so easy when you are publishing via FTP from Blogger as I am... probably I should change something there)

What Is A Platform?*

2007-09-20T15:49:00.001-03:00

Probably, you have read the Marc Andreessen' post about the three kinds of platforms, and the interesting answer from Joshua Allen. If you don't, I recommend both.

First, I don't believe Marc Andreessen is using his argument to advertise Ning. It makes no sense, he doesn't need it. From my point of view, he has an obviously strong conviction about where the platforms should go, and that is the reason why he founded it.

He proposes basically two things: something can be called a platform if you can program it; and that you can classify all the platforms in three levels depending on where the code runs (remote code that uses an API to communicate with the platform, a plugin attached to the platform, an application inside of the platform).

Then, Joshua responded that his analysis has some problems because the data is the platform, not the software. That is clearly part of the vision of Tim Berners-Lee for the semantic web.

But, my question is: is data enough?

I don't think so. I think we need a Marc Andreessen' style platform to make the Joshua's data accessible in a massive and new way for everyone, something very close to the Strategy Letter IV that Joel wrote a few days ago. With that conviction I founded Himalia two years ago, to give the developers something they can program to give their users much more data available, in an easy and interoperable way. This is a very long way, but I am convinced that it is where we should go, because we have the technology to do that.

(*) I added this post to my software redefinition series, What Is A X?. We need to rethink many of the definition of the main concept of our still young industry.

Usability Cookie - Airplane entertainment system

2007-09-09T10:56:00.001-03:00

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.

I have the DSL Tools book!

2007-08-31T00:55:00.001-03:00

It's very strange to see part of your work in someone else book...

Thank you Andrés for the book!

I will take the book to the conference to read during my loooong flight to Seoul. I will post some thoughts about it when I come back home.

MIT Sketching

2007-08-30T19:11:00.001-03:00

Take a look to this video. I am wondering why I didn't have this tool during my physics classes in the university.

The video's comments don't seem to agree with me ;)

Pay-per-crawl

2007-08-28T22:40:00.001-03:00

One of the first things I understood after I created this blog was that Google is using their power (position) in a very insane way. To say in their words, they are being a little evil.

People think Google indexes the web, but really, they don't make too much (after they created the brand and the PageRank algorithm). Some studies say 30% of the web isn't indexed. That is, 1 of 3 pages you are looking for, is not present in any search engine.

Believe me, you have to work hard just to enter in a search engine (one month or more from your submission), and then, if some day they decide to include your website, you have to hire a SEO to make Google work properly, and appear in the first page when the user type your name... Google should be indexing the web in the right way, not you (by hiring a SEO for them), or Google should pay for it.

It is a vicious circle, you pay a SEO and Google get more people working for them to get the top-5 positions for the "britney spears" search entry. Then, that word becomes more competitive and you need another SEO to keep your position. It is ironic, everybody doing the Google's work while they give 20% to their employees to create Orkut for Brazilians and play ping-pong ;)

But if it is not enough, Google consumes your bandwidth (money) every time they crawl your site. Ok, you may think it isn't too much waste, they are just using a little part of your bandwidth... but, what would you think if 1 million of companies start crawling the web and your site, just like Google does. Clearly, that is different, because the abuse becomes obvious. On the other hand, you can't use a robot to consume their money (i.e. writing a program to auto-click adSense advertisements) because they may sue you. So, why can they waste my money but I can't waste theirs? Do you think it is fair? I know, I can write a robot.txt file to avoid the crawler, but why should I waste my time for them? Why are they assuming they can use my bandwidth?

I think it will be a problem in the long run. But don't panic, it won't happen for a while. Some day, if everything continues as it goes, people will notice that Google is not producing accurate results for their searches, because SEO's are manipulating them, and a fairer search engine will emerge. Google is becoming a advertised menu, and I don't want to search stuff there.

Let be sincere, Google is not producing the web, they are just getting money from your production and using your resources to do that! It could be a fair model when they were a start-up, but nowadays, that they are earning billions of dollars with your customers and your bandwidth, and you have to outsource a SEO for them, I think it can be considered evil, don't you?.

I can think in two solutions to this problem on the top of my mind: Google should pay-per-crawl your site, and they should crawl your site only if you specifically allow them (crawler should be disabled by default). But I will keep thinking, in Internet you always can do something to avoid the use of the power.

What do you think? May be, I am the only one thinking that this model is wrong.

I'm going to the MDUCDE2007 in Seoul

2007-08-16T15:21:00.001-03:00

I am traveling to Seoul (South Korea) to present "HIMALIA: Model-Driven User Interfaces Using Hypermedia, Controls And Patterns" in the first workshop on Model-Driven User-Centered Engineering 2007. The presentation is programmed to be on September 5 at 14:00hs, after the launch. I am expecting to meet interesting people there, and have some productive interchange with other similar-fields researchers to enrich ourselves.

I made this map to show the straight and VERY LONG flight. It is difficult to measure the amount of time on-the-fly because of the different time zones, but in any case, it isn't less than 30 hours!!! I hope not to experience very much jet lag, but I think it will be impossible to distinguish between jet lag and 30 hours of flight ;)

So, don't expect very much activity in this blog from 1st to 9th September. I will share the photos and surely some comments when I came back home.

BTW, if someone knows the people in the DICyT, could you hurry up them? I sent them an one-page-letter three weeks ago, but they didn't have enough time to see it yet... came on! it's one page! They should be receiving like 1000 letters a day to argue that, and I don't think it's the case.

Navigation != Presentation

2007-08-09T14:45:00.001-03:00

BrowseGoods (via elAbra, via dirk) presents the same navigation model than an usual e-commerce shopping, but, with a different presentation approach.

For both cases the Navigation Model should look like a traditional hierarchy composed of menus and indexes of goods. But this time, it is presented in an only zoom-in-out control, instead of using traditional controls as does -for example- Amazon (i.e. menus, grids, search boxes, etc.).

The Navigation Model exposes the navigation paths the user have to follow to reach each concept; the Presentation Model just defines where and when render each concept and specifies which control to use for each case.

It can be a good example to show the power of the separation of concerns exposed in the Himalia's meta-model (that was taken from older hypermedia methods). I will add it to our Mingle.

Plastic figurine as input

2007-08-06T16:58:00.001-03:00

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.

New user interface for search engines!

2007-08-05T16:44:00.001-03:00

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.

Book-Driven Development

2007-07-27T14:37:00.001-03:00

Watching this Chris Anderson's interview, he explains the new development methodology they are using in the Connected Systems team.

He says they are going beyond Testing-Driven Development (and obviously Behavior-Driven Development), they are not thinking how to test the code they are writing, they are thinking how to write the book that explains the technology while they write it!!!

Really, I don't know if it is true, but it sounds good.

TDD and BDD are based on how your consumer will use your technology, and in this kind of team, their consumers usually read the book while they use the technology. I don't believe you can rigorously follow this methodology, but it could be an interesting principle to have in mind while creating new stuff.

P.S: BTW, he also thinks that WPF is a "tipping point" for model-driven development. May be the start for model-driven user interfaces? Who knows..

What Is An Operating System?

2007-07-19T20:16:00.001-03:00

We all know that Windows, Linux, OS/2, Unix, etc are Operating Systems.. but how do you define them concretely?

Is it a set of drivers? Is it a platform to run applications? Is it just a set of applications?

I remember the OS's teacher trying to answer this question the first day of classes... but he couldn't find the right answer.

Facebook has acquired Parakey, a company that promote themselves as a Web Operating System..

So, this question came to my mind again: is Parakey really an Operating System? What do you think?

But, who cares? I am sure that Facebook has paid it as if they were ;)

iPhone? No, Simon!

2007-07-05T13:22:00.001-03:00

If you think the iPhone was the first multi-touch user interface phone, you are wrong.

Bill Buxton, the man behind Microsoft Surface explains the multi-touch history here (and his history with multi-touch user interfaces).

Please, don't forget to scroll down to see the Simon phone launched for IBM and Bell South in 1992!!!!

The reasons why nobody know it:

launched too early?
technology adoption curve is longer than people believe?
marketing is SO important?

What do you think?

Himalia on Acropolis

2007-06-28T13:05:00.001-03:00

Some people believe Himalia and Acropolis may overlap in some zones. And they are right! Himalia and Acropolis overlap in the zones where Himalia doesn't want to be... Yes, some time ago we had to build our own service schema and now we were thinking about a composite strategy for large teams... but it isn't our real focus. We just want to have more time to show you how we can build semantic user interface in minutes... this is our mission!!! (BTW, we will need this services schema anyway for the other platforms: asp.net and .net 2.0. Keep in mind that Acropolis requires .net 3.0)

Now that the first Acropolis CTP is public, our composite strategy will be far easier: we should put just on top of Acropolis.

So, I spent a couple of hours trying my first approach... (there are other two methods we are discussing right now and will attack in the near future).

**** Disclaimer: This code doesn't work with the public version available from December. ****

1. Create a Part Library, and name it Himalia.Acropolis

2. Add a new Part (HimaliaPart) and a new PartView (HimaliaPartView)

3. Add a new connection point to the Himalia Part: RootElement

<AcropolisComponent.ConnectionPoints>
<ComponentProperty Name="RootElement" />
</AcropolisComponent.ConnectionPoints>

4. Override the OnFactoryCreationComplete method on the HimaliaPart

        protected override void OnFactoryCreationComplete()
        {
            base.OnFactoryCreationComplete();

            // Creates the Himalia Session in the WPF Runtime
            WinFxUISession session = new WinFxUISession(this.Name);
            session.StandAlone = false;
            this.Title = session.Title;

            // Set the root element to the connection component property
            this.RootElement.Value = session.Start<FrameworkElement>();
        }

5. Override the OnPartAttachedmethod on the HimaliaPartView

        protected override void OnPartAttached()
        {
            base.OnPartAttached();

            // Add the root element to the control
            this.Children.Clear();
            this.Children.Add(this.Part.RootElement.Value as UIElement);
        }

6. Now, in your Acropolis application, you can use HimaliaPart's, like this

  <AcropolisApplication.ChildParts>
    <Him:HimaliaPart Name="C:\\PetShop.hui" />
    <Him:HimaliaPart Name="C:\\Invoices.hui" />
  </AcropolisApplication.ChildParts>

7. Replace the OnActivated method of the Application (it throws a null exception because the MainWindow is bad set, I don't know why)

        protected override void OnActivated(EventArgs e)
        {
            foreach (Window w in this.Windows)
            {
                if (w is Window1)
                {
                    base.MainWindow = w;
                    break;
                }
            }
            base.OnActivated(e);
        }

8. This is how it should looks like:

Conclusion

You can integrate Himalia and Acropolis points of view nicely. In one side, Acropolis allow you to better segment the desktop application in divisible parts. On the other side, Himalia allow you to better create each part, focusing in the most important things for your users. Remember, Himalia focuses on usability and is a modeling tool. Acropolis focuses on composability and extensibility and isn't a modeling tool.

But soon, you will see how these developer-side separated user interfaces could be user-side integrated again... just give us some time.

Technorati tags: Acropolis, Himalia, Semantic UIs, WPF, Orcas

Multi Touch User Interfaces

2007-06-20T14:35:00.001-03:00

I found this "open source multi touch" group (http://nuigroup.com/) and the free C++ library (TouchLib) including the Visual Studio solution.

I would like to have enough time to give it a try!!!