Skip navigation
Help

web coding

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
Joseph Alessio

  

In the first installment of this two-part series on type classification, we covered the basics of type classification — the various methods people have used, why they are helpful, and a brief survey of type history, classifying and identifying typefaces along the way. Unfortunately, we only got as far as Roman (traditional serif) typefaces and the early-19th century. Now we’re back for part 2!

Part 2 will primarily cover sans typefaces, with a nod to display typefaces and other less common categories, as well as address a few of the questions people have about whether type classification is helpful and necessary.

If you haven’t read part 1, now’s your chance to go over it. It lays important groundwork for this article, covers the categories of serif typefaces, and contains plenty of useful information about the development of serif type. If you already have read it, here is a quick recap to get us started before we move on to the new material.

type classification

Review

Type Classification Systems

Type has been classified in many ways over the years, both formal and informal — Thibaudeau, Vox, British Standards, etc. None of these are complete or all-encompassing, but they’re helpful as an aid to study as well as for learning to use type correctly and effectively. The material in this two-part series draws heavily from the Vox-ATypI system, which is the most “official” of the systems today, having been adopted by the Association Typographique Internationale in 1962 and still the most commonly referenced system.

Is it perfect? No, but it provides a good overview of what is out there; and when you describe typefaces using the terms you’ll learn in this series, anyone who is reasonably familiar with typography will know what you’re talking about.

Here is a quick overview of the type categories we covered in part 1.

Humanist/Venetian

Venetian Typeface Characteristics

  • Notable calligraphic influence, patterned after handwriting.
  • Strongly angled axis or stress.
  • Based on typefaces designed in Renaissance cultural hubs such as Venice.

Garalde

Oldstyle Typeface Characteristics

  • Less calligraphic influence because type began to be viewed as separate from writing.
  • Named after influential type designers Claude Garamont and Aldus Manutius.
  • Still has a tilted axis but less obvious than in Humanist type.

Transitional/Neoclassical

Transitional Characteristics

  • No calligraphic influence. Designed independently, sometimes on a grid.
  • First appeared in the late-17th century.
  • Virtually vertical axis and high contrast between heavy and thin strokes.

Didone

Didone Characteristics

  • Extreme contrast between thick and thin. Rigidly vertical axis.
  • Abrupt, or unbracketed, serifs. Very precisely designed.
  • Named after Firmin Didot and Giambattista Bodoni.

Slab Serif

Slab Serif Characteristics

  • Very heavy weight and low contrast between thick and thin.
  • Unbracketed, prominent serifs.
  • First typefaces created expressly for display purposes.

Sans Serifs

When we left off in part 1, it was circa 1815, with the first appearances of slab serifs, also called Mechanistics or Egyptiennes. By the time slab serifs were being popularized, early sans serifs had already been around for some time in a variety of forms. To follow the progression of sans serifs, we must step back in time a number of years.

History of Sans Serifs

The earliest sans-serif letterforms were, of course, not type, but inscriptions, dating back to as early as the 5th century BC, and enjoyed a resurgence in engraving and inscriptions in the 18th century.

etruscan type
Caslon’s Etruscan type, as seen in a 1766 specimen book. Larger view. (Image source: Typefoundry)

Strangely enough, the first “sans serif” type was created not for the Latin alphabet, but for use in 18th-century academic works on Etruscan culture, which preceded the Roman Empire in the geographical area of modern-day Italy. Circa 1748, the foundry of William Caslon (with whom you should be familiar) cut the first known sans-serif Etruscan type for the Oxford University Press, although there are earlier usages of sans serifs in similar applications.

Embossed Type
Haüy’s type, created to emboss pages so as to be read by touch, was oddly ornate for its purpose. Larger view. (Image source: Camille Sourget)

Another interesting typographic innovation was the work of Valentin Haüy, who founded a school for blind children in 1785. In 1784, a year of preparation during which he devoted himself to educating a single student, Haüy developed an embossing typeface with which to make tactile books. The typeface, which, along with his method, is called the Haüy System, is an early form of sans serif, but it reads more like an upright italic or a disconnected script.

It was first embossed and then often carefully inked over the top so that it could also be read visually, as in the photo above. It looks lovely, but was superseded in both practicality and readability by the system devised by Louis Braille, himself a student at the school Haüy founded.

Caslon Sans
William Caslon IV’s sans serif was categorized as “Two Lines English Egyptian,”. (Image source: typophile)

William Caslon IV — who inherited the type foundry, as well as his name, from four generations back — is credited with the first sans-serif printing type for the Latin alphabet, appearing first in the 1816 Caslon specimen book. It featured only capitals and was marketed as “Two Lines English Egyptian,” the “Two Lines” being a reference to the size of the set type. There was much confusion over this new style, being variously called Egyptian (despite early slab serifs also being marketed as Egyptians), Gothic, Grotesque and Antique, among others.

Figgins Sans Serif
A sans from an early Vincent Figgins type specimen. Larger view. (Image source: Typefoundry)

Eventually Vincent Figgins (whom you may remember as being credited with the first slab-serif type) called the new style “sans serif,” which became the widely accepted term, although you’ll see many of the old terms in use on some typefaces.

Classifying Sans Serifs

At first glance, you might think that sans serifs can’t be classified the way that serifs can, since fewer variables are apparent in the ones we see most often. However, plenty of details can aid specificity when discussing, using and pairing typefaces, even within the broader category of sans serifs or, as Maxmilien Vox termed them, “linéales.” Subcategories were implemented by the British Standards classification, a permutation of Vox’s system, and they provide excellent means of discerning characteristics. I am presenting here a slight variation of those four, with a couple of minor differences for the sake of practicality.

Grotesque

The Grotesque category covers the early sans serifs, specifically those designed in the 19th century and the first decade or two of the 20th. Many of these typefaces had only capitals or exist only in centuries-old specimen books, but a number of them are still quite commonly used. These typefaces tend to be very idiosyncratic, with awkward weight distribution around bowls of characters and irregular curves.

Monotype Grotesque
(Image source: MyFonts)

Monotype Grotesque (above, 1926), based on Berthold’s much earlier Ideal Grotesque (1832), is an excellent example of the quirks commonly evident in Grotesques. Note the awkward “a” and “g,” the squarish bowls, the odd curves and angles at the tips of strokes in the “J” and “S,” and the overall irregularity.

The capital G in a Grotesque is usually spurred, and the British Standards specifies a curled leg on the capital R, although that is not apparent in many typefaces of the period. They tend to display some variation in the thickness of strokes, but the contrast does not show calligraphic influence or a logical pattern. The style became more sophisticated over the course of the 19th century. Perhaps the finest sample of this category appeared in the Berthold Type Foundry’s 1896 release of Akzidenz-Grotesk, which, along with Schelter Grotesk (1886), served as an archetype for many Neo-Grotesques, most notably Neue Haas Grotesk and Univers.

grotesque

Interestingly enough, it has been postulated that Akzidenz-Grotesk was based on Walbaum or Didot. Despite looking extremely different at first glance, a simple comparison of the basic forms shows that the metrics are very similar.

Examples of the Grotesque category include Franklin Gothic, Monotype Grotesque and Schelter Grotesk.

Neo-Grotesque

The Neo-Grotesques, also called Transitionals or Realists, include many of the most commonly used sans. They are based on the later Grotesques and take the design of the sans-serif to a new level with their careful construction and aesthetics. They are much more refined than the Grotesques, during which period type designers were still feeling their way around the new style; thus, the Neo-Grotesques lose many of the awkward curves and idiosyncrasies that are common in earlier sans serifs. You’ll see much less variation in line weight, and most often a single-story “g.”

neo-grotesque

Created with an emphasis on neutrality and simplicity, they were extraordinarily popular among the Modernists and remain popular today. Despite many claims otherwise, simplicity does not directly translate into legibility: A tight vertical rhythm and pinched apertures keep many Neo-Grotesques (including Helvetica) from being good choices for body text. In fact, in the 2013 edition of the DIN 1450 (the German standards on legibility in typefaces, published by the Deutsches Institut für Normung), Helvetica is used as a negative standard. That’s an entirely different topic, however.

In 1957 — a big year for Neo-Grotesque sans serifs, as Frutiger’s Univers as well as Folio (originally thought to be a stronger competitor, although history has proved otherwise) were released — Haas Foundry released Max Miedinger’s Neue Haas Grotesk, which drew heavily on Schelter and Akzidenz Grotesks. In 1960, Haas, in an effort to market it more effectively, rebranded Neue Haas Grotesk to what we know as one of the most ubiquitous typefaces of all time — you guessed it — Helvetica.

helvetica specimen
Many people love Helvetica so much that they’ll hang prints of vintage Helvetica specimens as decoration. (Image source: etsy)

The quintessential members of this group are, of course, Univers and the immortal Helvetica, which has gone through quite a number of permutations over the years (as have all of these typefaces) and was recently revived by Christian Schwartz as a rerelease of Neue Haas Grotesk. A nice informational minisite was created by Indra Kupferschmid and Nick Sherman for the release. Other typefaces in this category include the DIN 1451 and its derivatives, and Bell Gothic and its successor Bell Centennial.

Humanist

If you remember the most important quality of Humanist serif type, you’ll be relieved to learn that the same quality carries over to the sans serifs! The primary characteristic of Humanist type, both serif and sans serif, is a strong calligraphic influence, basing its shapes and flow on forms that could originate from a pen or brush. This means a much higher stroke contrast, and some Humanist sans even feature some stress, whereas nearly all other sans serifs have a completely vertical axis.

Another interesting characteristic of Humanist sans serifs is that their proportions often derive largely from Roman inscriptions and early serif typefaces, rather than 19th-century sans serifs as the Neo-Grotesques did. Because of this design process involving older letterforms, the lowercase “a” and “g” are most often two-story in Humanist sans serifs. All of these characteristics combine to make most Humanists a more legible choice than other types of sans faces.

Humanist Sans (Optima)

Hermann Zapf’s Optima is one example that clearly shows the calligraphic heritage, with an unusually obvious difference between thick and thin strokes, while many others in this category have more subtle features. The Humanist sans group includes classics such as Gill Sans and Frutiger as well as more recent releases like Myriad (1991), Trebuchet (1996) and Calibri (2005).

Geometric

Geometric sans serifs are exactly what their name suggests. Instead of being derived from early Grotesques, like a Neo-Grotesque, or from calligraphic and engraved forms like the Humanist sans, they are built on geometric shapes. The characters often have optically circular bowls and are otherwise typically very rectangular, sharing many components between the various glyphs.

Erbar Grotesk
Erbar’s small x-height, among other factors, renders it difficult to read. Larger view.

Jakob Erbar, whose eponymous typeface is credited as being the first Geometric sans, reportedly based his construction on the circle. Released in the 1920s, Erbar-Grotesk was intended to be legible. Ironically, because of the awkward visual rhythm, resulting from strict adherence to geometric forms, Geometric lineals are among the least legible of sans serifs and are usually suitable only for display type. Geometric sans serifs usually show little or no stroke contrast and usually feature a single-story lowercase “a.”

Geometric Sans

Paul Renner’s Futura, Koch’s Kabel and Lubalin’s Avant Garde are typical examples of the style. H&FJ’s Gotham is also a Geometric sans, although it is less strictly geometric than some and allows for more variation in the heavier weights.

The Rest Of The Story

That’s the basic classification for sans serifs! While the two parts of this series primarily deal with serif and sans type, there are many other styles to consider. The Vox-ATypI system also provides five subcategories of “calligraphics” (i.e. type that is derived from handmade letters), but as they are largely self-explanatory, I won’t dedicate much space in this already lengthy article to them. Here is a brief summary of each category.

Scripts

Script Metal Type
A case of script metal type. (Image source:
Etsy)

Scripts are, of course, typefaces based on handwriting, particularly formal scripts. The letters often connect, but not necessarily so. They range from the very formal — Matthew Carter’s Snell Roundhand, named after the author of a 1694 booklet on penmanship, originally released in 1966 — to the very casual — Ashley Havinden’s eponymous Ashley Script, from 1955.

Glyphic

Trajan Inscription
Carol Twombly’s Trajan was based on this inscription at the base of Trajan’s Column in Rome.

Glyphic typefaces are those derived from engraved or chiseled letters. Many of these typefaces look like they could be classified as serifs but are based on the work of a chisel, rather than having gone through the traditional design process and referencing the stroke of a pen. As such, Glyphics, also called “incised” typefaces, sometimes contain only capitals, and the serifs tend to be small, as a natural detail of the chiseling process rather than as a design feature. Trajan and Friz Quadrata are excellent examples of this style.

Graphic

Graphic Wood Type
Graphic wood type from the extensive Hamilton Wood Type collection.

Graphic is essentially a sort of catch-all label for display type that doesn’t fit into any other category. It includes anything that would be drawn or designed, with a brush, pen or any sort of tool. If it’s not exactly a sans, not exactly a serif, and you’re not really sure what it is, it is most likely a Graphic typeface!

Blackletter

Gutenberg Bible
Gutenberg printed with type designed to mimic the late-medieval Fraktur style of handwriting. (Image credits: JMWK)

Blackletter type began with Gutenberg and was used in printing, even printing body text, until the early- to mid-20th century in Germany. It is based on a medieval scribal hand, written with a broad-nib pen, and differs from graphic typefaces and scripts in that it has been used at length in body text. It has a very dense type style. When the traditional style that Gutenberg had used began to give way to the more readable early serifs (the Humanist/Venetian designs of Aldus Manutius and his colleagues), printers called the new style “Whiteletter,” in reference to the negative space-to-ink ratio on the page; thus, the old type was termed Blackletter, and we still use this term today.

Gaelic

Gaelic Type
Gaelic type includes the Latin alphabet as well as some additional glyphs. Larger view. (Image source: mathewstaunton)

Gaelic type is based on the insular script found in manuscripts throughout the UK. As with Blackletter, it has been used in printing body text in Ireland, from its earliest appearances in the 16th century all the way through to the mid-20th century, but is no longer popular as a text typeface. The Vox-ATypI system was amended to include the Gaelic category in 2010 at the ATypI annual conference, appropriately held in Dublin.

Non-Latin Type

Beyond that, there is still another world of type to discover. The entirety of these two articles on the subtleties of type (and, believe me, it can get much more complicated!) have discussed only the Latin alphabet, which, while quite commonly used, is merely one of many writing systems used today. I encourage you to learn more about, and get involved in, the typography of other writing systems! Some are very widespread and used daily by hundreds of millions of people; others are used by mere thousands.

Regardless of how many people use it, each writing system needs quality typefaces. From the commonly used (check out Nadine Chahine’s interview on Arabic type) to the rarely seen (Jean-Baptiste Levée gave a fascinating talk at last year’s TypeCon on creating Air Inuit Sans, supporting Inuktitut glyphs), the typography of non-Latin writing systems promises an exciting future.

Closing Remarks

We’ve barely scratched the surface of the fascinating subject of typography and type history in this two-part series “Making Sense of Type Classification.” Hopefully, it has piqued your interest in this intriguing field. Knowing your way around the typographic resources available to today’s designers is essential, and it is helpful to understand a little behind the characteristics, history, visual character and idiosyncrasies that make each typeface unique and that define how it communicates.

At one point in the history of Web design, an extensive knowledge of type history was unnecessary because a Web or interactive designer was limited to half a dozen typefaces, and those in limited weights and variants.

Today, however, the landscape of Web design is completely different, and the typographic possibilities are endless! Also, while this material is covered in many design schools, a significant portion of designers today haven’t had a formal design education, so now is the best time to catch up!

That being said, we also must remember that, while type classification is an important aid to studying type, it is not a hard and fast system that cannot be questioned. Many typefaces combine characteristics and could easily fit into multiple categories, and no classification system can cover all of the possibilities. In the end, type classification is an excellent means of learning to recognize common patterns and distinguishing characteristics of typefaces, and we get to learn some type history along the way.

With this short series, you’re now equipped with a strong knowledge of categories of type; you’ve learned to analyze typefaces and pick out unique aspects of letterforms; you’ve seen how type has evolved with culture; and, most importantly, you have a solid foundation for further study of typography and type history! It cannot be overstated how immensely important sound knowledge of typography is for anyone in the broad field of design, and the material we’ve covered here will serve you well in navigating the world of type.

(al) (ea)

© Joseph Alessio for Smashing Magazine, 2013.

0
Your rating: None
Original author: 
Lars Kappert

  

We are talking and reading a lot about responsive Web design (RWD) these days, but very little attention is given to Web applications. Admittedly, RWD still has to be ironed out. But many of us believe it to be a strong concept, and it is here to stay. So, why don’t we extend this topic to HTML5-powered applications? Because responsive Web applications (RWAs) are both a huge opportunity and a big challenge, I wanted to dive in.

Building a RWA is more feasible than you might think. In this article, we will explore ideas and solutions. In the first part, we will set up some important concepts. We will build on these in the second part to actually develop a RWA, and then explore how scalable and portable this approach is.

Part 1: Becoming Responsible

Some Lessons Learned

It’s not easy to admit, but recently it has become more and more apparent that we don’t know many things about users of our websites. Varying screen sizes, device features and input mechanisms are pretty much RWD’s reasons for existence.

From the lessons we’ve learned so far, we mustn’t assume too much. For instance, a small screen is not necessarily a touch device. A mobile device could be over 1280 pixels wide. And a desktop could have a slow connection. We just don’t know. And that’s fine. This means we can focus on these things separately without making assumptions: that’s what responsiveness is all about.

Progressive Enhancement

The “JavaScript-enabled” debate is so ’90s. We need to optimize for accessibility and indexability (i.e. SEO) anyway. Claiming that JavaScript is required for Web apps and, thus, that there is no real need to pre-render HTML is fair (because SEO is usually not or less important for apps). But because we are going responsive, we will inherently pay a lot attention to mobile and, thus, to performance as well. This is why we are betting heavily on progressive enhancement.

Responsive Web Design

RWD has mostly to do with not knowing the screen’s width. We have multiple tools to work with, such as media queries, relative units and responsive images. No matter how wonderful RWD is conceptually, some technical issues still need to be solved.

start-image_mini
Not many big websites have gone truly responsive since The Boston Globe. (Image credits: Antoine Lefeuvre)

Client-Side Solutions

In the end, RWD is mostly about client-side solutions. Assuming that the server basically sends the same initial document and resources (images, CSS and JavaScript) to every device, any responsive measures will be taken on the client, such as:

  • applying specific styles through media queries;
  • using (i.e. polyfilling) <picture> or @srcset to get responsive images;
  • loading additional content.

Some of the issues surrounding RWD today are the following:

  • Responsive images haven’t been standardized.
  • Devices still load the CSS behind media queries that they never use.
  • We lack (browser-supported) responsive layout systems (think flexbox, grid, regions, template).
  • We lack element queries.

Server-Side Solutions: Responsive Content

Imagine that these challenges (such as images not being responsive and CSS loading unnecessarily) were solved on all devices and in all browsers, and that we didn’t have to resort to hacks or polyfills in the client. This would transfer some of the load from the client to the server (for instance, the CMS would have more control over responsive images).

But we would still face the issue of responsive content. Although many believe that the constraints of mobile help us to focus, to write better content and to build better designs, sometimes it’s simply not enough. This is where server-side solutions such as RESS and HTTP Client Hints come in. Basically, by knowing the device’s constraints and features up front, we can serve a different and optimized template to it.

Assuming we want to COPE, DRY and KISS and stuff, I think it comes down to where you want to draw the line here: the more important that performance and content tailored to each device is, the more necessary server-side assistance becomes. But we also have to bet on user-agent detection and on content negation. I’d say that this is a big threshold, but your mileage may vary. In any case, I can see content-focused websites getting there sooner than Web apps.

Having said that, I am focusing on RWAs in this article without resorting to server-side solutions.

Responsive Behavior

RWD is clearly about layout and design, but we will also have to focus on responsive behavior. It is what makes applications different from websites. Fluid grids and responsive images are great, but once we start talking about Web applications, we also have to be responsive in loading modules according to screen size or device capability (i.e. pretty much media queries for JavaScript).

For instance, an application might require GPS to be usable. Or it might contain a large interactive table that just doesn’t cut it on a small screen. And we simply can’t set display: none on all of these things, nor can we build everything twice.

We clearly need more.

Part 2: Building RWAs

To quickly recap, our fundamental concepts are:

  • progressive enhancement,
  • responsive design,
  • responsive behavior.

Fully armed, we will now look into a way to build responsive, context-aware applications. We’ll do this by declaratively specifying modules, conditions for loading modules, and extended modules or variants, based on feature detection and media queries. Then, we’ll dig deeper into the mechanics of dependency injection to see how all of this can be implemented.

Declarative Module Injection

We’ll start off by applying the concepts of progressive enhancement and mobile first, and create a common set of HTML, CSS and JavaScript for all devices. Later, we’ll progressively enhance the application based on content, screen size, device features, etc. The foundation is always plain HTML. Consider this fragment:


<div data-module="myModule">
    <p>Pre-rendered content</p>
</div>

Let’s assume we have some logic to query the data-module attribute in our document, to load up the referenced application module (myModule) and then to attach it to that element. Basically, we would be adding behavior that targets a particular fragment in the document.

This is our first step in making a Web application responsive: progressive module injection. Also, note that we could easily attach multiple modules to a single page in this way.

Conditional Module Injection

Sometimes we want to load a module only if a certain condition is met — for instance, when the device has a particular feature, such as touch or GPS:


<div data-module="find/my/dog" data-condition="gps">
    <p>Pre-rendered fallback content if GPS is unavailable.</p>
</div>

This will load the find/my/dog module only if the geolocation API is available.

Note: For the smallest footprint possible, we’ll simply use our own feature detection for now. (Really, we’re just checking for 'geolocation' in navigator.) Later, we might need more robust detection and so delegate this task to a tool such as Modernizr or Has.js (and possibly PhoneGap in hybrid mode).

Extended Module Injection

What if we want to load variants of a module based on media queries? Take this syntax:


<div data-module="myModule" data-variant="large">
    <p>Pre-rendered content</p>
</div>

This will load myModule on small screens and myModule/large on large screens.

For brevity, this single attribute contains the condition and the location of the variant (by convention). Programmatically, you could go mobile first and have the latter extend from the former (or separated modules, or even the other way around). This can be decided case by case.

Media Queries

Of course, we couldn’t call this responsive if it wasn’t actually driven by media queries. Consider this CSS:


@media all and (min-width: 45em) {
	body:after {
		content: 'large';
		display: none;
	}
}

Then, from JavaScript this value can be read:


var size = window.getComputedStyle(document.body,':after').getPropertyValue('content');

And this is why we can decide to load the myModule/large module from the last example if size === "large", and load myModule otherwise. Being able to conditionally not load a module at all is useful, too:


<div data-module="myModule" data-condition="!small">
    <p>Pre-rendered content</p>
</div>

There might be cases for media queries inside module declarations:


<div data-module="myModule" data-matchMedia="min-width: 800px">
    <p>Pre-rendered content</p>
</div>

Here we can use the window.matchMedia() API (a polyfill is available). I normally wouldn’t recommend doing this because it’s not very maintainable. Following breakpoints as set in CSS seems logical (because page layout probably dictates which modules to show or hide anyway). But obviously it depends on the situation. Targeted element queries may also prove useful:


<div data-module="myModule" data-matchMediaElement="(min-width: 600px)"></div>

Please note that the names of the attributes used here represent only an example, a basic implementation. They’re supposed to clarify the idea. In a real-world scenario, it might be wise to, for example, namespace the attributes, to allow for multiple modules and/or conditions, and so on.

Device Orientation

Take special care with device orientation. We don’t want to load a different module when the device is rotated. So, the module itself should be responsive, and the page’s layout might need to accommodate for this.

Connecting The Dots

The concept of responsive behavior allows for a great deal of flexibility in how applications are designed and built. We will now look into where those “modules” come in, how they relate to application structure, and how this module injection might actually work.

Applications and Modules

We can think of a client-side application as a group of application modules that are built with low-level modules. As an example, we might have User and Message models and a MessageDetail view to compose an Inbox application module, which is part of an entire email client application. The details of implementation, such as the module format to be used (for example, AMD, CommonJS or the “revealing module” pattern), are not important here. Also, defining things this way doesn’t mean we can’t have a bunch of mini-apps on a single page. On the other hand, I have found this approach to scale well to applications of any size.

A Common Scenario

An approach I see a lot is to put something like <div id="container"> in the HTML, and then load a bunch of JavaScript that uses that element as a hook to append layouts or views. For a single application on a single page, this works fine, but in my experience it doesn’t scale well:

  • Application modules are not very reusable because they rely on a particular element to be present.
  • When multiple applications or application modules are to be instantiated on a single page, they all need their own particular element, further increasing complexity.

To solve these issues, instead of letting application modules control themselves, what about making them more reusable by providing the element they should attach to? Additionally, we don’t need to know which modules must be loaded up front; we will do that dynamically. Let’s see how things come together using powerful patterns such as Dependency Injection (DI) and Inversion of Control (IOC).

Dependency Injection

You might have wondered how myModule actually gets loaded and instantiated.

Loading the dependency is pretty easy. For instance, take the string from the data-module attribute (myModule), and have a module loader fetch the myModule.js script.

Let’s assume we are using AMD or CommonJS (either of which I highly recommended) and that the module exports something (say, its public API). Let’s also assume that this is some kind of constructor that can be instantiated. We don’t know how to instantiate it because we don’t know exactly what it is up front. Should we instantiate it using new? What arguments should be passed? Is it a native JavaScript constructor function or a Backbone view or something completely different? Can we make sure the module attaches itself to the DOM element that we provide it with?

We have a couple of possible approaches here. A simple one is to always expect the same exported value — such as a Backbone view. It’s simple but might be enough. It would come down to this (using AMD and a Backbone view):


var moduleNode = document.querySelector('[data-module]'),
    moduleName = node.getAttribute('data-module');

require([moduleName], function(MyBackBoneView) {
    new MyBackBoneView({
        el: moduleNode
    });
})

That’s the gist of it. It works fine, but there are even better ways to apply this pattern of dependency injection.

IOC Containers

Let’s take a library such as the excellent wire.js library by cujoJS. An important concept in wire.js is “wire specs,” which essentially are IOC containers. It performs the actual instantiation of the application modules based on a declarative specification. Going this route, the data-module should reference a wire spec (instead of a module) that describes what module to load and how to instantiate it, allowing for practically any type of module. Now, all we need to do is pass the reference to the spec and the viewNode to wire.js. We can simply define this:


wire([specName, { viewNode: moduleNode }]);

Much better. We let wire.js do all of the hard work. Besides, wire has a ton of other features.

In summary, we can say that our declarative composition in HTML (<div data-module="">) is parsed by the composer, and consults the advisor about whether the module should be loaded (data-condition) and which module to load (data-module or data-variant), so that the dependency injector (DI, wire.js) can load and apply the correct spec and application module:

Declarative Composition

Detections for screen size and device features that are used to build responsive applications are sometimes implemented deep inside application logic. This responsibility should be laid elsewhere, decoupled more from the particular applications. We are already doing our (responsive) layout composition with HTML and CSS, so responsive applications fit in naturally. You could think of the HTML as an IOC container to compose applications.

You might not like to put (even) more information in the HTML. And honestly, I don’t like it at all. But it’s the price to pay for optimized performance when scaling up. Otherwise, we would have to make another request to find out whether and which module to load, which defeats the purpose.

Wrapping Up

I think the combination of declarative application composition, responsive module loading and module extension opens up a boatload of options. It gives you a lot of freedom to implement application modules the way you want, while supporting a high level of performance, maintainability and software design.

Performance and Build

Sometimes RWD actually decreases the performance of a website when implemented superficially (such as by simply adding some media queries or extra JavaScript). But for RWA, performance is actually what drives the responsive injection of modules or variants of modules. In the spirit of mobile first, load only what is required (and enhance from there).

Looking at the build process to minify and optimize applications, we can see that the challenge lies in finding the right approach to optimize either for a single application or for reusable application modules across multiple pages or contexts. In the former case, concatenating all resources into a single JavaScript file is probably best. In the latter case, concatenating resources into a separate shared core file and then packaging application modules into separate files is a sound approach.

A Scalable Approach

Responsive behavior and complete RWAs are powerful in a lot of scenarios, and they can be implemented using various patterns. We have only scratched the surface. But technically and conceptually, the approach is highly scalable. Let’s look at some example scenarios and patterns:

  • Sprinkle bits of behavior onto static content websites.
  • Serve widgets in a portal-like environment (think a dashboard, iGoogle or Netvibes). Load a single widget on a small screen, and enable more as screen resolution allows.
  • Compose context-aware applications in HTML using reusable and responsive application modules.

In general, the point is to maximize portability and reach by building on proven concepts to run applications on multiple platforms and environments.

Future-Proof and Portable

Some of the major advantages of building applications in HTML5 is that they’re future-proof and portable. Write HTML5 today and your efforts won’t be obsolete tomorrow. The list of platforms and environments where HTML5-powered applications run keeps growing rapidly:

  • As regular Web applications in browsers;
  • As hybrid applications on mobile platforms, powered by Apache Cordova (see note below):
    • iOS,
    • Android,
    • Windows Phone,
    • BlackBerry;
  • As Open Web Apps (OWA), currently only in Firefox OS;
  • As desktop applications (such as those packaged by the Sencha Desktop Packager):
    • Windows,
    • OS X,
    • Linux.

Note: Tools such as Adobe PhoneGap Build, IBM Worklight and Telerik’s Icenium all use Apache Cordova APIs to access native device functionality.

Demo

You might want to dive into some code or see things in action. That’s why I created a responsive Web apps repository on GitHub, which also serves as a working demo.

Conclusion

Honestly, not many big websites (let alone true Web applications) have gone truly responsive since The Boston Globe. However, looking at deciding factors such as cost, distribution, reach, portability and auto-updating, RWAs are both a huge opportunity and a big challenge. It’s only a matter of time before they become much more mainstream.

We are still looking for ways to get there, and we’ve covered just one approach to building RWAs here. In any case, declarative composition for responsive applications is quite powerful and could serve as a solid starting point.

(al) (ea)

© Lars Kappert for Smashing Magazine, 2013.

0
Your rating: None