Tag: user experience

Return of the Popup

More than a decade ago, the internet userbase (all of humanity) resoundingly rejected popup windows. Popups became a popular method for scumbag web sites to serve advertisements and malware to visitors. They annoyed, they took up system resources needlessly, and they were generally unwanted. The lowly popup was the bane of the IE6 era, and many countermeasures were employed to block them, culminating in browsers adopting default settings to block popup windows and to require the user to approve popups on a per-domain basis.

It’s 2014, and popups have been returning thanks to javascript. Now, instead of popping up a new browser window and loading an entire webpage, popups have become ajaxy, serving an html fragment inside a FancyBox or similar javascript construct. They tend to serve up nags to Like, Share, and Follow the host site, rather than display advertisements for the ad network sponsoring the site, but they are no less annoying, and a stop needs to be put to them. It’s pervasive with clickbait “viral” websites, which are themselves annoying to begin with, due to the way they craft their teasers in often misleading ways. But these modal javascript annoyboxes need to go. Especially on mobile browsers, where the close button frequently doesn’t work well, they harm the user experience on web sites that use them.

FancyBox Etiquette for the Scrupulous Web Developer

There are legitimate uses of FancyBox, to display fullsize content in image galleries, for example, or to bring up contextually relevant controls in a web application. But the social share nag needs to go. The little buttons under the headline or at the bottom of the article ought to be sufficient. If people aren’t clicking on them, you don’t need to shove it in their face after a few seconds delay, or they’ve scrolled halfway down the page.

Here’s how to know whether your popup is a good popup or bad popup:

  1. Does the content being served in the popup serve the user’s needs, or is the site asking the user to do it a favor or asking the user to buy something?
  2. Did the user do something to request it, like click a button or link? Or did you throw the popup at them because they have been in the page for more than 10 seconds or scrolled down to read more of the article?
  3. Is the popup enabling the user to do what they came to the site to do? (eg., reading content, view a gallery of images, interact with features of a web app) Or is the site interrupting what the user came to the site to do and asking them to do something else (eg, buy something, donate money, sign a petition, LikeShareFollowSubscribe?)

There’s really not much gray area possible here. If you’re a web developer, stop doing the scumbag stuff, and get back to providing a good user experience to the user.

An appeal to end FancyBox popup abuse

Unfortunately the new popup phenomenon seems to be increasing in popularity, which means that, apparently, they work. If users don’t stop clicking on the Like|Share|Follow buttons when they’re served, we’re only going to see more of them. We need to stand up and say enough is enough.

Therefore, I’m issuing this appeal:

To the masses: stop Liking, Sharing, Following, and Subscribing to sites that try to signal boost through popup social nagging. In fact, stop going to those sites altogether.

To website developers: Stop making use of popup nags. Just stop already. Stop it.

To browser developers: Javascript has become a crucial part of the web, and necessary for many web sites to serve any content at all. But it is also a too-easily exploited vector for external threats to execute malicious code through the web browser, simply by visiting a URL. Come up with a way to selectively and effectively block javascript from running, so that desired features and functions of a site can be allowed while undesired scripts can be left blocked. Let javascript be used in ways that serves the user’s needs rather than the webmaster’s.

Managing Categories and Tags in WordPress

For the longest time, I’ve paid little attention to the categories and tags on this site. I played with the features a bit, but didn’t really understand them well enough to feel like I knew what to make a category, what to make a tag, how to do it consistently, and so on.

As often happens, I figured it out “naturally”, by just using the site and over time the purpose became more clear. Then for a long time I just didn’t feel like going through the tedium of going through all the old posts and re-doing everything. I hated feeling like “If I had to do it all over again, I’d do things differently”, though, so eventually I had to do something about it.

I’m here to share the lessons I learned.

Know your purpose, or if you don’t know your purpose, find it

When I started this site, I wasn’t entirely sure what I wanted to use it for. I knew I wanted it to be a site for promoting and blogging my professional activities, but beyond that I wasn’t sure how I wanted to do it. This was something that developed for me over time, as I became more comfortable. At first I was very risk averse about putting up any content at all. Putting my real name up on the web made me feel inhibited and over-cautious. I didn’t want to make a mistake, embarrass myself, offend someone, lose my job, etc.

As time went on, I began to get over these fears, and it allowed me to post more frequently, feel more free about saying what I want to say, and knowing what I wanted to talk about. I surmise that most web sites develop their purpose over time, and refine what they do. I couldn’t have known how to do everything before I started.

Doing it is an essential part of the process of learning how to do it.

This means making mistakes, and you shouldn’t let yourself be inhibited from making them. Learning from them quickly and doing things better is more important. But sometimes lessons take a while to sink in, and when that happens it is not always the best thing to start making changes right away. You don’t have the time and you quickly lose energy if you put yourself through a comprehensive overhaul several times in quick succession. So before doing a drastic overhaul, take time to think about it, and before you do the whole thing, do a small part of it first and see how it works. Iterate a few times until you think it’s just about right. Then do the overhaul.


Here’s how I think about WordPress Categories: If my WordPress site was a book, the Categories would be the headings I would use for my Table of Contents. This isn’t quite right, but it’s a close enough way of looking at it.

If your site has a relatively narrow purpose, you should have relatively few categories. Categories should be broad. Think of your categories as sorting bins for your posts. Your posts fit into or under them. It’s OK if your posts fit into multiple categories, since there’s often overlap. You can create a hierarchy of categories as well, which can be helpful if you have a number of closely related category topics.

If you find that you are constantly writing posts that fit into the same group of categories, you should think about whether those categories would be better off consolidated into a single, broader category, and perhaps your former categories re-done as Tags.


Tags are like index keywords that help describe the major ideas that are contained within your post. You should think about the content of your post, and what the main ideas or topics were, and tag appropriately. This is not a SEO game, where you want to try to guess all the variations of words that people search by and include them. So skip the -s/-ing/-ly game.

Tags should be short, single words or phrases of two or three words. Try to avoid redundancy, but some small amount is probably OK. WordPress separates tags with commas, so you don’t have to worry about using spaces. It’s OK to use spaces between words, rather than running words together.

I frequently see tags being misused as a sort of meta-commentary on the content of the post or page. This is witty, entertaining, gives some personality to the site. I’m not sure that it’s helpful, but the occasional humorous tag might be amusing.

Witty tags work when you’re reading at the bottom of a post, or reading the summary or digest of an article before you click to Read More. But the intended way for your readers to use tags is to find other related content on your site that is of interest to them. If you over-do the witty tags, you’re not giving the reader useful ways to find a reason to spend more time reading your site.

How your site’s users use Categories and Tags

How, indeed? You can guess, and you can assume, but the truth is unless you have some system of measuring that can watch your readers behavior while they’re on your site, you don’t have too much of a clue how a site’s users actually use the category and tag features.

With WordPress sites, typically it’s the authors who are doing the tagging and categorizing. Readers merely consume them. Some sites, where there is an element or even an emphasis on user-generated content, give users the capability to creating their own tags and categories. If your site does this, you absolutely need to observe and track your users’ behavior. It’s fascinating, amusing, and will give you a lot of insight.

If you retain sole control the category and tag features, you need to think about what your readers need and how useful you are making your site through these features. If you can, try NOT to have to rely on guessing or “common sense” to tell you this — find ways to observe user behavior (though logging, perhaps), or solicit user feedback, and use that to influence your planning and decisions.

Another useful thing to do is to monitor the way people are searching your site, or the search engine query that brought them to your site. The most common search terms your users used to find you should jump out as terms that you should use for tags, possibly for categories as well. And if you’re advertising your site, or using advertising to generate revenue on your site, knowing what terms users are searching for is crucial to drawing traffic and generating revenue.

WP-Admin and the Category/Tag Renovation

My experience with this was that it could have been faster and less tedious. It’s probably my host more than anything, but it seemed that reloading the post, tag, and category administration pages took longer than I had patience for. Clicking update, then waiting a few seconds for the refresh, times however many posts I updated, adds up.

If I wanted to apply the same changes to multiple posts, there’s no way to do this through the web interface. A “mass action” feature to allow adding/removing the same category or tags to multiple posts at once would be very useful.

I could have attempted to directly manipulate the database through building a custom update query, but I didn’t want to sink time into doing that, didn’t want to run the risk of messing it up, and in any case, it’s probably beyond the capability of most WordPress bloggers, so I don’t recommend it. If you have an absolutely HUGE site that needs hundreds or thousands of changes to be made the same way, look into it. If you’re just dealing with dozens, just do it manually.

The other thing that would have been helpful was some kind of redundant tag merging. It’s not uncommon to apply very similar tags inconsistently over the history of your site.

For example, I used the tags “GameMaker” and “Game Maker” quite a bit. I had a few other GameMaker-related tags, which included a specific version, such as 8.0, 8,1, etc.

My first attempt at merging these was to simply re-name the “Game Maker” tag to match the label of my “GameMaker” tag. This did not merge the tags, though; it just created two identical tag labels, which were still separate as far as my WordPress site was concerned. A reader clicking on the “GameMaker” tag from one of my posts would only find about half of the posts I’ve written about Game Maker. Not good!

In order to fix this, I had to remove the redundant tag from my tagging system. To avoid losing the posts that I wanted to be tagged, though, I had to go through and re-tag those posts with the correct tag. At that point, I had a bunch of posts that had BOTH “GameMaker” tags — the correct one, and the incorrect tag that I’d re-labeled. I still needed to remove the incorrect tag to get rid of the redundancy, but looking at my Posts I couldn’t tell which was the redundant tag! So, I went back to the tag admin page, and changed the label of the incorrect GameMaker tag to “dup”, and then went through my posts and removed the “dup” tag.

It would have been much simpler, easier, and faster, if I could have simply navigated to the tag admin page, selected both the “Game Maker” and “GameMaker” tags, hit a button to merge the two tags, and specified which label I preferred to keep. I hope they include that feature in a future WordPress release.


I’m sure there’s still more room for improvement with the way I’ve done it, but I’ve managed to clean up my categories considerably, and applied tags much more consistently through all of my posts. It took a couple hours, but I hope it is worth it. I see a few benefits worth mentioning:

  • Users will have an easier time finding content that is relevant to their interests or related to something they came to the site to read.
  • It will increase the amount of time users spend using the site.
  • It will decrease the amount of time users waste on the site.
  • Better organization will convey to users that the site is of good quality.

The Type of Fortune That Never Misses

I’ve been having a rough time of it lately, at least judging what I’m normally accustomed to when it comes to my normally very convenient, easy, underappreciated life.

Just so you know, I’m typing this post one-handed. I’m doing about 30wpm now, which is pretty good, but I’m frustrated that it’s not the 90wpm that I normally do. Hahaha, no, that’s not why… I had a bicycle accident about three weeks ago, in which I broke my left humerus, just below the shoulder joint.

This was to have been my comeback ride — for about a month prior, I wasn’t able to ride my bicycle due to pain caused by an inflamed sciatic nerve, which was aggravated by an overly ambitious bike ride that caused me to have some lower back pain.

I normally don’t write about personal stuff in this blog, as the intent is for the web site is to be a professional portfolio and blog about software development, IT, and other things related to whatever it is I’m making my career out to be. But, as I have realized as a result of my experience in putting together my presentation to Notacon 8, I feel most complete when I do not separate my professional life from my personal life. I’m not very happy when I compartmentalize my life, working 9-5 just to earn a paycheck, and leaving work behind when I’m done with my day, and having the balance of the day left to pursue my personal interests. I want to make a unified life where nearly everything I do is geared toward achieving personal goals, and my professional goals align and merge with my personal goals to a great degree.

So this might not be the most technical of blog entries, but rest assured it ties in, as all aspects of my life tie in somehow to the work that I do and the experience and qualifications that enable me to do it.

I have been disappointed at these setbacks that have hampered me for the last two months. I had been enjoying bicycling with my friend Rachel, who had gotten me interested in hitting the road a few times a week, and had been feeling great as a result of the exercise. But it seems like every time I make an effort to get into shape, something happens that prevents me from continuing my program and I lose the progress I’d gained until I get my life in order enough to start again. This has happened countless times in my adult life. And then when I try to make my comeback after patiently waiting for the inflammation to subside enough to be active again, misfortune strikes again.

I got pretty depressed about the prospect of losing my whole summer to being sidelined with this stupid broken arm. But this lasted only a few days. The experience of mending is still ongoing, but so far has been very unlike what I might have expected. Although it is not something I would have wished for, I am the sort of person who delights in surprises, particularly when they have something to teach me. And I have come to the point where I realize that there have been things worth observing and reporting coming out of this experience.

So here’s what I’ve learned:

Broken bones don’t always hurt…. also, Pain has evolved to provide a GREAT User Experience.

When I fell off the bike, I didn’t hear or feel the bone break. I wasn’t quite stunned by the impact with the road, but it definitely staggered me, the way a body slam does. I knew almost immediately that there was something wrong with the arm, and didn’t want to try to use it. But the injury was numb initially. Not tingly numbness, but just not feeling much of anything at all numbness.

Before this happened to me, I would have expected any broken bone injury to be constantly acutely painful. I was surprised that in my case, it wasn’t. Perhaps it would have been for a worse injury than I sustained. I recognize that in my case, the type of fracture I had was perhaps one of the best possible ways to break a bone, if you had to break a bone. There was no displacement, no compound fracture, and a clean break. It only started to feel painful about 30-40 minutes on after the injury.

This gave me adequate time to do things that I needed to do in order to survive: pick myself up and get out of the street, and assess my condition, for example. Even when I did start to feel it, it wasn’t too bad unless I got jostled or bumped.

The pain was very useful in this way. It communicated to me what I needed to know, namely that I had an injury, that it was fairly serious, and then it largely got out of the way and let me take care of myself. If I did anything that might have made the trauma worse, the pain increased sharply, giving me immediate feedback that what I had done, or what had happened, was not something that I should allow to continue for any length of time.

From a User Experience perspective, I find this very instructive.

A few months ago, I watched a video of a talk entitled “Stealing From God!“, which in retrospect might have put me in the right frame of mind to pick up this lesson. The talk is worth watching in full, but in summary it’s about bio-mimesis as an inspiration to the design of technology.

When it comes to systems I might design in the future, I’ll definitely be taking this into account. Very often users complain about a shitty user experience by calling it “painful”. It’s a metaphor, but usually means tedious, repetitive, or time-wasting. Normally we designers who care about User Experience just want to eliminate any pain so that users will never have to experience it. I still think that this is a good goal. But I now think pain has something to tell us, and what it can tell us is important, and that a user experience designer can learn from it when s/he encounters it.

My advice is this: Don’t simply seek to avoid any and all pain. When you first experience “pain”, explore it. Find out what it is telling you, and if you’re the designer, ask yourself if that’s the right message, or what else or how else can you communicate more effectively. Delve into it, listen to it, appreciate it in its subtlety, learn from it. Once you understand the pain fully, then you can work effectively to avoid it altogether, or to make the “pain” as beneficial an experience as possible for the user.

It’s still best to avoid painful experiences if at all possible in the final design. But where “pain” is actually useful, it may be possible to incorporate it into the design in such a way that a user actually appreciates it. The pain experience that I had through breaking my arm was so much more useful than my typical negative experiences with computer software errors… in a strange way I find myself almost welcoming the experience with the arm — not that I would rather break my arm than experience a stupidly designed software error condition! But I can appreciate the beauty of the user experience that the bone fracture pain has given me much more than I can appreciate certain repetitive nags and modal dialogs with inadequate information and poor choices that I often see when using a computer.

Broken bones don’t need a cast to heal… and other unexpected things experience can teach you.

Common, seemingly familiar events can still surprise when they happen to you. Due to the location of the break, the ER couldn’t put me in a cast. Before this happened, I thought I pretty well knew what “the deal” is when you break something. I assumed walking into the ER that I’d be walking out with my torso half encased like a plaster or fiberglass cyborg, stuck in an immobilized position for months, and emerge from my chrysalis months later, atrophied and unable to move through my usual full range of motion. In my mind, broken bone == cast. Experience has taught me otherwise.

It turns out my experience will be nothing like that. They put me in a sling. Three weeks after the injury, my doctor tells me I’m doing well and the sling is now for comfort, not necessary to keep the arm immobilized. I can already use my arm to do light tasks. My effective strength is greatly diminished, and my range of motion is greatly restricted, but other than an ugly bruise, to look at me you wouldn’t think I had anything wrong with me, leastwise a broken bone.

As I’ve been healing, I noticed early on that if I ate a lot of protein, particularly red meat, the pain in the fracture site lessened. Often this effect was greater than the effect of the pain management drugs that the ER prescribed for me. I was surprised, but I understood immediately that it makes a great deal of sense for the body to be wired to work this way. My body needs more and different nutrients to mend a fractured bone than it normally needs, and the reward of reduced pain for eating the right (apparently) stuff is a great example of positive feedback. As a result of the reduced pain, I learned immediately that I needed to eat more of certain foods. And the pain would return if I hadn’t eaten recently enough. Again, more lessons to learn from the pain user experience. If I wasn’t paying attention to the pain, I might have just taken more pills to dull the pain. The pills, as it happen, dull my appetite, and would have created a negative feedback loop by not eating what I need in order to heal quickly and properly.

Instead, I’m amazed that three weeks after the injury I’m able to do so much, and am ready to begin physical therapy. I hear that it’s going to be painful. I’m acutely interested to learn what new messages I will be able to read in the pain to come.

People should try out being disabled. Especially user interface designers. But really, everyone.

To ensure that I eat well while I’m in this crucial healing period, and to keep myself from going stir crazy while I’m stuck at home (my doctor told me I shouldn’t drive, so I’ve been working remotely from home) without much human interaction, I sent out an open invitation to about sixty of my friends, asking them to pick a day to come over for dinner, which they would have to provide for me and they would also have to do the dishes afterward.

Surprisingly, a number of my friends were happy to take me up on this invitation. Tonight, my friend Jennifer came over with chinese food. Jennifer works with accessibility issues for disabled computer users, and is rather obsessed (I guess the polite term is passionate) about it. Perhaps because she’d come straight from work, perhaps also because she knows I’m an IT guy who is into design issues especially as they intersect with user experience issues, we ended up talking a lot about accessibility.

Jennifer clearly knows a ton about accessibility, way more than I do. I get what she says without trouble, but she’s way more familiar with the problem domain than I am. As a designer, I think it’s important to account for accessibility when designing the user experience.

Developer is a generic word — usually it means “programmer” but it also incorporates “designer.” And of course, developers are not always — in fact not often — good at both programming and good at design.

It’s hard enough for your average/mediocre programmer-developer to come up with a good UI to provide a high quality experience to the user because the average programmer-developer doesn’t know much about design, or usability. Developers who are decent at usability can design an OK user interface, but often forget about accessibility issues.

Actually, forget might be too strong a word. I sympathize with developers, so allow me to soften that a bit. They’re often resource constrained and unable to devote resources into providing accessibility. And because they seldom get to work on accessibility, they tend to not “get” accessibility.

For that reason, I think it’s a good idea for developers to “try out” various disabilities.

I’ve learned a great deal from not being able to use my off-arm at all for two weeks. I found I can do almost everything that I can normally do, but I have to take a different approach to it. It definitely slows me down. I have to think and plan actions and break them down into multiple steps that a one-armed person can accomplish. Not having the off-arm to assist my strong arm slows me down a lot more than you might think — two arms working together realizes synergy. I can carry a lot more with two arms together than I could with each arm doing its own thing. And the off-arm assists the strong arm in innumerable ways. If I needed to accommodate a one-armed person in some future project, I’d at least have some idea about what approach I’d take.

If I were to head a User Experience group, I think a great team building exercise would be to have each member try out being disabled while at work. Each person in the group would randomly select a disability, and then they would have to live it at least while at work, and I’d encourage them to continue living it at home. And not just for a few hours, or a day… say, for a week, or two. To really get an appreciation, you need to get to where you almost forget what it was like not to have the disability, but that would take a long time. A compromise “tryout time” will do well enough. During this time, they would observe carefully their experiences, and note where they found difficulty or obstacles, what approaches they took to deal with those obstacles, including asking for help. And they would be tasked to identify changes to their work environment that would make their disability easier for them to manage, and implement solutions. Needless to say, they would also have to do this for whatever projects they happen to be working on while disabled.

After going through that disability, the employee would put it down, and take on another. We’d have blindfolds, noise-cancelling ear protection, wheel chairs, arm and hand restraints, maybe special glasses to simulate colorblindness, whatever we could come up with. On a regular basis, employees would be encouraged to talk about their experiences as a “disabled” person and share what they are going through, what they are feeling, and especially how they are dealing with everything.

After the employee had gone through each disability that we could simulate, they would no longer be required to try them out, but could still revisit a disability if they wanted to go back and look for more insights. I have a feeling the best user experience guys would do so regularly.

This isn’t just a good idea for people who design the things that we use — it’s a great exercise for everyone.

For one, it makes you appreciate the things you can do but take for granted.

Second, it prepares you for the possibility of living with a disability at some point later in life if that should ever happen, as it commonly does for so many.

Lastly, it would help foment sympathy and caring for people with disabilities. So often disabled people aren’t thought about at all, and when we’re confronted with the need to accommodate their needs, too often people resent it, and and up resenting the person as well. This is terrible, but avoidable through the right experiences, learning, and appreciation.

In a way, I’m almost glad that I broke my arm. I still wish I hadn’t, but I’m grateful for what I’ve learned from it.