Google unveiled progressive web apps around 12 months ago. We’ve now had the chance to look at some of the pioneers of the technology, see how they’ve managed to implement the concepts, and look at their results.
As both a web and Android developer, I’ve been very interested in progressive web apps, not just from a professional point of view but also because this is a technology that I actually believe in.
Build a command line option into your next user interface.
Some of you techies may be reading this and thinking, “Yes! I live in a command window all the time on my computer.” Well, I’m not really thinking about you as my target audience. I’m talking more about applications used by everyday people outside the IT industry.
Hear me out.
This concept first hit home for me some years back while working on a content management system. My team had built this shiny, new GUI with a backend database for managing user education content. The GUI was quite extensive, with a main screen plus many dialogs for maintaining the assets in the system. A number of teams across the company used the system quite effectively. But then we needed to on-board a new team habituated to an existing system that used a local source control system, an XML editor, and a command window. Commands were entered to do things like check out a topic, open a topic in the editor, and view source control history.
The new team began trialing our nifty GUI-based system, and we very soon heard complaints that the team’s productivity was going to take a big hit once they adopted the system. And for this team—who were always under the gun to get content updated and published—productivity was a huge concern.
It took me just a few minutes while sitting with a writer from the team to totally understand their concerns.
In the previous system, they could have a topic checked-out and open in the editor in seconds just by typing a single command. Using our GUI, the steps necessary to accomplish the same goal took quite a bit longer: They had to navigate a hierarchy tree to find the topic, followed by separate steps to check-out and open the topic in the editor.
Now you may be thinking that the GUI had to be simpler to use than remembering many sets of command syntax. But remember, we’re talking about folks that worked with their content hour after hour, every day. It was nothing for them to memorize the syntax for a set of commands since repetition leads to memorization.
I ended up getting approval to build a command line interface option to the system run from a Windows DOS command prompt. The set of commands started out small, focusing on core functionality. But the library grew significantly as team members started using it and liking it. They just kept begging for more! The GUI lived on of course, as it did offer the complete set of features for the system. But, it was amazing to see how popular the command line interface became with our users.
Long before GUIs became mainstream, command lines were king. But even after GUIs came along, some command line interfaces survived and are still alive and kicking today. One of the most prominent and heavily used applications that still rely on a robust command line interface is Sabre, the largest systems provider for airline bookings in North America.
If you’ve ever travelled by air in North America, you’ve probably been on the other side of the airline counter from a customer service representative using Sabre. Now think about it—was the person using a mouse and clicking around the screen? No, they were using the keyboard, typing away like crazy and being very productive in getting to the data and information they needed to help get you on your way.
Why does a command line interface work so well in the case of airline reservations? The reason is that the airline customer service representative uses a relatively small set of commands over and over again, to the point that they have memorized the syntax for these commands. With the command syntax memorized, it is faster and more efficient for the person to let their fingers fly over the keyboard to interface with the system.
Here is an example. The screen shot below shows the following command:
If you break this down, it is an inquiry command to look for flights on the 12th of November from Cleveland (CLE) to Orlando (MCO). (I’m not positive what the 07A represents but I would venture a guess that it means to look for flights departing around 7AM.)
Now compare this with a GUI (see screen shot below) to accomplish the same inquiry. Think about how you must use the keyboard and mouse to interact with the UI elements presented in this dialog. There is no way you can interact with the GUI faster than typing at a command line.
To be clear, we are talking about how effective a command line is for a frequent system user, not the casual consumer looking for flight schedule information. The GUI is no doubt the best interface option for a consumer to find flights, but for the airline customer service rep that searches for flights hour after hour each day, the command line option is going to be a more efficient interface, hands down.
Another example involves a less technical user group: horse show secretaries. I’ve been involved with horse shows—managing, competing, and judging—for a number of years. Being one of those IT guys, I’m always interested in the software used by the show office. I’ve seen some systems that I thought were very non-intuitive for a novice user, but I attribute that to my critical eye when using any software product.
Here, as with airlines, there are scenarios that would be well-served with a command line option. For instance, one of the most common things a rider will do in the office is to add or drop a class.
A typical situation is that a rider will come into the show office and say something like, “My trainer told me to add class 126, and it starts in 20 minutes!” The show secretary will instruct the rider to fill out an “Add/Scratch” form: The rider writes down their horse’s entry number, the class number, and circles the word “Add.” Similarly, to drop a class they use the same form, supply the same information, but circle the word “Scratch.” The rider drops the form in a basket, heads out of the office, gets on their horse, and hopes the show secretary processes the request before the class starts.
Now, if the show secretary was not busy when the rider came in to add the class, she could have just done the work right away, but it is rarely the case that the secretary at a horse show is just sitting around looking for something to do.
If she is busy doing something else in the system, you can imagine there would be a number of steps to perform to close out the current dialogs in-use, then bring up the screen where a horse can be added to a class. But what if, with a keyboard shortcut, the show secretary could pop into a command line and simply type >add 57 126 and press the Enter key? In this case, the command would result in horse number 57 being added to class 126. A scratch could be just as simple >scr 57 126
Below is a screen sample that shows a command line option built into the GUI of a popular horse show management system (see lower-right section of the screen). Adding and scratching is a very common function executed by the show secretary, so memorizing the syntax for add or scratch would happen very quickly. With a command line option, regardless of where they are in the system, they could quickly drop to the command line and execute any number of common functions.
A key tenet of a command line option in an application is that the commands and their syntax must be simple and intuitive. In the above example, you are adding a horse, represented by a number, to a class, also represented by a number. So the syntax is very simple and easy to remember.
You really have to look for the right functionality to offer a command line option. Two basic questions can be asked:
Is it a commonly used function?
Are there a small number of data elements necessary to accomplish the task?
For example, here is a dialog (see below) to add a horse into a system. Clearly, this task would be best accomplished with a GUI since there are far too many data elements involved with getting a horse into the system. Memorizing the command syntax would be impossible. Also, horses are typically added before a show starts so this function would be classified as non-common, especially once a show has started.
As I mentioned, I also judge horse shows and I built an application designed to be used by show jumping judges. I hadn’t thought about adding a command line option to my application, but then I really started thinking about some common tasks that would be excellent candidates for a command line. The judge is not only keeping track of results for each horse/rider, but may also be operating the timing equipment and may even be announcing over the PA system. That gives the judge little time to do anything that would distract them from their core responsibilities.
I’ve spent hours tuning the user interface in my application to be very intuitive and easy to use but this means that some functions will be buried on a screen that takes a couple steps to access when needed. So I started thinking. What if I had a command line always visible and quickly accessible where the judge could type in something like:
>view ss 175
This could quickly open the score sheet report for class 175 in a browser window. After thinking about it some more, I came up with 16 functions that made sense to offer as a command line option. All the functions have very simple syntax and helps the judge execute items quickly. Here is a screen shot of my judging application with the command line at the bottom of the screen.
Seems I’m not alone in my thinking here. For all intents and purposes, a command line has appeared atop the ribbon bar in Office 2016 apps. The Office team has named this the “Tell Me” feature. The feature is described on this blog post:
Tell Me is an entirely new way to find the commands you need. Just type what you want to do in the Tell Me box at the top of Word, PowerPoint, Excel, and Outlook, and you will get a set of results that let you take the desired action directly from within those results.
In any Office 2016 application, you press Alt-Q to get your cursor right in the Tell Me box. Once you use this new feature, you’ll see that it really is a command line on steroids, but it does serve the main purpose of providing quick access to certain functionality.
In conclusion, I hope this gets you thinking about the user interfaces you’ve designed in the past and ones that you’ll design in the future and ask yourself this question—is there some functionality where a command line option would be beneficial to your users?
Something that I feel is overlooked by a lot of product designers is the second-hand experience of their product. That is to say, above and beyond the target user, who is affected by the product—and most importantly—what is their experience?
If the UX team has satisfied all the needs and desires of the target user, minimized their pain-points, and maximized their ability to enjoy the most common process flows, that is truly awesome—but how does the experience they design affect that person’s social circle? Do product designers currently see that as a question worth spending additional time and resources to answer?
The classical method of product design is for design considerations to be dictated by our insights regarding the target user, as well as the goals (often monetary goals) of internal stakeholders. But as tech continually permeates our lives in an increasingly personal fashion, I believe the need for second-hand experience analysis will begin to shine through.
The power of shared experiences
The experience of the target user is not isolated from the experience of the indirect user. Whether it happens immediately or eventually, the two experiences affect and influence each other.
The target user, as entranced as they may be by their own experience, will continually receive feedback from others who were witness to this experience and will begin to judge the primary experience not only from their own frame of view but also from feedback received from constituents of their social ecosystem. The final verdict on an experience is often a group effort.
The need for second-hand UX
The need for greater focus on second-hand user experience is real. Many existing products already demonstrate a gap in the experience that affects indirect users.
One easy example of this might be the prevalence of texting and how it affects secondary users. What started as a flicker of excitement with the invention of smartphones (even if they were flip phones, sliders, or some other sort of archaic paperweight) has grown into something that has become a contentious social (and sometimes physical) habit.
Whether texting is positive or negative as a whole is a subjective judgement which requires a certain scope to even make a judgement feasible. For example, in a very surface-level, everyday efficiency scope, is texting positive? Probably so, at least for the direct user. But within a different scope, one that perhaps takes a look at the sociological/psychological effects of texting, would you come to the same judgement? Maybe, maybe not, but you’d certainly give it more thought.
Common responses to these deeper-level scopes consider issues such as how mobile phone usage creates a social distance between the primary user and secondary users. The dynamic, generally speaking, encourages less frequent and more shallow interaction between the person using the mobile device and the other people that may be around them. How often do you see people over-indulge in their electronic devices at the expense of paying attention to those around them?
Think back on personal situations where you might have been the secondary user. How did your feelings change towards the primary user? How about toward the product itself?
The smartphone—something that was intended to be a design solution for pain-points of communication efficiency, frequency, and accessibility—brings a complicated dynamic. It has raised questions with philosophical, psychological, and sociological underpinnings that should lead us to question the pros and cons of what I call short-term experience solutions, ones that satisfy the immediate user but don’t necessarily take into consideration the long-term effect these decisions have on the social ecosystem that encompasses the user.
That being said, I’m not here to rag on texting. On the contrary, I am totally addicted to texting and general mobile phone usage, despite the fact that its negative impacts are so apparent to me that I have recently started doing several exercises to try to correct my text neck.
Rather, I’d like to draw attention to the social dynamic that is created by tangible tech, be it a wearable, a mobile phone, a laptop, earbuds, or even a virtual reality headset. Each device, as well as the context it is used in, bears with it a social dynamic. These social dynamics are a much more important part of the experience of a product than the field of UX / product design would demonstrate historically.
I do think that designing for the primary user should be of utmost importance—but I also think product designers need to start valuing how the primary user’s interaction with the product affects their relationship with their social environment.
If you somehow think we’ve seen the peak of socially-permeating tech, think again. Technology is only going to continue to penetrate our lives as time passes, further warranting the need for considering second-hand UX.
The big question
This raises the question: When will second-hand UX become an integrated concern within the practice of UX?
Undoubtedly, product designers are concerned to some extent about how their products may affect second-hand users, but how often do we actually involve indirect users in the discovery and validation portions of our design process? To what extent are second-hand users a driving force behind how we generate requirements? (How many times will I say “second-hand”?)
Making this concept of valuing the experience of indirect users a top of mind concern could drastically alter the way UX practitioners do their work.
Just imagine the potential shift in focus for user research. Direct observations of people near someone using their virtual reality / augmented reality headset. Surveys, interviews, and focus groups inquiring about the experience that people had when their friends were using their new smart-watch. The possibilities are vast.
One way to utilize second-hand user research would be to engage existing UX assets, but with a new twist. Instead of traditional personas, we could have second-hand personas that examine the demographics, behaviors, likes and dislikes, proficiencies and deficiencies, and other attributes of the indirect user of a given product / experience. Who is our typical second-hand user? How might we describe them?
Similarly, UX practitioners could start developing second-hand journey maps that divulge the way an indirect user is thinking, feeling, and acting for each action that the primary user takes in their experience with the product. How did you feel as your friend watched a video on their virtual reality headset? What action did you take when your coworker started working next to you with their earbuds in? What were you thinking when your roommate used a voice command on Amazon Echo to lower the song you were listening to?
This shift in focus could open up a whole new realm of UX research and design that could lead to interesting new experiences.
Collaborative mode for VR headsets where multiple people share the same vision? More functionality built into health informatics for sharing data from person-to-person? Socially-contextual settings to limit notifications and keep users engaged in the real people that surround them? Maybe, maybe not. One thing is for certain: The ability to definitively and accurately decide how and when to implement design patterns like these will be dependent on empathizing with indirect users.
So why is this important? Why should we care what indirect/second-hand users think or feel?
From a monetary perspective, the answer is simple: Purchase and usage considerations do not end at how the product/service will affect the buyer. Considerations extend into how it will affect the things they care about (which transitively affect them)—most often being their relationship with other people.
From a philosophical perspective, a lack of care about the psychological and sociological toll our products may take on users could drastically alter the concept of a traditional society altogether. It’s better to recognize and reverse potentially harmful design patterns now before habits and cultural beliefs lose sight of social concerns that were once fundamental. Despite popular belief, money and societal good do not have to be mutually exclusive. Let’s start taking second-hand experience into consideration and make it a core part of the way we practice UX.
The global wearable technology marketplace is growing at a staggering rate, estimated to increase from $7.1 billion in 2015 to $12.6 billion by 2018.
One of the hottest segments in that market is smartwatches. In the past year alone, smartwatch shipments have increased from 7.4 million units in 2014 to nearly 25 million units in 2015. Some analysts believe global smartwatch shipments will reach 101 million units by 2020.
While Google, Samsung, and others are pouring money into wearables, Apple continues to drive many market segments, including smartwatches. Although it’s difficult to accurately size and predict rapidly growing markets, IDC analyst Ryan Reith believes Apple Watch will ultimatelyaccount for 62% of the smartwatch market in 2015. Apple’s record of innovation, and their ability to create new markets, demands that developers take note of their product releases and market activities. Apple is positioned to lead the smartwatch market for the foreseeable future.
With those thoughts in mind, here are four tips for designing applications for the Apple Watch.
1. Simplify your app to focus on glances and notifications
The first thing to consider is that the Apple Watch isn’t a miniature iPhone; it’s a wearable device positioned to support short, lightweight interactions with users. While iPhone interactions are measured in minutes, smartwatch interactions are measured in seconds. Apple research concluded that the average time spent interacting with a smartwatch is two to five seconds—checking email, reviewing a schedule, reading an alert, etc. These short interactions are categorized as glances, notifications, and applications.
Glances are time-based interactions with scannable, timely, and contextually relevant information such as date, time, heart rate, current weather, and financial account balances. Glances aren’t a mandatory companion for every application, but are often presented as an entry into an app and a broader set of information.
Notifications are brief but meaningful information presented upon a user raising their wrist. Customized by size and actions, notifications can be local or remote, presenting the user the most common and relevant actions to use in a quick response.
Notifications can be categorized as short or long. Short notifications include basic information like the announcement of an incoming message. Long notifications provide more details about an incoming message and may allow the user to take simple actions, such as replying to an incoming call or iMessage.
Applications allow users to interact with information similar to the way they would interact with the same app on an iOS device. While this type of interaction is possible on an Apple Watch, glances and notifications are typically better uses. For now, smartwatches are best used as a companion device for short user interactions measured in seconds.
2. Choose the best navigation model for your app
Swiping and tapping are navigation capabilities built into the WatchKit SDK. Both are viable solutions to move from one information display to another. Swiping and tapping are associated with the layout of information either in a page-based or hierarchical navigation format, with swiping used to scroll between pages of unrelated information and tapping used to access layered information.
As a designer, your role is to design an intuitive navigation layout best suited to your app, bearing in mind that the two navigation types should not be mixed.
Page-based navigation is recommended when information between pages isn’t related. It lets the user swipe through pages horizontally. This navigation type is well suited for simple applications such as weather locations, time zones, etc.
Hierarchical navigation is a convenient and flexible navigational structure best suited for complex data and layered information. With hierarchical navigation, you access related information in increasing levels of detail by tapping to move from one display to another.
Regardless of which navigation you decide is best for your application, the best practice is to sketch the design as part of the decision process. This forces you to consider how displays work together and how users access information in your app with swipes and taps. Sketching your navigation also flags cautionary design considerations such as having too many pages in a paged-based navigation or similar issues where usability can be negatively affected due to complex navigational structures hindering an application’s use.
3. Pay attention to your app’s style and branding
By design, smartwatch screens are very small—the Apple Watch is not an exception to that rule. Given the small area available to display information, you need to avoid displaying too much information on one screen. Consider using visual groupings and left-aligned elements to maximize space and readability.
Typography is a very important design decision that tracks directly to usability. Apple created a font named San Francisco to specifically use with the Apple Watch to maximize readability. The font was purpose-built for small screens and high contrast displays. While Apple’s font is preferred for the Apple Watch, generic typography design principles still apply, such as choosing a font early in the design process, minimizing the use of multiple fonts, and using native fonts whenever possible.
Brand identities can be expressed through font, color, and image choice, but you should minimize the use of your logo and avoid filling backgrounds with your brand color. Since smartwatches inherently have small displays and are positioned around the notion of lightweight interactions based on glances and gesture notifications, best practices suggest limiting the use of your brand color to your app’s global tint.
4. Take the time to build and test prototypes
As with all software development initiatives, it’s a best practice to build and test prototypes as part of the design process. This helps your development team visualize the application in its final form and better understand the way users will interact with it when released into its marketplace. Using Invision or Marvel, you can create clickable prototypes before you begin development. This not only validates your design, it can reduce development costs and decrease the time it takes to bring an app to market.
When you prototype your app, be sure to involve end users in the testing and focus on single use cases. This helps you validate the use of the application and gain valuable feedback from target users who aren’t directly involved in your design, possibly giving you a fresh perspective of the application and its value in the marketplace.
Wearable technology, in general, and smartwatches, in particular, are in their infancy, with a lot of activity underway from both global technology powerhouses such as Google and Samsung to startup companies and new entrants of all scales looking to make a name for themselves and claim a stake in the burgeoning smartwatch marketplace. As with other technology markets, Apple is leading the way in smartwatches with its Apple Watch device. This creates a vibrant and promising developer environment.
Designers need to approach an Apple Watch development with several things in mind, chief among them being that the Apple Watch isn’t a small iPhone. Designing an app for the Apple Watch should be approached with its own design process, taking care to focus on Glances and Notifications, with careful use of swipe and tap navigation through page-based and hierarchical navigation to create an intuitive user experience.
Designers also need to take the time to prototype and test their design with target audiences, as well as pay close attention to the effects of brand fonts and colors that may affect the readability and usability of their design.
Ultimately, Apple Watch apps will be successful the same way other mobile apps have enjoyed success, by creating a valuable and intuitive user experience that attracts, welcomes, and serves the interests of end users. Given the infancy of the smartwatch marketplace and early release limitations of the Apple Watch, companies may find a best practice is to team with experienced smartwatch designers and developers, to speed their development and reduce the time to market.
The frequently-raised objection when it comes to quality research, UX research included, is that the conclusions are drawn based on the participants’ declarations. However, there exist some methods which allow one to grasp the real behaviors of participants, and they can be easily implemented into the research scenario.
During exploratory research, the respondents are often unable to articulate their needs or opinions. In turn, when it comes to usability tests or satisfaction surveys, it very often happens that the respondents’ answers are limited to vague opinions which, without being further explored by the moderator, don’t bring in much data.
Very often, they hide their opinions, because something is “not quite right” to say, something makes them feel ashamed, or their behaviors are controlled by mechanisms which they don’t even perceive—because who would admit to having certain prejudices or not fully socially-accepted desires?
Then how does one find out the real opinions of respondents?
One method is observation, which is a fundamental element of every research. However, observation brings us limited information, and without other methods such as an interview, based on declarations it’s difficult to obtain a complete picture of the situation.
The other way is to use psychoanalytic techniques, such as projection, during the marketing survey.
From Freud to marketing
According to the classic concept of Freud’s psychoanalysis, people have a natural tendency to protect their ego. It happens through an inside “censor”—the “super-ego”—which is a part of person’s personality structure and filters all instincts and desires while allowing in our consciousness only those which are socially acceptable. That is the reason why, in many situations, people do not realize their basic attitudes, motivations, or desires. However, it turns out that people are able to assign them to others. That is called projection.
Projection is used most often in the marketing surveys, such as in research about a brand’s image. Usually, the projection methods consist of describing brands as people or objects. The respondent might be also asked to assign people with certain traits to a brand. For example, one might be asked to complete a sentence: “People with traits such as ___ drink X brand beer.”
How to describe modernity?
A current Studio EDISONDA project is a sales platform for a client working in the tourism industry. We’ll call them Green Roller Coaster. During the exploratory research, I used one of the projection methods to deepen the respondents’ answers.
In the initial stage of design for Green Roller Coaster’s new web site, we wanted to find out what kind of image our client has among business partners. During the in-depth interviews, we asked how Green Roller Coaster’s business partners would rate their cooperation with company.
Most of the answers were positive: The respondents praised their relationship with the Green Roller Coaster. The surveyed partners were also asked to describe Green Roller Coaster as a person, a personalisation technique. The company was most often described as a nice and reliable but also as quite old, old-fashioned, not progressive, or even conservative.
This example illustrates some of the many benefits that accrue from the use of projection techniques. On the declarative level, the company was rated neutrally or positively, probably in accordance with the real opinions of the respondents. The interesting thing is that nobody mentioned that they view the company as not really modern. Only after using the projection technique could we obtain the complete image.
In UX research, projection methods might bring a range of valuable information which will be useful while designing the project, such as information about colors, shapes, or words associated with a certain brand, situation, or impulse. Thanks to that, we can utilize the potential hidden in the users, and they can actually participate in the design we are working on.
My dream university
Not too long ago, we worked on redesigning Adam Mickiewicz University’s web site. To get to know the environment better—its problems and the needs of different groups of recipients—we used exploratory research.
We conducted focus interviews (group interviews) with research workers, administration employees, doctoral candidates, students, and student applicants. Additionally, we conducted several in-depth interviews and computer-assisted web interviews (such as online surveys) with the Adam Mickiewicz University’s students.
During focus interviews with applicants and first year students, apart from the standard scenario, we also used the collage technique. The surveyed group was asked to create a collage titled “My dream university.”
On the declarative level, the respondents talked mainly about the didactic offer, the university as a preparation for a future job, the university’s infrastructure, and international cooperation. Of course, these things were also reflected in the collages prepared by the surveyed group, but what really stood out were values which were never mentioned during the group interview.
The collage works contained many themes alluding to having fun, fine dining, sex, sport, and slogans mentioning freedom, openness, and lack of restraints. When creating a web site which aimed to convince the applicants to choose Adam Mickiewicz University, such knowledge was invaluable for the designer.
What convinces young people is not only an attractive way of presenting one’s didactic offer but also showing what will they be able to experience at the university aside from the classes. Collages not only helped us to obtain very valuable data, but they were also an inspiration for graphic designers and copywriters, and they showed how to effectively communicate with the applicants.
Projection as a supplement
The projection techniques allow one to look “deeper” into the respondents’ minds and in many cases let one obtain valuable information which wouldn’t be otherwise easily found with classic survey methods.
It has to be kept in mind, though, that the results obtained from the projection techniques are often ambiguous and usually difficult to interpret correctly without a wider context. Interpretation of the data is based mainly on intuition and experience of the researcher, not on specific criteria.
It also sometimes happens that projective methods do not bring any valuable information, such as when it is difficult to observe any trend in the results. For instance, if students have created collages titled “My dream university” and we could not see any factor in common, a projection as an independent method does not bring valuable results.
Because of this ambiguity, projection techniques should be treated more like a valuable supplement method than the main way of obtaining data. However, in conjunction with other, more established techniques, projection often provides key marketing information which we would not be able to reach based only on declarations or observation. Projection methods are based on natural human psychological reactions to a stimulus and in combination with other methods often have a full picture of the situation and help in interpreting the other test results.