Teach Me Something

I am constantly reading articles with new tips, techniques and best practices in our industry, and I spend many nights and weekends outside of normal office hours working to master these new techniques. When I discover an article or idea that I think is valuable, I always share it with the rest of my team. And I love it when others on the team return the favor.

When a new employee shares a worthwhile article or an approach that I had not considered, they demonstrate their passion and their dedication to growing in the industry. It also shows that they are willing not only to learn, but also to teach others.

Check Your Work

I appreciate when a team member completes a task quickly, but speed doesn’t trump accuracy. Too often, in an attempt to impress their manager, new team members will race through a task to show how efficient they are. They submit work before really going over it to make sure that all of the tasks have been completed correctly.

Checking your work before submitting it to a manager for review probably sounds like common sense, but it’s one of the biggest problems I hear about from other team leaders and managers. Work that is missing key elements or that has little errors (spelling mistakes are common) or whose functionality hasn’t been fully tested (broken links, forms that do not submit properly, etc.) are major headaches for many team leaders. A manager would rather the person finish the task a bit more slowly if the bulk of the errors could have been caught by a more thorough review.

Before you submit work as being complete, give it a once over to make sure that everything works as intended.

Mind The Clock

Web design is not a 9:00 to 5:00 job. Sometimes, inspiration or a breakthrough strikes at the end of the day. If you punch the clock exactly at 5:00, you could lose any momentum or spark of creativity you may have had, when instead you should nurture the moment. Other times, a deadline is looming that requires extra hours in the office. You need to accept that the day doesn’t always end at 5:00.

It goes both ways, though. An employee who is willing to stay late and put in extra effort when needed will be recognized and appreciated, but don’t stay at your desk 12 hours a day, only to go home and do more work there.

The server is also the appropriate place to segment your content to avoid sending unnecessary data over the network and to improve performance. Lastly, you can update the server transformation engine and keep it consistent, instead of dealing with potentially different quirks and levels of XSLT support among browsers. (For example, while XSLT 1.0 is supported in most browsers, XSLT 2.0 is not supported in any, although Saxon-CE is one attempt to add it via JavaScript.)

Second, XSLT’s roots in functional programming make it inaccessible to the average Web developer. It isn’t simply a matter of learning a new syntax. The recursive processing model of XSLT requires a new way of thinking that is unfamiliar to developers of imperative languages, especially developers from a design background who do not have formal training in computer science.

Finally, a larger challenge is that this technique works only for Web pages that are in XHTML (a flavor of HTML that is XML-compliant), because XSLT can transform only XML, not HTML. According to W3Techs, 55% of websites are in XHTML. While this is a majority, it still leaves out a large number of websites. In fact, for this retrofitting example, I worked around this limitation by running Hacker News’ HTML code through an HTML to XHTML converter.

In the next section, we’ll explore how the Tritium transformation language was built to address these issues.

In the example above, we’ve used transformations in the browser to create a responsive experience for an existing website, but conceptually the two approaches overlap. Because responsive Web design is itself about changing presentation across multiple screen sizes, transformations can help in that process as well. Instead of simply pairing different CSS styles to the same fixed HTML as in typical responsive design, we can leverage transformations to change the HTML across devices.

As we explored earlier, the ability to manipulate the HTML (which is missing from CSS alone) not only creates flexibility but actually improves the separation between presentation and content. As a result, maintainability becomes easier because the content is more semantic and less tied to layout. In essence, think of this as moving the breakpoints in responsive design to the transformation layer.

At Moovweb, we’ve leveraged these insights about transformations to implement a technique called responsive delivery, which draws inspiration from responsive Web design, RESS and adaptive design. With responsive delivery, transformations are used to adapt an existing website to different touch points, such as smartphones and tablets.

In reaction to this news, most Web developers would likely shrug and say “So what?” That’s unfortunate.

Transformations are a simple yet powerful technique for separating content and presentation in Web applications. Yet, outside of enterprise and data-processing circles, transformations have failed to gain popularity through XSLT. As a result, Web developers are liable to think that transformations “don’t apply to me,” even though they work with HTML, a structured format ripe for transformation. Thankfully, new transformation frameworks are on the horizon, including work by the inventor of Sass, that hold the promise of a revival.

In this article, we will reintroduce transformations and explore their applications to mobile and responsive design. We will not only teach the old dog new tricks, but show that transformations are relevant to everyone who deals with HTML.

For more on Enlive, I recommend David Nolen’s excellent tutorial. But the key point is that content and presentation have been decoupled. Website changes, A/B tests and even a redesign could be as easy as getting new HTML from your designer and dropping it in. In addition, the designer doesn’t need to know anything about the templating language and may use HTML classes and IDs, concepts that they already know.

While you don’t need to build a website in this way, the situation is analogous to building a Web page without a style sheet. True, you could design a page purely with inline styles (that is, using only the style attribute), and novice developers often code this way out of expediency. But experienced developers know that a style sheet improves workflow and productivity at scale.

Similarly, by separating content and presentation, you will unlock more productivity and agility for your team. In effect, transformations truly separate the front end from the back end and create a new workspace for the visual design team to operate independently of the rest of the system. In an industry where even simple things like the color of a button can affect conversion rates, enabling your visual design team to iterate more quickly and continually could deliver tremendous value to the bottom line.

Transformations are not just useful in a templating system. This decoupling of content and presentation can also be applied to an existing website, enabling developers to apply a new presentation regardless of how the original website was built. This combination of separating content and presentation and its applicability to existing websites is what makes transformations so powerful and useful to a broader audience than currently use them. I’ll illustrate this by responsively retrofitting an existing website using a transformation technology that’s in every browser today (at least for now), XSLT.

XSLT was introduced in the late 1990s as a language for transforming XML and XHTML documents. During the ascendency of XML, XSLT was seen as a solution for separating content and presentation in Web applications built on XML data formats. The W3C recommended XSLT as a standard, and almost every major browser incorporated support for some form of the language.

Now that Google’s Chrome and Blink team has proposed dropping support for XSLT, some might be concerned about using it long term. However, at the time of writing, XSLT is supported in all major browsers, including Chrome and the latest versions of the iPhone and Android browsers. In addition, XSLT may be used both server- and client-side. Server-side implementation works regardless of browser support, and open-source and commercial XSLT engines are available. Finally, JavaScript implementations of XSLT, such as Saxon-CE, could also fill the gap client-side if Google does indeed decide to drop support for XSLT.

Responsive retrofitting is the process of grafting responsive Web design techniques onto an existing website that was not built to be responsive. Although a lot of resources and tutorials on building a responsive website from scratch are out there, retrofitting has curiously received far less attention, despite its enormous value. A lot more old websites exist than new ones, and significant capital and effort have been invested in them.

The natural first step would be to retrofit the website purely in CSS. Ben Callahan’s bookmarkletfor example, inserts a custom CSS file to make a given website more responsive. However, adding CSS gets you only so far. Eventually, the layout, nesting and order of elements in the original HTML will restrict your design options. John Shirrel describes this as an inherent flaw of CSS:

Since learning is a lifelong task that doesn’t stop after pursuing a certain academic certificate, this round-up is not only dedicated to beginners. It’s for everyone who wants to become an expert in a certain field or is simply curious about the Web and the latest tools and techniques around them.

We hope that this round-up will bring you closer with many of the valuable resources that are available out there. Some are completely free while others can be obtained through quite affordable memberships. You may also be surprised to find that your local college or university is also publishing free classes and courses on all sorts of topics you can think of — make sure to keep an eye open!

Instead of wondering how to style headings, you could look to the style guide for answers. As your design grows and you add elements, putting all of the elements on one page will help to ensure that they look like they were all crafted by the same hand — or at least look consistent. The secondary benefit is that you won’t have to solve the same design problem multiple times.

If you work on a team or for a client, handing off the document to someone else is very easy. You’ve already done the work of specifying how things should look; so, anyone else can step in and pick up where you left off.Speaking of which, if you’ve ever applied a CSS class or ID to an HTML element, then you’ve basically written a style guide — even if you didn’t necessarily formalize it as such.

When you’re presenting a design to a client or team, use the style guide to guide your presentation. A lot of people are talking about style tiles, style prototypes and element collages these days; there’s no reason why a style guide can’t fit in there. It’s a great way to help someone visualize what a product will look like without having to design every screen.

The short answer is: a lot of people. Companies use them; banks generate reams and reams of documentation on how the logo should be implemented and which pixels should go where. While extending a brand across a wide range of products and services is complex, a small company typically does not need such extensive documentation yet still would benefit from consolidating its design standards into a single set of guidelines, a style guide.