UI Technologies are trendy…but what are they really good for?
vote
+2 rating
/ 6 vote
Loading ...- 10 comments
- 4 pings
- view license
[UI development flow and actors: Graphical Designer, Interaction Designer, Software Engineer, classical technologies: GTK, Qt, next generation: Flex, Silverlight, WPF, TAT, XUL, SVG… guest blogger Thomas Menguy describes what are the main concepts behind all the UI technologies, what the new generation ones have in common, what those modern approaches are bringing to the product development flow…and what is missing for the mobile space].
A good UI is nothing without talented graphical designers and interaction designers: How the plethora of new UI technologies are helping unleashing their creativity? What are the main concepts behind those technologies?Let’s try to find out!
UI is trendy… thank you MacOS X, Vista and iPhone!
|
|
|
|
|
UIQ |
S60 |
iPhone |
Put the designers in the application development driver seat!
Here is a little slide about the actors involved in UI design
UI flow actors and their expertize
What does it mean?
Different actors, different knowledge …. So different technologies and different tools!
Those three roles can be clearly separated only if the UI technology allows it. This is clearly not the case in today mainstream UI technologies where the software engineer is in charge of implementing the UI and the service part, most of the time in C/C++ , based on specifications (word document, Photoshop images, sometime adobe flash prototypes), that are subject to interpretation.
-
The technologies used by the designers have nothing in common with the one used to do the actual UI.
-
The technologies that allow UI implementation…require an heavy engineering knowledge.
-
Big consequence: the software engineer decides at the end!
The picture is different for web technologies where it has been crucial and mandatory to keep strongly uncorrelated the service backend from its representation : Web browsers have different API and behavior, backend have to be accessed by many other way than web representation…and above all data is remote and presentation is “half local/half remote”.
Separating representation, interaction and data has been the holly grail of applications and services development for years. It has been formalized through a well known pattern (or even paradigm in that case) : MVC (Model View Controller)
MVC pattern / source: wikipedia
- From wikipedia: http://en.wikipedia.org/wiki/Model-view-controller
- Model
- The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items).
- Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.
- View
- Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.
- Controller
- Processes and responds to events, typically user actions, and may invoke changes on the model.
All the UI technologies are offering a way to handle those 3 aspects and, as a consequence, are providing a programming model defining how information and events flow is handled through the MVC.
See below a simple schema I’ve made describing a GTK application: when you look at an application screen, it is made of graphical elements like buttons, lists, images, text labels, called widgets (or controls) .
Rmk: the term “widget” is used with its literal meaning : “window-gadget”, this term is now used a lot in web 2.0 marketing terminology and by Yahoo/Google/MS to represent a “mini application” that can be put on a web page or run through an engine on a desktop PC or a mobile phone, to avoid confusion I prefer the term of “control” over widget for the UI technologies, but will continue using “widget” in the rest of the GTK example as it is the term used by GTK itself.
Widgets are organized hierarchically in a tree, meaning that a widget can contain other widgets, for example a list can contain images or text labels. In the example below the “root” widget is called a “Window”, it contains a kind of canvas which itself contains a status bar, a title bar, a list and a softbutton bar. Then the list contains items, the title bar has a Label, the softbutton bar contains some buttons and so on.
A widget is responsible for
- Its own drawing using a low level rendering engine, called GDK in the GTK case (GDK offers API like draw_image, draw_text, etc).
- Computing its size according to its own nature (like the size of the text that will be displayed for example) and the size of its sons.
- Reacting to some events and emiting some specific ones: the button will emit a “press event” when it is pressed with the touchscreen or when its associated keypad key is pressed.
The widget tree will propagate system events (keypad/touchscreen, etc) and internal events (redraw, size change, etc) through the widgets. The developer will register callbacks (in fact functions, piece of code implementing a functionality) that will be called when widgets will fire events (like the “press event”) .
GTK Widget tree structure: a phone screen example
The major GTK/gLib formalism is how those events/callback are handled: through what is called a “gloop” where all events are posted in the loop queue, dequeued one by one and “executed” in this loop, meaning their associated user callbacks will be called. This loop is running in one thread. This is what we call a programming model. In nearly all the UI technologies such a loop exists with various formalisms for the queue handling, event representation, etc.
To finish with the above schema the user callback will then access to the middleware services, the various databases and so on.
There is no clear MVC formalism in that case, the controller is mixed with the view …and even the model that is mixed … with the widgets! (so with the view)
Qt Model is really identical to the this one.
One last point very relevant for application development and design: the notion of states. Each application is in fact a state machine displaying screens linked by transitions, like in the example below where in the state 1 the user decides to write an SMS, it will open an SMS editor screen and clicking send will go to a selection of phone numbers.
Application State Machine: write sms example
Here is an attempt to formalize a modern UI framework with Data binding (for Model abstraction).
UI engines formalization
| Control: | equivalent to a widget but where the MVC model is fully split. A Data Model as to be associated alongside with a Renderer to make it usable. |
| Control Tree: | equivalent to the widget tree: aggregation of Controls, association of the controls with a Renderer and a Data Model. Possibly specification of Event Handlers. |
| Data Model: | Object defining (and containing when instantiated) a set of strongly defined and typed data that can be associated with a Control instance. |
| Data Binding: | Service used to populate a Data Model. |
| Control Renderer: | Object that is able to graphically represent a Control associated with a Data Model, using services from a Rendering Library. |
| Rendering Library: | Set of graphical primitives, animations, etc. |
| Event Handling (and Event Handler): | code (any language) reacting to events and modifying the current state machine, the Control Tree, etc. |
| Standardized Services: | Interfaces defined to access middleware directly from the event handling code. |
| Server Abstraction: | Possibility to transparently use Data Binding or any service call locally or remotely. |
Ok if you are still there, and your brain is still functional, here is what’s happening today in this area….
In traditional UI frameworks like GTK, Qt, win32, etc the control tree description is done with a C/C++ description … a little niche technology have paved another way: it is called HTML: after all an HTML web page description is defining a tree of controls, W3C use a pedantic term for it : the DOM tree. JavaScript callbacks are then attached to those widget to allow user interaction. It is why all the new UI technologies are based on an XML description for this tree, it is muuuuuch more easier to use, and allow a quicker description of the controls, and above all it allows nice design tools to manipulate the UI….Apart from this XML representation the majority of the UI technologies are coming with:
- An animation model, allowing smooth transitions, popularized by the iphone UI, but it was already there in MXML (Adobe Flex Format), XAML (MS format), SVG, TAT offer….
- Modern rendering engines (Flash for Flex, MS has one, TAT Kastor).
- Nice UI tools for quick implementation: Adobe Flex Builder, MS Expression line, TAT Cascades, Digital Airways Kide, Ikivo SVG…
- In many case : a runtime, to be able to run a scripting language.
Here are some quick tables, really not complete, of some of the most relevant UI technologies in the PC and mobile phone space.
Just to explain the columns:
- RIA : Rich Internet Application, delivered through a browser plugin
- RDA : Rich Desktop Application: delivered through a desktop runtime
- Runtime: ok, galvoded name here, just a name to represent the piece of technology that allows the UI to run
- UI: Technology to describe the control tree (you know what it means now!)
- Event Handling: the dynamic UI part, and how to code it (which languages)
- Tools: UI tools
RIA&RDA Chart
Embedded rich UI technologies
So its time to answer the main point of this post: How those technologies are helping unleashing designers creativity? By defining a new development flow, allowing each actors to have a different role.
Here is an Adobe Flex “standard development flow:
Adobe Flex&Air tools flow
In the next schema I try to depict a more complete Adobe Flex flow, adapted to the mobile world, where, for me, a central piece is missing today: it is not possible now to expand “natively” the adobe air engine, this is mandatory for mobile platform with very specific hardware, middleware, form factors.
So I take the adobe flow more as an example to demonstrate how it should work, than as the paradigm of the best UI flow because this is not the case today (same remarks for MS flow, less true for TAT for example)
An Adobe UI design flow for embedded
This shows clearly that the “creativity” phases are clearly uncorrelated: different tools are used between the designers, they can do a lot of iterations together, without any need of the software engineer. This one can focus on implementing the services needed by the UI, optimizing its platform, adding middleware features.
- Interaction Designer defines the application high level views and rough flow
- Graphical Designer “draws those first screens”
- Interaction Designer import it through Thermo
- Graphical Designer designs all the Application graphical Assets
- Interaction Designer rationalizes and formalize what kind of data, events and high level services the application needs
- Interaction Designer & Software Engineer are working together on the above aspects HINT: A FORMALIZM IS MISSING HERE once done:
- Software Engineer prepares all the event, data services, test it unitarily, in brief: prepare the native platform
- Interaction Designer continues working on the application flows and events, trying new stuffs, experimenting with the Graphic Designer based on the formalism agreed with the Software Engineer.
- Once done … application is delivered to the Software Engineer that will perform target integration, optimization…and perhaps (hum certainly) some round trip with the other actors
So this is it! this flows really focus on giving power to the designers…taking it from the engineer hands. Some technologies are also missing to really offer a full Mobile Phone solution:
- All the PC technologies are about building ONE application and not a whole system with strong interaction between application. With today technologies, the designers are missing this part….leaving it to the engineer: How to cleanly do animation between applications?
- Strong theming and customization needed for:
- product variant management: operator variants, product variants (with different screen sizes and button layouts for example), language variant (in many phones 60 languages has to be supported, but in separated language packs).
- A not well known one: Factory line fast flashing of those variants. It is very long to flash the whole software of a mobile phone while on the factory line … so if you are able to have a big common part and a “customization” part as little as possible but with the full UI…you gain productivity…and big money
- Adapted preset of widget or controls (try to do a phone with WPF or Flex…all the mandatory widgets are missing)
Anyway an UI technology is only the way to interact with a user…to offer him a service. Most of the technologies presented above are about service delivery and not only UI…My next post will be about this notion of service delivery platforms.
[Update] Replaced the term “ergonomics specialist” by “Interaction Designer”, thanks Barbara, see comments below.
The professions involved in creating a user interface have increased significantly since the time I would have agreed with the graphics designer | ergonomics specialist | software engineer mapping. In fact, many of those professionals would be offended by the description of “ergonomics specialist”. They would prefer the substitution of “interaction designer”, with the observation that ergonomists are largely not trained in design.
I say this as an engineer, ergonomist, interaction designer, business manager. Knowledge acquired in that order.
Thanks a lot for the insightful comment Barbara.
I really prefer your term of “interaction designer” over mine.
ergonomics specialist is more of an adaptaion of a french word (yes, I’m a froggy) than really what I had in mind. I’ll modify the article to reflect that, thanks.
I’m coming from the handset world, more with an ODM vision…where UI design and user experience flow are , hum, let say prehistoric, for the majority of actors. In this world UI are defined in a big MS Word document, and software engineer are trying to code in in C…those technologies allows to put in place new flow, with strong added value in the definition and design phase.
You are right in stating that “in the end the software engineer decides”. This is at the core of why its so hard to make great usable products. The software engineer is highly trained in the ability to “think like a computer”. The logic that governs a computer is not the same logic that governs human minds.
The engineers’ primary task is to implement functionality. When resources are sparse, that’s what he or she will focus on. There is also the issue that software engineers are often more interested in the “inner workings”. Implementing usability might not involve a programming challenge or a new technology.
You seem to suggest that this problem can be overcome by better technology, and I tend to disagree on that. I believe that the main problem is organizational, not technical. If you want a good UI, you have to put people that focus on a good UI in charge.
Of course, when the user interface can be declared in a markup language, which is a very important benefit. Especially where there are good UI tools available.
An organizations ability or create usable products are not dependent on their choice of technology. Scott Berkun says this better than I can; here is a quote from his blog:
Who has the most control over how well a thing is made? That’s really what all of us want: well made things. The answer to the question is always either:
A) People who do the making, or
B) People in charge of the makers.
For all their progress, most usability/design folks are still neither A nor B. Instead most are
C) people who try to convince A or B to make things in a certain way.
No matter how talented you are, if you are a C, your talents will often be watered down by A and B. If you want more power, there’s only a limited amount A and B will be able to grant, no matter how much they need and respect you.
(http://www.scottberkun.com/blog/2007/usability-is-not-a-verb/)
Oops, I clicked Submit before proof-reading. Sorry for the messy comment above. Maybe this blog needs a way to preview comments.
(You know, Interaction Designers are never satisfied! :-))
Hi Morten,
What I’ve said is not that technologies is enough to overcome the issue.
It is more, like you said, a Development flow, by development I mean the flow from Marketing for definition, to product management, development, test, etc…and who actually is in charge and responsible for the product delivery: if it is the engineering team, we are screwed, the Interaction Designer has to be responsible for THE END RESULT and not only the design. It is were technology is mandatory but not enough…
You are right, and it was not clear in the article that this notion of responsibility for the finished product (what you depict as “Who has the most control over how well a thing is made?”) is the key point.
Thanks for the clarification Morten
Thomas
Good article but there are a few issues that, after consideration, I disagree with and would like to open debate on
1) The tools do not give complete control as claimed, a proper specification document and process can ensure that the person with the correct ability is able to influence the system at the appropriate time. (Software that supports makes life a lot easier).
2) Widget is poor terminology when covering these three disciplines as they could be different things to different people (An application developer and a web developer see widgets as very different things). Additionally in the mobile area it is coming to mean a mini-application running in a dedicated container.
I also think you have highlighted a gap that creates issues with development, by the lack of formalization in the relationship between the Software Engineers and the Interaction Designer
The Interaction Designers today are not as good as they should be of extracting from and agreeing with the software engineer what the impact of certain application events will be in terms of the user experience. Certain application events will take a few seconds (establishing network data connection or heavy requests to a server are good examples). The point at which these events occur and what is communicated to the user at this time is not accurately captured in a screen flow or screen layouts and needs an enhancement to most UI documents I have seen or a dedicated User Experience (UE) document developed after the screen flow has been agreed.
One small note the: The Interaction Designer is also responsible for defining what is to be captured by a screen, not just presented but I see no controversy here.
Thanks a lot for the comment.
I’ll try to answer your points:
1) “The tools do not give complete control as claimed” … you are right, because in real life, you still need some old-school specifications, but they should be enough, and for me I see multiple reason it is not the case, and won’t be very quickly:
* you need some kind of “agile” process, where prototyping equal implementation, and specification roughly equal prototype (My program manager won’t like that :-))
* But above all you need to communicate with your client …and he knows MS word…
2) Agreed : I prefer the Control term, over Widget for the “UI technologies” part, it is why I have introduced “Control” in my glossary (the yellow table). The Widget term have effectively been stolen to describe mini application either in a browser or in a native container, this will be part of a later article.
We have begun some work about this Interaction Designer and Engineer interaction, if you have some inputs, or want to share data, I’ll be very happy to do so.
sex shop
WOW! Interesting article and comments for an artist/graphic designer who every year gets more and more lost in all the technology. I love the comment referring to A, B, or C people…it’s so true on so many levels!
“No matter how talented you are, if you are a C, your talents will often be watered down by A and B. If you want more power, there’s only a limited amount A and B will be able to grant, no matter how much they need and respect you.”
Excellent insight into the main problem that the mobile domain is facing. Very well captured the issue and possible solutions. May be can be add about how do we move towards the upcoming technologies, what are the roadblocks and the challenges in implementing those.
visionmobile 2005-2008
visionmobile 2005-2008
