Thinking Inside the Jira Text Box

If you work in or around software development, you might be familiar with Atlassian’s Jira. It’s one of the more popular project management applications out there, especially if you work in a Scrum or Kanban-style agile environment. It’s not just for software, of course—I know IT departments and salespeople that use Jira for tracking task progress. Nothing’s stopping you from using Jira for shepherding your comic book creation process, other than its incredible cost and administrative overhead. I’m a relatively new user to Jira, with a year’s worth of experience under my belt. Before that I used Redmine, Bugzilla, and proprietary bug tracking systems. It’s safe to say that I have some experience with issue tracking platforms.

When I started a new job one year ago, a friend of mine warned me about Jira. He’d gripe about how terrible Jira was and how he hated it. I sort of dismissed his complaints, as he hadn’t been suffering under the terrible weight of Redmine, let alone an inscrutable proprietary system. I thought anything had to be better than the terrible proprietary stuff I endured in the past. So I was willing to give Jira an honest shot. And you know what? I don’t hate it. But I don’t really like it, either, and it’s because it’s a bloated Javascript nightmare. There’s dozens of papercuts in its user experience that gradually scar you over time. And just like a papercut, these flaws aren’t going to kill you—but they’ll slow you down and make you so very angry.

One of the most irritating is some user interface designer’s obsession with dead space. Not white space, that stuff is useful, though sometimes abused. No, I’m talking dead space, which distracts the user and actively interferes with your usage of the product. Take something as simple as a text box. You’d think people would know how to make a text box work, but this one must have slipped by the folks at Atlassian. If you have an instance of Jira, go ahead and open up the new ticket window. You’re looking for a rich text text box in that window, like the one for a description. Here’s an image if you don’t have it in front of you.

So if you saw this text box, where do you think you would click on it to start typing? Would it be inside the outlined area of the text box? Maybe the white space below the toolbar. Both are sensible guesses, but before you give me your answer, step back and think about the question. Remember your past experience with text boxes. Your instinct is that you can click anywhere inside the boundaries and start typing. That’s a good example of Fitt’s Law: “The time to acquire a target is a function of the distance to and size of the target.” Or in other terms, a bigger target is easier to hit. I’m already ignoring several problems in this box, like how there’s no clear separators between the toolbar and the editable text area, or the fact that the buttons aren’t even buttons. For the sake of this post we’ll grant these now common-day “cleanliness” design touches, even though I loathe them. But that’s a rant for another day, so back to the subject at hand. Let’s get back to the original question: where do you click to start typing?

If you answered “anywhere in the text box,” congratulations: you’re wrong. It’s not your fault; you’ve been conditioned to click on the box and start typing since you started using a computer. After all, text boxes have been around since the dawn of the GUI, and they’ve generally worked the same way for decades. It’s a fair and reasonable assumption to make. But that assumption is a trap when it comes to Jira, because you have to click in a very specific region of the text box to start typing. There’s no hint where that region is, other than when your cursor transforms into the I-bar. Take a look at this GIF.

Notice where the cursor transforms from the normal pointer to the I-bar. You can only enter text when the cursor enters this invisible zone that takes up a fraction of the text box! There’s no hint or clue for where this zone is—you have to carefully watch the cursor to know where to type. What looks like a big, appealing target is really just a tiny, hard to click strip.

Earlier I called that area outside the magic zone “dead space.” It’s dead because it does nothing inside the box. That doesn’t mean it lacks purpose—a little bit of white space to separate your text from the boundaries makes it easier to read. From a visual design standpoint, that’s a good thing. But most user experience designers would tell the programmers to make the white space a clickable area! Atlassian’s lack of care inadvertently tricked the user and made their life just a little harder.

Compare this to another product most of us have to endure: Slack. There’s a lot of criticisms I can lob at Slack, but at least they managed to make a functional message box. Compare Slack’s behavior when you click in the message box’s white space.

Slack text box

Clicking anywhere in the text box that isn’t a button makes it ready for text input. There’s a few things I could complain about here—namely, buttons should look like buttons, and I’m not really a fan of the toolbar sandwich. But what makes the toolbar sandwich tolerable is that clicking any place that isn’t a button puts the focus on text entry. The penalty for missing or being a little sloppy isn’t harsh. As soon as your cursor goes over the box, it changes to the I-bar, making it immediately obvious that you can type after clicking. It’s a nice, big target that’s hard to miss. It’s a good example of obeying Fitt’s Law. It’s rare that I tell some other app to be more like Slack, but in this case Jira could be a lot more like Slack.

Here’s the real kicker, though: Atlassian manages to do this correctly in other parts of Jira! For example, hot zones for comment text fields behave properly. If you create a ticket that has no text in its Description, then edit the ticket, you can click anywhere in the description text box to activate the cursor. There’s even a nice little horizontal line separating the toolbar area from the text box itself!

Editing an already created issue in Jira

It’s these kinds of inconsistencies that really grind users’ gears. A user expects that their applications will work consistently no matter what mode they’re in. Larry Tesler had a NOMODES license plate for a reason. Our job as user experience designers is to eliminate friction and make our users’ lives easier. They shouldn’t have to think about where to click in a text box to start typing. Atlassian, fix your freakin’ text boxes.

Commodore 64 Highlights - Chips and Bits

As a followup to Computers of Significant History Part One, here’s some of my favorite Commodore 64 software and doodads, in no particular order:

The Print Shop

Partially responsible for me getting into computer graphics.

Partially responsible for me getting into computer graphics.

I’ve written a very long history of The Print Shop and its influence on computing in an episode of Macinography. The Print Shop is a contender for one of the top ten most influential pieces of eight-bit software, and I spent a lot of time making birthday cards and school banners with it.

Castle Wolfenstein

I’m still playing Wolfenstein games to this day. While Wolfenstein 3D and its follow-ups are very different from Silas Warner’s Castle Wolfenstein, this game cemented my ongoing love for the series at a very young age. Its control scheme was somewhat clunky, especially if you had the wrong kind of joystick, but it’s still mostly playable. The game also taught me my first speedrunning trick—you can glitch doors that are near a wall to short-circuit the normal escape route. As far as the plot and bad guys, I had no context for the game’s setting at the time. No one’s teaching a six year old about Nazis. It wasn’t until years later, when Wolfenstein 3D was available on the Super Nintendo, that I started learning about the series’ World War II inspirations.

Kwik-Write!

I used a lot of word processors on the C64, but Kwik-Write is the most memorable because it’s what I used to craft my childhood letters to Nintendo. To their credit, the game counselors at Nintendo answered every single one of them. Alas, all those letters—both to and from Nintendo—are long gone. It was more like a text editor than more powerful WYSIWYG word processors. It let me type words and send them to the printer, and that’s all I wanted. As a grownup, I’d find its limited formatting and lack of spell check infuriating. At least it had copy and paste.

GEOS

Ah, GEOS. Rarely has so much been made with so little power.

Ah, GEOS. Rarely has so much been made with so little power.

The only application in GEOS that I used for any real amount of time was GeoWrite. Since it was a WYSIWYG word processor, it was much more powerful than programs like Kwik-Write or Bank Street Writer, but it was glacially slow. By the time I had learned about fonts and good typography, I had access to better word processing tools at school, like Microsoft Word. But I still wanted to write things at home, and I tried really hard to make GeoWrite my main word processor. The last thing I ever wrote in GeoWrite was an essay for sixth grade history class, about the Rosetta Stone. I only remember this because it was the same day as the debut of the classic Simpsons episode Summer of 4 Ft. 2—May 19, 1996. I took all day slowly writing the essay, in part because I was a procrastinating thirteen-year-old, and in part because GeoWrite was just so sluggish. I barely finished it in time to catch the episode premiere. From that point forward, any papers or correspondence would be written in something more modern, even if it meant staying after school to write them on a Macintosh. In retrospect, I appreciate the ingenuity required to make a GUI that could run on a C64.

Ghetto Blaster

Here’s another game whose context was completely lost on me as a young child. What can I say, I was five and had no idea about the musical references. All I knew was that it was “the boom box game.” I returned to it over the years, getting better and better at the mechanics, but I never actually finished it. Turns out that was for the best, since the ending’s terrible. Thank God it had one of the best soundtracks ever written for the SID chip—the main theme was a banger. The graphics are very nice too, considering the system’s limitations. I’d take a modern remake of this in a heartbeat.

Tenth Frame and Leader Board

I’m lumping both of these Access Software titles together even though they probably deserve their own entries. They have similar graphical and play styles. These were my dad’s favorite games on the C64. I enjoyed them a lot too—the graphics in Leader Board (and its sequel) were excellent for the time, and there was something fun about printing out your scorecard after a game of bowling in Tenth Frame. All modern golf games owe a debt to Leader Board, which pioneered the dual-meter stroke power system.

Epyx and Quickshot Joysticks

In our household, we had two kinds of joysticks. One was the Epyx 500XJ, and the other was the Spectravideo QuickShot II. The former was designed to be handheld, while the latter attached to the desk via suction cups. Some games just didn’t play well with the Epyx because it required two hands—the aforementioned Castle Wolfenstein was a non-starter—but I don’t think there was anything better for rapid-fire back-and-forth movements required in some titles like Summer Games. The Quickshot wasn’t good for twitchy games, thanks to the longer movements required to engage its microswitches. It had one helpful advantage if you needed to use the keyboard at the same time—the suction cups kept it in one place. Nowadays these joysticks would annoy me due to their terrible build quality. Neither held a candle to an NES pad for responsiveness or toughness.

If you haven’t checked it out already, make sure to read my C64 edition of Computers of Significant History for more Commodore fun..