Say I've got an app with a laughably awful GUI setup screen. I could fit 90% of the properties I need to let the user set up with one of those boxes that look like
▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪ ▪height ▪ 1.3in ▪ ▪width ▪ 3.0in ▪ ▪top ▪ 3.2in ▪ ▪left ▪ 2.3in ▪ ▪caption ▪ 'awesome'▪ ▪order ▪ 3rd ▪ ▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪
But, are these really good and usable or do I just assume they are because as a programmer I use them all the time in my IDE?
With a fair amount of attention to detail, you could make it usable. However if you have many nested objects it'll soon get unwieldy. I'd look at a re-design of your current GUI. How about a screenshot?
That really is going to depend on the type of application being created and the type of users accessing it.
If they are technical types and there is some analysis going on with the application, I can see that fitting in quite nicely. If the application is a little more action or workflow oriented, I'm not sure how well this would fit in.
Again, it all depends on what is going to give the end user the most productivity.
Ideally, you'll have good defaults, so the user won't need to change anything... But if that's unavoidable, and you're smart about it, I think it could be done.
A few tips:
You probably can't do this with a default control... So write your own. It will take some time, but IMHO it's worth it.
The number of properties here is a relevant factor.
My gut feel is that four or five may be forgivable. Seven may be pushing it.
My experience is that when it gets to dozens or hundreds, it becomes unworkable. People can no longer simply read all the entries to find the feature they want, without secret recipes that get passed around from experienced user to experienced user.
As mainly a user, I use these sometimes with applications with configuration screens, but after a certain number of them (usually around 5 or 6), I start to get the feeling that the program is poorly made.
What kind of bicycle do you ride? One-speed Cruiser? Easy! An old 10-speed clunker with 6 gears that work? Basically usable. 21-speeds take greater than average skill, and then most folks use a subset. 80-speeds? Hmmm.
A critical item that makes it much more user friendly is categories. As Oddthinkingnoted in his response, four or five items is about right.
Although, you can get away with more as long as you group them very concisely and carefully. For instance, height and width can and should be grouped together, because whenever users specify one they are used to specify the other.
If your categories are very well laid out and have only four to five items in them, then your setup screen can contain a lot more options without seeming confusing, because the titles tell them what kind of information they need at their disposal before they attempt that section.
it's certainly usable.
For simple concepts it is adequate. I find that I'm often trying to get a user to input something he doesn't understand. At times, it's been data I don't understand.
Then I feel it's REALLY IMPORTANT to get a good understanding of exactly what your data represents, and then rather than ask for a table of numbers, find a way to inform your user of what he's entering at the same time as he's entering it.
For instance, in the very simple example you give (pretend it's complicated), you could actually display a picture of a box on the screen as well as the data. As you input the data, the box may shift a little or visibly resize itself.
You could then further this by allowing them to drag the edges of the box and have the drag update the fields.
Although this is too simple an example to warrant that kind of effort, I've had a lot of success--for instance setting up a circuit where you must contain a DS0 in a group of DS0s inside a DS1 or T1 which is in a bundle of T1s in an OC-3 which is on one of 3 channels on a fiber loop.
It was actually much more complicated than that and took 10 engineers 2 days to document correctly once they figured out what I was asking. At one point we had 4 white boards full of permutations, then we refactored them down to a single (very crowded) piece of paper.
Once I could understand that, I made a GREAT UI for it.
Also that paper became a marketing document itself--they had never described what their box actually does before (and that's exactly what their marketing manager said when he looked at the paper).
So the shorter take-away version: For anything that isn't obvious, try to fully analyze and comprehend the business problem behind the data you are presenting to/requesting from the customer. When you grok it, figure out exactly what caused the break-through and turn it into a GUI.