Introduction

“Form Follows Function (FFF)” – You can think for hours about these three words and for their explanation quite some words are necessary, for it is a frequently misunderstood design principle.

Launching their new operating system Windows 8, Microsoft establishes an entire set of novel technologies and concepts. The familiar desktop will be supplemented with an additional Start screen in “Modern UI” style (formerly known as “Metro UI” style); in addition to that, Microsoft introduces a new application type called “Windows Store App” (also referred to as Windows RT application or Modern UI application). Especially this new application type is the subject of controversial discussions in the community and thus requires to be focused on in particular.

They are considered intuitive and their handling easy to learn – Touchscreens. To humans it feels far more natural to touch an object of interest with the finger on screen instead of using the mouse. Apart from the clearly easier hand-eye-coordination, touchscreens create an elegant and user friendly experience through merging input and output actions into one device.

But even despite of all these advantages, they can create a lot of frustration and anger, which probably every one of us has realized at some point. For example: If you accidently call someone although you only tried to scroll down the address list, if you have to type in a word five times, because you hit the wrong letter, or the alignment of “Ok” and “Cancel” is so narrow that you are afraid to click the wrong one. It would be too good to be true, if touchscreens did not raise new usability problems. Especially the usage of desktop operating systems like Windows 7 or OS X with touch devices creates a bunch of problems.

Have you ever thought about switching from Windows Forms (WinForms) to WPF seriously? Try something new and stop to develop along the old well known patterns? To be honest until a few months ago, I haven’t had any thoughts about making a transition. I was very familiar with Windows Forms and WPF would have been something I would have to learn from scratch. So it was only a test project and my applications remained Windows Forms applications. So, when I joined Centigrade earlier this year, after working as a developer for nearly 15 years in the financial industry, Centigrade made the transition to WPF long ago. Just take a look at related blog articles on our website! My colleagues in the field of design engineering are working for several years with WPF. Especially younger designers and design engineers only knew Windows Forms from their study – if at all. They never worked with it in practice. Many companies already use WPF, but despite the fact that already the fourth version of the technology is out lot of them are still in the evaluation phase. From my own experience, I can only report – it can even be worse. Especially, in the financial sector applications with a rather boring look and feel are created until today. Yet, things could be so much more appealing…

So a new chapter started in my programming career. With a healthy dose of skepticism, I joined my first WPF Project. I was hooked immediately. I have collected some of my experiences and summarized them within this article.

In April I blogged about metro style pictograms being the new sliced bread in icon design. Remember? The article was, of course, highly interesting, incredibly important and not to mention terribly knowledgeable – and naturally it was in no respect longwinded. Well. Let’s just say it was rather formal and academic. Today, dear reader, I am going to be emotional. And pretty much so. Why? Because bad user interface design can drive you up the wall.

When I started working at Centigrade, I wondered what the “User Interface Architectures” tagline in the company name is about. New terms are common in our line of work; the terminology is still young and changing all the time, many people try to influence it with their own terms and definitions. Still, I thought “why architecture” – maybe you, as a reader, did too?

The short, upfront answer: drawing attention. Readers are supposed to be teased by that line. So, of course it is supposed to stick out, elicit associations and set Centigrade apart.

Still, “User Interface Architectures” is not just another empty cliché buzz term, which brings us to the long, more profound answer. These words sum our work up for newcomers quite precisely and descriptively. We always have to expect that customers, users and external designers or developers may not have a clear understanding of our work. By comparing our services to the field of traditional building architecture, we offer a way to approach it.

Of course, we and other interface designers are familiar with the typical tasks, processes and results of our field. If, however, we get lost in our own work, the comparison to traditional architecture and to traditional architect’s way of working can bring about new ideas and give us new drive. Internally, “User Interface Architecture” forces us to re-evaluate our way of work and view it in a broader context. We want to present four things architecture has in common with user interface design to show how the comparison works internally and externally.

After the introduction of Microsoft’s new approach to user interface design with its current mobile device Windows Phone and upcoming operating system Windows 8, user interface designers and clients alongside them are beginning to “think Metro style”. Based on Swiss Graphic Design principles (established in the 1950’s) and focusing on clean typography, not only interaction, navigation and information architecture have changed, but the understanding of and thereby design process for icons has, too.

As discussed in one of our blog articles about UI guidelines for mobile devices, the concept of Metro style icons is inspired by the idea of quick wayfinding, using pictographic signs found in metropolitan areas, airports or train stations. These simple-shaped icons are not only reduced in both color and detail, but especially shall strive for understandability across cultures and languages. This requirement is by no means new, nor is the Metro icons’ attire. Designed along the lines of traffic signs using the most generic and salient mental model available, Metro icons are in fact pictograms, which against the background of spreading globalization have been standardized in many areas of deployment. Not only for reasons of maximizing their recognition and thereby their value was standardization a good idea, but also because a lot can go amiss in designing a pictogram.

To understand the significance of pictograms and their design one must first of all engage in the characteristics of pictographic and symbolic language and discern these from usual interface icon metaphors, speech and appearance. When this is accomplished five points should be taken into consideration while designing intuitive, understandable and aesthetic pictograms.

No doubt, when creating software, there is always one topic that everybody talks about: performance. In this respect, even though Windows tries to hide a lot of performance optimization work from the developer’s eyes (when developing for .NET with WPF), there are still a dozen of issues to be kept in mind when implementing a piece of software.
To start things off slowly: How does computer science define performance? Spoken very generally it is formally described as “the ability of software to complete certain tasks” (see Wikipedia). Most commonly, however, it is simply referred to as the speed of software. In this case, people usually do not differentiate between the user interface’s performance and the performance of the application logic itself.
Nonetheless, inside a development team there should be a clear understanding of who is responsible for what performance aspects, rather than pushing away all responsibilities to a single developer alone. Even though performance certainly affects the entire application, many advantages can be gained by distributing optimization tasks to different people regarding their expertise and specialization. For this reason I, as a Design Engineer, put significant effort in performance analyses for our customers and while our customers focus on optimization of C#-based Code, such as the user interface logic or other respective layers below, my area of expertise focuses on optimization of XAML Code.

Part 1 of this article has pointed out that the false doctrine to restrict menu items, bullet points etc. to seven is based on a misreading of Miller (1956). Contemporary research shows that capacity limitations do indeed exist, but these are currently estimated to lie at about four items. Recently, as a reaction to the oversimplified propagation of the “magical number seven”, the opposite opinion has become increasingly popular: Its proponents argue that there actually is no reliable capacity limitation at all or that—if there is such a limitation—it is not relevant for UI design. If these critics were right, also the new “magical” number 4±1 would be of only minor importance for UI design. I argue that this position throws out the baby with the bath water; although it is advisable to be suspicious of magical numbers and other oversimplified rules, capacity limitations are a psychological fact and indeed relevant for UI design. As is often the case, the truth lies somewhere in the middle…

There are several apparently axiomatic design principles that purport to be perfectly adjusted to the human cognitive system. Their prominent characteristics are that they are broadly applicable and easy to grasp for the psychological layperson. Unfortunately, however, they are usually false. One of these principles is the “magical number seven”. Very loosely based on an influential article by Miller (1956), this “magical” number provides designers with an easy guideline to estimate how many elements their products can maximally contain without overcharging the cognitive capabilities of their users. Generations of designers were forced to limit, for example, steps in a workflow, tabs, items in dropdown lists, links, choices, bulleted lists, radio buttons and checkboxes, to this apparently magical number (cf., e.g., Eisenberg, 2004). As every myth, there is also some truth to the “magical number seven”. I here give a brief overview of some aspects of research on cognitive capacity limitations from a basic experimental psychological perspective. Although the here discussed insights are not as magically applicable as some would like, the present overview might be of use for the interested UI designer.

This article was inspired by two interesting days at the GUI&Design conference that took place just recently on 8th and 9th December in Fürth, Germany. The conference audience consisted of professional user experience designers and developers and the talks and workshops focused on Microsoft user interface technologies such as WPF and Silverlight.

Not only this article is a spontaneous creation – one of the activities I participated in during the conference was, too: Clemens Lutsch, User Experience Evangelist at Microsoft, asked me to join a discussion panel in order to conclude the first conference day and discuss concepts and roles in the UX domain with regard to aspects that are challenges in our daily professional work.

For me this was an excellent opportunity to discuss a term that we have introduced at Centigrade a couple of months ago: “user interface design engineering” or a bit shorter “UI design engineering”. Having used the term just internally in the first place, we started to bring it up in conversations with our clients and partner companies more and more frequently – with great acceptance. When I brought up the term during the panel discussion, I observed similar acceptance from the audience and my co-speakers – almost as if the term closed a gap that many professionals felt has existed for quite some time. It was even picked up by other conference speakers, right the next day, which motivated me to shed some more light on the term and its meaning. So, what is UI design engineering, anyway?

Three years ago, we published a blog article that shed some light on the development of the iPhone. The motivation for writing the article was the fact that the iPhone was often used as reference when talking about usability goals and user interface design ideals and that design requests often could be roughly summed up as “Make it like the iPhone”. The blog article described of aspects of iPhone development that did not get the same publicity as the product and its user interface themselves. Those aspects were

• Apple’s complete control over design, manufacturing and marketing,
• a completely new operating system that had been created and
• the considerable effort in terms of time and money that had been invested in the project.

In the meantime, Apple has created several new versions of the iPhone and even included a completely new product in its portfolio: the iPad. After those success stories, it is no surprise that reference to “user interfaces like Apple” is still made. It is therefore appropriate to revisit the topic and add some insights regarding the “Apple design process” in general that have become known to a larger public, not least through the Steve Jobs biography. Such insights can prevent misguided approaches in which Apple-like results shall be reached without implementing a corresponding process.

Texts are important parts of most user interfaces, be it, e.g., as form field labels or longer help texts. This article is aimed at providing a common introduction to the topic „choosing the right font”. It contains some hints an pointers that simplify the search for the right typeface.

The first part of this article provided an overview of the concepts of the currently implemented user interfaces for the Kinect™ sensor. It pointed out technical specifications and explained the human-machine interaction within Kinect games. This second part now scrutinizes this interaction and assesses its potential for industrial application.

In November 2010, Microsoft® introduced Kinect™. As an expansion of the Xbox 360™ gaming console, it brings controller-free gaming to the living room and even long before its actual release it was believed to revolutionize Human Computer Interaction. Therefore, expectations were rather high and one felt reminded of the Natural User Interface (NUI) featured in the movie Minority Report. Will this futuristic vision soon become reality?

To our great delight and surprise, our animated Facility Manager Prototype and respective Blog article was used as demonstration and reference material at UXCamp Europe 2011. In regard of the apparent interest in the topic this article picks up the issue yet again, focusing on scientific considerations of the past years.
Indeed, animations have become an integral part in today’s modern applications, especially the iPhone and Co. Having this said, it astonishes that scientific efforts are still in fledgling stages and that the few existing approaches vaguely draw upon techniques and rules used for cartoon movies. At the same time however, choosing the wrong animation will literally paralyze a User Interface.

The first part of the article dealt with potential causes for wrong expectations regarding usability, that lead to perceptions of “usability as a product” that can be acquired right off the shelf and then implemented into a user interface. This part describes how the UX designer can cope with these challenges in order to create realistic expectations and conduct a successful UX design project.

Sometimes, prospective clients request user experience designers to “bring along some ideas” for a first meeting. The thought behind such a request can, e.g., be the desire to get some inspiration regarding the look of user interfaces, which is legitimate.

The problems start when the request is made with the expectation for the user experience designer to bring along ready-made solutions that can more or less directly be used to optimize an existing user interface – a “usability catalog” from which the client can choose the right solution, which can then be provided without much delay.

This article deals with the question why this kind of “off the shelf usability” does not exist and which causes can potentially lead to these expectations.

Comparing computer games with “serious” software applications may seem like comparing apples and oranges if we think of serious software as tools that allow users to achieve mission-critical productivity goals in their working live. In this respect, the two industries couldn‘t be further apart regarding their target audience and the way they rank productivity vs. fun. For this reason, we are oftentimes asked why Centigrade as a “serious” user interface design company collaborates so closely with the game industry and even has a branch office located in a building that’s otherwise occupied solely by game development studios.

Yet, the link between computer games and industrial software is more obvious than one may think. To summarize why we believe computer games can have a positive impact on the user experience (UX) of industrial software applications, this three-part blog post provides a bulleted list of ten arguments we keep on stating in this regard. The first part gives a high-level and process-oriented perspective on the topic, the second part will shed more light on the transfer of aesthetic and interactive aspects found in games to serious software and the third part will have a look at the game industry as a technical driver for innovations that spill over to other software industries.

Communication is essential to UX design. As with other contexts, communication can be impaired by – sometimes very subtle – influencing factors, some of which were described in part 1 of this article. This second part of the article deals with additional aspects that can be detrimental to communication, such as (unconscious) language barriers and the “human factor” in UX design.