himalia.net | community blogs

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

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

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

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