My SmartGwt Wish List

[amcculley]

Background and Context:
Been using SmartGwt in an enterprise environment for 3 years now including supporting multiple development teams who are using it. In addition to being a lead engineer, I'm a UX designer working primarily with interaction design.

I love the software.... especially the datasources, servlets, RESTful API, etc.

That being said, if I were king for a day at Isomorphic, here are the changes I'd be trying to drum up support for:

MOBILE SUPPORT
1) New layouts and APIs focusing on responsive design

2) I understand SmartGwt Mobile exists, but it is kind of "one or the other". Instead, tying back into #1, the responsive design APIs should include the ability to dynamically choose widgets used based on device media settings. Twitter Bootstrap does an amazing job at this.

3) More universal / generic look and feel. SmartGwt Mobile is very iOS-inspired.

4) Performance. While SmartGwt technically works on a ton of mobile devices today, not everything works as you would expect and it can be slow, zoom issues, etc. This is an area I don't know much about, but it seems to be due to all of the very heavy javascript.


DESIGN / UX SHORTCOMINGS:
1) Everything is outdated, imo. While it works great for internally facing applications, it isn't ready for B to B or public consumption... not in the "modern web".

2) The themes provided don't differ enough. They essentially boil down to different color schemes and icons.


DESIGN / UX SUGGESTIONS:
1) Create a new theme that is modern and contemporary. Need to look at spacing (more), font sizes (bigger), softer (not so blocky / square)

2) This new theme should come with the LESS / SASS source. Instead of 10 themes that only change colors, have 1 configurable theme. Again, the "Customize" option of Twitter Bootstrap is a perfect example.

3) Paginated Grid. I know the "Live Grid" is "better", but at the end of the day, people want what they are comfortable with. If it hasn't caught on by now, chances are it isn't going to. The Dvorak keyboard is better than the Qwerty one, but which one does everyone use? It isn't right, nor fair, to simply try to force change on people. Live Grids introduce training, usability, and adoption issues for companies and users.

I hope this doesn't come across as critical... I love the software and think it is amazing and truly have enjoyed using it (and will continue to do so whether or not these things are ever implemented). However, I do think doing some of these things would do a bunch in terms of getting more technical decision makers to convince their leadership that this is the right product for their needs.

[sjivan]

I agree on several of your points, especially the need for a bootstrap like modern theme, and the need for an out of the box paginated grid for the very reasons you mention.

[Isomorphic]

Thanks for the constructive feedback. Some feedback on your feedback:

1) New layouts and APIs focusing on responsive design

There's more to do here, but have you looked at SplitView?

Is there any other *specific* layout behavior you're looking for?

4) Performance.

4.0 introduced a much lighter DOM and other improvements. Have you tried it?

1) Create a new theme that is modern and contemporary. Need to look at spacing (more), font sizes (bigger), softer (not so blocky / square)

Just a note that SmartGWT's sweet spot is functionally dense interfaces. People designing such interfaces generally really really don't want to burn space, even though this definitely is the trendy style for consumer non-mobile web apps. So this hasn't received priority due to a lack of requests, but is always valid for Feature Sponsorship.

1) Everything is outdated, imo. While it works great for internally facing applications, it isn't ready for B to B or public consumption

Is there anything you be specific about here other than pure aesthetics like fonts and spacing?

[Isomorphic]

Missed one:

3) Paginated Grid.
...
It isn't right, nor fair, to simply try to force change on people. Live Grids introduce training, usability, and adoption issues for companies and users.

We've heard this claimed before, and our follow-up question is always: have you actually been in the room with an actual end user and seen them unable to use, or confused by, a grid with a scrollbar?

The answer has uniformly been "no", which seems the intuitive result - scrollable grid interfaces are everywhere, including the most common business software around (Outlook email, Excel, etc) and much of the most common consumer software too (iTunes, etc).

Further, since interfaces involving link-based paging almost always *also* involve grid scrolling (for variable height rows, trees, etc), it doesn't seem possible that additional *training* could be required for an interface that appears elsewhere in the same application.

Overall, there certainly is a lot of confusion about this issue - there are a number of UX people and even some end users who believe that link-based paging is more intuitive because they have seen some kind of broken / buggy "live grid" interface.

When presented with the real thing.. one of our actual experiences with an end user involved the user trying out our grid and being asked about whether they preferred that interface or a link-based paging interface they had been using previously. The user was indeed confused. They didn't understand the request because they didn't realize paging was occurring at all. And they were delighted to be free of having to click multiple times instead of just scrolling, like they were used to from so many desktop apps.

If it hasn't caught on by now, chances are it isn't going to.

Given the examples above, it's pretty clear scrollbars on grids have "caught on" :)

[amcculley]

Thanks for the responses.

Personally, I've encountered mixed results with the live grid. It isn't a matter of which one is better... it is the problem of convincing people that what they want or are accustomed to isn't better. Its a hard sell.

Most of our clients want us to build one. We tell them the live grid is better and to give it time. 2 years later, those same clients are asking us if we can build them one.

Personally? I like the live grid. I think the issue is convincing the other stakeholders in the equation... not the users. It just comes across as something less common, useful, etc.

"How many records are there? How many pages? How can I page down? The performance is slow. It looks funny. Everyone else is using one."

I mean - I've heard it all. At the end of the day, decision makers (not always the users) look at the live grid like it has a 3rd arm sticking out of its head. And since they will never use it, its a tough sell.

*EDIT*
And thanks again. I love the product... and will continue to use it and suggest it to colleagues. I haven't checked out 4.0 yet but I'm going to as soon as I get a half day or so of uninterrupted time.

[amcculley]

Looking at the javadocs for 4.1d. Can't seem to find a Splitview or SplitView anywhere.

Point me in the right direction?

[Isomorphic]

It seems that you are saying that actual end users prefer the "live grid" interface, but that various "stakeholders" with a variety of different misconceptions continue to push for link-based paging.

If so, we wholeheartedly agree with this assessment, and we would ask that you help to clear up the misconceptions over time.

This post provides a bunch of very strong, ready-made arguments that will help.

Also note, from a product perspective, what it would mean to offer a link-based paging mode as a core feature:

- it has interactions and or conflicts with dozens of grid features, including vertical row autoFitting, grouping, inline editing, expandable records, drag and drop, recordComponents, etc.

- there are multiple ways each such conflicts could be resolved, resulting in multiple sub-modes for link-based paging in combination with different features. For example, with grouping, do you have the grid expand when groups expand? Introduce simultaneous presence of a scrollbar and link-based paging? Switch on-the-fly to "live grid" style presentation?

- these interactions and conflicts would require the behavior and documentation of hundreds of properties to be updated. It would also require scores of new samples to demonstrate all the additional modes. This would make the grid much harder to understand for developers, much harder to maintain and much harder to test.

Ultimately this implies a huge and ongoing engineering effort which makes the product much worse, in order to support an interface which is also worse for end users.

It would be a horrible disservice to our community to spend time on something like this. There are so many other things which clearly deserve attention and effort instead.

Now that you have a more complete view of the decision, we're hoping you are more motivated to clear up misconceptions (and armed with the tools to do so!).

[Isomorphic]

About SplitView - sorry, wrong name, it's SplitPane.

[nova3421]

2) This new theme should come with the LESS / SASS source. Instead of 10 themes that only change colors, have 1 configurable theme. Again, the "Customize" option of Twitter Bootstrap is a perfect example.

Didn't want to start a new thread, I was just wondering if there was any updates on making the SASS/LESS source available?