Methodology, or, “I wonder how long this kicker can be without kicking me out of the kicker area for the title of this post”. Evidently pretty long.

Designing for Edge Cases

Ever wonder how long you can make a photo caption on Medium?

This illustration was created by Matt Carlson and it’s a metaphor for “edge cases” because the car is parked at the edge of a cliff. Get it?! I promise that you’ll actually learn a thing or two in this otherwise very wordy article. I’ve already learned a couple of things about photo captions in the past two sentences. For one, the text isn’t a hex grey. It’s actually true black at 60% transparency. I figured this out when I tried to add an emoji and it looked ghostly, which comes in handy if you’re actually wanting your emoji to look ghostly. Like this ghost: 👻. What I do find most unfortunate is the fact that you can’t add line breaks inside of a caption. To Medium’s credit, this makes sense. Why would you ever have a photo caption that required line breaks? Surely users won’t try to add line breaks in their photo captions, right? That said, they deserve special applause for protecting photo captions from new lines, because I was kicked out of this caption no fewer than six times each time I attempted to add a line break. Bravo! What remains to be seen is how long I can keep typing until either a) I run out of space or b) I run out of things to say. I can’t think of a realistic reason that Medium would limit the length of a photo caption because, I mean who knows, maybe I have a lot to say about a photo? I don’t think it’s their responsibility to tell me when to stop typing. So far so good, though. Oh another thing, you can do some very basic text formatting inside of this caption. And by very basic, I mean bolding and hyperlinking. No italics here. Really the only way you can add a splash of color is by tagging someone. Like Medium Engineering. Way to go guys. You really knocked it out of the park in QA and testing! I think this is an important lesson for designers, developers, and product managers. “The user will never do that!” Truth is…they will. Annoying users like me will try just about everything. And the worst part about it? Usually they’re not trying to be malicious or nefarious. They’re just using your product however they see fit, and it’s your responsibility to ensure that either a) whatever they’re trying to do still works, and b) you guide them back toward best practice. If you ever use Google Inbox and try to email yourself a reminder, a soft guiding hand will tell you about their “Reminders” feature, which is more of a To Do list of sorts than a usual email reminder. Such a delightful little message! Way to go Google Developers. Side note, I discovered something new about photo captions. If you select the image and press Command+K, you can hyperlink the actual image. That’s nice, but we probably already knew that. However, if you have a hyperlinked image then try to hyperlink some text inside of the caption, it won’t work! You have to remove the hyperlink from the image by pressing Command+K again, then it will allow you to hyperlink text in the caption. How odd! One tiny little ProTip™…if you’re trying to source an image from some place like Dribbble, just copy the “by [author]” link at the top of the Dribbble image and paste it into your article. Medium will smartly carry the hyperlink with it and past it as hyperlinked text. It’s pretty convenient when your article has lots of links. So anyway, back to designing for edge cases. There’s a time and a place for it. If you’re doing initial concept designs for a client, either internally or externally, you shouldn’t be overly concerned with supporting edge cases. That doesn’t mean you should ignore them completely, but don’t sweat it in the beginning. You’ll end up sacrificing good design for use cases that may or may not even ever occur, and it’s usually fairly easy to account for these later during the production design phase. Developers and product managers love to bring up edge cases. This is great! Someone has to consider these. Just make sure they’re all logged so that you can test them later. One other note about these. Don’t feel like you have to physically design for all of these edge cases. Sometimes a two-sentence explanation is all a developer needs to understand how to handle such behavior(s). Don’t waste your time designing 25 edge case screens unless they actually ask to see them. You’ll save yourself a lot of time and headache that way. The most important thing to know about edge cases is to be realistic and to categorically organize edge cases into groups. If you’re not planning on internationalizing your product anytime soon, don’t stress over 24-letter German words or supporting Japanese characters. I could literally come up with a thousand different edge cases for Medium’s simplistic content editor, but they wouldn’t be all that realistic or useful. Let’s pretend, however, that you could design for every single edge case. Is that actually a good thing? It’s not! You’re just enabling users to do things in your product that aren’t best practice. If it’s not the right way to do something, then don’t support it. That’s why bowling alleys have bumpers. You start learning the game with bumpers covering the gutters until you get good enough to roll ball straight down the lane. Put bumpers in your product. Users will try all kinds of strange, weird, and wonderful things, and it’s up to you to keep them headed in a straight line. This concludes my photo caption article.

Medium, you pass the test.*

*EDIT: Mostly. As Daniel Newman points out, caption text doesn’t factor into read time, so at the time of editing, this article is marked as having a “1 minute” read time! Not sure about that 😋 It DOES give me a really great read ratio, though:

Realistically, 80% of people probably “noped” right out of this article.

When I’m not writing long photo caption articles, I’m working on Sketch design tools at UX Power Tools to make you a better, more efficient designer.

Follow UX Power Tools on Twitter
Follow me on Twitter