This is a critique of the XULMaker UI. I find this project really interesting and quite a lot further along in it's development than I had imagined. Thus, I definitely want it to succeed. But I find the UI very rough. It really needs to be simplified, or 'Firebirdified'.
I'm not sure exactly of all of the things that are planned for XULMaker. Some of the suggestions below may already be planned.
I see XULMaker as an application which new developers will use to learn XUL and build simple applications. To that end, it needs to be as simple as possible. Experienced XUL developers probably won't use the editor often, as they would edit the files by hand.
Thus, the XULMaker UI needs to be very simple and not require the user to have any knowledge of XUL in order to use it. Also, since it is written in XUL itself, users should be wowed by how powerful XUL is for making applications. Neither of these are possible with the current UI as it is far too complicated.
The key is that XULMaker should be designed for novice users, not experts.
The first thing I noticed is that there were rather a lot of toolbars on the screen. The View menu lists seven toolbars that can be shown or hidden. That's six toolbars too many. There only needs to be one toolbar. The rest of the toolbars aren't necessary and the functionality they provide can be done in other simpler ways.
The first two toolbars provide the various lists of elements that can be placed. Why are there two separate ones? They both seem to serve the same purpose. I assume the first one is meant to be customizable by the user. In that case, it should just be the first tab on the other toolbar. (labeled Common Items or something similar.) The labels on the tabbed toolbar should be capitalized (as all the labels in the UI should be). Labels shouldn't have abbreviations such as 'app toolbox'. XUL doesn't have forms; I'd rename 'form controls'. The buttons on the 'other' tab can easily be moved into the other panels.
A final tab could be added for User Defined elements, which could be elements with an XBL binding. The user could Import an XBL file and have all bindings in it included.
I don't understand most of the options on the Mode toolbar, even after reading the Help. The only one I really understand is 'add location'. Why give the user this choice? What if I wanted to add an element somewhere between first and last? This option isn't necessary. If the user really wanted to add an element at the beginning, he can move it there later. At the very least, put it as a checkable item on the menu. One wouldn't need to change this often anyway.
Although I can't be sure, I'm pretty sure the other Mode settings are unneccesary as well. They seem to modify things about the element and attribute toolbars. Since these toolbars aren't necessary either, the modes are hardly needed. They use way too much space and provide minimal value.
The three element and attribute toolbars seem to be a way to create elements and set attributes on them. This functionality is already provided by the much more logical sidebar and the tabbed toolbar. An application should always avoid having multiple ways to do the same thing presented to the user.
The toolbars seem to have text that is written like a tag. For instance:
<button id="button" [ ] = " [ ] " >
This is very confusing. Novice users won't know the syntax and this provides no benefit. The help file suggests that the drop-downs will be prepopulated in some way. This is fine but the sidebar should be populated anyway.
The tabbed element toolbar already provides a means to add elements. I counted at least three other ways to add elements -- the element toolbar, the element sidebar and the Edit menu. Definitely remove the element toolbar. The 'make new / keep current' option (is this the same as the Mode toolbar choice?) is definitely unnecessary. There is no reason to clutter up the UI to save the user an occasional click. In fact, it wastes more time, as the user has to think what they need to choose whenever they add an element.
Remember, every choice you give to the user directly (such as, in the main UI) adds more time the user has to spend thinking about what to choose. Far simpler to pick for the user and let them adjust later if necessary.
I assume the Trace toolbar is for debugging purposes. Fine, I'll ignore that.
The tab labels on the main content 'View' area should be capitalized. There isn't really a need for 'Prettify' or 'Update' buttons. That should be done automatically when switching tabs. After all, why would a user want the default to be Make Ugly Code? They won't. Actually, the 'Prettify' option should be on the menu so the user can choose it if they edited the source manually.
I assume the 'browser view' isn't updating yet, so I'll ignore that for now. In fact, I'd be inclined to put the tabs on the bottom and put the coordinates status bar to the right of it, so it doesn't take up an entire row of space. Also, the coordinates should be relative to the content area not the whole window.
Moving to the sidebar...
Why 'Element Explorer'? Why not just 'Elements'? The sidebar panel isn't a product. It doesn't need a product-like name. That would be like having a preference panel called 'Smart Browsing (TM)'. Similar for the Attribute Inspector. Just 'Attributes' please.
Might I suggest renaming 'Tree' in the Element sidebar to 'Hierarchy', or just put 'Elements' there and remove the groupbox around it. Or, better, remove the tabs altogether and require the user to select from the View menu or a context menu to switch between flat and nested view.
Hmmm, the elements sidebar contains yet another element creation method. Unnecessary. Despite all these element creation mechanisms, one cannot create elements in another namespace as far as I can tell. Better is to provide a User Defined tab on the main toolbar for assigning custom elements. Otherwise, the user can just use the main toolbar for adding regular elements.
Also, there's a dotted border around the currently selected element in the listbox. One shouldn't be changing the default style of elements.
The elements seem to be created with id's like 'xm:window0'. What purpose is 'xm:' for? 'window0' seems fine to me.
Moving to the attribute list. There is a bit of bold text next to it showing the tagname and id. The tagname is already known as it is selected in the element list. The id is already shown there as well, and again in the list of attributes. This extra info isn't necessary.
The splitter in the attribute list needs to have zero width so it doesn't look distracting.
The lower area allows one to add and remove attributes. Change 'Add Attribute' to just 'Add'. We can assume it will add an attribute since we're in the attribute UI. Same for 'Remove'. Or, use a + and - button and put it on the same row as the other fields. In fact, there really should just be an 'Add' button that adds another row to the listbox. When clicked, a row is added and selected which the user can type into. The two textboxes aren't necessary at all.
I think the attribute list should be populated with the 10-15 common attributes one would normally have on the element (flex, orient, etc). Remember, novice users won't know what attributes are valid. Having them presented all together is much easier. Other visual IDEs do this. If the value happens to be blank, don't assign the attribute to the element.
I noticed a schema processor to handle valid XUL tags and attributes is being used. Is that what's causing the application to be too slow? Did you know Mozilla has a built-in schema parser? Granted, I haven't tried it out too much, so I don't know if it would be suitable here.
There's a margin around the entire window. That's weird. The Options menu has one choice on it. Better, move it into the Tools menu.
The application could use some context menus too. For instance, on elements in the Element List, provide options to move/delete/etc.
A suggestion: when adding a tabbox, automatically add a tab and panel. Have a context menu for tabboxes that add and remove panels, which will add and remove the tab and tabpanel. Similar for menus, toolbars, grids, etc.
That is all I can think of for now. Don't let this make you think that I don't like XULMaker. I do. It's obvious a lot of work went into it. I just think a simpler, cleaner UI will make it much more useful and successful.