We heard interesting stories from a number of people using GWT at the Voices that Matter conference in December. Chris Jones from YesMail was one of those. In our ongoing series of guest blog posts on how companies and individuals are using GWT, here is Chris to describe their experience.
In the spring of 2006, Yesmail began an initiative to re-invigorate its technology department with the development of Enterprise 6, our retention mailing platform (managing email communication with a subscribed customer base). The goal was to take the power of the platform and expose it as intuitively and comfortably as possible, taking opportunities to simplify and extend along the way.
(1) Creating a modern user experience.
The proclivity of Web 2.0 being what it is, the days of accepting poor interfaces as "inherent to the web-based platform" has gladly become dated.
We started out using another framework but ran in to some pretty big issues quickly. Getting good end-to-end test coverage on that app with Selenium was difficult due to our lack of full DOM control. That, coupled with early concerns regarding performance led us to fall back to a more traditional Spring/Hibernate form-based approach. With this foundation in place, we began integrating Dojo and DWR piecemeal to gain back some of our Web 2.0 feel.
When the time arose to challenge ourselves with a cutting-edge interface, to allow our users to simply and quickly construct complex data queries with an intuitive front end, we decided to evaluate two design prototypes, pitting the Dojo/DWR solution against GWT. Within one day of development time, the GWT solution was working, and looked great. Not only that, but the code was clean, straightforward Java code, readable and maintainable by every team member. With IDs and CSS classes assigned through the DOM interface, we could both test our app through Selenium and style it easily. Additionally, we were able to keep the vast majority of our JSP page structure and just attach our GWT module to a specific point in the DOM.
(2) Scalability and Maintenance
As development progressed, we continued to evaluate each feature, initially using GWT only when we needed something beyond the scope of standard forms. As our code base grew, the team figured it could enhance our interfaces by refactoring some of our GWT UI Code into a common library. This allowed us to leverage our knowledge of Java and our development platforms while making it easy to keep our UI design consistent. Eventually, our code base was rich enough and the development team fluent enough with GWT that it became our de-facto development platform for the user interface. Whether it's allowing our users to transform a scheduled list of data into a calendar format, create on-the-fly filters for large data sets, or build graphical overlays for image-based content, GWT has consistently proven to be a great decision for us. It's even allowed us to do things like this to browse help movies within the application.
The speed with which we can develop features using GWT was an encouraging first step, as it worked within our two-week iterative process. For long-term success, however, issues would need to be resolvable by any member of the team in a timely fashion. Enabling Java programmers to develop complex user interactions means that any skilled engineer can do it, not just developers with resumes heavy in JavaScript, Dojo, and CSS. As issues arise in QA, any developer on the team is fully equipped to take them on, encouraging team code ownership and removing bottlenecks that often pop up when niche skill sets are required by the project.
(3) Testing Practices
Our development process relies heavily on unit and acceptance testing before handing an iteration off to QA. The GWT-generated content allows Selenium to easily access and manipulate the DOM structure within the test cases. With the ability to assign IDs to various DOM elements through Java code as well as JSNI methods for the setup of various states associated with asynchronous calls, we were able to create a structure for acceptance testing which allowed us to programmatically drive these complex interfaces.
Our QA staff also uses our testing framework to build their own regression suites, and while this is probably a perfectly natural thing to do, it might be worth pointing out that GWT does nothing to limit us, or force us to use any additional syntax or code to do so. Trivial things like declaring: public static final String SAVE_BUTTON_ID = "saveButton"; ...go a long way when you can directly reference that String in your production GWT code as well as your unit tests and Selenium tests.
public static final String SAVE_BUTTON_ID = "saveButton";
Conclusion
The decision to turn to GWT for our front-end solution was a leading factor in our success over the past year which was recognized in The Forrester Waveª: Email Marketing Service Providers, Q4 2007. We're up to 17 GWT modules and 33,000 lines of GWT code although we're hoping to apply some of the performance techniques from the conference to reduce that. In nearly a year of running live in production, we have risen to over 60 live customers represented by over 740+ application users, and have added several new clients since the launch of version 6 of our product. Our projections for growth are strong, and we're looking forward to building on our technology over the next year. Cheers!
(Update: I've added the link in to one of YesMail's widgets, which "things like this" was supposed to point to but got dropped somewhere while I was posting. Also, thanks Scott Anderson and Manny Ju for helping out with this writeup on YesMail.)
