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.