Exactly Xolatron. The image you posted (which if you could change to .jpg extension rather than .JPG so I can view using explorer), would be a nightmare for anyone who doesn't understand most of whats going on.
The idea of a good design is to break everything down into layers of what sort of person would be using it. Also grouping things with understandable names.
Effectively you end up with 3 levels of competance.
- None
- Literate / Know-it-All
- Professional
Most people fall into Cat2, but a reasonably large number will also be in Cat1. So you have to cater for this.
The best way to achieve this is actually to have 2 seperate Properties Areas for your project.
Area 1) This area is the quick glance version. Your putting only the key things people will want to change here.
Window Size, Window Title, Fullscreen|Windowed|FullscreenEx
As far as the Executable Type goes, what you want that to be is a drop-down on the Build Toolbar. This would be setup similar to Visual Studio, so the build-types would be Pre-Set project building blocks. The advanced option elsewhere to create your own Build-Type based on the base types is something that would be nice but only a few users would end up using. Hense why your hiding it somewhere out of the way.
As you have it your properties Window itself has just lost most of what it has from normal. So this can now be tucked away underneath the project settings as a small sub-window.
Another point to make is the context of it. For standard programming the context doesn't matter too much, although having it to fill a UDT would be very helpful so that you just fill in the values and it put in the actual code. However for a visual integration of BlueGUI, etc. then you will want to make sure that the properties are contextual to the Window/Control your working on.
As for the main properties, provide users with a number of ways to get to it (right-click -> properties on the solution, or via the menu Project -> Properties). In any case you choose make sure that either the Pop-up Window or Tab is also designed with the user abilities in mind.
It's a common and very good design to use Side-Tabs for this. So they act like a sub-menu style system. Grouping Resources (media), Build Information, Application Information, etc.
Is an essential part of making it useable.
As far as the media itself goes, I would also recommend making the Media and Files using a Tree Based System. However rather than simply showing what you have, layer it.
As I keep repeating, making more manageable groups is a key element to providing a better interface.
Having
File1.dba
File2.dba
Texture1.dds
Model1.dbo
etc.. isn't as easy to ready and navigate as
Solution
|-------Source
|-------|-----File1
|-------|-----File2
|-------Images
|-------|-----Texture1
|-------Mesh
|-------|-----Model1
Also using Icons to represent what they are is another plus.
Further more the reason I'd suggest keeping the Media and Source seperate, is because for Media what you can do is provide an overview of what is in the project. It could also be noted which is included as part of the project build and which will be simply linked from the Hard Disk.
For the Source File, letting the user know which References (DLLs) are being used and the Size would be a very helpful situation.
It would also help users to understand which Functions/UDT/Variables/Arrays are based in each file.
Of course again I would also have another Tree contextual to the source that was currently open so I could quickly search for things.
Keeping everything seperate is a good idea, but also don't be afraid to make more than one method to achieve the same goal. People will apprieciate this given not everyone likes doing things the same way.
