Feature:

How to make an HTML5 developer smile: A Google Web Designer wish list

By Cameron McKenzie

TheServerSide.com

On June 4th, 2013, Neal Mohan, Google’s Vice President of Display Advertising, made a single mention in the official DoubleClick Advertiser blog about a new software development tool that is about to emerge "in the coming months" called "Google Web Designer (GWD)." The blog entry was pretty nascent on details, other than to state that GWD is intended "to help advertisers and publishers more seamlessly unlock the potential of cross-device programs." Since the development community can only speculate about the functions and features this new tool will provide, speculate is exactly what the industry will do. The following is a wish list of the top five features that would seriously go a long way towards simplifying cross device, HTML5 web development and should be included in any, modern day web development and design tool.

1. Vendor prefix aggregation and consolidation

If GWD wants to provide a new tool for developing cross-device, HTML5 applications, they first need to create a tool that can seamlessly deal with all of the incompatible prefixes that various browsers use to implement modern features. While the big players in the browser market can boast about support for various HTML5 and CSS3 constructs, their dirty little secret is that the implementation is done in a non-standard way. Take a look at the following monstrosity of code that is required to perform a simple, three dimensional transformation on a solitary DIV element.

#ridge .slice {
  transform: translateZ(-25px) rotateY(-50deg);
  -webkit-transform: translateZ(-25px) rotateY(-50deg);
  -moz-transform: translateZ(-25px) rotateY(-50deg);
  -ms-transform: translateZ(-25px) rotateY(-50deg);
  -o-transform: translateZ(-25px) rotateY(-50deg);
}
Exactly what Google Web Designer will be when it is released remains a mystery.

Cameron McKenzie, Editor-in-Chief of TheServerSide

The various vendor prefixes that are required are verbose and unmanageable. Furthermore, their mere multitude introduces a greater potential for coding errors to occur, making maintenance and troubleshooting much more difficult than it needs to be. Sure, there are excellent third party tools on the market such as CSSPlease and Prefixr that can be used to help generate vendor prefixes, but they are just that: third party. If Google wants to simplify web design and development, advanced CSS3 prefix support, maintenance and migration capabilities must be fist order functions of the tooling.

2. Pre-compilation tools for stylesheets

Another glaring issue with the stylesheet snippet above is the repetitive nature of the literal values of -25 and -50. Finding out that the transition on both the Z and Y axis should be -30, instead of -25 and -50 respectively, means ten changes to the code. This theoretically could be achieved simply by performing a Find and Replace for this example, but as stylesheets become more complicated, and common settings span across multiple text files, the Find and Replace method runs out of steam pretty quickly. Again, there are third party alternatives available that perform these functions, with Syntactically Awesome Stylesheets (saas) and lesscss being two of the most popular, but whether it's the fact that saas requires a Ruby based installer, or the added complexity of using a third party tool like Less, web developers find the need for installing tool after tool after tool to be tedious and cumbersome. A CSS3 preprocessor and pre-compiler is an absolute necessity for any modern web development tool.

3. Transparent feature checking

Worse than the proliferation of vendor prefixes is the fact that there are still a variety of CSS3 and HTML5 features still are not globally supported, regardless of the availability of vendor prefixes. Something as basic as decorating content with a simple, image based border is completely hit and miss with the latest browsers. It's an effect that works great with Firefox, but current versions of Safari and Chrome lack an implementation altogether. Predicting browser support becomes even more difficult when prior versions, increments and browser updates are factored into the mix. It would seem that the JavaScript library modernizr is currently the go-to standard for performing HTML5 feature checking in modern browsers, but not everybody is interested in adding another open-source JavaScript library into their mix. Whether Google Web Designer leverages this library internally, or they take a more proprietary approach, the requirement persists.

Google is a company that is interested in advertising dollars, and every project they promote pads that bottom line.

Cameron McKenzie, Editor-in-Chief of TheServerSide

Of course, identifying the various features that a browser will support is only half of the HTML5 development battle, which takes us to our next requirement, which involves the art of how to deal with browsers that don't implement the HTML5 features that are required.

4. Graceful feature degradation

Being able to identify the various features that an older browser might not support is a good start, but it is just that: a start. Effective web developers know that discovering a given HTML5 or CSS3 feature is not where their job ends, but it is actually where the tough part of their job begins. For example, a browser might not support HTML5 drag and drop functionality. If that's the case, there should be a fallback plan where a YUI or jQuery library is loaded and used to implement the same, but perhaps limited, functionality. Given the number of features that are defined by the HTML5 specification, along with the multitude of ways to implement those features with JavaScript, Java Applets or other browser based technologies, a web developer can be easily overwhelmed. If Google Web Designer really wants to bring feature full web development to the masses, they should be paying a great deal of attention on how to ensure all users, regardless of the browser or version they are using, will enjoy the greatest, feature filled experience possible.

5. WYSYWIG Responsive Design Tooling

Responsive design, a development approach that allows a single user interface to realign and contort itself so that it can be rendered effectively on everything from a 1080p big screen television to the smallest of handheld devices is a vision that has become a reality through HTML5 flexible boxes, CSS3 media queries and to a lesser extent, JavaScript frameworks like Twitter's Bootstrap.js and Zurb's Foundation. These technologies are incredibly effective, but they do come with a requisite learning curve. Furthermore, maintaining and updating a responsive design that may have been created by a fellow developer can be a challenge. Any new web development and design tool not only needs to support the technologies that make responsive designs happen, but they must also provide effective, visual tools that make maintenance and feature enhancements a more standardized process. A WYSYWIG responsive design creation and development tool is an absolute must.

Of course, exactly what Google Web Designer will be when it is released is still a mystery. At it's core, Google is a company that is interested in advertising dollars, and every project they promote has padding the bottom line as the primary, if not sometimes obfuscated, directive. Despite what the development community might be wishing for in a new web design studio from Mountain View, Google Web Designer may be nothing more than a cross-platform plugin that simply makes it easier to drop DoubleClick ads into Android and iPhone applications. But until it's eventual release, there's nothing wrong with hoping for a feature filled development tool that will empower the web developer to create the next generation of HTML5 based web applications.

What features do you hope to see in Google Web Designer? Let us know.

07 Sep 2013

Related Content

Related Resources