On Sep 17, 1:13 am, "marius.andreiana" <marius.andrei...@gmail.com>
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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment