The first part of this article was about the treacherous intuitiveness of establishing an HMI styleguide based on a Corporate Design (CD) styleguide, and why this decision is risky: unlike a CD styleguide an HMI styleguide has to work for software engineers as well as visual designers. Also, this form of documentation is too rigid for a dynamic modern HMI. The most important insight: an HMI styleguide cannot be the sole basis for developing a consistent, aesthetic and intuitive HMI. Looking back on many years of big HMI design projects and speaking as a UX consultant I can say: only a combination of tools and processes will lead to success.
Thinking Out of the Box
Posts Tagged ‘User Interface Development’
Intuition seems to be one of those things we all profit from a lot. But at times it will deceive us. Designing an intuitive HMI seems to be one of the highest priorities of modern software development, minimizing both the need for training and the risk of operational errors. Still, a lot of software engineers and even HMI designers stumble into one trap when aiming for intuitive software design: listening to their own intuition. They will tell themselves, and quite rightly so, “A good HMI design has to be aesthetic and consistent, so that operators will be able to profit from already learnt patterns in a new context of use – if they can use one machine, they can use all machines.” So far, so good. But now comes the misconception: “If you want your HMI design to be consistent in every way, why not adapt the already established corporate design? It has been there for ages, guiding along the way to consistency and brand experience: the corporate design (CD) styleguide”.
Alas, this is the wrong analogy – but not the first time it has been used: the early years of television had the same problem, reading the daily news to their audience the same way radio did, or the early years of the internet, displaying long columns of information in serif fonts, just like contemporary newspapers did. This might have felt intuitive because it was well-known and long-established – but it was still wrong.
The philosophy of a CD styleguide cannot be transferred to a modern HMI and its development.
When developing graphical user interfaces (GUI) with Java Swing one tends to stumble upon surprising effects and problems, often wondering about the cause behind the effect. Ignoring background mechanics like database integration or the modelling of business logic, the effects in question regard windows and components right in front of you: the part of the software that the user will actually see and look at. To illustrate this further a simple but effective test-application was written that for all intents and purposes compares to applications out in the real world – allowing for enough room to optimize while making it easy to investigate the phenomena.
Black text on a white background is trustworthy. Even more so: black on white is a fact. It is printed and displayed on screen. The truth is said to be “black on white”. Except when it is not. In programming, the truth oftentimes is white on black. And the truth was white on a blackboard back in school. There are reasons for these exceptions and there are reasons for the rule. I’ve collected some of the reasons that might be interesting for interface designers.
This article is currently only available in German language.
This article is currently only available in German language
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. read more…
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.
More and more operating systems use a border resembling frosted glass for their windows, like, e.g., the Aero Glass® decoration known from Windows Vista® and Windows 7®. Providing this ‘special effect’ on the Java™ platform is still not easy to realize. Most Look and Feels use opaque borders, which do not visually match the surrounding designs of these operating systems.
This article describes a pragmatic approach to solve to this problem.
In the first part of this series I described how user interface design tools bring together developers and designers in a seamless workflow and gave an overview of the technical environments of Adobe’s and Microsoft’s tools in that area.
In this article, I am going to focus on the use of pixel and vector graphics in design, deal with some of the pros and cons of the two graphic types and finally give an introduction on the scaling of bitmap GUI components.
This series of blog articles deals with the use of GUI development tools by designers and developers, with a particular focus on Microsoft Expression Blend and Adobe Flex Builder.
In the first part, I will have a look at the cooperation between designers and developers during GUI creation, describe some issues that can affect their collaboration and point out how GUI design tools can improve the overall design and development workflow.