Skip navigation
Help

web technologies

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

By Dominique Hazaël-Massieux: People used to stare at me and laugh, back in 2005 when W3C launched its Mobile Web Initiative to advocate the importance of the web to the mobile world. Now I am the one smiling much of the time, as I did most recently during the 2013 edition of the Mobile World Congress (MWC) in Barcelona, one of the largest events to focus on mobile devices and networks.

This year W3C had a huge HTML5 logo splashed across its booth to emphasize the impact of the Open Web Platform across industries and devices. But the real adoption story was told by the HTML5 logos prominent at many, many other booths. The web has gained real visibility on mobile, and we should all be smiling because we are all getting closer to a platform for reaching more people on more devices at lower cost.

MWC 2013 also confirmed that HTML5 has broken out of the browser. We are seeing more and more HTML5-based development platforms, such as PhoneGap, Windows 8, Blackberry, and Tizen. Mozilla’s big announcement at MWC 2013 centered on FirefoxOS, Mozilla’s mobile operating system entirely based on web technologies. W3C and Intel partnered to create a T-shirt that says “I See HTML5 Everywhere.” And indeed, I do.

The challenge of mobile

Not only has the web a big role to play on mobile, mobile has also a key role to play for the web. As more and more of our connected interactions start or end on mobile devices, we must ensure that the web platform adapts to our mobile lives. I believe this is critical for the future of the web.

For many years W3C has designed technology to make the experience of web users on mobile ever more rich, adapted, and integrated. For example, CSS media queries provide the basis for responsive web design. There is already a lot for mobile, and a lot more is coming. To help people follow all the activity, every quarter I publish an overview of web technologies that are most relevant to mobile.

These technologies are the tools designers can rely on to build the user experience they need. But technologies are only a small piece of the puzzle when it comes to making the web user experience work on mobile devices. The number of A List Apart articles about mobile development provides a clear sign that this challenge is driving creativity in the design community. Responsive web design, mobile first, future friendly, and just-in-time interactions are some of the trends that have resonated with me over the years. The creativity is fantastic, but we still want our lives to be easier. Where web technologies do not yet provide the hooks you need to practice your craft, please let us know. Feel free to write me directly: dom@w3.org.

Closing the gap

Another challenge that we, the web community, face on mobile is the amazing energy devoted to native development.

The web has displaced a lot of the native software development on traditional computers; on mobile, the reverse trend has happened. Content that users had enjoyed on the web for years started to migrate to native applications: newspapers, social networking, media sharing, government services, to name a few. And to add insult to injury, a number of these content providers are pushing their users away from their website toward their native application, with obtrusive banners or pop-ups.

It is unclear where the world is going on mobile: some statistics and reports show a strong push toward moving back to the web (e.g., the recent Kendo UI survey), while others argue the opposite. What is clear to me, though, is that we cannot afford to let mobile become a native-entrenched ecosystem.

What has made the web unique and popular in so many hearts is not the technology (some great, some terrible) nor even the ubiquity (since interoperability can reduce it). I believe the much more fundamental importance of the web comes from its structural openness: anyone can publish the content they see fit and anyone can participate in defining the future of the web as a platform.

Native ecosystems on mobile have historically been very closed ecosystems, under the control of single commercial entities. A world where the majority of our information and infrastructure would be trapped inside these ecosystems is not something we should accept lightly. Mind you, I appreciate the innovations spawned by these platforms, but we need to encourage the cycle where innovations become standards, and those standards prime the platform for the next innovations.

Of course the best way to shift the balance to the web is to make the web the best platform for mobile. Achieving this will require ideas and energy from many people, and web developers and designers play a critical role in shaping the next generation of web user experiences. I am leading a focused effort in W3C to assess what we can and should do to make the web more competitive on mobile, and welcome feedback and ideas on what the missing pieces in the puzzle are.

Beyond mobile

I believe a key part in making the web the “king of mobile” is to realize that mobile devices are a means to an end. In our connected world—computers, phones, tablets, TVs, cars, glasses, watches, refrigerators, lightbulbs, sensors and more to come—mobile phones will most likely remain the hub for while. The only platform that can realistically be made available on all these devices is the web.

We have a unique opportunity to make the Open Web Platform a success. I realize getting it right will not be trivial. Building user experiences that scale from mobile (or watches!) to TV is complex. Building user experiences that adapt to these very different type of interactions will be hard. Matching the needs from users in a growing diversity of contexts will make us cringe. Creating user experiences that abolish the devices barrier (as I explored some months ago) is guaranteed to create more than a few headaches.

But there is unprecedented momentum to create an open platform for the planet. And that has me smiling a lot.

0
Your rating: None

Vexing Viewports

“The Web is Agreement.” Jeremy Keith’s eloquent statement neatly summarizes the balance that makes it possible for us to build amazing things. Each week, new devices appear with varying screen sizes, pixel densities, input types, and more. As developers and designers, we agree to use standards to mark up, style, and program what we create. Browser makers in turn agree to support those standards and set defaults appropriately, so we can hold up our end of the deal.

This agreement has never been more important.

That’s why it always hurts when a device or browser maker does something that goes against our agreement. Especially when they’re a very visible and trusted friend of the web—like Apple.

You see, Apple’s newest tablet, the iPad Mini, creates a vexing situation: Its device-width viewport tag defaults to the same values as Apple’s original iPad (768x1024 pixels), even though the Mini's screen is physically 40 percent smaller. That means every button, graphic, link, and line of text on a web page on the iPad Mini appears tiny—even when we try to do the right thing and build flexible, multi-device experiences.

Two iPads, one too small.

But Cupertino isn’t the only culprit out there. This is a problem that’s been brewing since we started using the viewport—and it has to do with not just pixels, but our own practices as well. Let’s take a step back and understand what’s really causing today’s woes—and what all of us need to do about it.

The trouble with pixels

Today’s viewport woes can be traced right back to pixels—yes, those tiny elements we work with every day.

The first pixel challenge is quantity. The more pixels in the display, the more information can be displayed. But as these are physical pixels whose number can’t be altered after the fact, a second factor comes into play: the screen’s physical size.

Imagine two two-inch-wide displays (about the width of the iPhone), as shown below.

Two devices, each with a two-inch-wide display. The one on the right, at 640x960, would pack four times as many pixels into the same space as the 320x480 screen on left.

The first is 320x480 pixels, the second 640x960. This gives the second display four times as many pixels as the first, but fits all of them into the same physical space. This smaller pixel size results in content that is also smaller—making it crisper, but much harder to read as well.

This is exactly what happened on the Nokia E60. In 2005, most mobile phone displays were about an inch and quarter wide, with an average of 176 pixels in that width. But the E60, which sported a “huge” 352x416-pixel display, crammed twice the number of pixels into a similar amount of space. The result: A gorgeous, crisp—but often hard-to-read—display.

The E60 also introduced a now-familiar problem: how users would manage to surf “big” sites on a tiny device. Nokia’s solution was a new browser, the Mini Map. This browser behaved similarly to today’s smartphone browsers by first rendering the full-sized page, then scaling it to fit the available screen size. Superimposed onto this rendering was a transparent red box that could be repositioned using the device’s joystick. Clicking the joystick would zoom the content indicated within the box.

Enter viewports

Mini Map was probably one of the first commercial uses of a dynamic viewport—a construct designed to dynamically change the size or scale of the visible screen area in order to improve the user experience. But it was far from the last.

In 2007, Apple released the iPhone, a much larger device than the E60, but one with a similar problem. Even on a “huge” two-inch display, surfing the “real web” on an iPhone meant loading large pages onto a small device. Apple chose to solve this problem through a series of carefully orchestrated enhancements.

The first was the creation of a virtual viewport similar to the one Nokia designed for Mini Map. When encountering desktop websites, the browser would render them at their full size (based on a default canvas width of 960 pixels). It would then scale them down to fit the two-inch display. Users could interact with the page to scroll and zoom in on areas of their choice.

Apple didn’t stop there. It also developed a new viewport meta tag. Sites not using the tag would be rendered using the default, legacy-web viewport of 980 pixels. But developers who opted to use the tag could declare the viewport for their sites, including setting the width to the all-important device-width value. This value tells the browser, “please pick a width that fits this specific device’s screen best.”

Other mobile browser vendors were quick to follow Apple’s lead. Nowadays just about every mobile browser supports the viewport meta tag, including the device-width value. This provides us with an even playing field: It respects the efforts of those who take the time to adapt sites for the multi-device web, while those who haven’t yet made this transition still receive a “good-enough” default experience.

Mini problems

The value device and browser vendors assign to device-width is directly related to that device’s physical dimensions. Physically smaller devices need a smaller device-width value (which will result in larger content). Set a value that’s too large, and most content will be too small to comfortably read.

And that’s why Apple’s iPad Mini has a vexing viewport. It uses the same 768-pixel device-width as the regular iPad, even though its physical size is much smaller. One would expect to see a device-width more in line with those of similarly sized tablets like the BlackBerry PlayBook or second-generation Samsung Galaxy 7″—around 500 to 600 pixels, as shown in this chart.

Because of this device-width, web pages appear 27 percent smaller on the iPad Mini than they do on the Google Nexus 7 (calculated based on the relative size of device pixels)—all because Apple decided to describe the device’s viewport as 768 pixels.

Solving for content size

One of the first places this causes problems is in text: More pixels in a smaller space means that fonts sized in pixels will look correspondingly dinky.

Of course, many of us aren’t sizing in pixels anymore—we’re using relative dimensional elements like ems, right? Only, that doesn’t quite solve the problem this time.

When we use ems, we imply a certain trust that the browser’s baseline font size at the default zoom level—1em or 100 percent in unit parlance—is sane and readable. But that’s not always the case. The browser’s baseline font-size value (1em) roughly equates to a 16-pixel square. This ratio serves as a ligament that binds absolute and relative units, but it can vary from browser to browser.

On the iPad Mini, font-size at baseline is precisely 16 pixels. That may have worked fine when fewer pixels were packed into our screens, but on a dense display with an improperly defined viewport, that’s going to be uncomfortably small.

Not all browsers toe the 1:16 em-to-pixel line, though. The Kindle Touch’s browser, for example, has a high-density viewport, but adapts by using a 1:20 ratio, kicking the default font size up a few pixels for readability.

This might not fix all of iPad Mini’s viewport problems, but at least the content would be legible.

Three seven-inch tablets. Note the difference in rendering.

So why did Apple do this?

To understand why Apple would release a product with such a vexing viewport, we don’t have to look further than our own habits.

In the wake of the iPad’s initial release, web folk worldwide scrambled to adapt sites to look good on the new tablets. Somewhere along the way many of us collectively settled upon pixel-based notions of tablet-ness, and those notions often resulted in fixed, 1024x768-pixel layouts precisely targeted at these devices.

Were Apple to decrease the device-width value for the iPad Mini on account of its smaller physical size, it would guarantee a second scramble as existing tablet-adapted sites assuming a 1024x768 viewport suddenly looked unexpectedly wretched on the new device.

The responsibility here goes two ways. Browser makers need to provide reliable baselines of viewport and text sizing, yes. But we as implementers also need to stop grasping for pixel-perfect control over our layouts (the “control” is an illusion, anyway).

A way forward

The only way for us to move forward is together. As developers and designers, we need to hold up our end of the bargain and be mindful of how we do our work—and that means letting go of the notion of pixel precision once and for all. We need to earn the trust of browser makers so they hear us out when things just frankly aren’t right. We hope this article illustrates we’re trying to do the right thing. We hope browser makers acknowledge that and follow suit.

Standards and consistency are more important now than ever before. Please let browser makers and device manufacturers, like Apple, know that we rely on consistent and reliable decisions about default viewports and their zooming. We’re willing to hold up our end of the agreement, and we need them with us.

Let’s move into the future—together.

RSS readers: Don't forget to join the discussion!

0
Your rating: None

HTML5 Logo

Today, the Worldwide Web Consortium (W3C) is announcing that it’s completed its three-year quest to finalize the HTML5 specification. As the W3C says in its press release, "HTML5 is the cornerstone of the Open Web Platform," the cross-platform programming environment usually referred to by the umbrella term "web standards." HTML5 and related technologies like JavaScript and CSS provide a way to write rich web applications designed to run on any device that follows the specifications, and many companies are hitching their futures to the platform’s success. But despite the fact that the specification is now feature complete, meaning nothing more will be added to it, there is still a lot of work that needs to be done before HTML5...

Continue reading…

0
Your rating: None

  

Editor’s note: This is an introductory article about a book idea to be published by Smashing Magazine with Chris Heilmann. Check out what we propose as an idea — explaining a way to reconsider how we build websites to ensure they are leaner and more future-proof. At the end of the article, we’d ask you to fill out a quick survey to show your interest.

The Web as it is now is suffering from an obesity problem. If you surf the Web on a flaky mobile connection or some hotel wireless, you’ll find yourself a lot of times staring at a page or app that doesn’t do anything and doesn’t tell you what is going on either. The spinner in the tab or the URL bar seems to be the thing that gets the most mileage in browsers. Surfing with a net tab open in your developer tools shows you an incredible amount of data being sent for seemingly very simple end products.

Why is that? Shouldn’t years of Web development and advocacy about performance by Yahoo and Google and many others have born fruit and made us aware of how much each HTTP request costs? If you look at the final products, it doesn’t seem that way.


Image Credit: seelensturm.

Reasons For An Obese Web

There are a few reasons why our Web is on the chubby side, and most of them actually are possible for us as developers to change.

We Don’t Develop in Realistic Environments

Probably the main reason is that as developers, we work on fast and big computers connected to a fat line, and the first time someone tests our products on slow connections is during quality assurance (QA). And as QA is the first thing to get ditched when deadlines are not met, sometimes this never happens at all.

Clinging On to the Past

Another reason for the love handles on our Web products is a false sense of allegiance to outdated and old technology, namely browsers of the ’90s that refuse to go away. There are many attempted solutions to the problem of legacy environments, each of them with its own problems. The fact is that there are a lot of end users out there on terribly outdated computers with — in our view — bad browsers and probably limited connections. These users should not be blocked out, but they should also not dictate what we build.

Browser Differences

Another big reason is the annoyance of browser differences. There are not many Web technologies and APIs where all browsers are in agreement when it comes to supporting them, and many times we need to repeat code and fork and test to give the same functionality to all of them.

Embracing The Chaos And Celebrating Differences

The last point is the main mistake we make: instead of embracing the chaos that is the Web and our end users’ environments and abilities, we don’t seem to be able to give up on the dream of having a product that works and looks exactly the same everywhere.

My Browser Isn’t the World?

In the worst case, we try to achieve this by blocking out all the browsers we don’t like and proclaiming proudly that “everybody uses browser X and whoever doesn’t is an enemy of the modern web.” This, of course, is just lying to ourselves, and is based on the fleeting concept of a “modern web.” A lot of the most terrible web-based products out there were built years ago to only work in Internet Explorer (IE) 6, which was the bee’s knees at that time. It does not matter which cool hardware has a hardwired browser that is hot right now — we are making the same mistake again if we only build to one browser and lock out others.

Locking out any browser means actually writing more code to test for browsers, and it is almost impossible to reliably detect which browser is in use. If you want proof, just take a quick look at the user agent string of the Yandex browser, which contains the names of almost every browser engine out there:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.5 (KHTML, like Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5402 Safari/536.5

I hope we can agree that building for one browser (or engine) only works for you if you are targeting a certain market and group, and even then you are not safe from losing them in the near future.

Libraries Are The Future

Another attempt to achieve the dream of cross-browser uniformity is a strategy of abstraction, using libraries, polyfills and frameworks to allow us to write in one language and have all the browser-difference magic happen under the hood. For production use, this is a very good idea. In the long run, libraries should get us where we want to be — almost every software environment, sooner or later, is running using libraries that unify the access to hardware or data APIs. For app development, we need to define and nurture these libraries and use them to our advantage.

Built-In Redundancy

The issue we have now, though, is that libraries and abstraction frameworks are becoming the starting point, and in the case of simple websites with a bit of extra flair, they are not needed. We just started to use them without considering their impact or even forgot how to do things without them. And in many cases, a lot of the things we do with them are already available in the browser for us, we just need to use what is there instead of simulating it. Libraries themselves start to suffer from obesity, and in a lot of cases, the extra fat is the functionality to make legacy browsers do things they were never meant to do but that browsers based on the HTML5 specification have already built in.

Death By A Thousand Plugins

Misuse of abstraction of code is rampant these days. We use libraries and converters that allow us to write the least amount of code possible to achieve a lot. This comes with a price. The three lines we write in an abstracted language can result in dozens after conversion to browser-understandable code. It is very tempting to use 20 small scripts on our pages when all of them are just a few lines, but this amounts to a mass of HTTP requests and generated code that chokes the browser. As we never see this code, it doesn’t appear to be our mistake — we just wrote the least amount of code possible. Surely adding yet another script with just five lines of code can’t make a difference?

So this is where we should start thinking harder about what we do right now. We’ve become dependent on abstractions for the most simple things and follow a cult of adding lots of helper tools, as they make things much simpler and are needed for a product to be maintainable and able to grow. A lot of the best practices in Web development were found and defined by large companies who had to build products that are maintained across different countries and teams and have to stand up to the requests of millions of users. What is a best practice for the Yahoo homepage or Gmail does not necessarily have to be what makes your smaller product most effective.

Jonathan Snook has a great example of this when he talks about his SMACCS approach to writing CSS. He points out that almost every product starts with a reset.css file, but once finished, removing that file doesn’t show any difference at all because for the elements we use we do define the margin, padding and sizing.

A Vanilla Diet For The Web

So here is what I propose: we need to put the Web on a diet, using vanilla Web technology that comes with browsers. As Alex Russell put it in his talk at Fronteers this year, if we want to change the Web it is up to us to move it ahead, and using polyfills and libraries is a future tax we currently pay.

Every successful diet is connected with a change in lifestyle. For the Vanilla Web Diet, here is what I propose we can do to slim down the products we build. This will not be applicable to everything, of course, and there is a place to start with a library and an abstraction layer. As I said before, sooner or later we will have an environment where libraries allow us to build great apps and products. But for a simple website with a few enhancements, it is time we stop randomly putting things together because they look shiny or seem very small.

The principles of a vanilla Web diet:

  • Build on what works
    Our base layer should be HTML, plain and simple and doing the thing the product is meant to do. Something that looks like a button but doesn’t do anything is not helping our users. When everything else fails, HTML is the thing users get — let’s not deprive them of that.
  • Lack of support is an opportunity
    If an old browser cannot do something, it allows us to test for that and not give it that functionality. In 99% of cases, the functionality is a nice-to-have and not needed.
  • Browser-specific code cannot be trusted
    Every functionality you make dependent on browser-prefixed code adds to the landfill of code that breaks very, very soon.
  • Use a mix of technologies — each for what it does best
    It is very tempting to do everything in JavaScript, but it is not needed.
  • Ask questions
    Whatever you do should be wrapped in an “if,” making sure that only environments that can apply what you want get it.
  • Write as much as needed, not the least possible
    Let’s think about what we write before we write it, instead of adding lots of small, quick solutions.
  • It is not about what you can add — it is about what we can’t take away
    Basic functionality should always be there.
  • Usefulness beats consistency across browsers
    Instead of giving everyone the same experience, always consider what is the best way to ensure people can use what we build.
  • Load only what is needed
    Why should a browser get a library or a data file if it cannot do anything with it?
  • Analyzing effects beats adding FX
    If you want to add shiny things, make sure they can perform in a shiny fashion; nobody likes their browser to slow down for a laggy effect.
  • Strong foundations beat a possible future addition
    A lot of times we add a lot of code and interfaces to allow for a future that will need them. This future hardly ever comes about. Let’s build for the now.

A Quick Example: Adding A Video To A Website

Let’s take a simple example: adding a video to a page. Conditioned and burdened with years of Web development, our thinking might be:

  • HTML5 video is nice, as it is native to the browser, the controls are readily accessible and I could build my own controls using the JavaScript API that comes with it.
  • Older versions of IE, however, don’t play any HTML5 video, so I need to add a Flash fallback.
  • Furthermore, not all browsers support MP4, so I need to have the video in two formats, MP4 and WebM, as well as OGV if I want to support even older Firefox and Opera.

With these in mind, we’ll probably get a video player from GitHub and use that one. The video player would be clever enough to recognize what the current browser supports and write out a Flash video or a native video. It will not help with the codec and browser support issue, unless we also use a player that detects that and sends the correct format, like Vid.ly.

That makes everybody happy and ensures everyone can see the video, right? True, but it also adds a lot of overhead that is really not needed. Let’s think about the use cases here:

  • If I am on an old browser, do I want to load a JavaScript library, have some detection happening and get a Flash player? What if I have no Flash? I loaded a library for nothing and I still cannot get to the video at all.
  • If I am on a modern browser, I loaded a library, and if I have Flash enabled, then I will get a Flash player with all the memory consumption and initialization overhead (granted, this isn’t much, but on my MacBook Air for example, the fan mostly starts because of Flash).

A vanilla diet approach to this would be the following:


	
	
	
		Frolicking hedgehogs
	
	Click image above to download video

HTML5 video-capable browsers will show the video, and others will get an image preview linked to the video. This way, users on old computers and bad connections or browsers without HTML5 video capability will get an image and can watch the movie in the video app of their operating system. They can even do something else while the video is downloading instead of staring at a “buffering” message.

Is is too much work to have the video in two formats? Fine, use one and move the link out of the video tag — that way you offer the option to download the video to everyone on flaky connections:

 

	Frolicking hedgehogs

Download video (MP4, 3MB)

Don’t want your video to be downloadable? Use Flash or Silverlight. This will not stop anyone dedicated enough to download it, but it makes sure you’ve done your part in securing the content. It blocks quite a few potential customers and readers, though.

Another Example: Expandable News Items

A lot of times we use a JavaScript library to have some headings that, when clicked or rolled over, show some paragraphs below them. jQuery’s show() and hide() are meant for that and there are a myriad of plugins to give us that functionality.

If you want to do this in a vanilla Web diet way, there is no need for JavaScript. Let’s start with the HTML. There are many right and wrong ways to do this — lists, definition lists, headings and divs and so on. Many an hour was wasted on forums discussing what the perfect markup is for this. Taking a leaf out of Nicole Sullivan’s book, let’s apply some OOCSS and make ourselves independent of the element names by adding classes:


	Interesting news	
	

Amazing stuff happened

Now, in order to make these collapse and expand in a smooth way, all we need to do is apply some CSS:

.collapsible .content {
	overflow: hidden;
	max-height: 0;
	opacity: 0;
	transition: 1s;
}
.collapsible:hover .content,
.collapsible:focus .content {
	max-height: 200px;
	opacity: 1;
}

Here you can see some of the principles in action. Older versions of IE do not understand max-height or opacity, so they will never apply the styles that hide the content. The much larger max-height of the hover and focus states makes sure that the browser expands the content all the way (it will always go to the real height, the only problem you will have is when the content is higher than 200 pixels, so this is something to point out to whoever is maintaining the code). The transition of one second makes sure the browser does this smoothly instead of just showing the content. Browsers that don’t support transitions still show and hide the content. You can add browser-prefixed transitions, too. Firefox and IE10 already dropped the prefix for transitions and others will follow.

Now, if you want to add onclick functionality to the header, we need some JavaScript. First of all, though, we change our CSS to look for a class on the collapsible element instead of relying on hover. We also make the hiding dependent on a JavaScript class as we don’t want to hide the content in browsers that don’t fulfill all the requirements of our script.

.js .collapsible .content {
	overflow: hidden;
	max-height: 0;
	opacity: 0;
	transition: 1s;
}
.js .collapsible.show .content {
	max-height: 200px;
	opacity: 1;
}

When the user clicks the header, we want to add the class of show to the collapsible element, and then remove it the next time the user clicks. For this, all we need is a single event handler on the document. To remove and add the class, we could change the className property, but newer browsers have the much more flexible classList implementation. We test for the things we use in an if statement and end up with not much code at all:

if (addEventListener && 'classList' in document.body) {
 document.body.classList.add('js');
 document.addEventListener('click', function(ev){
   var t = ev.target;
   if (t.classList.contains('trigger')) {
     t.parentNode.classList.toggle('show');
   }
 }, true);
}

Older versions of IE don’t understand addEventListener(), so this will not be executed as we test for its existence. If classList is supported, we apply a click handler to the document. We then test for and toggle the show class to trigger the CSS change using classList whenever the element with the class trigger is clicked.

More?

Now here’s the idea: I am planning to write a book about this, published with and by Smashing Magazine. I really believe that there is a lot to be said about the things in HTML5 that browsers now give us and that allow us to write simple and effective code to release pragmatic products instead of adding a lot of code we just don’t need for what we want to achieve.

If you are interested, quickly fill out the survey below or drop us a comment and we’ll go ahead.

© Christian Heilmann for Smashing Magazine, 2012.

0
Your rating: None



Mozilla has teamed up with Web design studio Little Workshop to develop a Web-based multiplayer adventure game called BrowserQuest. The game is built with standards-based Web technologies and is designed to be played within a Web browser.

With the technical capabilities offered by the latest standards, Web developers no longer have to rely on plugins to create interactive multimedia experiences and application-like user interfaces. As we reported earlier this month, modern standards are making the Web an increasingly viable platform for game development.

BrowserQuest, which is built with JavaScript and HTML5, is a compelling demonstration of how existing standards can be used to create browser games. It uses the HTML5 Canvas element to render a tile-based 2D world, HTML5 audio APIs to support sound effects, WebSockets to facilitate communication with the backend server, and localStorage to save the player's progress.

The game's remote backend, which enables the real-time multiplayer gameplay, was coded in JavaScript and runs on top of Node.js. The load is balanced across multiple Node.js instances on three separate severs. At the time this story was written, the backend was successfully handling over 1,900 simultaneous players. The status of the BrowserQuest backend can be monitored through the game's real-time dashboard interface.

The developers focused on using widely-supported standards so that the game would work well across a wide range of desktop and mobile browsers. It works just as well on a tablet device, for example, as it does on a desktop computer.

The future looks even brighter, as there are a number of pending Web standards that will greatly enhance support for building games on the Web in the future. Features like 3D graphics and support for game controller peripherals, for example, could eventually take the browser beyond the realm of casual gaming. You can refer to Mozilla's wiki to see an overview of the work that the organization is doing to improve browser-based gaming. For more details about BrowserQuest, see the Mozilla Hacks blog or check out the backend server code on GitHub.

Read the comments on this post

0
Your rating: None

Pimpin’ ain’t easy; neither is self-critique. If you are passionate about what you create, it is impossible to completely disassociate yourself from your work in order to objectively evaluate and then improve it. But the ability to achieve “artistic distance”—that is, to attain a place that allows you to contemplate your design on its own merits—will enable you to improve your own work immeasurably and, ultimately, to cast off the immature shackles of ego. Learn to let your work shine by letting go of it. Acquire the knack of achieving artistic distance.

0
Your rating: None

  

As a Japanese person living in Europe, I’m sometimes asked: “Japanese is a difficult language, isn’t it?” Those asking are often surprised when my answer is a simple: “No, actually, it’s not.”

While it is true (at least to many Westerners) that Japanese is an exotic language, when compared to learning other European languages, it may seem harder because it has has no relation to their own language. But from my own experiences of learning English and German (and also from seeing some European friends learning Japanese), I can say with confidence that learning spoken Japanese is, in fact, not so difficult. The grammar is in many ways simpler than most European languages. Take for example the fact that we don’t have cases, grammatical genders, nor articles. However, reading and writing in Japanese is… well, not so simple.

While discussing typography we most often focus on English language problems, which is only natural considering that the majority of design material is written in English. However, a lot can be gleamed by looking at how other languages are used as part of communication and design — it helps to lend context and a different point of view.

Japanese Scripts

Modern Japanese is written in a mixture of three basic scripts: Kanji — which are Chinese ideographic symbols — as well as Hiragana and Katakana — two phonetic alphabets (syllables). There are a few thousand Kanji characters, while Hiragana and Katakana have 46 each. Although there is a basic rule for when to use which script, there are many exceptions, and what’s worse is that words written in Kanji have often multiple pronunciations, depending on the context or conjunction. This is hard enough for native speaker to get right every time, so I almost feel sorry for those non-natives who are learning to read and write Japanese.

Kanji, Hiragana and Katakana Japanese scripts
From top to bottom: Kanji is mainly used for the lexical elements: nouns, verb stems, adjective stems, and so forth; Hiragana has rounded letter shapes, which are mainly used for the grammatical elements of sentences such as particles, auxiliary verbs, and suffixes of nouns; Katakana has an angular letter shape, which is most often used for foreign words and also for the purpose of emphasis.

Some say that the “tragedy” started when Japan decided to “import” the Chinese writing system, inscribing it into their own language in the 3rd century.

Since Japanese is as different from Chinese as it is to any other language, simply using the Chinese writing system was not sufficient, and a more appropriate way of writing Japanese was sought out. Some Chinese characters began to be used not for their meaning, but purely for their phonetic value. So by the 9th century, Hiragana and Katakana scripts were derived from simplified Chinese characters that were used to write Japanese phonetically.

The story doesn’t end there. As if using three scripts isn’t enough, we write in both horizontal and vertical orientation.

Horizontal? Vertical? The Unique Case Of Japanese Typography

“Vertical or horizontal?” — when setting a piece of text in Japanese, this is a question that Japanese designers constantly need to ask themselves. Being able to use both vertical and horizontal writing orientations is something so normal for us native Japanese speakers that most of us won’t even stop to wonder why this is possible, or even when and how it was first introduced.

The identical piece of text set vertically (right) and horizontally (left).
The identical piece of text set vertically (right) and horizontally (left). When it is set vertically it’s read from top to bottom, as the lines go from right to left; when it is set horizontally, it is read from left to right, like in European languages.

In general, these two writing orientations have a clear usage: vertical for something “Japanese”, “traditional”, “novels and other humanistic writings”; horizontal for “contemporary”, “business documents”, “scientific & foreign language related writings” and so on. When a main text is set horizontally, the binding is on the left-hand side, and pages progress to the right, like books in Latin scripts. Traditional books in vertical setting are the other way around, with the binding at the right hand side, and pages progressing to the left. So when you handle a Japanese book, don’t confuse the front with the back!

A typical page layout of a Japanese paperback novel
A typical page layout of a Japanese paperback novel using a vertical setting. Ogai Mori (1913), “Abe Ichizoku”, Shincyo-bunko.

traditional calligraphy is always done vertically
With its organic flow, characters are often connected and have different heights and widths
Needless to say, traditional calligraphy is always done vertically. With their organic flow, characters are often connected and have different heights and widths — which makes it impossible to disconnect and align them horizontally. Calligraphy by Keiko Shimoda, 2011 (tsukushidesign.com)


Horizontal setting is preferred for scientific texts, mathematical texts and language related books, where words and phrases in foreign scripts and signs are often included, as they are more easily incorporated horizontally. The example (above) is a Japanese-English dictionary. (Pocket Comprehensive English-Japanese / Japanese-English Dictionary, 2000, Obunsha)

Where the efficient use of space is important — namely newspapers and magazines — both orientations are often combined. Although it may appear a bit chaotic, or even random to foreign eyes, these two directions are usually used in a systematic way as a means to indicate different text elements on a page. For instance, a main text is often set in a vertical setting, but headings and captions may be set in a horizontal setting.

A typical newspaper layout
A typical newspaper layout — the main text is vertical but headings, diagrams, tables, and captions are placed horizontally.

The same newspaper as above, but highlighting the vertical text (orange) and the horizontal text
The same newspaper as above, but highlighting the vertical text (orange) and the horizontal text (blue). © The Nikkei (May 8th, 2009)

In a way, it’s comparable to “typographic variants” which are found in Latin typography — in Latin script text one may use bold, italic, or a different font to differentiate things such as pull quotes from the main text, whereas in Japanese we can do this by using a different orientation. Publications which accommodate non-linear or complex text (as opposed to linear text, such as novels) seem to benefit in particular from having these two orientations, which allow the layout to be highly flexible, and also to create strong visual impact.

The extreme cases of “space-efficiency-oriented typography” are informational-heavy pieces of text, such as diagrams and signage — also exploiting the two directional orientations. The Tokyo Metro map (Fig 10) is a good example of this — as you can see, both orientations are used accordingly, so that everything fits best within the limited space.

Tokyo Metro Map.
Tokyo Metro map

Tokyo Metro map with more typography in differing directions.
Tokyo Metro route map. The large type on the top is the station name which is placed horizontally. The name of the metroline may be horizontal, but the name of the stops are placed vertically.

It’s true that in many cases they look quite chaotic and sometimes even aesthetically questionable to eyes that are used to “orderly” design. But it’s easy to appreciate the visual impact and energy they create — they remind you that effective, appealing informational design does not always have to look “neat and tidy”.

Letters from my friends
Letters from my friends: when it comes to handwriting, orientation is up to a personal preference or simply one’s “mood”. But when you are writing a more official letter, or writing to somebody who is much older than you, it’s probably safer to opt for vertical orientation.

What’s Happening On Screen-Based Media?

Since the introduction of horizontal writing in the Japanese language, print-based media and signage have been employing both of these writing orientations effectively, and in ways that complement one another. But what’s been happening to screen-based media? With a few exceptions — such as word-processing machines made exclusively for the Japanese text output, or subtitles for film and TV screens, which tend to use either depending on the background image — horizontal orientation has been the dominant choice.

The prime example of this is the Web: horizontal orientation has been used almost exclusively. For the past 15 years, I have hardly come across a website that uses vertical setting. Mobile phone screens also use a horizontal orientation. I believe this may be due to the relations of hardware, operating systems and user interfaces that have become the norm, all of which have been designed to work with horizontal writing. It feels somewhat awkward to see vertical writing while all the other elements on the screen, such as the menu bar and UI elements, are horizontal.

Needless to say, the technical limitations (the support of a vertical setting by browsers is a fairly recent introduction) have largely contributed to this too. Perhaps underestimated, maybe the biggest factor for not using vertical setting for screen-based media could well be the mental association with horizontal orientation being used for something “modern” and “contemporary”.

The Nihon Keizai Newspaper website.
The Nihon Keizai Newspaper website. Although the printed newspaper employs a vertical setting for the body texts, the web-version uses a horizontal setting.

A Japanese Tea Ceremony website
So far, even with content as Japanese as a tea ceremony, a website will use a horizontal setting. (Accessed Jan. 20th, 2012)

Will Vertical Writing Orientation Die Out?

Will vertical writing orientation die out from screen-based media? Or can it make a comeback, when the technological environment allows us to use vertical settings more easily? Many e-book apps on smart phones and tablets have already started using vertical settings. With its intuitive way of navigating the screen along with the lack of external input devices (and apps being able to have more flexible/responsive layout), vertical writing seems to be incorporated much more comfortably.

I’ve spent some time reading these e-books — and pleasantly surprised at how easy they are to read. Apart from the fact that you need to scroll the screen horizontally, it’s just as comfortable as reading “normal” or horizontally set text. In fact, it’s even better for some types of publications like novels, or Manga. Our association towards this type of content when compared to the vertical setting is pretty strong mdash; it would somehow feel “wrong” to see them set horizontally.

Amazon’s Kindle has yet to support the Japanese language, but apparently they’re on their way to doing so. If they seriously want to attract Japanese readers, it would be unthinkable for them not to support vertical setting.

Soseki Natsume's “Sanshiro”
Soseki Natsume’s “Sanshiro” (1908) e-book on iPhone.

Kotobuki Shiriagari's
Kotobuki Shiriagari’s “OSHIGOTO” (2010) e-book on iPhone.

The situation also seems to be slowly changing on the Web — some interesting attempts have been made in order to familiarize ourselves with Web pages that have vertical setting. One such example is Taketori, which works just like Google translate — you can type in the URL of a Web page you wish to see in vertical setting, and Taketori does it for you. There’s also a piece of software called Kagetaka, which can switch any Web text into a vertical orientation.

Personally, I’m not too sure how well vertical setting will be supported by the users of normal Web pages, unless the way we navigate Web pages is re-developed, or a new type of browser with more innovative UI appears. Even though I complained earlier about the difficulty of the Japanese writing system, I do appreciate its diversity and flexibility, while making use of its three scripts and two orientations allows us to express subtle nuances of content — and we have been benefiting from that for decades.

I thought it would be a shame if we lose these methods of textual articulation in an age of screen-based media. But what has been happening for the last couple of years on touch-screen mobile devices (as well as the Web) can reassure us that both writing orientations may happily co-exist and collaborate on screen in the future, just as they have done off-screen for the last hundred years.

Feel free to share your thoughts in the comments section below.

(jvb) (il)

© Shoko Mugikura for Smashing Magazine, 2012.

0
Your rating: None

Any -webkit- feature that doesn’t exist in a specification (not even an Editor’s draft) is not CSS3. Yes, they are commonly evangelized as such, but they are not part of CSS at all. This distinction is not nitpicking. It’s important because it encourages certain vendors to circumvent the standards process, implement whatever they come up with in WebKit, then evangelize it to developers as the best thing since sliced bread. In our eagerness to use the new bling, we often forget how many people fought in the past decade to enable us to write code without forks and hacks and expect it to work interoperably. Lea Verou explains why single-vendor solutions are not the same as standards and not healthy for your professional practice or the future of the web.

0
Your rating: None