On the topic of the widget set. * One thing we do internally is use deferred binding on some of our custom widgets to deal with different browsers having different levels of functionality. For example, in our custom styled button widget, we use CSS3 properties (e.g.: border-radius) to render buttons on CSS3 browsers, and the CSS2 sliding doors technique (which use images for rounded corners) to render identical looking buttons on less capable browsers. One advantage of using border-radius on the browsers which support it is that you avoid aliasing when zooming in on the page. This has been very successful for us, it should be something to consider for new widgets where appropriate. * Performance is important. Sluggish sites are not fun to use. I love how the GWT team is already so focused on performance, please do not lose sight of it while you are in the process of making it look good.
On the topic of the scaffolding app: * Pagination is the standard solution to the 'large number of entities' problem. However, there is a usability cost to pagination. It would be really nice to get rid of the pagination and just use a scrollbar. If you used the approach of SlickGrid (http:// wiki.github.com/mleibman/SlickGrid/), where you only rendered what was visible on the screen, you can render large numbers entities without the need for pagination. * Alternatively, you can just provide developers with the choice between using a scrollbar and with using pagination. This is what we have done internally - in practice, 80% of our crud pages are 'low cardinality' (e.g.: <300 entities) - and we show low cardinality pages by displaying all elements inside a standard ScrollPanel. For extra usability points, if you have a table, the headers should stay on screen as you scroll the data down. * Assuming we stick with pagination, why are there only 8 entities on a page? That wastes a lot of screen real estate, there is a big blank below. Ideally, the list would fill all available space on the page. That would be more difficult, but either way, but 8 is far too low if it is going to be set to a static number. * When you click 'create employee' the 4 input fields for employee creation appear below the search list. That works well enough if there are only 4 input fields, and 8 items on a page, as is in the demo. However, we had CRUD screens with 50 input fields. We also want to put a lot more than 8 items on a page. So, the input fields would need to be on their own page, replacing or overlaying the 8 entities in the list. This is one of those things where there is no one-size-fits all solution, but our experience is that a large number of input fields is more common than a small number. One last 'wishlist' point: * We've actually developed our own GWT-based CRUD infrastructure recently - versioning/duditing is one of the biggest reasons we ended up creating our own infrastructure instead of reusing an existing one. When an entity is created, it is created as 'v1'. When it is edited, we just create 'v2', mark it as current, and leave 'v1' alone. When the entity is deleted, we just mark it as deleted. Because of this, in addition to just CRUD screens, we also have an audit trail screen that lets users see all previous versions of an entity, when each change was made, and who made each change. And users can then select an older version of the entity and 'revert' back to that version. * Undo/redo fall nicely out of versioning as well - undoing an edit is just reverting back to the prior version * We haven't yet implemented it ourselves, but 'future dated changes' (changes that only take effect on a date in the future) and 'approved changes' (changes that must be approved by another user before they take effect) fall nicely into that pattern as well * I know we aren't the only company to have to deal with this, if GWT's built-in infrastructure had this, and did it really well, I believe it would be a huge win in the enterprise market. * Even if GWT's built in infrastructure didn't have this built in, this type of thing shows how important it is for the framework to be easily extendable, so that developers can add this to the framework if needed. --- Chi Hoang On Aug 9, 7:26 am, Chris Ramsdale <[email protected]> wrote: > Thanks for all of the great feedback (and please, keep it coming). With > these suggestions and some internal guidance, we're going to move on to > fleshing out mocks. Once I have something tangible, I'll share it here. > > -- Chris > > On Fri, Aug 6, 2010 at 8:01 PM, martino <[email protected]> wrote: > > While I appreciate the richness of widgets and behaviours offered by > > framework like SmartGWT or GXT, I don't particularly like their > > "windowish" look and feel, also I don't think it's a particularly good > > idea promoting GWT powerfulness or web application in general by > > mimicking desktop application widgets aspect (how many useless "web > > desktops" simulating a windows desktop inside your browser have you > > seen?). > > > I think GWT/Roo should support at least two basic skin: a light theme > > with few/no images/resources (http://gwt-bikeshed.appspot.com/ > > Scaffold.html isn't a bad start to me!) and maybe an heavier more > > appealing one but I think some effort should be done to distinguish > > GWT/web applications from desktop app. I would use more/nicer effects > > (slide, fade ecc.) to have smoother transitions and/or communicate to > > the user that something is happening/has happened (think of mobile > > apps also...). > > > Just my 2 cents > > > Martino Piccinato > > > On Aug 6, 2:44 pm, Chris Ramsdale <[email protected]> wrote: > > > Hey GWT(ers), > > > > I've heard from many of you that GWT apps simply don't look that good out > > of > > > the box, and styling the default app would go a long way. We couldn't > > agree > > > more. As some of you know, GWT 2.1 (with the help of Spring Roo 1.1) will > > > generate a full-fledged scaffolding app that users can then go customize, > > > and build on top of. The current incarnation looks like this: > > > >http://gwt-bikeshed.appspot.com/Scaffold.html > > > > And while it's a start, it's long from being...well...good looking. I'm > > > working with some UI/UX people back at Google, but in the spirit of > > openness > > > I wanted to get feedback from the real users -- you. Specifically we're > > > looking for "business" apps that are a good example of UI and/or UX. Apps > > > that allow you to track tasks, expenses, travel, projects, etc. > > > > If you have ideas, simply post a link in a follow-up to this thread. > > > > Cheers, > > > -- Chris > > > -- > > 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]<google-web-toolkit%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. -- 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.
