himalia.net | community blogs

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

# posted by leovernazza : 6/19/2008 04:19:00 PM  1 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

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

# posted by leovernazza : 11/09/2007 01:20:00 PM  3 comments links to this post

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:

1. you can't test interaction in a reliable way
2. what you see is not what your get; but mainly, is not what the user see
3. once you have started with the development, paper-prototyping becomes more and more expensive
4. 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:

1. start with a little one
2. load most used layouts and patterns from a repository
3. change the initial prototype through many steps
4. test interactivity from the beginning and in each step
5. iterate in seconds from the changes to the user-feedback
6. 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. 

Labels: Guilder, Himalia, Prototyping

# posted by leovernazza : 10/15/2007 11:17:00 PM  2 comments links to this post

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.

Labels: Himalia, Platform, Software redefinition series, Technology

# posted by leovernazza : 9/20/2007 03:49:00 PM  0 comments links to this post

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.

Labels: DSL Tools, Himalia

# posted by leovernazza : 8/31/2007 12:55:00 AM  0 comments links to this post

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.

Labels: Acedemic, Conference, Himalia, MDUCDE, Travel

# posted by leovernazza : 8/16/2007 03:21:00 PM  0 comments links to this post

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.

Labels: Himalia, Hypermedia

# posted by leovernazza : 8/09/2007 02:45:00 PM  0 comments links to this post

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.

Labels: Acropolis, Himalia, WPF

# posted by leovernazza : 6/28/2007 01:05:00 PM  0 comments links to this post

Himalia is being retrieved in the first place at least for the following search keywords in Yahoo:

• . model driven user interfaces
• . model driven user interface
• . model driven uis

This is the fist time in the history of the World ;) that any Search Engine retrieves Himalia as the first one in the result list for a search keyword not including: "Himalia", "Leonardo Vernazza" or "leovernazza". I always said that the Yahoo search engine was moving faster that the Google one... ;)

Let me know if there is any new keyword throwing traffic to Himalia.

Labels: Crawlers, Himalia

# posted by leovernazza : 5/23/2007 03:54:00 PM  1 comments links to this post

As Steve Cook points out, the DSL Team's Book is almost ready for sale.

I want to congratulate the DSL Team, they have made a fantastic work with the tool itself and I am sure the book will be great too.

Gareth Jones indicated that you can read it online using Safari.

You can also look for "Himalia" inside it using this online tool ;)

I told you.

Labels: DSL Tools, Himalia

# posted by leovernazza : 5/18/2007 12:45:00 AM  1 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

I made an abstract submission for the First International Workshop in Model-Driven User-Centric Design & Engineering that will take place in Seoul/Korea on September 4-5, this year.

My submission was accepted. Now, I have to make it happen. That means: to complete the final paper and figure out how to go to the other side of the world ;)

If you will be in the zone, please let me know, it will be great to met there.

Labels: Conference, Himalia, MDUCDE

# posted by leovernazza : 4/27/2007 10:39:00 PM  0 comments links to this post

When someone ask me the typical "what are you doing?" question I have two possible responses.

I'm doing a software product for software developers, you won't understand.

This is the typical answer to my father, my sister and my girlfriend (my mother doesn't ask me, she already knows I'm playing with the computer). But it works, and nobody keep asking and it is the idea ;)

On the other hand, for the computer guys my answer has changed in the last year.

At the beginning, I defined Himalia as a language for service-oriented user interfaces. It's still the definition you can see in the index page of the website. But it had a problem: nobody knew what it was and they used to say something like: "aaahh". Nobody has ever asked me a second question, but it wasn't the idea here ;)

Then, Andrés Aguiar, defined it as a model-driven tool for user interfaces.

The first time I read it I found it simplified, but then... I understood. You can't say everything in the first sentence, and really you don't want to do it. When you try, you loose the chance to get the people interested. Although this definition doesn't define the technology and focuses only in the tool (Himalia Guilder), it's a very good introduction that everybody understand.

But now, my new answer is that Himalia is a user interface builder, that is the guilder definition after all. Why? I don't want to carry on the Himalia's shoulders all the problems of the model-driven tools' history. Himalia wasn't made just for modeling, it was made for modeling and running a user interface; for the specification time, the design time but also for the runtime. We want something else that writing down the models in a paper and admire them, that is the purpose of most of the formal modeling languages.  So, this definition make sense for the real Himalia goal: to build user interfaces. Simple.

Keep it in mind, Himalia is a user interface builder, and more, Himalia is the user interface builder, until someone copy us.

Labels: Guilder, Himalia

# posted by leovernazza : 4/16/2007 08:13:00 PM  1 comments links to this post

This snapshot was taken from the Himalia's website visitor stats from Europe.

The top-five list is the following:

1. France
2. Germany
3. United Kingdom
4. Netherlands
5. Belgium

This is a little strange, if you see the Internet Usage in Europe stats:

1. Germany   50,471,212
2. United Kingdom   37,600,000
3. France   30,837,595
4. Italy   30,763,940
5. Russia   23,700,000
6. Spain   19,765,032
7. Turkey   16,000,000
8. Netherlands   12,060,000
9. Poland   11,400,000
10. Portugal   7,782,760
11. Sweden   6,890,000
12. Ukraine   5,278,100
13. Belgium   5,100,000

 50. Vatican City State 93

So, first conclusion, the Pope is using Internet and as a consequence, the Vatican firewall configuration will be a controversial issue some day ;)

And second, you need to spread the word in different languages if you are planning a global strategy. I think this post helped giving french readers to the website and turning France as the second country in the world-wide Himalia's website visitor list, after USA.

There are post about Himalia written in French, Spanish, English, and now, there's a post written in Lithuanian, but I don't understand anything about them ;)

The point is that there are a lot of people out there that never will know about Himalia just because the read in other languages, and so, we will need help with it :-)

Labels: Himalia, Internet

# posted by leovernazza : 3/22/2007 03:26:00 PM  0 comments links to this post

Microsoft (through Wilson Pais) invited me to talk in the first Architect Forum of the year in Santiago de Chile.

I also used this opportunity to visit a friend of mine who lives there, Hugo Cortés. I meet him for first time in March 2004 when he come to Montevideo -as a member of Un Techo Para Chile- and helped us to create Un Techo Para Uruguay, a non-governmental organization that help houseless people in my country. I'm outside the organization now (because you can't do everything at the same time), but I really feel as a member of it... technically, I'm one of the founders ;)

Back to the Architect Forum, Alejandro Pacheco made a discussion about the available technologies for the presentation layer. After that, Martín Cabrera introduced Domain-Specific Languages, and showed a mini-example. Then I presented Himalia and finally, Carlos Carminati and Luis Molfino presented their company and what are they doing.

In the picture, from left to right, you can see to Martín Cabrera (Microsoft), Carlos Carminati (d2B), Luis Molfino (d2B), Alejandro Pacheco (Microsoft) and me. 

My presentation was specially discussed with the people, so I think they enjoyed it ;) I already know that the Himalia proposal is disrupting, and it's great when people keep thinking about these ideas.

This photo was taken by Luis Molfino, as you can see he's an artist :)

I want to thank you to Martín Cabrera and all the Microsoft Chile team. Surely we will meet again in the near future...

Labels: DSL Tools, Himalia, Talk, Travel, WPF

# posted by leovernazza : 3/06/2007 12:55:00 AM  0 comments links to this post

One of the first task after the beta release was to redefine the Presentation Model Designer (the one under the "Layout" node in the solution explorer).

It should be intuitive, useful and simpler.

As you can see, we were very uncomfortable with the ease-of-use of the 0.8 version, but it was just the first presentation designer version.

The Presentation Model Designer is also made with the DSL Tools, and in the next released version, will looks something like this.

The new features include:

• . Screen resolution design-time testing. It allows you to change the target screen resolution and see how it looks.
• . Transitions were included in the model itself as arrows... It's far more intuitive!
• . Area control was merged with the area definition in order to make it simpler to understand.
• . Propagation rules were removed. Now you should set the landmarks and/or the propagating child (the model is still using propagation rules, but you don't have to care about it anymore). The landmarks are shown in the diagram, decorating the area with the navigational element icon.
• . You can define visual effects (fx) for any transitions, like in Power Point. This feature will change the world ;)
• . All the diagram decorators can be shown/hidden with in one-click. The decorators are: Docking, Transitions, Effects, Area names, Constrains, Landmarks and Propagation rules. In this way, you can focus in the specific aspects you are modeling at each moment.

Labels: DSL Tools, Guilder, Himalia