Month: September 2018

I work with a lot of folks who are new to information architecture, and I’ve answered a lot of “but where do the controls go?” questions lately. There is a definite sense of directionality to interfaces, and understanding the expected direction that the user moves through the page helps you determine how to control the display or change to the content on the page. It will also help you understand why a poorly-placed control causes confusion or frustration in your users.

The rule:

The controls to display or interact with a piece of content should be above and/or to the left of whatever they’re controlling.

Caveats and preconditions:

First, everything in this article applies for left to right (LTR) languages. If you’re designing in a right to left (RTL) language, an up-down language, or a down-up language, your mileage may vary, but flipping the rule is probably a good start.

Second, this pattern requires two things: containers you want to manipulate, and controls to manipulate them. Containers may refer to:

• Tabsets
• Cards
• Accordions
• Forms (particularly forms with subsections or embedded tables)
• Tables
• Charts and sets of charts

In this case we’re also going to take specific types of encapsulated containers out of the pattern, including:

• Carousels
• Video / video controls
• Audio / audio controls
• Search boxes

We’ll explain why in the Exceptions section.

These lists are not all-inclusive.

The design principles

Let’s start with the obvious: left-to-right (LTR) languages are read left to right. So at the highest level of generalities, readers are more likely to notice the thing to the top left first and the bottom right last. When a user is scanning a page to get a sense of place, we call this specific pattern F-Shaped Scanning because of the roughly f-shaped eye-tracking patterns it produces.

A sense of place is critical for a user to acquire; knowing where they are, what the state of the place is, and what they can do allows them to move forward (or backward) toward their intended goals. Because “Where the hell am I?” is the first question anyone has in any situation, and because people read left-to-right, we answer the questions “where the hell am I?” by putting the wayfinding tools (the site title, logo, and global navigation) as far up and to the left as we can get.

Consider this the functional equivalent of the “Welcome to Pennsylvania!” sign you get when you cross a state border. Even assuming you knew you were going to Pennsylvania, it’s good to know when you’ve crossed the border, and if you didn’t know you were visiting the Keystone State today it’s really important to find out you have.

Almost as important as answering “Where am I?” is answering “What can I do here?” You may have also heard this referred to this in terms of questions like “Can the user perceive the purpose of the page?” or “Does the user identify the call to action?”

(To answer “What can I do here?” we also have to answer “And what state am I in right now?” Most of the visual components that we use present information display both state and affordance simultaneously through a visual language,  but if we’re presenting information through auditory means via a screen reader or speech-controlled interface, we have to specify both.)

In general, it’s best to present interaction controls either in conjunction with the wayfinding points or directly after them.

So for example, a tabset is both wayfinding (answering “Which content set am I on?”) and interaction (answering “How can I switch to other related content?”).

A call to action to “buy it now!” on the other hand, should be to the right (or below) of the name of the product because nobody wants someone shouting “BUY THIS THING!” when they don’t know what the thing they’re being asked to buy is yet.

You may have noticed that the direction with which we read and the containers that we digest convey more than just wayfinding and interaction, however. They also convey a sense of time. For example, as the reader you assume that if I were reading this paragraph out loud to you, I would read it after the content above this paragraph, and before the content below this paragraph. Events lower on the page are perceived as taking place after events higher on the page, even though somewhere in our brains we know that the entire page is present all at a single moment.

The reason that we put the wayfinding above or to the left of interactions is because we want to know “where am I?” before we know “what can I do?”, and in a left-to-right language, earlier events get put to the top or the left of later elements.

The time component is true of any reading, but is most obvious in serial art or comics. In Understanding Comics, Scott McCloud explains (emphasis his):

In learning to read comics we all learned to perceive time spatially, for in the world of comics, time and space are one and the same… so as readers, we’re left with only a vague sense that as our eyes are moving though space they’re also moving through time — we just don’t know by how much!

Obviously, if a perception of time is present in straight written words and also in something as visually-oriented as comics, we can assume it also applies to our less-visual-than-comics, more-visual-than-a-novel websites.

When using a web interface, users hate moving backwards in time.

Think about the last time you filled out a long form on the web. Maybe it was shipping information. Maybe it was a mortgage. Whatever it was, I’m fairly confident that if the form designers required you to get information from the top of the form to continue something at the bottom of the form, it made you grouchy. We expect that if we’ve provided something at the top of an experience, it’s remembered during the time it takes us to get to the bottom.

The most frequent information architecture mistake I see in form design is form fields that don’t respect the perceived time directionality of the form. For example, I was recently shown a form where checking a box in row 6 would change a value in row 2. When you’re filling out that form, and you’ve reached row 6, row 2 is in the past. You’re neither going to expect to have to recheck your past nor look for changes — especially if you’re on a small screen and row 2 is no longer visible!

On the other hand, if row 2 affects the values (or fields) available row 6, well, you haven’t even gotten to row 6 yet… it’s in the future.

Or to put it another way, “If X then Y” has to run in the order “first ask X then ask Y”. Even if you can’t quite grok that for visual interfaces, think of the impacts for users who are listening to the screen… if you update something that’s already been read, it’s like interrupting yourself to say “nope, changed my mind”, and then you have to tell the user about the whole form all over again or risk confusing them.

In addition to wayfinding, interaction-finding, and the perception of time, our controls need to be visually associated with the things they affect.

The Gestalt Principle of Proximity states that things that are grouped together appear to be related. That means that if you want a control to be associated with a container, they have to be near each other.  The further apart they are the less they look connected.

Fitts’s Law strengthens this principle by pointing out that the further apart two things are the bigger you have to make the second one to make it quickly usable.

The Law of Uniform Connectedness helps us strengthen the connections between controls and the things they effect by stating that elements that are visually connected are perceived as more related than elements with no connections… which is a fancy way of saying “draw a line between two things or put a box around them, and they look like they work together.”

A popular mistake is putting a control at the top of a page which doesn’t affect anything except at the bottom of the page.  Another popular mistake is putting a control inside a child container that actually controls the parent.

So here’s a quick test: if you can draw a box around the thing being changed and the control, and everything in the box is being controlled by the control, then they’re probably (but not always) associated correctly.

I see this mistake most often with tabsets and charts, so here’s an example.

If we put the controls above and to the right of the tabset’s content body, it’s perceived to control not just the current tab’s information but also the information on the other tabs.

If we put the controls within the body of the Charts tab, but outside of the body of any of the charts on the page, the controls are perceived to control all of the charts on the page. For heaven’s sake, don’t put in exceptions! Nothing drives a user crazy like having three charts that will switch between day, week, and month with a single control and one chart that’s like “nope, I’m not even time-related, I need different controls”.

So what if we do have four charts that require at least two different controls? At that point the best thing we can do is give each chart its own control, so that the user can see explicitly what controls affect which charts. Oh, and if you have to group your charts into two sub-containers for “affected by time” and, say “affected by amount spent” or something, each of those containers only needs one control… as long as all its children use the same scale.

Exceptions

One exception to this rule occurs when you can use the Principle of Proximity and containerize the controls to be very obviously related to the thing to their direct left or directly above them. Remember when we mentioned that we weren’t going to talk about video players? That’s because the controls for a video player are generally below the video player, but there’s such a strong containership thanks to the Principle of Proximity and the Principle of Uniform Connectedness that we can get away with it.

Containers with encapsulated controls such as video players, audio players, and carousels tend to display mostly visual or visual/auditory content (as compared to written or mixed types), have specialized controls such as play/pause which are different from most of our other use cases, and don’t change the content of anything other than their own container. (Also, fuck carousels.)

Another exception can be found in micro interactions for form fields. Search fields, select menus, and similar elements may have controls or affordances at the right or bottom, but they are so tightly visually coupled with their content that they’re viewed by the user as a single element. That isn’t to say that with some creative destruction you can’t break their usability through CSS styling, but at least you’ll have to put some effort into it.

(Don’t.)

In conclusion…

Web pages have directionality. Assuming you’re working in a LTR language, you should ensure that you’re answering wayfinding questions to the top or left and interactivity questions directly after that, also to the top or left of the content container you’re affecting.

Users don’t like to go backwards in time, so make sure that your conditional logic never asks a user to move back up or to the left of the page because of something they completed further down or to the right.

Users also don’t understand when controls are far away from the things they’re controlling, or are perceived to control a larger set of things than they actually affect, so follow the Principle of Proximity and put your controls closest to the border of the container they’re affecting.

Finally Gestalt principles, especially around proximity and uniform connectedness, can help you strengthen relationships between controls and content when you need to break the rules, but avoid breaking the rules whenever you can, so that your sites will make more sense.

It’s been a couple of weeks since The Atlantic ran their article entitled “The Problem With ‘Hey Guys‘” and I’m still thinking about it, so I thought maybe it was time to air it out a bit.

Specifically, at the time it was published, someone said to me (paraphrased) “We should just let ‘guys’ evolve into the gender-neutral term it is heading towards. And for the record, if the ladies would rather turn ‘gals’ into a gender-neutral term I’m fine with that too, but it would mean starting from evolutionary scratch.”

Some of you are immediately beating your head into your desk right now and others are going, “Yeah, I mean, right?!?”

I’ve worked really hard to take “hey guys” and “you guys” out of my speech, which considering I’m smack dab between Philly, Jersey, and New Yawk, is no easy feat. I’m surrounded by “you guys”, “yous guys”, and “dese guys” and far enough from “y’all”, “youse” and “yinz” for all of them to feel unnatural.

I fight against both my internal programming and the “general trend” The Atlantic suggest may be occurring for one simple reason: Guys isn’t gender neutral, and we shouldn’t allow it to evolve that way.

Saying we should let the word “guys” evolve into an acceptable gender neutral term is essentially saying we should allow the state of maleness be the default.

There’s no point in history in which the name “Guy” or the word “guy” meant “girl” or “nonbinary individual”. It’s always meant “man”, whether that man was Guy Fawkes or a man dressed weirdly, or a bunch of men.

And we’d never argue that “hello, gentlemen” or “yo dickheads” are gender-neutral.

In this society, being the default gender isn’t the building block upon which all others build, it’s the thing to which we are all to aspire. When we say male is the default, everything not-male is less than the default. So when someone says “women can make ‘gals’ gender neutral if they want to” they’re actually suggesting that women do the work necessary to not only overcome the political and cultural obstacles of becoming a more acceptable default than maleness, but also the cultural obstacles of meeting the default in the first place. After all, if women, non-binary, and transgender people were seen as the default, there would be no discussion. The “goal” to be seen as the default isn’t just stating from scratch, it’s starting from a deep hole someone else dug for us.

Besides, that’s not the direction language is going.

When I was in undergrad (studying linguistics in the late 1990s) the expected and understood default to use in academic and journalistic writing where you didn’t know the gender of the person was to write “he”. So, for example, if you wrote about programming you would say “If he has a development problem he should go to his tech lead and he will help him out.”

But if you were confident the unknown person was female you wrote in that gender, “She was a seamstress.”

The argument then was that “he” was gender-neutral, because “he” was the default. (Don’t even get me started on how this erased non-binary people.)

The actual impact was the erasure of women as developers, scientists, farmers, professors, welders (and erasure of men as nurses, teachers, etc.) in pretty much all documentation.  In one social experiment, studiers found young children are shocked to meet women firefighters, surgeons, and RAF pilots. Transgender and non-binary people have been virtually erased altogether.

When the rule that “he” is the literary, academic, and journalistic default rule finally, painfully, inexorably got thrown out, I suddenly discovered that I could read a technical article that either used the true gender-neutral singular “they” (which has been around since the 1400s) or that the article actually would switch genders so both male and female-identifying people were acknowledged to program computers or work as scientists or, y’know, exist.

The trend of rejecting “you guys” as gender neutral, I argue, stems not from “you guys” becoming more gender-neutral but rather from our growing awareness of the need for gender-inclusive language. It’s not that “you guys” has changed, it’s that in a world where calling everyone we can’t identify as “he” is unacceptable, calling a group of unknown gender “you guys” looks flat-out stupid.

True story: I once found myself part of an all-woman UX team. This was remarkable as I’d been in UX almost 10 years by that point and had only had one woman manager, much less an all-woman team. While we were in a meeting with a few tech leads (all men) one of them said, “And the guys on the UX team will provide us the guidance for [project].”

I looked around and said, “What guys? Who are these guys? Did we hire guys while I was at lunch?”

The tech lead turned pink with embarrassment, and I turned pink with embarrassment. (It takes practice to call out gender-erasing behavior and it’s embarrassing to have to. Also, I am a generally tactless individual and I know it.)

But, you know, that person hasn’t called the UX team “guys” since, even though it’s now a much more even balance of genders (and twice its original size).

Gender inclusive language matters. It matters to me that women are acknowledged as programmers, just like it matters to me that there are female characters in Elder Scrolls games and it matters to me that the doctors in my family (all women, by the way) aren’t mistaken as nurses by their peers.

Representation matters. It builds confidence in the underrepresented and sends a message that “hey, I think you belong here too.” It says “I don’t believe male is the default state for this job or this activity”. It says “I see you”. It says “I’m glad you’re here.”

And yes, I acknowledge that it is hard to change our internal grammar and semantics. I still screw up on so many things — using “hey guys” or “you guys” is just a drop in the bucket of cultural blunders I make. I still use “crazy” as a pejorative every day and as someone with mental illness that’s essentially attacking myself.

One thing I’ve done as the “owner” of a Slack board for, well, slackers, is approved of adding a Slackbot message keyed to “you guys” or “hey guys” to provide a hopefully-humorous reminder to use gender-neutral language when possible. I don’t deserve credit for the idea; our members built it and continue to add entries to it. I also wasn’t sure it would catch on (and it almost didn’t). Nobody likes to have their language corrected especially when they didn’t mean to offend and we had some pretty raucous conversations about the bot when it was first introduced.

I also recently had run-ins with a number of men (I wish I could say it was more than just men, but it hasn’t been) who were exposed to a similar (and honestly, much more professional) Slackbot, who have postulated that being called out in public for saying “you guys” is more offensive than saying ” you guys”.

Here’s how I hear that phrase: “Being called out in public for misgendering someone is more offensive to me than my act of misgendering someone is to them.”

Funny how as a woman who’s been “one of the guys”, “hey guys”, “you guys” “those guys” and “I don’t know which of the guys did this” for 40 years I’ve got a different take on it than the guys.

If you think that being called out for bad behavior (sexist, racist, homophobic, etc.) is worse than enacting that bad behavior in the first place, you are wrong. Seriously. It’s only worse to you because you don’t want to feel the consequences of your bad choices, or change. It’s not actually worse than the thing you did.

I would rather pull out my own teeth than reprogram something so automatic as my linguistic defaults.  But we’re humans. We can change. If words are “just” words then it doesn’t matter if we change them to not hurt someone else’s feelings or make someone else feel welcome, and if words are so much more than “just” words, then all the more reason to change.

And change, while difficult, isn’t always painful. Where at first I thought we were going to have a mutiny, or at least someone throwing all their toys out of the pram, I’ve found that our Slack members have accepted the ongoing Slackbot interruptions. It’s become a running joke on my Slack board to yell at the Slackbot for correcting us (in a very “Shut up, Westley!” kind of way), because we all slip up.

More importantly, despite our abusing the Slackbot for doing its job, we’ve cut way back on uses of “hey guys” or “you guys” as an organization. “Shut up, Slackbot!” is a regular occurrence… but not nearly as regular as it used to be, when all of us used “hey guys” constantly in our communications.

Our Slackbot’s responses to the key phrases include:

And what about the gals? Or the gender-queer?
How about y’all? (Or the formal all y’all.)
How about saying folks next time? Peeps? Gargoyles?
Pittsburgh it up next time with a little “yinz”?
Philly it up: try “you jawns”!
Break brains in both ends of the state and try “yinz jawn” next time. 😉
All the kids are saying “fam” these days. Don’t you want them to think you’re “hip” and “wit’ it”?
Pro tip: “Foolish mortals” is a gender-neutral form of address. (Hat tip: https://twitter.com/@Black_Isis)

As an eternal optimist, I’d much rather that everyone out of the goodness of their heart magically rewired their own internal programming to not only accept everyone but talk in ways that show their acceptance.

But we’re humans.

So we have to work at it.

And if that means throwing out garbage articles that want us to believe that gender-exclusive language is suddenly gender-neutral because we don’t want to give it up, well, that’s a small step to take.

In the meantime, Slackbot continue to remind yinz jawn that we can do better.

So we’re about a quarter more than two years old here at The Interconnected and it’s safe to say that building an audience and publishing on a regular basis is harder than it looks on TV.

Or anywhere else, especially the internet.

And there’s lots of reasons for that.

For example, it sounds easy to make writing a habit, but like every other habit that doesn’t involve addictive substances like nicotine or dopamine it’s hard to start and easy to quit. Speaking personally (and that’s all I’m doing in this essay — our other editors have either already weighed in on how hard writing is or will do so when the mood strikes them) I know I should write every day, because my fiction would certainly improve if I was writing words more, and my nonfiction certainly wouldn’t be harmed.

But that means carving out time, sitting down, and doing the work.

You know, like everything else in life.

There’s also the problem of imposter syndrome and self-doubt. At one point I told the other editors that I didn’t want this site to become “the anne show” so I wouldn’t publish more than two weeks in a row, because really, who’d want to read the anne show? If you wanted that… well I don’t know what you’d do because I’ve never given you chance, have I?

Yep. Hello writing demons, good to see you’ve teamed up with my inner editor yet again.

Then there’s the fact that because I love writing, I naively assumed lots of people in UX love writing, and would love to write for us. Except if that were true most of us would probably actually be in writing positions, not in design positions. Even our offer of an admittedly-pathetic $25 paycheck per post doesn’t draw in lots of writers.

Writing is work. Writing about work is as tiring as doing the work. Writing about work carries other risks — what if people don’t like it? what if they think I’m not a good designer? will this hurt my career? what if nobody wants to hear from me? what if it upsets my boss/company/HR department? — and those risks are real. There are not a ton of people who, when they hear, “Do you want to write an article?” punch the air and yell “Shit yeah! Sign me up!” and most of the ones I know who do are already editors here.

My years on the outskirts of the webcomics industry taught me that you can’t build an audience if you, the creator, don’t show up. On time, on a schedule, consistently enough that your audience can find you. They’ll binge on your work if they can find it and they’re behind, but they won’t follow you forward if finding your work is a pain in the ass.

But that’s exactly what we’ve done here at The Interconnected; we’ve gone from a once-a-week schedule to a haphazard schedule of posts going up willy-nilly, to long gaps of silence.

Well, that’s no way to run a railroad.

So while I strongly hesitate to use the word “promise” as in “I promise we’ll have good readable content for you every week”, I am going to make an effort to up the output around here at Casa Interconnected. I’ll probably be posting on either late Tuesday nights (hello!) or Wednesdays, depending on pinball league and tournament schedules, work needs, life needs, and whatever these three nitwits need.

Obviously, our other writers are all still going to post when and where they can, at the schedule that best meets their needs. We don’t normally post more than once a day, but heck we don’t normally post once a week right now, so we’re not real big on hard and fast rules.

Let’s see what we can do to turn these fits and starts into a running engine, shall we?