Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

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

    Leave a comment:


  • amcculley
    replied
    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.

    Leave a comment:


  • JordanSparks
    replied
    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.

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • poirot
    replied
    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

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • kolban
    replied
    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

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • hobbsjd
    replied
    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.

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • kolban
    replied
    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

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • kolban
    replied
    Hi guys,
    I'll certainly do some more study but just a quick bit of background. My job is build Proof of Concepts (PoCs) on back-end applications (for the sake of discussion, imagine I sell "database software"). My focus is not on selling or building User Interfaces but instead demonstrating the feeds and speeds of my database product vs other folks database products. On occasion, some of the customers I am visiting wish to see "user interfaces" that look "sexy" as front-ends to my database for specific applications. Remember, my goal is to demonstrate database and not to be in the UI building business. To progress my work, I am still forced to build some UIs in short-order. To that end, I am looking for UI development environments that are as quick and easy to use and learn as possible.

    If my job were building UIs, I can easily see an investment of my time to learn UI at the API level however, working with UI is maybe 5% of my time and when I do work on UI, it is a few hours at a time to build a one-off demo that will be discarded after use.

    For my purposes, it is not important which UI technology I use ... in the past it has been thick SWT and sometimes Flash ... now that I have found GWT and WindowBuilder, that seems like a great weapon of choice. Looking at GWT took me to SmartGWT and "great" ...

    So for the suggestions (which are good and valid and thank you) ...
    1) It is my alone responsibility to build custom demos (my job) and they have to be built by me alone so I can't farm them out to others more skilled in UI
    2) I need speed of creation vs ability to master/use APIs ... and since it is 5% of my job, I can't keep current (or memorize) SmartGWT APIs
    3) Using GWT instead of SmartGWT is working right now ... but (as this thread shows) I am exploring the story of using WindowBuilder with SmartGWT
    4) I guess I can certainly use SmartGWT 2.5

    This is meant to offer some background on my individual story that may help give some context to where I am coming from.

    When I show demos to potential customers, my focus is on "database" and UI is "this ... I just knocked this up to illustrate what might be possible". I am not selling nor pushing any UI technology and I will use the one that is easiest to use to build UI. As mentioned, before finding WindowBuilder, I had been using FlexBuilder and was hoping that the same "rational" for Adobe saying "build Flex apps with FlexBuilder" would also apply to "build SmartGWT apps with <insert IDE here>".

    Neil

    Leave a comment:


  • amcculley
    replied
    I know this sounds odd, but once I got use to 2.5, I actually found using the WindowBuilder to be slower and less productive than doing my UIs in code. To be honest, I wasn't even aware of a problem with 3.0 and WindowBuilder... that is how long it has been since I have even attempted to use WindowBuilder.

    As a paying customer, count me in as someone who just thinks Isomorphic spending time on it is a "nice to have".

    If you aren't a strong coder and/or don't want to put the time in to become familiar with the robust API (which I have personally found to be much faster at getting my job done than any visual editor I could perceive using), then you have several very viable options:

    1) Mock your UIs with Balsalmiq, Axure, OneNote, etc and leave the implementation up to software devs familiar with SmartGwt's API
    2) Learn SmartGwt's API
    3) Use GWT instead of SmartGwt
    4) Use SmartGwt 2.5 instead of SmartGwt 3.0

    I'm about 8 months into my SmartGwt experience - the first 5 months or so was spent dabbling in my spare time. Just ditch the WindowBuilder, get in there, and get your hands dirty with the API - you'll soon learn to really appreciate just how awesome it is... especially once you start creating abstract classes, custom widgets, wrapping your head around the power of SGWT's data binding, etc.

    If there were 1 area I feel a visual/real-time builder would be useful, it would be with SmartGwt's DynamicForms... which I personally feel could use a bit of an overhaul with the API regarding layout, options, etc... but if that were to happen, I probably wouldn't feel the need for a visual editor.

    Leave a comment:


  • Isomorphic
    replied
    Take a look at the QuickStart Guide for the approach we recommend, especially Data Binding and the beginning of the Server Framework chapter, explaining the extremely high productivity approach of generating UI from your data model and tweaking from there. See also the FAQ on GWT Designer.

    Leave a comment:

Working...
X