Journal tags: feedback

Ten years ago I gave a talk at An Event Apart all about interaction design. It was called Paranormal Interactivity. You can watch the video, listen to the audio or read the transcript if you like.

I think it holds up pretty well. There’s one interaction pattern in particular that I think has stood the test of time. In the talk, I introduce this pattern as something you can see in action on Huffduffer:

I was thinking about how to tell the user that something’s happened without distracting them from their task, and I thought beyond the web. I thought about places that provide feedback mechanisms on screens, and I thought of video games.

So we all know Super Mario, right? And if you think about when you’re collecting coins in Super Mario, it doesn’t stop the game and pop up an alert dialogue and say, “You have just collected ten points, OK, Cancel”, right? It just does it. It does it in the background, but it does provide you with a feedback mechanism.

The feedback you get in Super Mario is about the number of points you’ve just gained. When you collect an item that gives you more points, the number of points you’ve gained appears where the item was …and then drifts upwards as it disappears. It’s unobtrusive enough that it won’t distract you from the gameplay you’re concentrating on but it gives you the reassurance that, yes, you have just gained points.

I think this a neat little feedback mechanism that we can borrow for subtle Ajax interactions on the web. These are actions that don’t change much of the content. The user needs to be able to potentially do lots of these actions on a single page without waiting for feedback every time.

On Huffduffer, for example, you might be looking at a listing of people that you can choose to follow or unfollow. The mechanism for doing that is a button per person. You might potentially be clicking lots of those buttons in quick succession. You want to know that each action has taken effect but you don’t want to be interrupted from your following/unfollowing spree.

You get some feedback in any case: the button changes. Maybe the text updates from “follow” to “unfollow” accompanied by a change in colour (this is what you’ll see on Twitter). The Super Mario style feedback is in addition to that, rather than instead of.

I’ve made a Codepen so you can see a reduced test case of the Super Mario feedback in action.

See the Pen Unobtrusive feedback by Jeremy Keith (@adactio) on CodePen.

Here’s the code available as a gist.

It’s a function that takes two arguments: the element that the feedback originates from (pass in a DOM node reference for this), and the contents of the feedback (this can be a string of text or it can be HTML …or SVG). When you call the function with those two arguments, this is what happens:

1. The JavaScript generates a span element and puts the feedback contents inside it.
2. Then it positions that element right over the element that the feedback originates from.
3. Then there’s a CSS transform. The feedback gets a translateY applied so it drifts upward. At the same time it gets its opacity reduced from 1 to 0 so it’s fading away.
4. Finally there’s a transitionend event that fires when the animation is over. Once that event fires, the generated span is destroyed.

When I first used this pattern on Huffduffer, I’m pretty sure I was using jQuery. A few years later I rewrote it in vanilla JavaScript. That was four years ago so I wonder if the code could be improved. Have a go if you fancy it.

Still, even if the code could benefit from an update, I’m pleased that the underlying pattern still holds true. I used it recently on The Session and it’s working a treat for a new Ajax interaction there (bookmarking or unbookbarking an item).

If you end up using this unobtrusive feedback pattern anyway, please let me know—I’d love to see more examples of it in the wild.

It’s day two of An Event Apart Seattle (Special Edition). Lara is here to tell us about Navigating Team Friction. These are my notes…

Lara started as a developer, and then moved into management. Now she consults with other organisations. So she’s worked with teams of all sizes, and her conclusion is that humans are amazing. She has seen teams bring a site down; she has seen teams ship amazing features; she has seen teams fall apart because they had to move desks. But it’s magical that people can come together and build something.

Bruce Tuckman carried out research into the theory of group dynamics. He published stages of group development. The four common stages are:

1. Forming. The group is coming together. There is excitement.
2. Storming. This is when we start to see some friction. This is necessary.
3. Norming. Things start to iron themselves out.
4. Performing. Now you’re in the flow state and you’re shipping.

So if your team is storming (experiencing friction), that’s absolutely normal. It might be because of disagreement about processes. But you need to move past the friction. Team friction impacts your co-workers, company, and users.

An example. Two engineers passively-aggressively commenting each other’s code reviews; they feign surprise at the other’s technology choices; one rewrites the others code; one ships to production with code review; a senior team member or manager has to step in. But it costs a surprising amount of time and energy before a manager even notices to step in.

Brains

The Hulk gets angry. This is human. We transform into different versions of ourselves when we are overcome by our emotions.

Lara has learned a lot about management by reading about how our brains work. We have a rational part of our brain, the pre-frontal cortex. It’s very different to our amygdala, a much more primal part of our brain. It categorises input into either threat or reward. If a threat is dangerous enough, the amygdala takes over. The pre-frontal cortex is too slow to handle dangerous situations. So when you have a Hulk moment, that was probably an amygdala hijack.

We have six core needs that are open to being threatened (leading to an amygdala hijacking):

1. Belonging. Community, connection; the need to belong to a tribe. From an evolutionary perspective, this makes sense—we are social animals.
2. Improvement/Progress. Progress towards purpose, improving the lives of others. We need to feel that we do matters, and that we are learning.
3. Choice. Flexibility, autonomy, decision-making. The power to make decisions over your own work.
4. Equality/Fairness. Access to resources and information; equal reciprocity. We have an inherent desire for fairness.
5. Predictability. Resources, time, direction future challenges. We don’t like too many surprises …but we don’t like too much routine either. We want a balance.
6. Significance. Status, visibility, recognition. We want to feel important. Being assigned to a project you think is useless feels awful.

Those core needs are B.I.C.E.P.S. Thinking back to your own Hulk moment, which of those needs was threatened?

We value those needs differently. Knowing your core needs is valuable.

Desk Moves

Lara has seen the largest displays of human emotion during something as small as moving desks. When you’re asked to move your desk, your core need of “Belonging” may be threatened. Or it may be a surprise that disrupts the core need of “Improvement/Progress.” If a desk move is dictated to you, it feels like “Choice” is threatened. The move may feel like it favours some people over others, threatening “Equality/Fairness.” The “Predictability” core need may be threatened by an unexpected desk move. If the desk move feels like a demotion, your core need of “Significance” will be threatened.

We are not mind readers, so we can’t see when someone’s amygdala takes over. But we can look out for the signs. Forms of resistance can be interpreted as data. The most common responses when a threat is detected are:

1. Doubt. People double-down on the status quo; they question the decision.
2. Avoidance. Avoiding the problem; too busy to help with the situation.
3. Fighting. People create arguments against the decision. They’ll use any logic they can. Or they simply refuse.
4. Bonding. Finding someone else who is also threatened and grouping together.
5. Escape-route. Avoiding the threat by leaving the company.

All of these signals are data. Rather than getting frustrated with these behaviours, use them as valuable data. Try not to feel threatened yourself by any of these behaviours.

Open questions are powerful tool in your toolbox. Asked from a place of genuine honesty and curiosity, open questions help people feel less threatened. Closed questions are questions that can be answered with “yes” or “no”. When you spot resistance, get some one-on-one time and try to ask open questions:

• What do you think folks are liking or disliking about this so far?
• I wanted to get your take on X. What might go wrong? What do you think might be good about it?
• What feels most upsetting about this?

You can use open questions like these to map resistance to threatened core needs. Then you can address those core needs.

This is a good time to loop in your manager. It can be very helpful to bounce your data off someone else and get their help. De-escalating resistance is a team effort.

Communication ✨

Listen with compassion, kindness, and awareness.

• Reflect on the dynamics in the room. Maybe somebody thinks a topic is very important to them. Be aware of your medium. Your body language; your tone of voice; being efficient with words could be interpreted as a threat. Consider the room’s power dynamics. Be aware of how influential your words could be. Is this person in a position to take the action I’m suggesting?
• Elevate the conversation. Meet transparency with responsibility.
• Assume best intentions. Remember the prime directive. Practice empathy. Ask yourself what else is going on for this person in their life.
• Listen to learn. Stay genuinely curious. This is really hard. Remember your goal is to understand, not make judgement. Prepare to be surprised when you walk into a room. Operate under the assumption that you don’t have the whole story. Be willing to have your mind changed …no, be excited to have your mind changed!

This tips are part of mindful communication. amy.tech has some great advice for mindful communication in code reviews.

Feedback

Mindful communication won’t solve all your problems. There are times when you’ll have to give actionable feedback. The problem is that humans are bad at giving feedback, and we’re really bad at receiving feedback. We actively avoid feedback. Sometimes we try to give constructive feedback in a compliment sandwich—don’t do that.

We can get better at giving and receiving feedback.

Ever had someone say, “Hey, you’re doing a great job!” It feels good for a few minutes, but what we crave is feedback that addresses our core needs.

	General	Specific and Actionable
Positive Feedback	♥	♦
Negative Feedback	♣	♠

The feedback equation starts with an observation (“You’re emails are often short”)—it’s not how you feel about the behaviour. Next, describe the impact of the behaviour (“The terseness of your emails makes me confused”). Then pose a question or request (“Can you explain why you write your emails that way?”).

observation + impact + question/request

Ask people about their preferred feedback medium. Some people prefer to receive feedback right away. Others prefer to digest it. Ask people if it’s a good time to give them feedback. Pro tip: when you give feedback, ask people how they’d like to receive feedback in the future.

Prepare your brain to receive feedback. It takes six seconds for your amygdala to chill out. Take six seconds before responding. If you can’t de-escalate your amygdala, ask the person giving feedback to come back later.

Think about one piece of feedback you’ll ask for back at work. Write it down. When your back at work, ask about it.

You’ll start to notice when your amygdala or pre-frontal cortex is taking over.

Prevention

Talking one-on-one is the best way to avoid team friction.

Retrospectives are a great way of normalising of talking about Hard Things and team friction.

It can be helpful to have a living document that states team processes and expectations (how code reviews are done; how much time is expected for mentoring). Having it written down makes it a North star you can reference.

Mapping out roles and responsibilities is helpful. There will be overlaps in that Venn diagram. The edges will be fuzzy.

What if you disagree with what management says? The absence of trust is at the centre of most friction.

	Disgree	Agree
Commit	Mature and Transparent	Easiest
Don’t Commit	Acceptable but Tough	Bad Things

Practice finding other ways to address B.I.C.E.P.S. You might not to be able to fix the problem directly—the desk move still has to happen.

But no matter how empathic or mindful you are, sometimes it will be necessary to bring in leadership or HR. Loop them in. Restate the observation + impact. State what’s been tried, and what you think could help now. Throughout this process, take care of yourself.

Remember, storming is natural. You are now well-equipped to weather that storm.

See also:

• Torre’s notes on this talk
• Luke’s note on this talk

When I was talking about Async, Ajax, and animation, I mentioned the little trick I’ve used of generating a progress element to indicate to the user that an Ajax request is underway.

I sometimes use the same technique even if Ajax isn’t involved. When a form is being submitted, I find it’s often good to provide explicit, immediate feedback that the submission is underway. Sure, the browser will do its own thing but a browser doesn’t differentiate between showing that a regular link has been clicked, and showing that all those important details you just entered into a form are on their way.

Here’s the JavaScript I use. It’s fairly simplistic, and I’m limiting it to POST requests only. At the moment that a form begins to submit, a progress element is inserted at the end of the form …which is usually right by the submit button that the user will have just pressed.

While I’m at it, I also set a variable to indicate that a POST submission is underway. So even if the user clicks on that submit button multiple times, only one request is set.

You’ll notice that I’m attaching an event to each form element, rather than using event delegation to listen for a click event on the parent document and then figuring out whether that click event was triggered by a submit button. Usually I’m a big fan of event delegation but in this case, it’s important that the event I’m listening to is the submit event. A form won’t fire that event unless the data is truly winging its way to the server. That means you can do all the client-side validation you want—making good use of the required attribute where appropriate—safe in the knowledge that the progess element won’t be generated until the form has passed its validation checks.

If you like this particular pattern, feel free to use the code. Better yet, improve upon it.

Right before I set off on my antipodean adventure, hell froze over and I opened up comments. There was a twist, of course. I wanted to solicit feedback but discourage conversation so, to foster independence of opinion, comments were not immediately published. Instead, all the comments were published together once the ability to add comments had been switched off. In this case, that was a period of one week.

The post received quite a few comments, some more interesting than others.

Quite a few people were sidetracked by the issue of spam and assumed that I would simply be inundated with comment spam. Spam was something I deliberately didn’t mention in the original post as it is tangential to the matter at hand. As it happens, the Akismet API — which I’m using to filter comments — does a great job of keeping comment spam out.

The original post was prompted by Mike mentioning the lack of comments on my site at the Future of Web Apps summit. The audio of Mike’s talk is now available and I highly recommend you listen to it. It’s an excellent presentation chock full of ideas about community, participation and social interaction. Mike also weighed in on my post, saying:

In my view, comments can significantly raise the quality of experience on most sites but cannot significantly lower it.

Now, this is interesting because I disagree almost 100%. In my experience, coming across pointless, lame, nasty or redundant comments attached to a blog post can lower the quality of the document as a whole. I think Mike has managed to crystalise why others are willing to put up with the downsides of comments, while I find the trade-off unacceptable.

Bradley Wright says:

I’m curious as to how comments that no one else can see will foster good feedback.

Well, that goes back to the whole wisdom of crowds thing I was talking about: independence is one of the defining factors.

He continues:

Sometimes the best leaps I’ve seen in online “conversations” come from the back and forth, which is helpful for some people to help crystallise their thoughts.

I agree. But I haven’t found those conversations happening very often in comments. Instead, I find them happening blog to blog. People tend to post more well-thought responses on their own blogs than they do in the comments to someone else’s blog post.

Guy Carberry brings up an important issue:

I have got some very useful information from the comments of a post.

This is true. This is also something that Andy said to me when we were discussing blogs and comments. Well, with my system of comments, this will still be true. Once comments are displayed, there is a greater chance that they will contain only useful information rather than a mixture of information and conversation. The google dance usually takes a while anyway, so if someone is looking for information on a topic and they end up at one of my blog posts, the ability to add comments will probably be disabled and all comments will be displayed. That person gets the information in the original post along with any feedback sent in via a comment. In fact, I would argue that my comment system will prove more valuable for long-term information search.

But how long is long? For how long should the ability to add a comment be available? For the inaugural post, I chose one week. I figured that would be a nice length of time to allow everyone to have their say. As it turned out, the vast majority of comments were submitted in the first few days. Clearly, a week is a long time on the web. I think two to four days might be a better length of time to keep the comment form available.

Pete Lambert commented on the need for some way of tracking when comments get published:

My only issue with it is that I would have to remember to come back and check the comments after whatever arbitrary quarantine period you define.

This is clearly something I need to work on. I still think some form of email notification would work best. Another option would be to actually publish the comments in my RSS feed as well as on the site. With a little jiggery-pokery, this could be flagged up as unread in most RSS readers. But this could just end up pissing off the people who don’t care when comments are published.

Here’s another point:

I suspect what you are going to wind up with is a long list of the same comment over and over again.

Surprisingly, this didn’t turn out to be the case. I actually received a fairly wide range of ideas from people.

That’s not crowd wisdom at all. If your blog was a multiple choice quiz, then fine, but it’s not.

That’s a good point: the wisdom of crowds does seem to work best with multiple choice questions (or “guess how much this weighs” questions). I opened up comments on another entry, where I was soliciting opinions on things to do in Melbourne. I personally thought that this would be a better test of my commenting system. The aggregate results should have given me a good independent overview of recommendations.

As is turned out, I shot myself in the foot by

1. restricting the crowd to people who know anything about Melbourne and
2. also encouraging feedback via my contact form.

Still, my point above about the added value of comments via findability still stands: somebody googling for restaurants in Melbourne will not just find my original post, but also the (one) useful comment about places to eat. The fact that the comments was originally hidden during the submission process doesn’t affect the long-term usefulness. I can see the commenting system working well for less tightly focused questions.

Based on the inaugural post with comments, I’m pretty pleased with the results. Clearly I need to work on a better notification system and I also need to figure out the sweet spot of how long to allow comments to be submitted but overall, this little experiment has yielded some pretty tasty fruit.

I was all set to start allowing more comments when I came across a post by Robert Nyman entitled A blog without comments isn’t really a blog.

Oh, brother! Here we go again.

After all these years of trying to define what a blog is, who knew that someone blogging for a year and a half would stumble upon the answer?

Forgive my sarcasm, but I get pretty fed up of being judged based on how I set up my personal site. I said as much in a comment on Robert’s post.

In his post, Robert has this advice for people who don’t have comments enabled:

Then you shouldn’t blog.

At the same time, he claims to love the openness of the web. I’m seeing a disconnect here. In his reply to my comment, Robert says:

I’m glad that I have comments here so everyone can read your and my opinions on this, and also have the possibility to contribute with what they think. That’s what I like about the web: the openness.

That’s a pretty narrow view of openness. I don’t think it’s very open to have all responses in a single document.

Here’s what I like about the web: openness through hypertext. I can link to any resource on the Web and comment on it here on my own website. Conversely, anyone is free to link to this document and comment on it on their own site (or a third-party site like Newsvine). That’s openness. Demanding that everyone post their thoughts together on the originating document is a closed system.

So, just as I was ready to start experimenting more with feedback mechanisms, I’m confronted with a “my way or the highway” ultimatum about what I’m allowed do on my own site. It’s enough to make me give up on the whole idea.

But I won’t. I’ll keep opening up the occasional post for comments, although I’m also really interest in using tags and pings for tracking responses, hence the Del.icio.us, Technorati, and Flickr links at the end of each post.

I was thinking of opening comments on this very post, but I think most of the salient points have been gathered from the initial post. If you would like to respond to this, you can write a blog post of your own and it will appear through the Technorati link (I really wish Trackback worked better but spam has effectively killed that off). If you have any feedback, there’s always email and IM.

Technorati has been redesigned, or realigned if you prefer. It’s gone a bit gradient happy but overall, it’s quite a pleasing visual aesthetic.

For some reason though, they’ve chosen to lock the pages into a fixed width of 1024 pixels.

Now, I understand the reasoning behind fixed-width layouts. I can see the justification for wide fixed-width layouts on content-heavy sites like A List Apart (even if I disagree with it). But forcing users of what is fundamentally a web app to set their browser to a certain width seems counterproductive to me.

The content on Technorati is user-generated. Usually, that user is me. It has my favourites, my watchlist, and my search terms. I should be able to interact with that content in my way.

This is something that, as with so many things, del.icio.us gets just right. Upcoming is on the right track too. These sites allow me to interact with my data without putting me in a straitjacket.

Flickr is still avowedly fixed but the image-based, rather than text-based, nature of the data I store there makes this somewhat understandable.

Now, don’t misconstrue this as a tirade against 1024 pixel wide layouts. The problem would still exist in an 800 pixel wide design. Choosing an arbitrary number of pixels in which to serve up user-generated content is the issue here. On the one hand, Technorati is a very Web 2.0 sort of site, based on user-generated distributed content and collective wisdom. On the other hand, its visual design is grounded in a very Web 1.0 idea of top-down control and inflexibility.

I like Technorati a lot. It’s come on in leaps and bounds in the past couple of years. I’d like to use it every day. I’m even willing to put up with the oversize ads. But I resent the feeling that I should adjust my browsing environment to the needs of the site, rather than the other way around.

My thoughts on comments were cause for some debate in certain circles. I’m not the only one grappling with this issue.

I managed to lure Dunstan out of his self-imposed exile long enough for him to point to some ideas he had for a more heavily moderated commenting system where only useful additions appear with a post. This is somewhat along the lines of the BBC’s website where occasionally feedback is solicited but it’s more along the lines of letters to the editor: comments enter a queue and only representative selections are published.

For a very interesting take on the comments question, I highly recommend listening to this interview with David Sifry posted on the Podleaders podcast. Responding to the question of whether Technorati has any plans to begin indexing comments, he points out that whereas blog posts have a certain level of accountability, comments are more like the (often anonymous) throwaway remarks that polluted Usenet and chat rooms, preventing those technologies from scaling past a certain point:

One of the reasons I think blogging is very different from bulletin boards or chat rooms is that it fundamentally enforces a level of accountability.

I find that that level accountability tends to create, or enforce, a certain amount of thoughtfulness… a willingness to think twice before someone says nasty things.

The problem I have with many commenting systems on blogs [is that they] do not enforce any level of accountability.

That’s exactly what I was getting at in my original post when I said:

The best online conversations I’ve seen have been blog to blog: somebody posts something on their blog; somebody else feels compelled to respond on their own blog. The quality of such a response is nearly always better than a comment on the originating blog for the simple reason that people care more about what appears on their own site than on someone else’s.

Then the tricky bit is tracking those conversations. And that’s where services like Technorati come in.