Tag: UX

Makeup on a zombie – Java Swing UX improvements

Even if they are outdated, GUI-based desktop applications won’t disappear anytime soon. But they should get improved user experience (UX) if possible. Some things are surprisingly easy to achieve. This is an example of Java Swing and keyboard handling.

When I learned Java programming in 1997, the AWT classes were the default way to create graphical user interfaces. The AWT widgets were not very sophisticated and really ugly, so it is no surprise they were replaced by a new widget toolkit, called “Swing”, as soon as possible. At the end of 1998, the Swing graphical API was the default way to develop GUIs for desktop applications on the Java platform.

Today, twenty years later, the Swing API is still part of the Java core SDK and ready for your adventures in GUI creation. But time has taken a toll on the technology. The widgets, once displayed with a state-of-the-art design, look really outdated. Swing introduced the concept of pluggable “Look-and-Feels” (L&F), so you could essentially re-skin your interface with a few lines of code, but all L&Fs look ugly and feel cumbersome now. You can say that Java Swing is a zombie: It is still available and in use in its latest development state, but makes no progress in regard of improvements. If software development follows one rule, it is that software that isn’t actively developed anymore is dead.

My personal date when Java Swing died was the day Chet Haase (author of the Java Swing book “Filthy Rich Clients”) left Sun Microsystems to work for Adobe. That was in 2008. The technology received several important updates since then, but soon after, JavaFX got on the stage (and left it, and went back on, left it again, and is now an optional download for the Java SDK). Desktop GUIs are even more dead than Java Swing, because “mobile first” and “web second” don’t leave much room for “desktop third”. Consequentially, Java FX will not receive support from Oracle after 2022.

But there are still plenty of desktop applications and they won’t go away anytime soon. There is a valid use case for a locally installed program with a graphical user interface on a physical computer. And there are still lots of “legacy systems” that need maintenance and improvements. Most of them are entangled with their UI toolkit of choice – a choice made before 2007, when “mobile first” wasn’t even available as an option.

Because those legacy systems still exist and are used, their users want to experience the look and feel of today’s applications. And this is where the fun begins: You apply makeup on a zombie to let it appear a little bit less ugly than it really is.

Recently, my task was to improve the keyboard handling of a Java Swing desktop application. It was surprisingly easy to add a tad of modern “feel”, and this gives me hope that the zombie might stay semi-alive longer than I thought. As you might already have guessed, StackOverflow is a goldmine for answers on ancient technology. Here are my first few improvements and their respective answer on StackOverflow:

  • Let’s suppose you want or need to interact with your application without a mouse or touchscreen. Your first attempt to start an interaction is to press the “menu” key in order to activate the application menu. This would be the “Alt” key on a windows system. For modern applications, your input focus is now at the menu bar. In Java Swing applications, nothing happens. You have to press “Alt” and a mnemonic character to enter a specific menu. If you want to reduce the initial hurdle to just one key, you need to teach all your Java Swing menus to react to the “Alt” key alone: https://stackoverflow.com/a/8659116
  • Speaking of focus, in modern applications you can move your focus by using the arrow keys. Java Swing still thinks that “Tab” and “Shift+Tab” is the pinnacle of focus control. If you want to improve the behavior (and therefore the “feel”) of your focus traversal, you can do it globally for your application: https://stackoverflow.com/a/8255423
  • And if you want to enable the Return/Enter key for button activation, you can do it with just one line: https://stackoverflow.com/a/440536

If you happen to work on a Java Swing application and want some cheap user experience upgrades, I’ve assembled all the knowledge above into a neat little class that you can use as an add-on utility class: https://github.com/dlindner/java-swing-ux/blob/master/src/com/schneide/swing/ux/KeyboardUX.java

What are your makeup tips for zombies?

UX is a mindset, not an engineering task

With all those methods and measurements like A/B testing, eye tracking and so on you would believe you can engineer your way to a perfect UX but that isn’t what matters. The user and his experience matters in the end and this is delivered by the product which in turn reflects your mindset. Just like the Conway’s law which states that the architecture of your software reflects your architecture of your organization, the product’s design and user interface reflects your mindset.
But what mindset is this? Let’s take a look at my UX posts of the past.

For your last project ask yourself what did the stakeholders learn

There two lessons for UX in here: UX design is a collaborative effort and learning is really important.

How do I start a project
and
How I start a project – the next steps

UX is an iterative way to explore a problem space. It has a goal: meeting the users’ needs. And again: a collaborative one: we need a shared understanding between all the project’s participants.

Quick and dirty is a skill

Evaluating is key in UX, and for not overwhelming the effort to do so, we need to find quick and sometimes dirty solutions to test our hypotheses.

The definition of done

Meeting the spec isn’t a goal of UX, meeting the user’s needs and goals is.

Personas – the great misunderstanding

Tool is just a tool is just a tool. It can help to frame your thinking but it cannot replace your thinking.

Mapping the users workflow

Another tool which can help to connect the disconnected parts, the user stories or issues, to a whole. IN this way you see your software from the user’s perspective from his way through your interface.

What UX and sales have in common

The user is central and context is key.

Discount UX

Again: UX does not need fancy tools, the mindset is really important and you should use the tools you have: pen, paper and your brain.

From agile to UX – a change in perspective

Focus on the user and his tasks, try to formulate the requirements from the user’s perspective.

Requirements should not drive development

Jobs should. Jobs are tasks the users wants to do in a specific context. These define what the software should do when it is ready.

UX is like a text adventure

You start with a beginner’s mind, try not to assume anything.

Learning UX: where do I start

Start with listening with an open mind and think.

Assumptions how to find, track and eliminate them

Beware of your bias.

Transparent software: making complexity understandable

Complexity isn’t your enemy. Find the essential complexity that you need to reach your user’s goals.

What developers can learn from designers

Slow down, do not rush towards your goal. Software is intent. Build to learn. Focus on the whole more than the parts. Have and provide alternatives.

UX tips: charts

Continuing our series about UX tips for small areas we take a look at charts this time.

Continuing our series about UX tips for small areas we take a look at charts this time.

  • always label your axis – this one should be obvious the reader needs to know at what data he looks
  • use units – is this meter or yards, data can only be understood if the scale is clear
  • use distinctive colors – different data, different color, and don’t forget the color blind
  • use color with purpose – same data, same color, e.g. having different values of the same source should use the same color or tint of color
  • for bar charts always start at zero – the distortion often used for exaggerating differences is immense
  • leave out decoration – decoration distracts from the data
  • no 3d effect – data speaks for itself, please do not try to make it prettier
  • use them for lots of data – if you just have a few numbers a table of data might be more appropriate
  • use a title – what aspect or slice of data are you showing me, a summary helps to understand perspective and intention
  • use a big enough font – this and the appropriate contrast should be obvious for all UI work
  • label tick marks – use them at meaningful intervals, do not just slice the axis into equidistant intervals
  • include time – even if it isn’t a time series chart, tell the reader from when the data is
  • size 2d shapes by area – do not use diameter or radius for sizing 2d shapes (circles, bubbles…), unless you use bar charts (where the length is compared) the proportion gets way out of hand
  • use consistent rounding – first round your numbers and do this consistently
  • for comparisons use the same scale – do not distort your data by presenting it at different scale

UX tips: Forms

User experience is a vast field which can be overwhelming at start. To make it easier for others I want to break it down to specific areas.
The start makes a rather narrow field of software: forms.

User experience is a vast field which can be overwhelming at start. To make it easier for others I want to break it down to specific areas.
The start makes a rather narrow field of software: forms.

Forms are ubiquitous: almost every software user interface has them. Most of them are too big and overwhelm the user. But in complex software you cannot “just” leave out some inputs to make a small form. Here are some tips to improve your next form:

  • use a grid – your labels and inputs (and indeed every UI element) should be layouted on a grid, the goal is to improve scanability and readability and to reduce visual clutter
  • align all labels in the same way – this one should be obvious, but often it is missed, it doesn’t matter if the labels are left or above the input, all should be aligned in the same way
  • use labels – another obvious one but often labels are omitted to make the UI look cleaner, but if the user cannot see from looking at your interface where he inputs his username or password something went really wrong
  • put fields in chunks – if the form gets too big (and most of them do), use blocks with whitespace around them to chunk fields, how do find out the groups for the chunking? You should know the domain and you can always ask the user
  • use specialized inputs – if only a date can be entered use a calendar widget, if you need a color use a palette input, the goal is to reduce errors made by the user, which also reduces his frustrations
  • provide format helps – if you cannot provide a specialized input, provide format helps, describe how the input should be formatted and what formats are accepted, again to reduce errors
  • order the fields – ask the user and a domain expert what the mental model of the fields is, what order should the inputs be made, what is optional, what is important
  • distinct the mandatory from the optional – nothing is more frustrating than to fill out a form, click submit and get told 10 times which fields are missing
  • use different sizes – if the input is just a one digit number the input should be sized to indicate this, if you want 3 lines of text, use three rows, the goal is to visually communicate what kind of input is expected, but remember: please align them properly

I hope these tips help you to make better forms and make your users less frustrated.

How do I start a project

On my quest to build better software for people and their needs I try to move my current agile project approach to a more user centered and outcome oriented one.

This starts right at the beginning of a project. After getting the go from the client I start with meeting the project leads on the client side, the ones who will make decisions and control the way of the project.
I like to take an assumption driven process or learning focussed one to ask questions and clear my assumptions on my way.
The first questions I have are:

  • who will use the software
  • who will be affected by the software/project
  • what are their goals/expected outcomes, what if they could choose only one
  • what do they expect from the software
  • what will happen if the project stalls or even fails

The people using the software aka the users are one of the main focus during the project but also the people who get benefits from the software without directly using it are really important and should not be neglected. These can be the people responsible for operating the software or managers getting reports from actual users. I keep them in mind so that other parts which are often missed during a user centered approach are considered.
All these people have some expectations how the software will affect them, some even have goals or need something to come out of the project. These outcomes cover a great range: from measureable business goals like increasing revenue or retention rate, to personal benefits like visibility. It is important to get a rough priority, I use a narrowing question like ‘what if you could choose only one’.
Besides from goals and outcomes people have also imaginations how the software will be used by them, in which context and how often.
These are the positive effects of the project and the software but all is not sunshine, so I also look at what will happen if the project is delayed, stops or even *shudder* fails. These are the risks that I need to consider and may be even plan for.
All these questions help me frame the project from the end. I know what goals to aim for and in which direction the journey goes.
This is my first step to build a shared understanding among the project participants. The steps to learn about what picture they have in mind. My questions and their answers help me to clarify the direction. After that I need to plan the first phase. For this I have to clear my mind and start with a beginner’s mind to find my hidden assumptions. Every assumption I or other have need to be called out explicitly. I have to capture it and formulate a corresponding learning step.

But this is a topic for another post…

Personas: The great misunderstanding

Personas are a typical user research and design tool but are often misunderstood

Reminder: What are personas ?

Personas were first described by Alan Cooper in his ground breaking book “The inmates are running the asylum”:

Our most effective tool is profoundly simple: Develop a precise description of our user and what he wishes to accomplish.

He goes on to define personas as “hypothetical archetypes of actual users” and states that personas “are defined by their goals”.
One of the key points here is that personas are never made up but are grounded in research. They are used to provide condensed information about the result of the user research. Another take away is that a persona description should include its goals.

The misunderstanding

In recent times some designers dumped personas because they are 1) imaginary and 2) defined by attributes that leave out causality. The problem here is that personas are often seen as a collection of mere demographic data (like age, job, income, …). But this only describes marketing personas not the personas imagined by Alan Cooper. As seen in his books the data of a persona is never made up but inferred from user research. Also demographics play only a minor role in creating personas, citing Mr. Cooper again:

Personas are segmented along ranges of user behaviour, not demographics or buying behaviour.

So the behaviour of our users defines the persona not any demographic trait.

The causality mentioned in the criticism misses a vital part of a persona: the scenario. Personas go hand-in-hand with scenarios (by Alan Cooper, About Face):

Persona-based scenarios are concise narrative descriptions of one or more personas using a product or service to achieve specific goals.

and

Scenario content and context are derived from information gathered during the Research phase and analyzed during the Modeling phase

So with these scenarios personas describe the context and the goals and behaviours of our users.

As we see with the criticism the context, goals and motivations of our users are important. Personas and scenarios should not be made up but condensed from research. They are used to say ‘no’ to decisions in the process of designing. A word of warning: do not abstract your persona too far away from your users. One goal of personas are to built empathy. If your personas are too artificial your empathy will suffer. Also I like how Jeff Patton uses research findings: for him they are like vacation photos, if you’ve been there they are reminder what happened.

Consensus

The criticism largely comes from designers favoring the jobs-to-be-done (JTBD) methodology. Jobs-to-be-done is a framework to analyse and describe why a users hires a product or service to get something done. It provides a very useful perspective on the context and behaviour of users. Both approaches (personas and jobs) can be combined. Where personas provide a human connection, jobs provide a contextual one. Shahrzad Samadzadeh provides a sketch how both can be combined with the help of a journey map. All three methods help to balance each approach: the personas help to avoid making the jobs too analytic, the jobs help to ground and limit the personas in research valuable to the problem at hand and journeys can bring all together.

Mapping the user’s workflow

One of the most important things to understand before starting any design or development is the user’s workflow(s).

One of the most important things to understand before starting any design or development is the user’s workflow(s). A user uses your app to reach a goal. His starting point is the start of the workflow. His goal its end. He takes steps in order to get from the start to his goal.
The order and the type of steps he takes helps us to understand how he reaches his goals at the moment. Visualizing these steps, often called mapping, is a great way to see the system from the user’s perspective: what does he do with the system, how and when does he do it.
This workflow helps us to keep the big picture in mind and organise planning and execution around the important part of the project: the user goals.

How does a workflow look?

Use the visualization or tool that suits you most. A workflow can be a sketch of boxes and arrows. Or an excel sheet. You can use a diagramming software or a presentation software. The important point is that you see the start, the goals and the steps and can annotate each step with important details.

How can we create the workflow

A workflow describes a series of actions. When the system supports the user to get from his start to his goal our application does its job. The user experience is how efficient and pleasant it is for the user to take each step.
One way to find out about the steps the user takes is to observe him doing so. At first: try to only watch and listen. Take notes. Be open. Record each step as if you were a beginner knowing nothing about the system or how the software works or should work. Especially watch out for the struggles.
Struggles can be seen in:

  • mistakes
  • back steps
  • pauses
  • changing applications
  • repeated steps

The struggles give us a hint where to put our energy. In the second run keep an eye open for unusual steps. Unusual steps are actions which seem complicated or unnecessary from a beginner’s mind. Start with the notion that every step is needed but find out the reasons why it is. In subsequent observations look for variations and ask what information lead the user to decide differently this time.
Armed with your recordings you can now sketch the first version of what you understood about how the user reaches his goal using the current systems.

What UX and sales have in common

In the past sales has often been disregarded. But modern sales is more like UX. The goal of modern sales is to bring a positive impact to both the seller and the buyer. This is called a win-win.

In the past sales has often been disregarded. But modern sales is more like UX. The goal of modern sales is to bring a positive impact to both the seller and the buyer. This is called a win-win. Both parties win.
Shortcuts or favors result in one party losing which is not a sustainable strategy.
For the buying to be winning a seller has to care about the needs of the buyer. These needs range from jobs to be done to personal ones. As a seller you employ UX research methods like interviews and open questions targeting the thoughts and feelings of the buyer. The wins are always personal never something abstract like a company strategy or even KPIs. But: the wins are based upon result: measurable, objective things like conversion rates, efficiency improvements, closed sales. Together they are called win-results: an objective metric that has a personal benefit for the buyer.

Assumptions in UX can be dangerous and can doom a whole product. Assuming win-results or the wrong needs you can miss the buyer completely and lose the sale. In strategic sales every uncertain or missing information or contact is regarded as a red flag. UX should also mark its blind spots. The product kata is a great way to eliminate assumptions in a project.

But even if you know the needs you have to take into account the context. The personal and emotional situation a buyer is in has direct consequences for how you need to address him. The same with UX where context and the job to be done control your solutions – what works and what not.

If you are interested in a more person centered sales strategy I recommend reading strategic selling and following blogs like Seth Godin and Bernadette Jiwa

Discount UX

Creating a better user experience does not need to be expensive, you don’t need fancy tools like eye tracking or facial expression detection to make a difference. Here are some tools I use to get a better understanding of what users need.

Creating a better user experience does not need to be expensive, you don’t need fancy tools like eye tracking or facial expression detection to make a difference. Here are some tools I use to get a better understanding of what users need.

Sketching

The universal tool to communicate besides words are sketches. Whether I draw an idea for a user interface, use a state diagram to discuss transitions or draw boxes and arrows to show connections, sketches at the heart of everyday working and thinking. What you need for this? Paper and a pencil.

Observation

In order to understand a human using your system you not only need to talk to him but you have to observe him doing his work. This is not just playing the fly on the wall. These sessions are interactive in nature, resulting in a back and forth. The user shows you how he works, you ask questions, he goes into more detail, you wonder about certain points, he explain his reasoning (or sometimes has wonders himself). Again paper and pencil is great. Having the option to take screenshots or (permission provided) a photo is even better. The most crucial is an open mind. You need to go in with a beginner’s mind: do not assume anything and wonder about almost everything.

Card sort

Observation is a pretty direct way to learn about the user doing his work. But even then some part of the mental model is hidden. To dig deeper into what kind of concepts and words he uses and how these are interrelated, a card sorting session can be helpful. Together with him we draw those words onto cards and let him sort them into groups and give them priorities. Here often discussions arise about the exact words you write on the paper. Some words need to be in more than one group, two different words mean the same, another word means something different in a different context. Here you also can take a glimpse at (sub-)domain bounds. Again cards, a pencil and paper to take notes is all you need.

Design studio or crazy 8

Sketching is so helpful you can do it even in a group. If you need to brainstorm for a user interface you take a sheet of paper and divide into 8 sections. Then you draw 8 very simple sketchy version of the UI in 8 – 16 minutes. After that you evaluate them in the group against your goals. The first round produces divergent sketches after seeing each other drawings, you will see that the next round converges into a common direction. You probably guessed it already: paper and a pencil is all you need.

Paper Journey Mapping

The last one in this group is more of an analyzing and communicating results tool. A journey map is a way to show the user (his thoughts, feelings and actions) along the steps he takes in his daily work. This map can highlight different aspects of your findings: the many applications he has to use to get his job done, the critical parts which mostly affect his mood, the frustrations, the many points for failure, the different people involved and so on. A large (DIN A3 or bigger) piece of paper is helpful and different colors of pencils help to highlight aspects.

Summary

All these methods use (almost only) pen and paper but are very helpful in getting to a better user understanding and therefore a better user experience. What are your tools for understanding?
If you have any questions or need more details please feel free to comment. I am at the starting point of the user experience journey and like to learn from others.

Getting better at programming without coding

Almost two decades ago one of the programming books was published that had a big impact on my thinking as a software engineer: the pragmatic programmer. Most of the tips and practices are still fundamental to my work. If you haven’t read it, give it a try.
Over the years I refined some practices and began to get a renewed focus on additional topics. One of the most important topics of the original tips and of my profession is to care and think about my craft.
In this post I collected a list of tips and practices which helped and still help me in my daily work.

Think about production

Since I develop software to be used, thinking early about the production environment is key.

Deploy as early as possible
Deployment should be a non event. Create an automatic deployment process to keep it that way and deploy as early as possible to remove the risk from unpleasant surprises.

Master should always be deployable
Whether you use master or another branch, you need a branch which could always be deployed without risk.

Self containment
Package (as many as possible of) your dependencies into your deployment. Keep the surprises of missing repositories or dependencies to a minimum of none.

Use real data in development
Real data has characteristics, gaps and inconsistencies you cannot imagine. During development use real data to experience problems before they get into production.

No data loss
Deploying should not result in a loss of data. Your application should shutdown gracefully. Often deployment deletes the directory or uses a fresh place. No files or state in memory should be used as persistence by the application. Applications should be stateless processes.

Rollback
If anything goes wrong or the new deployed application has a serious bug you need to revert it to the last version. Make rollback a requirement.

No user interruption
Users work with your application. Even if they do not lose data or their current work when you deploy, they do not like surprises.

Separate one off tasks
Software should be running and available to the user. Do not delay startup with one off admin tasks like migration, cache warm-up or search index creation. Make your application start in seconds.

Manage your runs
Problems, performance degradation and bugs should be visible. Monitor your key metrics, log important things and detect problems in the application’s data. Make it easy to combine, search and graph your recordings.

Make it easy to reproduce
When a bug occurs or your user has a problem, you need to follow the steps how the system arrived at its current state. Store their actions so that they can be easily replayed.

Think about users

Software is used by people. In order to craft successful applications I have to consider what these people need.

No requirements, just jobs
Users use the software to get stuff done. Features and requirements confuse solutions with problems. Understand in what situation the user is and what he needs to get to his goal. This is the job you need to support.

Work with the user
In order to help the user with your software I need to relate to his situation. Observing, listening, talking to and working along him helps you see his struggles and where software can help.

Speak their language
Users think and speak in their domain. Not in the domain of software. When you want to help them, you and the user interface of your software needs to speak like a user, not like a software.

Value does not come from effort
The most important things your software does are not the ones which need the most effort. Your users value things which help them the most. Find these.

Think about modeling

A model is at the core of your software. Every system has a state. How you divide and manage this state is crucial to evolving and understanding your creation.

Use the language of the domain
In your core you model concepts from the user’s domain. Name them accordingly and reasoning about them and with the users is easier.

Everything has one purpose
Divide your model by the purpose of its parts.

Separate read from write
You won’t get the model right from the start. It is easier to evolve the model if read and write operations have their own model. You can even have different read models for different use cases. (see also CQRS and Turning the database inside out)

Different parts evolve at different speeds
Not all parts of a model are equal. Some stand still, some change frequently. Some are specified, about some others you learn step by step. Some need to be constant, some need to be experimented with. Separating parts by its changing speed will help you deal with change.

Favor immutability
State is hard. State is needed. Isolating state helps you understand a running system. Isolating state helps you remove coupling.

Keep it small
Reasoning about a large system is complicated. Keep effects at bay and models small. Separating and isolating things gives you a chance to overview the whole system.

Think about approaches

Getting to all this is a journey.

When thinking use all three dimensions
Constraining yourself to a computer screen for thinking deprives you of one of your best thinking tools: spatial reasoning. Use whiteboards, walls, paper and more to remove the boundaries from your thoughts.

Crazy 8
Usually you think in your old ways. Getting out of your (mental) box is not easy. Crazy 8 is a method to create 8 solutions (sketches for UI) in a very short time frame.

Suspend judgement
As a programmer you are fast to assess proposals and solutions. Don’t do that. Learn to suspend your judgement. Some good ideas are not so obvious, you will kill them with your judgement.

Get out
Thinking long and hard about a problem can put you into blindfold mode. After stating the problem, get out. Take a walk. Do not actively think or talk about the problem. This simulates the “shower effect”: getting the best ideas when you do not actively think about the problem.

Assume nothing
Assumptions bear risks. They can make your project fail. Approach your project with what is certain. Choose your direction to explore and find your assumptions. Each assumption is an obstacle, an question that needs an answer. Ask your users. Design hypotheses and experiments to proof them. (see From agile to UX for a detailed approach)

Pre-mortem
Another way to find blind spots in your thinking is to frame for failure. Construct a scenario in which your project is failed. Then reason about what made it fail. Where are your biggest risks? (see How to map your fears for details)

MVA – Minimum, valuable action
Every step, every experiment should be as lightweight as possible. Do not craft a beautiful prototype if a sketch would suffice. Choose the most efficient method to get further to your goal.

Put it into a time box
When you need to experiment, constrain it. Define a time in which you want to have an answer. You do not need to go the whole way to get an impression.