Sunday, November 26, 2006
The "page" thing
Reading this Joost Willemsen post I found myself thinking once again about the same thing: what is a page?
He tell us that single-page user interfaces are better than multi-pages ones. But.. how to understand it? Is a (Win)Form a page in a Desktop application? What if you design each task in a different form? Didn't it has the same problems? At the same time, using frames, you can see n pages at the same time... so?
The problem, from my point of view, is that the user doesn't know about pages. Pages are a platform related artifact, just like php archives, or java classes. Pages live in the implementation world, and NOT in the user world. The hypermedia paradigm tell us that users "know" about the hyperspace (something like the internal representation the user makes of the user interface). Using this terminology, a navigational element represents an hyperspace concept, like an Amazon "Book".
User interface designers need to make conclusions about how to show related concepts in the screen at the same moment, but not about how to code html.
The Back/Forward problem
One of the most interesting problems related with pages are the Back/Forward commands. The Browser's Back/Forward is a page-based implementation. It was expected, because Browsers are themselves page-based.
However, it causes a lot of problems for the user because "going back" is not the same than "go to the previous page" in most of the cases. Particularly, we had this problem in an intranet application where we loaded some charts using a web services from the client side. I am sure that most of the AJAX applications out there have the same problem today, because you need to interact with the Back/Forward by hand to avoid it. Now, the Avalon Navigation support will have the same problem again, because it was implemented XAML-file based. Of course, you can subscribe to the Journal.. but... will be everyone handling it in the right way?
So, I think it is time to forget pages and start talking about concepts, hyperspaces and navigation elements. There are the real patterns.
Labels: Browsers, Himalia, Hypermedia, Usability, WPF
Monday, November 20, 2006
Measuring UI Productivity with Himalia
I was reading the Jakob Nielsen's article about Productivity and Screen Size. He says: "Productivity is one of usability's most important elements", and he is right :)
I think that the Himalia's approach facilitates the way User Interface productivity can be measured. I believe we can find a way to measure it automatically, maybe setting the weight of each Use Case for each profile (or "Persona"?). At least, we should be able to compare the productivity of two different user interfaces definitions solving the same user goals against one specific criteria, and that is better than nothing.
Now, I am adding it to the ToDo list. Who knows?
Labels: HCI, Himalia, Productivity
Sunday, November 19, 2006
Releasing this week
We have all ready to release the first public version of Himalia this week.
It will include the designer for VS2005 (Himalia Guilder for Visual Studio 2005), the abstract Runtime environment, the WPF adapter for the runtime, and a standard control library for WPF too. Although we have no intentions of providing controls, we should make it while we have no alliances with third party control providers. We have also included a study case in this package: the Pet Shop application.
We think that this release will allow you to "guild" very quickly very interesting UIs.
Some work was also made in the website, there is a comparison chart with other technologies like CAB, UIPAB, RubyOnRails and DeKlarit. Now, you can fix an idea about what kind of problems are we trying to solve with Himalia.
