This article is only available in German language.
This article is only available in German language.
In December Centigrade carried out an evaluation of the racing game “Need for Speed: Rivals” for Electronic Arts – one of the biggest publishers and developers of computer- and videogames. Focus of the evaluation was the recording and analysis of the game experience under consideration of different situations in the game.
Based on their vast experience regarding the evaluation of computer and videogames, the pilot study was conducted by the Centigrade team of the North-Western branch under direction of Joerg Niesenhaus in close collaboration with the Deutsche Sporthochschule in Cologne. The Deutsche Sporthochschule runs a state-of-the-art interaction lab and contributed expertise in the evaluation of interactive entertainment via Dr. Carsten Moeller.
Some new e-mail clients have been introduced recently. Unibox, Airmail, Mail Pilot and others feature convincing visual design, increased joy of use and intriguing interaction concepts.
In my opinion, the person-centered approach of Unibox is very promising. Instead of being organized in a folder hierarchy, e-mails are sorted based on contacts (friends, colleagues, etc.), which results in speedier e-mail retrieval. In addition, one almost forgets that one is dealing with e-mails – it feels more like a conversation between two people. I wonder why nobody has thought of this approach earlier.
The redesigns have inspired me to have closer look at e-mail clients and propose some additional concepts.
A few months ago we discussed the challenges and potentials of gamification and the process of implementing gamification methods. We pointed out that an extensive analysis of the existing processes and well adapted gamification mechanisms increase the chances of success – for instance to optimize the efficiency of a process or raise the employee satisfaction.
In our current blog article we dive into the widely debated industry 4.0 theme and focus on the application area of industrial production and the role gamification methods could play within this area, and also which specific requirements have to be fulfilled to enable the implementation of playful elements.
This article is currently only available in German language
In Part 1, we discovered that the emotional factor of user experience is more important to games than goal-oriented functionality (though being an effective and efficient way of reaching a goal, there is no “Save the Princess” button in a Mario game at the beginning). Up to a certain degree, well-designed user experiences can distract from negative and/or not fixable interaction flaws and can make users “like” an application more than another.
Furthermore the diverse team composition of game development studios was discussed in the first part. In this context we pointed out that the production process of games forces programmers and visual designers to work closely together. Design is not seen as an add-on but as an essential part, which is necessary for the product to work.
The last chapter focused on the aspect of small budgets in game projects. Rapid iterative testing and evaluation (RITE) helps to detect and fix flaws of a UI in a very fast way, thus reducing time and money spent on traditional usability optimization.
In Part 2 we will look at the aspects of imaginary worlds and the link between reality and simulation. Thereafter, we will show which techniques are used in games to reduce loading, and even more important, waiting times. In the last section we compare how serious applications and games introduce their functionality to the user. To get a better understanding of the concept of Gamification you can also read: “Gamification as a design process” by my colleague Jörg Niesenhaus.
„Game-Based Learning“, „Serious Games“,„Games with a Purpose“ and „Gamification“– the list of concepts, which build upon the prospect of using the potential of games in other application areas is long. All concepts share the same idea of generating additional benefits beyond pure entertainment by using games, their technology or mechanisms. By no means, all of these expectations raised by the concepts are achieved. A lot of projects fail due to the incompatibility of games and serious applications and it often appears, that the effort for achieving compatibility is not commercially viable.
“We need ribbons” is the new “Make it like the iPhone“. Since Microsoft introduced ribbons as part of the Office Fluent User Interface with Office 2007, this sentence is frequently uttered by clients. The rationales for this requirement range from „Microsoft has probably put a lot of thought into it“ to „Our customers are used to Office“. Ribbons seem to be perceived as a remedy for poor usability. But not every interface benefits from using ribbons.
Microsoft’s Modern UI design language has arrived in many applications with varying success. By now, almost everybody has seen Modern UI, and Microsoft seems committed. Developers of Windows software have to think about the fact that a lot of established interfaces look out of place in a Modern UI environment. It needs to be adapted to the current state of interface design, even more with Apple moving iOS 7 in a similar direction. Working on such updates, we have collected a set of 10 design principles we call, for the sake of simplicity, “Desktop Modern UI”, and we want to share them with you.
“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?
|Subscribe to "Articles" blog|