As simple requests for feedback do not seem to bring too much response, looks like I need to do something more to get the conversation on the UI Designer going. :-) I’ve decided to do a series of posts highlighting the important features of the new UI Designer, and for a start, I’ll describe the main design goals and key decisions that went into our work.
I’m very eager to receive any kind of feedback, positive or negative, on our work and its underlying decisions. Don’t hesitate to leave comments here or come to the forum or newsgroup. It’s still not too late for us to make major and significant changes in the product. And of course, the version of the UI Designer available in recent EAP builds is not final, and we have a lot of work remaining in our plans, and some cool feature ideas too. And if the current EAP version falls short of accomplishing some of the goals, rest assured that the situation will improve a lot in the final release.
So, first of all, let me state our goal: To create the most productive environment for designing and maintaining Swing interfaces of any complexity.
There are a number of key points in it. The first is the most productive. Of course, we would like our UI Designer to be the best in existence (who wouldn’t?), but there are too many ways to decide which one is the best, so we had to focus on one aspect of best. Our choice – productivity – shouldn’t come as a surprise for those familiar with our products.
Productivity, in my view, comes from a number of factors. The actions not essential for accomplishing the most common tasks should be removed from the workflow for those tasks. Every time the IDE can do part of the user’s work by itself, it should do so, or offer the user to do so. Every bit of information that the IDE can use to do its work better should be used. All common errors made by the user should be detected as soon as possible, and the IDE should offer to fix those of them that can be fixed automatically. The interface should always provide adequate feedback on the result of the user’s actions so that the user does not make these errors in the first place.
Later I’ll show how these factors come into play in specific features of the UI Designer.
The second key point is designing and maintaining. A piece of code written in a few hours or days usually gets maintained for many months or even years, so the ease of maintaining (expanding or modifying) existing UI forms is just as important for us as the ease of creating new forms. An interface that allows to build a form from a clean slate very quickly but provides unexpected results when the user starts dropping components into the middle of an existing form would not be acceptable for us. Also, it should be very easy to understand the structure of an existing form and its connections to other code. (Forms are in general much easier to figure out than Java code, but still the UI Designer should help as much as possible.)
The Swing interfaces point represents a limitation of our focus for this release (we’re not touching SWT or midlet form design, for example). It also means that we’re going to significantly expand the coverage of different Swing features in the designer. We’ve already done much work in that area (support for more property types, standard Swing layout managers, button groups and so on), and there’s also much work remaining to do before the final release.
Finally, of any complexity means that the designer should be equally suited for both simple and complex forms. For simple forms, we need to provide very easy ways to accomplish the most common tasks. For complex forms, we need to support building forms from multiple parts, easy possibility to combine hand-written UI components with UI Designer forms, easy ways to modify the form structure, and so on.
In the next post, I’m going to cover the key decisions on which the current UI Designer is based, some of which are new for Demetra and others have remained unchanged since previous versions of IDEA.
Posted by Dmitry Jemerov at March 16, 2006 01:39 PMI would highly recommend you have a look at JFormDesigner (which now has finally has support for idea integration :), it's by *far* the best UI designer i've ever used (i must admit it's support for jgoodies forms helps alot, since that is the best layout i've used too ;)
Yannick,
Of course we have looked at JFormDesigner, and it's a great product indeed. But we think we can do better, or at least as good. :-)
Pointers to specific areas which, in your opinion, JFormDesigner handles better than the current version of our UI designer are very much welcome.
Posted by: Dmitry Jemerov at March 16, 2006 05:55 PMPlease don't automatically create member variables for everything, i.e. panels just used for nesting.
Also, it would be nice if the code that is generated is readable to the point of being broken into multiple methods (user optionally definable), i.e. createParentPanel(), createDetailPanel(), etc. This way we might be able to get some reuse or easily refactor these bits if needed.
Don't use a lot of custom layouts or components, maybe just one or two, the set that comes with swing should do it.
Please, please don't generate an external file, i.e. some XML file that the designer uses - just parse the code.
Just my thoughts..
Charlie
Charlie,
Member variables are always created only for those components where it's required - it has always been the case.
Breaking the generated code into multiple methods may be possible, but refactoring the generated code will not be, because the code is regenerated after every form change.
Currently we provide one custom layout manager which has some additional features compared to Swing layout managers, and you have the option of using either our layout manager or one of those that come with Swing.
What's the problem with storing the form in an XML file? That's the way it works now, and it doesn't look like we'll be able to change this.
Posted by: Dmitry Jemerov at March 16, 2006 07:08 PMDmitry,
I love IntelliJ, it is the best IDE I've ever used. But for UI work I have to confess that I use Eclipse's Visual Editor Project. It is awesome.
Why is it so awesome... well the code it generates is really "clean". You have access to all of the properties for each component. You can add your own beans. It supports most of the default layout managers. And once you are done, it's just "plain" java. I don't need any extra libraries or config files.
Have you guys looked at it?
Again, I love you IDE, keep up the good work.
John
Posted by: John Childress at March 16, 2006 07:31 PMJohn,
Yes, we have looked at Eclipse Visual Editor. Indeed, it does generate good quality code and does not need an external form file, but we found that it had major usability and performance problems. We haven't checked out the latest version - the problems might have been fixed during the last several months.
With our UI designer, you'll also be able to get "plain" java with no extra libraries as output, but you'll need the .form file in order to be able to modify the form.
Posted by: Dmitry Jemerov at March 16, 2006 07:36 PMYep, I will give you the "performance" problems... It is definately "slow". I chalk it up to the "free" aspect of Eclipse. As for usability, I haven't had any issues.
John
Posted by: John Childress at March 16, 2006 08:00 PMIMHO you should:
1. support the Forms library, like JFormDesigner does: https://forms.dev.java.net/
2. use https://binding.dev.java.net/ as example of biniding not the actual binding concept. Also the binding should not be "intrusive" like now, but only if the user wants something like the mentioned library.
3. "generate source code" should be default, not bytecode. Most companies will simply not accept this, as they do not accept to integrate in their projects open source frameworks that manipulate the bytecode - except obfuscators.
4. have a set of ready to use "forms" for most common usages so that the user can simply modify them: so file templates for Forms.
5. Add all possible controls to the pallete not only a part of them.
6. To get JBuilder users to IntelliJ not to Eclipse, IMHO you should also integrate their JBCL controls. I'm not sure what the license for them was, but were always supplied with source, and many many Swing projects developed with JBuilder was using them.
7. Generate CLEAN and READABLE code - look at concurrent products.
8. want more?
Ahmed.
Posted by: Ahmed Mohombe at March 16, 2006 08:38 PMAhmed:
1. The internal changes to the UI Designer have made it much easier to support different layout managers, but we're still considering whether we should support any layout managers other than the Swing ones. If we do, JGoodies Forms is on the top of our list.
2. The main problem with the current "binding" property in UI Designer is its name: we'll simply call it "field name". We don't support any real binding right now, and we don't yet have any definite plans to support it.
3. The default is easy to change. :-) We'll revisit this closer to the release.
4. File templates for forms are available since version 4.0. As for providing ready to use forms - what are your suggestions? We have a basic "dialog wizard". I don't think that supplying an extensive library of templates is a good idea - we don't do that for Java code, so why do that for forms?
5. Already done in Demetra.
6. We'll need to investigate this.
7. We'll see what we can do to improve this. A JIRA request with some specifics won't hurt.
8. Yes. :-)
Posted by: Dmitry Jemerov at March 16, 2006 08:49 PM>2. The main problem with the current "binding"
>property in UI Designer is its name: we'll simply
> call it "field name". We don't support any real
> binding right now, and we don't yet have any
> definite plans to support it.
Than don't call it binding at all. Everyone believes it's really that kind of bining I mentioned.
No plans to support "real binding"? Well it would be very good since this would really increase productivity.
> 5. Already done in Demetra.
I don't think so. I Demetra open right now, the Swing API and some other Desingers, and I see more available not present in Demetra.
> 7. We'll see what we can do to improve this.
I suppose you use some sort of templates for this.
> A JIRA request with some specifics won't hurt.
IMHO there's no need for this, since it's an investigation work side by side with a designer that already does good. You need no JIRA issue but a wide monitor :).
A few more:
8. A UIDesigner should be snappy - yes snappy: if there's just a small delay in the actions than the users will leave the designer and do it by hand or what's worse will use another GUI Builder.
9. Please drop the spacers for default usage - they are disturbing, very.
For GridbagLayout if one ads an element, the spacers occupy the entire space and one wants to insert the next element after or under, one must exactly target the 1 pixel wide separator because the entire space is occupied by the spacers and placing on them doesn't work, nor is the UIDesigner smart enough to know to transform them.
10. Group the Swing Elements for their usage - e.g containers. The list can get pretty long and the
user need all the time to search, as the order of controls has no logic.
11. The icons for controls are nice, but IMHO the distinction is pretty hard because they look too alike.
12. Put numbers and arrorws on the border makers like JFormDesigner does - it's much easier for users with them.
More later :).
Ahmed.
Posted by: Ahmed Mohombe at March 16, 2006 09:09 PMAhmed,
2. Exactly - we're going to rename the property.
5. Sorry, don't quite understand your comment. I think that all components which make sense to be added to the palette are there. Not all possible layout managers or property types are supported right now, but we plan to support more in future EAP builds.
8. Specifics are welcome as usual. :-) I believe that the performance of the UI Designer in Demetra is much better than 5.0. In the one place where I do see performance problems - adding new components - the slow part is not the UI Designer, but rather creating a field in the Java class.
9. The spacers are kinda preliminary/experimental - indeed, we need to come up with a better solution.
10. Agreed.
11. We'll look into that. :-)
12. It's of course easy to add, but I don't quite understand what value is added by the column numbers.
Thanks for all the feedback. :-)
Posted by: Dmitry Jemerov at March 16, 2006 09:18 PM> 12. It's of course easy to add, but I don't quite
> understand what value is added by the column
> numbers.
Well, than it seems to me that you haven't really used JFromDesigner, just "played with it a little" :).
Just try a more complex form (with more columns and rows) in JFromDesigner and you will see what I mean :).
Three more:
1. In Place editor is very ugly. E.g. for Labels the place is very small. It should "pop a little over" and have a red border while editing like JFromDesigner - to give a better feedback to the user.
2. Add support for alternative look&feels by *default*: e.g. Looks:
https://looks.dev.java.net/
3. Add "Default Editor Wizzards/Dialgos" for JTree JTable and JList. Mostly users will replace them with their model, but for design is better to have them (and have the code generated in separated method to remove it easily).
This kind of Mock model editor is present in JFromDesinger and is very efficient so.
Ahmed.
Posted by: Ahmed Mohombe at March 16, 2006 09:28 PMAhmed,
1. Agreed.
2. This is a general IDEA issue, isn't it?
3. We'd like to get finished with features that help in creating real production code, before starting work on features that create something which is only used for throwing away. :-)
Posted by: Dmitry Jemerov at March 16, 2006 09:32 PM> 2. This is a general IDEA issue, isn't it?
IMHO no. I need this only in the desinger since only there I try how it looks. For the IDE itself is irrelevnat IMHO. If the L&F is not eating too much space with it's borders from the workign surface, than L&F changes to the IDE is more importnat to the Eclipse people (in order not to have this as an argument against IntelliJ :) ).
>3. We'd like to get finished with features that
> help in creating real production code, before
> starting work on features that create something
> which is only used for throwing away. :-)
If you look at how JFormDesigner implemented it you will see that it's very simple to do it. You should try to "eat your own dog food" and make those simle wizards with the Designer itself. IMHO those would not take more than an hour or two to make - at least if I make them with JFromDesinger (I made similar Mock wizard for an application).
You must consider that "throwing away" is not a problem as in 95% of the cases UIDesigners are used for protoyping with the customer, so it's very important for the programmer to be able to do that too and to have very presentable UIs to the customer.
Regarding the old #4, you said:
>I don't think that supplying an extensive library
> of templates is a good idea - we don't do that
> for Java code, so why do that for forms?
It must not be very extensive, but:
Java code is not the same as the forms are. Prototyping is the keyword here (in many cases with the customer side by side)
BTW prototyping: what would be if the user would have a function like: "make this form a template" ? - than IntelliJ would extract it as a form template, put it in the list under the "DialogForm" and of course under the scene replace some code with parameters (e.g. the Form Name).
Ahmed.
> 2. This is a general IDEA issue, isn't it?
No. IMHO this is specific only to GUI designers.
>3. We'd like to get finished with features that
> help in creating real production code, before
> starting work on features that create something
> which is only used for throwing away. :-)
IMHO you should do this feature because:
a. It's very easy to implement it: with JFromDesigner at least.
b. in 95% of the cases when using a GUI designer is for prototyping (and mostly with the customer side by side) - so it's important to be able to do as complete UIs as possible.
c. It's not a problem that a part or the entire thing is thrown away - this is a characteristic of prototypes.
This is also true tor From templates - they make much more sense (not like Java Class templates) since here even a few seconds matter when the customer is stareing to your monitor.
So please don't forget most important use case of a GUI designer: GUI protoyping.
Ahmed.
Posted by: Ahmed Mohombe at March 16, 2006 10:08 PMIt seems that your tracker behaves very strange sometimes and is loosing messages (at least for a while).
I replied 3 times to your last message and each time the message didn't showed up(not even after a half an hour). Now (the next day) I see that two of my replys are there.
And it was not a refresh problem as I used several browers and checked also from different computers.
Ahmed.
P.S. For all of them I did a few previews while writting and only after that "post".
Ahmed,
Unfortunately this is by design - due to high amounts of comment spam, I have to review comments and publish them only after review. Nothing gets lost, but there may be some delay before publishing (I'm not online all the time :-) )
Sorry for not documenting this clearer. :-)
Posted by: Dmitry Jemerov at March 17, 2006 02:33 PM> Unfortunately this is by design ...
> Sorry for not documenting this clearer. :-)
If this is so, than IMHO you should find a way, maybe use another blog tool, or write one with Fabrique (you still have it I suppose :) ), that is able to integrate directly with the forums and most important with the Newsgroups, so that when the user is click-ing on "comments" to land directly in the right newsgroup (one comment link for browser and another for newsreader). Than the blog tool should also add a message with the title of the blog message and link inside it to your message, so that there's an automatic one to one relation.
This way the detailed text would be in the blog ( since it's better so) and the messages on the formus/newsgroups, but this in an automatic way.
I don't know if there already exists such blog, but this would be very efficient and a better protection for spam than manually filtering them.
I can even imagine that such a blog would have success since spam is the biggest problem of Blogs these days, and this problem seems to be much beter solved for newsgroups - not to mention about all the confort a tree view in a newsreader is offering over this "list of comments" representation.
Ahmed.
Posted by: Ahmed Mohombe at March 17, 2006 02:55 PM1) Make it possible to define a class that *is* a component, instead of *has* a component. Our typical idiom with IntelliJ 5 is to define a JPanel which has a variable called 'mainPanel', which is bound to the top-level JPanel in the UI designer. We then call this.add( mainPanel ) in the constructor. It would be nice to skip this step and simplify the hierarchy.
2) Make it easier to re-use components as JavaBeans. There are several problems with this in IntelliJ 5: The IDE caches the class definition, even if it is changed, until you close and re-open the project. This is frustrating when the reusable bean is defined within the project that it is being used in. Another problem is that all users on the team need to add this in their GUI preferences; it would be nicer if the .ipr file detected the java beans that were used and stored them with the version-controlled project file. Lastly, we've experienced frequent 'corruption(?)' with the JavaBeans feature where the IDE would display a red box ('JavaBean cannot be instantiated', I think) or even unexpectedly quit for certain JavaBean components.
3) Make the sizing stuff more straightforward. The combination of setting the fill, minimum, maximum, wants grow, wants shrink, can grow, can shrink, etc. combined with the 'spring' spacer component, and then multiply all those settings by the depth of the containment hierarchy, really detracts from productivity. It seems like we are always delighted at how fast we can slap together prototype UI's in IntelliJ, until we spend hours tweaking how components resize.
4) Find a way to easily use subcomponents of standard Swing widgets.
5) I favor source code generation over the form file - contradicting my previous is-a vs. has-a point, maybe IntelliJ could generate source code for the UI with no functionality, and make all the variables public or give them all public accessors (I'd recommend simply making them public). Then a separate class could instantiate this UI-only class, set up models / listeners / etc. on the public vars, and add the UI class to itself.
6) I would REALLY like it if there were an absolute positioning mode available. Yeah, I know, that's old fashioned, and for most UI stuff I don't do it, but for certain things (like designing printed forms and reports) you need pixel placement, and it would be really nice for certain projects to just shortcut all the sizing problems we run into.
7) My favorite thing about IntelliJ currently, and I hope you resist the pressure to change this, is the total separation of UI from behavior. I really like that there are no GUI ways to wire up actions/listeners/events/bindings. I do my presentation in the GUI editor, and do my behavior in code (I love the Binding framework, but I'd rather call it by hand then integrate it into a UI editor), and it's really nice not having to wonder if there is something buried in the .form file that is automatically doing some functionality for me.
Posted by: Jesse Barnum at March 19, 2006 07:23 AMI have used Intellij 5 GUI builder or had coded GUI exclusivly for Imagery, you can see some screen shots at http://www.xerto.com/imagery
I ganeraly like the GUI designer but it has a one major flaw which is: Support for custom components is next to useless. Dosn't support custom containers. Just that one thing reduces the places I can use it by over 50%.
Dosn't support more advanced look settings like full borders support including custom borders. Dosn't support setting colors or fonts. That would be really helpfull in tweeking things to look nice. Would be nice if it supported gradient paints for backgrounds of panels.
The other most anoying thing that has already been mentioned is not being able to have the top level panel bound to the bound class its self when its a subclass of JPanel. To save the extra panel.
90% of the time I find the current layout methods quick and effective. I have had a few cases where I have been playing with the propeties for hours and not got what I wanted and resorted to GridBag.
It would be really helpfull if you could test with a serious component set like JIDE http://www.jidesoft.com to see that you can add all the custom components and build with them ok. I am sure they would give you a free licence for testing with.
I have done a screen shot example for you, showing what I managed to create in UI designer and the amount of tweeking needed to get the final result. http://www.xerto.com/edit-catalog.png The closer I could get to the final result in the UI designer the more productive I could be :-)
Glad you are working on the UI designer it was the one thing that let down Intellij. Thanks Jasper
Posted by: Jasper Potts at March 21, 2006 02:55 PMOK, here are some ideas on productivity:
- Templates. Many products want their forms and UIs to have a common feel or layout. Allow us to create UI templates that have basic layouts. We can then drag and drop components onto those templates. The template will make sure to reorganize the form or UI to match the template. Don't have the template be a design time only thing (where the IDE applies the template at design time and spits out static non-templated code)... let it be something that is applied at runtime so that customers/clients can modify a template and apply their own custom UI changes to the application. Productivity, you say? Imagine being able to start a new form, pick a template, drag components to a form, and watch them all snap to the templated slots, sizes, colors, styles, etc. Oh, I guess this brings up the idea of styles. Wouldn't it be great to have something like CSS stylesheets for our Swing UIs?
- Metadata. Make it as easy as possible to integrate a form with the rest of the app. I know someone said they don't want it, but support binding mechanisms (JGoodies, spring-rich, etc). Support validation/constraint frameworks (JGoodies, commons validation, spring-rich, etc). Not by directly coding these things into the form, but by dumping metadata about the UI into a well known spot for me to query. IDEA could provide some standard "binders" that could query this metadata and provide support for binding to JGoodies, etc. If I don't want the UI to modify behavior, then I simply choose to ignore the metadata. For example, in our Spring-rich app we have code that loads a form and then iterates each component's name (as set via setName(...)) - it then matches that name to a property on the form's backing object with the same name and binds the property to the component via spring-rich's binding. This "name" for the component is a piece of metadata. The form could provide more if it wanted (type, constraints, etc). As simple metadata, this information would not modify or introduce behavior - it would be up to the developer to query the metadata and act accordingly. Once this is in place, let me define constraints and other things in the IDE. Again, the IDE would output these constraints as metadata only. For the guy who doesn't want this, let there be an option to disable it. We could also go the other way: provide a mechanism for the developer to supply metadata to the UI designer so that the designer can reflect what it knows. For example, if I have, say, annotations on my data objects with constraint information, let me provide that information to the form designer so that when I'm designing and testing the form it can reflect those constraints.
In the end, I think we have two components to a form: the form, and the metadata. The metadata can be supplied by the IDE, but since it is a separate component (probably via a well defined interface), the IDE could also let the developer supply their own implementation, and thereby their own metadata for the form. At design time, the IDE would work with whatever metadata implementation it is given. One result of this architecture is that IDEA could come with several different metadata implementations depending on the developer's needs. For example, one implementation would read and write metadata as Java 1.5 annotations on backing objects. At design time, I would select this metadata implementation and point it at my form object model. As I setup constraints and other things in the UI, it will modify the related annotations on my object model. Another metadata implementation could read/write metadata to a .xml file, another to a Java class, and so on. At runtime, the developer will then have these two components: the form, and the metadata. The form has no inherent functionality of its own. At runtime, the developer can choose to query and act upon the metadata in order to bind the form, apply constraints, or other such behavior. In fact, using my previous example of an annotation based metadata, the developer could choose to use the metadata interface provided by the form (which would then route to the backing annoations on the object model), or (if he really wanted) go directly to the annotations he knows are there. Obviously, the advantage of using the form supplied metadata interface is that if the backing metadata "store" should ever change, the developer will not have to modify any code - the form will just hand off another metadata implementation, and the developer will be none the wiser. Again, the developer can also choose to ignore the metadata. IDEA can provide prebuilt standard components to read the metadata and bind with various 3rd party products: JGoodies, spring-rich, etc. It could even provide its own binding framework if it so desired, as long as it is separated out and can be swapped for one of the other 3rd party frameworks.
- JFormDesigner lets you output either Java code or .xml forms. We use .xml forms, but I know many people who prefer Java code. Let us have a choice.
- Maybe I'll think of more later, but this is a good start. :)
I wonder if JFormDesigner would be open to a buy out? ;-)
Posted by: Andy DePue at March 21, 2006 09:27 PM