Hi, DarkWyrm wrote:
It's passable, but I have a suggestion (piggybacking off Waldemar's) that I think might be better for organization, but I'll leave the final verdict to the rest of you. :-) I'll give my best attempt at ASCII art and explain.
You could place the destination beside the type to provide a little visual balance. Placing them closer together also helps associate them logically. The size for each install type could be included in the label so that the user could see ahead of time how big the particular install type is before he selects an item. It also should be less work, which is also nice. :) Anyway, something to think about. TTFN
This ASCII art is a bit crooked here, so it's hard for me to exactly see the details of this layout :). Anyway, here's what I think:
I've placed the install destination separate from the install type since in most cases it's not quite dependent on the chosen profile. And having too much menu fields in one place can 'scare' away users by making the application look more complex IMO. Having the size of each install in the selection is a great idea. I don't think there would be problems with this issue too. The BMenuField adjusts its size to the width of the selected label by default, if not stated otherwise. In this case, will we still need the "Size:" label positioned somewhere else?
As for the scroller in the description field - wouldn't it be better to include it only if needed? I mean, the field size would depend on the description size (auto resize), but when it reaches some value, we make it scrollable. I think this would look a bit better. Or maybe that's what you had in mind yourself?
-- Best regards, Łukasz 'Sil2100' Zemczak