Thank you for you comments. I will respond inline below... On Sep 17, 1:13 am, "marius.andreiana" <[email protected]> wrote: > I'd like to add one more note to the comment below. > GWT Designer seems now a tool for engineers, which don't want to learn > all UiBinder tags or simply want to write code faster. IMHO, I see two > possible paths for GWT Designer future:
Yes. At the moment, it is very fair to say that GWT Designer is focussed primarily at engineers/developers writing GWT apps. A lot of its most powerful features (like having a powerful reverse-engineering Java parser, bi-direction code generation, refactoring-friendliness, custom composite creation etc), will appeal primarily to a developer (and primarily a GWT/Java developer at that). With our move to Google, we would like to improve the tool so that it appeals to a wider audience (while avoiding the all-things-to-all people problem). I'm sure there are lots of things that we could do to make the tool appeal more to designers and also make it easier for developers to use. While the first path you present is one we will continue to follow, exploring the second path is also very interesting and could actually end up having significant impact on the first path. > 1. Continue to improve it and address usability issues such as ones > below, making it easier/better for engineers use. Nice addition to GWT > toolkit in this case. Clearly, we want to address any obvious shortcomings, so please continue to point those out. If you have specific ideas on how to improve what we are doing, we are very interested in those suggestions. Most of the features in the current tool are there as a result of listening closely to our current users (over a very ling period of time). If there are pain points in the tool, let's fix 'em! To that end, if you have specific suggestions (or are even willing to mock up some UI sketches), we'd be very interested in them. I will throw out some ideas below that we have been thinking about. > 2. Work with UX & UI designers folks to understand how do they build > now mocks & wireframes for their companies apps. How do they use > Photoshop, Fireworks, Dreamweaver? What tools to they use for > wireframes and mocks and how? How do engineers use materials provided > by UX? (we are slicing Photoshop comps, we are rebuilding manually > some mocks or wireframes from scratch as if they were printed) To find > these guys, try going to web design shops or larger enterprise > companies and understand how are they working now, and not only to GWT > users. We are very interested in learning more about this. > Set a goal so that UX & UI designers can completely produce Views in > GWT using GWT Designer. Change GWT Designer so it fits their needs, > not engineers'. When receiving .ui.xml files from designer, an > engineer will just have to add ui:field attribute to some elements. > THAT'S IT. Try to consider any other change than this as a failure. > Now this would be awesome. I agree that would be awesome ;-) Now we just need to find a way to get there that will also keep our traditional GWT developers happy. I suspect that making the tool much more appealing to designers will actually have a similar effect on GWT developers, so I don't think that these two paths are divergent or at cross purposes. > > It's really not that usable now, or at least I don't know how to use > > it. Would be great to have some video tutorials building real life > > Views with it. We actually had quite a few on-line flash demos for GWT Designer at Instantiations. We need to create new ones now that we are part of Google. > > Some quick issues I encountered: > > * cannot add widgets to HTMLPanel Interestingly enough, I don't know that we ever had anyone ask about that. We'll look into it. > > * cannot add new CSS classes, as the dialog says I'm not sure what you mean here. It should be possible to add new CSS rules using the "Add" button... http://code.google.com/webtoolkit/tools/gwtdesigner/features/gwt/css_support.html > > * CSS class editor has poor usability (I've got to a 3rd level of > > popup window on Edit font list), misses auto-completion, color picker > > isn't the standard one and not allowing to manually enter color hex > > triplet if desired Yes. the CSS editor could be greatly improved. As you might have guessed, this was not a major focus for the tool. We needed to be able to edit CSS, so we created both a standalone CSS editor (right-click on a CSS file itself) as well as added access from within GWT Designer. At the time, we were very much focused on the needs of the GWT developer, so we somewhat assumed that the CSS files/styles would be provided pretty much as-is from another source (either from UX/UI designers or preexisting corporate CSS templates). If you open a CSS file it is own editor and keep it side-by-side with the GWT Designer editor, you can make changes to the CSS file, hit save, and then see the changes apply to the various widgets in the GWT Designer design view. One idea we have been discussing is calling out specific CSS properties (like font, color and a few others) and make those appear as sub-properties of the "styleName" property. That would give you direct access to those properties without need to access the entire CSS editing dialog. We could certainly allow the user to directly enter a hex triplet into the property pane if desired (you would need to enter those into the "CSS Rule" portion of the CSS dialog to do that now. I think some of these are first impression issues. I've done a lot of UI design for desktop apps and GWT apps and I rarely change the fonts or colors (or I will set those once for a couple of CSS styles and then leave them alone). But what do new users do first when playing with a GUI tool like GWT Designer (or its SWT or Swing companion tools)? They drop a bunch of different widgets and play with lots of properties (like fonts and colors) even though they might not use those much (or should not use them much <g>) in a real app. I even do that when demoing the tool to an audience, so there have been times when I would have liked quicker access to some of those popular style properties. > > * choosing styles in Properties for label/radio button doesn't have > > any effect in preview Hmmm. This seemed to work for me. Thanks again for your comments! Please keep them coming! :-) -Eric -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
