[Isomorphic]

We appreciate the attempt to provide feedback, but there's no point batting more ideas around until you've read the recommended parts of the QuickStart Guide. Once you've seen autoDeriveSchema (Server Framework chapter, very beginning) we think it will be self-evident that this is the right way to build a quick demo around SQL tables, and is far, far more efficient than doing so visually.

Nor does it require in-depth knowledge of APIs - its just the one property to set.

[kolban]

Hi there. I was using "I sell databases" as an example. I actually sell completely different software (Business Process Management to be specific).

My goal is not to convince y'all of anything, but to provide feedback on what I am experiencing in the hope that I will gain some tips/techniques to make what I am attempting to do easier while at the same time giving all feedback on my usage pattern.

In a Visual IDE, I get a real-time impression of what my screen looks like. I don't believe I get that with just a Java Code editor. In the Java Code world, the best I can do is edit, compile, test ... look at the test ... and then edit the code. With a Visual IDE, I can click on a visual widget, change its property (eg. color, position, parent ... etc) and immediately see a reflection of the change I just made. In a Java Code editor, I have to compile and test to see the change. WindowBuilder shows an editor pane that appears to reflect in real time a very close approximation of what I will see when I run my app. It also has a "test" button which means that I can immediately see a popup showing the app and its navigation/transition capabilities.

I commonly find myself sitting in front of prospective end users who's time is limited. These guys are willing to give me valuable feedback ... so in a Visual IDE, I make a change, show them the change live and in real time, and then we iterate over possible alternatives (lists, tabs, tables ... etc etc). So we get to prototype different UI options and styles in real-time. Both myself (as someone trying to gather requirements) and users (who want to express what they want) enjoy this. The end users also get to see live choices being made. If I have to drop into code to make a change, it loses a lot of context for my non technical consumers.

Again ... I'm not trying to be argumentative. I understand that SmartGWT doesn't support WindowsBuilder and there are no plans for it to do so. I am merely trying to share the impact of those choices to me. I have no expectations of any actions as a result of this thread.

Neil

[Isomorphic]

For interactive screen design session with a customer physically present, we would recommend Balsamiq as a much more effective tool (see FAQ). Anything that uses actual components and hence makes you worry about component hierarchy, layout policies etc is necessarily going to be a lot slower to work with than a dedicated mockup tool. It's also much much easier to collaborate with Balsamiq (send designs back and forth, have a customer view a design and suggest changes, etc).

For building any kind of demo that is actually going to talk to a database, again you should look at the approach in the QuickStart Guide, Server Framework chapter, right at the front - we think it's self-evident that if you are going to talk to a database in even a demo or sample app, this approach is far far faster than any visual tool, because you simply do not have to specify fields at all. Also, this approach will produce code that you actually will want to use if you continue to flesh out the sample/demo later. If you're going to provide more feedback, please be clear about whether you have or have not read this section yet.

Also, just a note that the code/compile/test cycle in GWT is just to reload the page, it wasn't clear whether you were aware of this as you described it as though it were a long or multi-step process.

[hobbsjd]

Add me to the list of those who really want to see SGWT LGPL 3 supported in WindowBuilder.

As a shop that is attempting to transition from ExtJS to SGWT (LGPL), the ability to use WindowBuilder was a key factor in our decision. Without that feature, I'm not sure we could have 'sold' the idea to management.

Abandoning the key factor in our decision, especially when we're also cross-training folks into Java, really throws a wet blanket on my enthusiasm for SGWT. As a senior developer, I can certainly just go to the source and get the job done, but even I still prefer to lay it out visually and tweak from there.

We decided to move away from ExtJS, in part, because if the massive relearning that would have been necessary from version 3.x to 4.x, and the lack of viable visual builders. Please don't leave me holding the same bag... Upgrade to 3.0 and lose the ability to do layouts visually in Eclipse? C'mon folks. We can do better.

[Isomorphic]

Jason, that's unfortunate, but please understand, Isomorphic did not "abandon" anything - you relied on something that Google has elected to stop developing. So complaints to us are misdirected.

And for completeness, we want to reiterate that we don't think anything has been lost. Due to the power of SmartGWT's data-binding system, code-level approaches have always been the more productive approach, for a developer.

[kolban]

Hi there,
I think what I am having a hard time struggling with is the notion that the proposed argument is that developing UIs with code editors is "more productive". I guess what concerns me is that there may be quite a few potential users of SmartGWT who actually don't subscribe to that perspective.

Maybe I can try another approach in my discussion. Can we think of another (successful) UI framework/toolkit that doesn't have a GUI builder? It seems that Flex, GWT, Ext-GWT, Dojo, SWT, Swing, .NET, Android, iOS (others?) all seem to provide UI builders and none of them seem to be saying that such a capability is not desirable.

What I am sensing is that the good folks at Isomorphic don't see a good investment in their resources for building or enhancing a UI builder to support SmartGWT. That, of course, is their right and no-one can mandate that they should do so. As has been said in previous posts, if we want to use a UI builder we can stick with older releases of SGWT that apparently were supported by WindowsBuilder.

Time will most certainly tell and I'm sure market forces will prevail. If the strong advocates of SmartGWT start to find their consumers are clamoring for a GUI Builder then one will have to be provided or else alternative frameworks may be chosen and market share will decline. If users are satisfied with the lack of a GUI builder then myself and others were simply wrong in our belief that a GUI builder is a highly desirable component.

Neil

[Isomorphic]

There's no need to speculate one way or another the productivity benefits, just actually try the approach suggested. The only person with actual knowledge who has chimed in so far has confirmed that the data binding approach we recommend is more effective than manual layout in a visual tool. This is a sentiment we've heard from many other customers in private as well. So again, actually try it.

Other corrections: SmartGWT has a tool (Visual Builder) we continue to enhance, we just don't think a visual tool is the right primary environment for a Java developer given the power and expressiveness of the data binding framework. See also the FAQ on loading screens saved in Visual Builder.

[poirot]

do you really suggest developers to use visual builder?

in early days of our evaluation phase we read about it and played with it ... but then we realized it could only produce xml-description forms instead of java code so we thought it is a "nice to have" for some special cases where customer has to define their own forms ... etc. ... nice

so we looked at window builder and we hoped that path will develop in the future because it works the way it should be .. but now we are a little bit disappointed about the fact that you are really recommend to use visual builder as a development tool and we see it as a sign that you maybe simply not understand why development teams choose java and gwt instead of scripting languages?

on the other hand, we understand that window builder wasn't your baby but you wrote that it is now open source .. so nobody stops you from contribute now?

regards,
ma

[Isomorphic]

We recommend Visual Builder for the specific scenarios listed in the FAQ.

We recommend the approaches in the QuickStart Guide for databinding, which in SmartGWT also covers most of your screen layout.

Rather than speculating about what we do or don't understand (wow!) start by learning about and actually trying out the approaches in the QuickStart Guide. You should also go back and read the whole thread (not just parts) because your other points have been addressed already.

[JordanSparks]

Couldn't Visual Builder simply be made to output Java in addition to the XML? Developers could be trained to not touch the automatically generated code. The existing databinding features do take care of about half of the UI, but there's still quite a bit left for us to handle manually.

[amcculley]

I don't think anyone is debating the usefulness of visual editors (when done correctly). I think the core issue is how high on the priority list is it given all of the other things and available resources. Is it truly needed or is it a nice to have?

We now have a dozen or so developers using SmartGwt across 2-3 different applications. At first, they all asked about a visual editor. No one has asked for it in a couple of months. However, everyone using SmartGwt are already java developers.

I think the core argument is that even if you have a visual editor, you'll still have to write java code. And if you can write code, the visual editor isn't that useful (imo). It doesn't mean it wouldn't be nice to have, but I can see several other areas where I'd rather see resources invested.

If Isomorphic did have a good visual editor, would they make more sales? Probably. But as soon as the honeymoon wore out, the people using it would still have to write java code and then the visual editor hasn't done much to help them.

[amcculley]

I'd gladly trade a visual editor for a robust adaptive layout platform.

[Isomorphic]

Support for automatic translation of Balsamiq mockups to SmartGWT screens is now available to try out.

As previously mentioned, we recommend Balsamiq for early, collaborative prototyping. Because Balsamiq focuses on replicating the experience of sketching on a whiteboard, it will always be a far more effective design tool than an IDE, which forces you to formally define containment relations, distracts from the design process by offering a blizzard of dialogs, properties and settings that aren't relevant yet, and is not usable by a typical product manager.

Our Balsamiq Importer allows you re-use the layout work you did during early design phases, then add data binding and event handling without loss of work.

[skitchin]

Isomorphic

When is Isomorphic going to provide SmartGWT support to WindowBuilder? Google have open-sourced their code to the public and your team can simply add the support. It's a lot of hassle for me to download GWT Designer from their repository, edit the com.google.gdt.eclipse.designer.SmartGWT to add support for 3.0/p, compile the whole package and jar them.

[jaredm]

...I actually sell completely different software (Business Process Management to be specific)...

Hey Neil,

Unless I've got you confused with someone else I'm pretty sure we've come across one another on TechD.

What Isomorphic say is fairly accurate, bolting WindowBuilder and SmartGWT doesn't pay dividends. However, in case you've not come across it already check out the SmartClient Custom XSL which will allow you to do PoCs pretty rapidly in IBM BPM - http://emrul.pbworks.com/w/page/40437383/Home

(FYI... it's free to use but no support...)

Regards,

Emrul