When it comes to usability testing, the best feedback you will ever get is from a new person who has never seen your software before. Once a person acquires a certain level of knowledge, they become accustom to little quirks and their expectations start to form around previous assumptions the software designer has made. An individual with a completely fresh perspective can often give the best feedback because they are unburdened with the knowledge of how your application works, and their perspective is the most similar to the market at large. Because the decision to adopt a product is made in a relatively short period of time, it's important to make that introductory usage period as intuitive as possible.
It's with that philosophy that I wrote up my description of my experience so far working with Code::Blocks and GCC/GDB. (Yes, I know they are separate things.) The most valuable feedback I can give is at the beginning of my usage. As I become more adept with these tools, my feedback will actually become less useful. I am unlikely to discover anything that hasn't been discussed many times over already, and I will lose sight of my original experience delving into the tools.
The reason I took the time to write a frank description of my experience so far, noobish mistakes included, is because I am interested in helping to identify potential friction in the user experience of Linux tools, so that the experience can be streamlined for new users.
My two chief complaints were that hooking into an external executable caused the debugger to pause inexplicably, and that GDB appeared to display variables values only in the current top-most function. Once you know to expect that pause, it's a simple matter to just always hit "continue" when the application starts, but that doesn't negate the value of my criticism; the fact remains that the application behaves in a way that is counterintuitive to what most programmers would expect. (I do not know if this is due to Code::Blocks or to GDB itself.)
As for the second issue, it was pointed out to me that you can actually right-click in the debugger and select "switch to frame" which is great. This must be an aspect of the Code::Blocks IDE. It's interesting that I actually did read the Code::Blocks wiki explanation of debugging. The first thing they talk about are watches, which is a little strange because I consider that functionality somewhat obscure. I rarely use watches in other debuggers. The next section is actually titled double-clicking in the callstack window and says "Note : when debugging, double-clicking on a frame in the "call stack" debug window does not automatically update the variables displayed in the "watches" debug window." That was the point where I stopped reading the documentation, which is unfortunate, because the next line gives you the secret you need to switch to the current frame.
So, to follow up on that post:
- It is likely that neither of my criticisms had to do with GDB itself, but rather the Code::Blocks interface with GDB.
- Just because you have documentation, that doesn't mean the user will read it. Documentation does not absolve your from the responsibility to make the user experience as frictionless as possible. Although sometimes it's unavoidable, I always consider it a minor failure if the user ever has to rely on documentation to use our tools.
I don't expect tools to be redesigned based on my personal experience, but if the developers notice a common pattern that feedback can be useful in eliminating friction in the user experience. Because for every one person who gets through each "friction point", ten will walk away. I like to think of it in terms of efficiency: If I invest ten hours making the user experience more intuitive, that improvement will result in tens of thousands of cumulative hours saved by my users. Therefore, identifying and improving little quirks in the user experience gives you a disproportionate benefit.
Building software that's powerful yet easy to use is really the heart of my design philosophy for Leadwerks. It involves many judgement calls, and the ability to view the application from the eyes of both the expert and the complete novice. But it's something I am oddly passionate about, and I really enjoy creating things that are able to satisfy these sometimes contradictory demands.
BTW, Code::Blocks has the absolute best target/build configuration dialog I have ever seen, by far. I wish Xcode looked like this.
seconds to go
Pledge $1 or moreYou selected
ENTHUSIAST: Help us take Linux gaming to the next level, and receive exclusive news and updates on Leadwerks developments by email.Estimated delivery:
Pledge $10 or moreYou selected
PENGUIN: We'll send you a sticker in the mail with our awesome logo on it. Put it on your computer, your skateboard, or even your dog.Estimated delivery:Ships within the US only
Pledge $25 or moreYou selected
INTERNATIONAL FAN: Due to popular request, we're now shipping two rewards in one, anywhere in the world! Get a Leadwerks T-Shirt for you AND a Leadwerks sticker for your computer, skateboard, or dog. (Only international orders will receive the sticker.)Estimated delivery:Add $16 USD to ship outside the US
Pledge $25 or moreYou selected
FAN: We will send you a stylish and comfortable Leadwerks T-Shirt in the mail.Estimated delivery:Ships within the US only
Pledge $50 or moreYou selected
INDIE BACKER: Receive Leadwerks for Linux "Indie Edition" when it's released. This allows you to program games with Lua. (We use LuaJIT to make it run fast.)Estimated delivery:
Pledge $100 or moreYou selected
BACKER: Receive Leadwerks for Linux when it's released. This allows you to program games with C++ and Lua.Estimated delivery:
Pledge $200 or moreYou selected
PRO BACKER: Receive Leadwerks for Linux when it's released. This allows you to program games with C++ and Lua. You will also receive Leadwerks for Windows and Mac.Estimated delivery:
Pledge $500 or moreYou selected
SUPER BACKER: Receive Leadwerks for Linux when it's released. This allows you to program games with C++ and Lua. You will also receive Leadwerks for Windows and Mac. You'll get early access to the beta of Linux for Leadwerks, plus a T-Shirt and sticker will be mailed to your home.Estimated delivery:
Pledge $800 or moreYou selected
INDIE TEAM: Get a team license with support for five seats for your team's next project. You will receive a registration key with support for five concurrent installations (on Linux, Mac, or Windows), and five forum accounts you can assign to your team members, plus access to the Leadwerks 3.1 beta.Estimated delivery:
Pledge $4,200 or moreYou selected
SITE LICENSE: Get a site license for your company's next project. You will receive a registration key with support for concurrent installations (on Linux, Mac, or Windows) within your company, and forum accounts you can assign to your employees, plus access to the Leadwerks 3.1 beta. The site license supports up to 30 installations.Estimated delivery:
Pledge $10,000 or moreYou selected
0 backers Limited (2 left of 2)
ULTRA BACKER: Leadwerks founder and GDC speaker Josh Klint will code anything you want full-time for a week. Communication will be conducted over Skype in the English language. Does not include proprietary knowledge and techniques. Timing can be anywhere in the next 12 months except the month of March 2014. Four weeks notice are required for dates after August 2013.Estimated delivery:
- (45 days)