GUI Design Matters

There's a new site in town. It's called GameInternals. I love stories about how things work. I can spend hours reading about algorithms and how someone thought of them. If you do, too, them you may be interested in reading Coders at Work, but I'm getting sidetracked.

The current post of GameInternals is a story about Final Fantasy X's sphere grid system. The game used to boast how your characters could be non-linearly leveled up. Although I encourage you to read the whole article, the sphere grid layout is what is relevant to this post. The next two images are mirrored from the linked section.

See how non-linear it is? There are all sorts of curves and paths branching out all over the place.

But what if you really took a good look at the content?

The grid looks pretty linear now. If you take the game's rules into account, such as not being able to unlock most of the locks until near the end of the game, the grid becomes extremely linear. The way the grid is presented makes the player think that the grid isn't linear. In other words the leveling GUI is obfuscated; it takes something simple and makes it complicated and confusing to hide how simple it truly is.

Obfuscation

"Magic" math problems used go all around the Internet during the late 90's. You may recognize it. (Math problem source)

1. Select a number - no matter how low or high.
2. Add 5 to the number you chose.
3. Double the number in your head.
4. Subtract 4 from the new number.
5. Divide that number by 2.
6. Subtract the original number from the new number you now have.
7. The end result is 3 and will be 3 for any number you choose.

When you break the problem down and remove the obfuscation:

Naturally, the answer is always three. Your number never mattered in the first place.

In the corporate world, some people obfuscate their work to make themselves seem important for job security, their ego, or other reasons.

Naturally, this leads in to a terrible project I once worked on at a company that I'll name Anacron.

The Worst "Simple" GUI Screen I Have Ever Seen

A test engineering lead who I'll call Mickey once called me in to help rewrite a GUI. The test engineers were having trouble diagnosing a problem in one Anacron's prototype devices. They were certain that the communications protocol worked, but their test no longer contained fake data. The tests now required data verification, and they were having trouble checking for bit errors and other data corruption.

I wondered why they couldn't tell. Then, I saw their interface. I've put together a mock up here. The data is just my hexadecimal lorem ipsum.

The worst part is that I added about 20 data fields on this. The real one had over 70!

There are so many things wrong with this. Why are the data fields so misaligned? Why are there more in one column than the other? Why is one covered? Why is there so much extra space on the bottom and right? Why must I uncheck "Z-High" when I ask for Status 2? What is "Z-High," anyway? Why is that check box separated by a bunch of minus signs? Are "Turn On" and "Turn Off" supposed to be radio buttons? Can they be checked simultaneously? Why is the window called "Form?" Actually, all of their GUIs are called "Form."

The monitor was small, so I tried resizing the window.

All of this led me to a few possible conclusions.

• The developer was pulled off the project before he could finish it.
• The developer was never given a proper specification.
• The developer had never used the required programming environment before.
• The developer was an intern.
• The developer was a moron.

After staring at the GUI for a little while in disbelief, Mickey asked me if I could help. I looked up at him. "What the fuck happened here?" I uttered, forgetting to switch my vocal filter to its "politically correct" setting in my bewilderment.

Mickey chuckled slightly. "Do you see these fields here?" He pointed in the general area of the GUI. "Whenever we send a message across, the data shows up as all F's or all 0's. Sometimes we get a random 3 thrown in there. We were hoping if you can make sure it's not a software issue before we start burning up FPGAs." (An FPGA are a type of microchip. Every attempt at a bug fix requires a new one. They cost hundreds of dollars each, and it takes hours to switch which chip is on the circuit board.)

"Right... OK. I get that," I said a little flustered, "but, I mean what happened to your GUI? How do you even read this thing?"

"Oh, you get used to it. Kang over there wrote the code if you want to ask him how it works." Mickey nodded over toward a man on the other side of the room talking to a few other people about something on the whiteboard.

Mickey introduced me to Kang and the rest of the group. He explained that I'm the software on loan from another department and that I'll be fixing up the GUI for them. Mickey wanted everyone to give me what I needed as fast as possible. "He's from [my department], so his time is at a premium," Mickey explained. At Anacron one department pays another department huge amounts of money to borrow people from each other; the engineer doesn't get any of that money, though. It's just the way the corporation does things.

I made plans to meet up with everyone after lunch.

Lunch

While I was sitting in the cafeteria with a horribly bad "sandwich" I bought, I thought that the sandwich tasted like how that GUI looked. It got me thinking:

• The developer was pulled off the project before he could finish it.

The developer was still on the project. If they are using this every day, why wouldn't he at least make all of the text boxes visible?

• The developer was never given a proper specification.

This may have been completely possible at the time. Things sometimes have to be developed before everything else is fully decided. But again, why would it be displayed so haphazardly?

• The developer had never used the required programming environment before.

Although I didn't really dissect the source too much yet, it was clear that Kang knew something of C/C++. He parsed the protocol well, and he used multi-threading and event handling to update the GUI from a separate communication thread. That's not very basic stuff.

• The developer was an intern.

Kang was a senior staff member.

• The developer was a moron.

So far this seems like the most likely point.

I sighed and resigned myself having to deal with a moron who wouldn't budge on anything. I've been here before. It's never fun.

Say Hello to My Non-Engineering Friend

I met up with Kang and the group. I didn't want to cause a ruckus, so I decided not to ask about the current GUI. "So, what do you need the GUI to do?"

"We just need to request status messages and parse the responses," one engineer said. "It would be nice if we can see what the fields are, too."

I wrote down everyone's thoughts. I told everyone that I wouldn't be able to do everything with the amount of time I had, but I'd try to add what I could. Kang never spoke. He just laid back in his chair aloofly. After the meeting, I met up with Kang in his cubicle to ask him for a copy of the protocol specification.

"I don't have your version of Visual Studio on my PC," I explained. "If it's quick, do you care if I rewrite the GUI quick in Qt?"

Kang handed me a stack of papers. "I really don't care."

"Sorry. I just didn't want to kill your ability to modify it. I don't know what IDEs you have installed."

"I don't have any. I'm not in software."

• The developer was a moron.
• It's not the "developer's" job.

Why didn't I think of that? After talking a little more, I found out that he was in charge of all of the documentation of the project. He didn't know a lot about what he was reading; he checked each document against a checklist for certifications. When his workload was lightening up near the holidays, the group needed a GUI. Mickey scheduled a two-day block for creating the GUI. Kang mentioned that he knew a little C++, and two days wouldn't be enough.

Mickey heard Kang as I know C++ and assigned the project to Kang, complete with two day schedule. This changed Kang's workload from "getting light before the holidays" to "requires unpaid overtime." Understandably, Kang stopped caring about his work and wrote the bare minimum to claim that it worked. Most of the code was copied and pasted from the Web. I think Kang wanted the GUI to say, "Stop asking me to do this crap." Apparently, Mickey had a bunch of ideas to give Kang, believing that Kang didn't have enough to do as a multi-project librarian.

I think everyone's been burned like this before.

The New GUI

I displayed both the raw data and the data divided into each field.

If the form is resized, everything inside resizes accordingly.

"Z-High" meant "high impedance" mode. It was supposed to turn a pin on the device into an input rather than an output. Any other setting caused a short circuit. Now, error checking is done, and the form automatically disables options as needed.

I also added a feature that allows the user to click a field, and the field's position in the raw stream highlights.

I did all this because I tried to think, "If I were testing this, what would help me?" The highlighting feature wasn't suggested, but everyone thought it was brilliant. I'd end up regretting it.

I Don't Learn From Other People's Mistakes...

...or my own for that matter. I went above and beyond everyone's expectations. That was a terrible decision. Now everyone requests for my help and expects the same attention to detail. In this case I understood RS-232 well. When I was asked to improve other front-ends i.e. accounting software, I had no idea how to think like an accountant.

I've always believed that I should do my best to make the best product I could. Years in the corporate world have taught me what Kang tried to tell me: don't do that. If you work fast, you will only be rewarded with more work and insanely high expectations^{gui-design-matters-fn1}. If you ever get stuck on something, 5 projects will be delayed rather than 1 or 2. Management will badger you, and the engineers you delay will resent you. Take your time, do it right, and do only what the requirements state. There's always a chance that your "great" idea for a feature will go against what the group really wants, and it may put you behind the already unrealistic schedule.

As for the original problem, the device baud rate was 300 bps. Kang's copy and pasted code was set for 9600 bps. I found out the speed from the communication chip data sheet and our jumper configuration. People were flabbergasted that a "software guy" knew how to read a data sheet and a schematic^{gui-design-matters-fn2}. For a few months after that, I had to debug hardware on top of my actual job. I never learn.

I feel your pain, Kang.

^{gui-design-matters-fn1} I hope that this is only true for Anacron.

^{gui-design-matters-fn2} I'm proud to have finally used the word "flabbergasted" in a serious context.