<p><a href="http://www.igloosoftware.com/campaigns/alistapart">Igloo</a> is now free with up to ten people, helping you work better with your team and your clients. <a href="http://www.igloosoftware.com/campaigns/alistapart">Get your (responsive!) Igloo</a>, and start sharing blogs, calendars, files, forums, microblogs and wikis today. And as your Igloo grows, it&#8217;s only $12/person each month.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/mMOKelnXCko" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<a href="http://daverupert.com/2013/06/ughck-images/" style="font-size: 18px;">» Ughck. Images.</a><br><br>In a follow-up to his ALA article <a href="http://alistapart.com/article/mo-pixels-mo-problems">Mo’ Pixels, Mo’ Problems</a>, Dave Rupert talks about all the progress we've made toward responsive image solutions — by which he means no progress has been made.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/UHauHAHdSDY" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<a href="http://googlewebmastercentral.blogspot.com/2013/06/changes-in-rankings-of-smartphone_11.html" style="font-size: 18px;">» Google Changes Rankings of Smartphone Search Results</a><br><br>Google has started decreasing the ranking of sites with misconfigured mobile content redirects and errors. Highly recommended for any developer who cares about site rankings in Google (i.e. all of them).<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/2cKmN-l1KtU" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<a href="http://timkadlec.com/2013/06/why-we-need-responsive-images/" style="font-size: 18px;">» Why Do We Need Responsive Images? 72% Less Image Weight.</a><br><br>We all need to step up our responsive development game and start thinking more about page weight. The most obvious place to start? Images.<br><br>℅ <a class="attribution-link" href="https://twitter.com/respimg/status/344478943715393538">@respimg</a><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/gfuyt_VUnPw" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

W3C published today a report summarizing the Open Data on the Web workshop that took place in April. The report summarizes the major themes discussed and conclusions arising from them. Participants discussed how to bridge the gap between the worlds...[mehr] (Quelle: W3C News)

The Education and Outreach Working Group (EOWG) invites comments on a new draft document: Easy Checks - A First Review of Web Accessibility. Easy Checks helps you assess if a Web page addresses accessibility. It provides simple steps for anyone...[mehr] (Quelle: W3C News)

One aspect of mobile accessibility is how web browsers on mobile devices support the accessibility needs of people with disabilities. Accessibility of web browsers is covered in User Agent Accessibility Guidelines (UAAG). The User Agent Accessibility Guidelines Working Group (UAWG)...[mehr] (Quelle: W3C News)

The HTML Working Group has published an updated Working Draft of the HTML5 Image Description Extension. This specification defines the &quot;longdesc&quot; attribute that enables web authors to provide longer text descriptions for complex images. It is developed by the HTML...[mehr] (Quelle: W3C News)

The Web Applications Working Group has published two documents today: A Group Note of Widget Updates. This specification defines a process and a document format to allow a user agent to update an installed widget package with a different version...[mehr] (Quelle: W3C News)

<p>The history of technology innovation is the history of disruption. New technologies become available and disrupt the market for more-established, higher-end products.</p> <p>We’re witnessing one of the latest waves of technological disruption, as mobile devices put access to the internet in the hands of people who previously never had that power. Always-available connectivity through PCs and broadband connections has already transformed the lives of people who have it. Mobile internet will do the same for an even larger population worldwide.</p> <p>Despite examples from countless industries where disruption has taken place, it’s easy to pretend that it won’t happen to the web. Today’s mobile internet is janky. It’s slow. It’s hard to navigate. It offers only a paltry subset of what’s available on the desktop. It’s hard to imagine anyone truly preferring it.</p> <p>Clayton Christensen, author of <cite>The Innovator’s Dilemma</cite>, argues that lower quality and less-than-adequate performance is, in fact, at the heart of what makes disruptive innovation happen:</p> <figure class="quote"><blockquote>In industry after industry, Christensen discovered, the new technologies that had brought the big, established companies to their knees weren’t better or more advanced—they were actually worse. The new products were low-end, dumb, shoddy, and in almost every way inferior. But the new products were usually cheaper and easier to use, and so people or companies who were not rich or sophisticated enough for the old ones started buying the new ones, and there were so many more of the regular people than there were of the rich, sophisticated people that the companies making the new products prospered. Christensen called these low-end products “disruptive technologies,” because, rather than sustaining technological progress toward better performance, they disrupted it.</blockquote> <figcaption>Larissa MacFarquahar, <a href="http://www.newyorker.com/reporting/2012/05/14/120514fa_fact_macfarquhar">The <cite>New Yorker</cite></a> </figcaption></figure> <h2>Disruptive technologies aren’t competitive at the start</h2> <p>In terms of quality, disruptive technologies don’t compete. They often have a less-polished design or are crafted of lower-quality materials, equivalent functionality (like bandwidth or memory) costs more compared to earlier products, and they don’t perform as well on key metrics.</p> <p>People often point at the failings of the mobile internet as rationale for why it won’t overtake the desktop web. “No one will ever want to do that on mobile” gets used to justify short-sighted decisions. Truth is, we can’t predict all the ways that people will want to use mobile in the future. Jason Grigsby, co-author of <cite>Head First Mobile Web</cite> (with Lyza Danger Gardner) says “We can&#8217;t predict future behavior from a current experience that sucks.”</p> <h2>Disruption happens from the low end</h2> <p>Disruptive technologies take off because they create a new market for a product. People who previously could not afford a particular technology get access to it, in a form that (at least at the start) is less powerful and of lower quality. These people aren’t comparing between the more established technology and the new one. They have no other alternative.</p> <p>McKinsey estimates that the mobile internet could bring billions of people online:</p> <figure class="quote"><blockquote>However, the full potential of the mobile Internet is yet to be realized; over the coming decade, this technology could fuel significant transformation and disruption, not least from the possibility that the mobile Internet could bring two billion to three billion more people into the connected world and the global economy.</blockquote> <figcaption><a href="http://www.mckinsey.com/insights/business_technology/disruptive_technologies">Disruptive technologies: Advances that will transform life, business, and the global economy</a></figcaption> </figure> <h2>Disruptive technologies eventually improve</h2> <p>Over time, the quality of low-end technology improves. As more and more people buy into a cheaper, less-capable technology, more attention and focus goes toward refining it. Eventually, it overtakes its larger, more capable predecessor.</p> <p>This is the challenge we face in mobile right now. Mobile won’t always be a secondary device or a limited, on-the-go use case. Mobile will be the internet. Comparing its shortcomings to what the desktop web does well is missing the point. Mobile will be <em>better</em> than the desktop—but it will succeed on what it does uniquely well. </p> <p>McKinsey estimates the astonishing potential economic upside of the mobile internet:</p> <figure class="quote"><blockquote>We estimate that for the applications we have sized, the mobile Internet could generate annual economic impact of $3.7 trillion to $10.8 trillion globally by 2025. This value would come from three main sources: improved delivery of services, productivity increases in select work categories, and the value from Internet use for the new Internet users who are likely to be added in 2025, assuming that they will use wireless access either all or part of the time.</blockquote> <figcaption><a href="http://www.mckinsey.com/insights/business_technology/disruptive_technologies">Disruptive technologies: Advances that will transform life, business, and the global economy</a></figcaption> </figure> <p>Today, the mobile internet provides a lousy experience. For billions of people coming online across the world, it will be their first (and only) way to access the web. The history of disruptive innovation shows that it’s okay if the mobile internet provides a less-than-adequate experience today. Most mobile internet users won’t be comparing between the desktop web and the mobile web. For these people, the alternative is <em>nothing</em>. </p> <p>Tomorrow, the mobile internet will provide a better experience. It’s up to us to make it happen.</p> <p>&nbsp;</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/8N_c-7U9_M0" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

The W3C Advisory Committee has filled four open seats on the W3C Advisory Board. Created in 1998, the Advisory Board provides guidance to the Team on issues of strategy, management, legal matters, process, and conflict resolution. Beginning 1 July 2013,...[mehr] (Quelle: W3C News)

The HTML Working Group has updated three Working Drafts and published three Group Notes: a Working Draft of HTML 5.1. This specification defines the 5th major version, first minor revision of the core language of the World Wide Web: the...[mehr] (Quelle: W3C News)

The Technical Architecture Group has published the First Public Working Draft of URLs in Data Primer. This document describes how to define data formats and publish the information necessary to support an application in determining which mode is intended when...[mehr] (Quelle: W3C News)

The Web Application Security Working Group has published a Working Draft of Content Security Policy 1.1. This document defines a policy language used to declare a set of content restrictions for a Web resource, and a mechanism for transmitting the...[mehr] (Quelle: W3C News)

<p>Jeremy Keith notes that what happens between the breakpoints is just as important as the breakpoints themselves—perhaps even more so. While I agree with this, we do have to start somewhere. In a way, this part of the process reminds me of storyboarding, or creating animation keyframes, with the in-between frames being developed later. We’re going to do that here.</p> <aside class="supplement"><strong>Major breakpoints</strong> are conditions that, when met, trigger major changes in your design. A major breakpoint might be, for example, where your entire layout must change from two columns to four.</aside> <p>Let’s say you’ve chosen three basic design directions from your thumbnails. Think about what your <strong>major breakpoints</strong> will look like (Figure 7.6). And here’s the key: <em>try to come up with as few major breakpoints as possible</em>. That might sound crazy, since we’re talking about responsive design. After all, we have media queries, so let’s use about 12 of them, right? No! If a linear layout works for every screen and is <em>appropriate</em> for your particular concept, then there’s no need for different layouts. In that case, simply describe what will happen when the screen gets larger. Will everything generally stay the same, with changes only to font size, line height and margins? If so, sketch those. For these variations, make thumbnails first, explore some options, and then move on to larger, more detailed sketches. Use your breakpoint graph as a guide at first and make sketches according to the breakpoints you’ve estimated on your graph.</p> <p>When thinking about major breakpoints, remember to think about <em>device classes</em>. If you’re thinking about smartphones, tablets, laptops/desktops, TVs, and game consoles, for example, you’re heading in the right direction. If you’re thinking in terms of brand names and specific operating systems, you’re on the wrong track. The idea is to think in terms of general device classifications and, sometimes, device capabilities. Capabilities are more important when designing web applications, since you should be thinking about what screens will look like both with and <em>without</em> any particular capability.</p> <p><strong>Rough sketches</strong> of major breakpoints can help you determine:</p> <aside class="supplement"><strong>Rough sketches</strong> are more detailed than thumbnails, but they shouldn’t take a long time to create. In a short period, you should have a sketch of each major breakpoint for each of your chosen designs. This should be enough to decide on one of the designs.</aside> <ul> <li>Whether or not more major breakpoints are needed</li> <li>Which design choice will be the most labor intensive; you might opt for a design that will better fit within time and budget constraints</li> <li>Whether or not a particular device class has been neglected or needs further consideration</li> <li>What technologies you’ll need to develop the design responsively</li> </ul> <figure data-picture data-alt="Figure 7.6"> <div data-src="/d/376/ch07-06_small.png" data-media="(max-width: 700px)"></div> <div data-src="/d/376/ch07-06_small_retina.png" data-media="(max-width: 700px) and (min-device-pixel-ratio: 2.0)"></div> <div data-src="/d/376/ch07-06_full.png" data-media="(min-width: 701px)"></div> <div data-src="/d/376/ch07-06_full_retina.png" data-media="(min-width: 701px) and (min-device-pixel-ratio: 2.0)"></div> <!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. --> <noscript><img src="/d/376/ch07-06_full.png" alt=""></noscript> <figcaption>Figure 7.6: Most websites need very few major breakpoints.</figcaption> </figure> <aside class="supplement"><strong>Minor breakpoints</strong> are conditions that, when met, trigger small changes in your design. An example would be moving form labels from above text fields to the left of those fields, while the rest of the design remains the same.</aside> <p>So where and when will you sketch <strong>minor breakpoints</strong>? <em>In the browser</em>, when you do your web-based mockup. You’ll find out why and how in the next chapter. In the meantime, simply focus on making sketches of the state of your web pages or app screens at the major breakpoints of each design.</p> <p>At this point, don’t worry too much if you notice that the initial breakpoints on your breakpoint graph simply won’t do. Those were just a starting point, and you’re free to revise your estimate based on your sketches. You might even decide that you need an extra breakpoint for a given design and record that in sketch form; you can add that breakpoint to your graph. This is a cycle of discovery, learning, and revision.</p> <h2>Think about your content while sketching</h2> <p>While sketching, you’ll certainly be thinking about the way things should look. My experience is that much UI sketching of this type revolves around the layout of elements on the screen. I’ve found it useful to keep thinking about the content while sketching, and to consider what will happen to the content in various situations. When designing responsively, it can be useful to consider how you’ll handle the following content in particular:</p> <ul> <li>Text</li> <li>Navigation</li> <li>Tables</li> </ul> <p>Oh, sure, there are many more things to consider, and you’ll end up creating your own list of “things to do some extra thinking about” as the project progresses. For now, let’s take a look at the items listed above.</p> <h3>Text</h3> <p>Before you say, “Hey, wait a minute, didn’t you just tell me that I didn’t have to draw text while sketching?” hear me out. While sketching, there are a couple of text-related issues you’ll need to tackle: column width and text size, both of which are relevant <em>in proportion to the screen and the other elements on the page</em>.</p> <p>Column width is fairly obvious, but it can be difficult to estimate how wide a column will be with <em>actual</em> text. In this case, sketching on a device might give you a better idea of the actual space you have to work with. Another method I’ve used is just to make a simple HTML page that contains only text, and load that into a device’s browser (or even an emulator, which while not optimal still gives a more realistic impression than lines on paper). When the text seems too large or too small, you can adjust the font size accordingly. Once it seems right, you’ll be able to make your sketches a bit more realistic.</p> <aside class="supplement"><b>Note:</b> Distinguish between <strong>touchability</strong> and <strong>clickability</strong>. Many designers, myself included, have made the mistake of refining links for people who click on them using a mouse, or even via the keyboard, without considering how touchable these links are for people on touch devices.</aside> <p>Think about the size of links—not only the text size, but also the amount of space around them. Both of these factors play a role in the <strong>touchability</strong> or <strong>clickability</strong> of links (and buttons): large links and buttons are easier targets, but slightly smaller links with plenty of space around them can work just as well. That said, there’s a decent chance that no matter what you choose to sketch, you’ll end up making changes again when you create your mockups.</p> <p>This is the great thing about sketching that I can’t repeat often enough: you’re going to refine your design in the browser anyway, so the speed with which you can try things out when sketching means you won’t have to do detail work more than once (unless your client has changes, but we all know that never happens).</p> <h3>Navigation</h3> <p>Navigation is another poster child for sketching on actual devices. The size issues are the same as with links, but there’s a lot more thinking to do in terms of the design of navigation for various devices, which means navigation might change significantly at each major breakpoint.</p> <p>Think back to Bryan Rieger’s practice of designing in text first, and ponder what you would do <em>before</em> the very first breakpoint if you had only plain HTML and CSS at your disposal—in other words, if you had no JavaScript. That means no, you can’t have your menu collapsed at the top of the screen and have it drop down when someone touches it. If you have your menu at the top, it’s in its expanded form and takes up all the vertical space it normally would.</p> <p>This is a controversial enough subject, with even accessibility gurus in disagreement: JavaScript, after all, is currently considered an “accessibility supported” technology. But this isn’t necessarily about accessibility. It’s about <em>thinking</em> about what happens when a browser lacks JavaScript support, or if the JavaScript available on the device is different than what you’d expect. Your content will be presented in a certain way before JavaScript does its thing with it, no matter what the browser. So why not think about what that initial state will be?</p> <p>In the chapter on wireframes, I talked about my preferred pattern for navigation on the smallest screens: keep it near the bottom of the screen and place a link to that navigation near the top of the screen. JavaScript, when available and working as expected, can move that navigation up to the top and create the drop-down menu on the fly.</p> <p>But a pattern is not design law, so how you choose to handle the smallest screens will depend on your project. If I had only a few links in my navigation, I might very well put the menu at the top from the very start, and there it would stay at every breakpoint.</p> <p>Remember that JavaScript and CSS let you do a lot of rearranging of stuff on the screen. That knowledge should empower you to safely design a great page with plain HTML and use JavaScript and CSS to spice it up any way you like. This is the essence of progressive enhancement.</p> <h3>Tables</h3> <p>Tables! Oh, the bane of the responsive designer (or wait, is that images? Or video? Or layout? Ahem). Tables are tough to deal with on small screens. I’d love to tell you I have all the answers, but instead I have more questions. Hopefully, these will lead you to a solution. It’s good to think about these while you’re sketching.</p> <p>First of all, what types of tables will you be dealing with? Narrow? Wide? Numerical? Textual? Your content inventory should give you enough information to answer these simple questions. Once you’ve considered those, try to categorize the types of tables you have into something like the following classes (Figure 7.7):</p> <ul> <li><b>Small-screen-friendly tables</b>, which you’ll probably leave as they are, because they’re small enough and will work fine on most small screens.</li> <li><b>Blockable tables</b>, which you can alter with CSS so that each row in the table functions visually as a block item in a list (Figure 7.8).</li> <li><b>Chartable tables</b>, which contain numerical data that can be transformed into a chart, graph, or other visualization that will take up less space on a small screen.</li> <li><b>Difficult tables</b>, which are hard enough to deal with that you’ll need to come up with a different plan for them, sometimes even on a case-by-case basis. These are our enemies, but unfortunately, are the friends of our clients, who all love Microsoft Excel. Oh well.</li> </ul> <figure data-picture data-alt="Figure 7.7"> <div data-src="/d/376/ch07-07_small.png" data-media="(max-width: 700px)"></div> <div data-src="/d/376/ch07-07_full.png" data-media="(min-width: 701px)"></div> <!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. --> <noscript><img src="/d/376/ch07-07_full.png" alt=""></noscript> <figcaption>Figure 7.7: There are several different types of tables, and different ways of dealing with them on small screens. (Sources: <a href="http://mobilism.nl">mobilism.nl</a> and <a href="http://eu-verantwoording.nl/">eu-verantwoording.nl</a>)</figcaption></figure> <figure data-picture data-alt="Figure 7.8"> <div data-src="/d/376/ch07-08_small.png" data-media="(max-width: 700px)"></div> <div data-src="/d/376/ch07-08_full.png" data-media="(min-width: 701px)"></div> <!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. --> <noscript><img src="/d/376/ch07-08_full.png" alt=""></noscript> <figcaption>Figure 7.8: One way of dealing with small screen tables is to treat each row as a block.</figcaption></figure> <p>Thinking again in terms of progressive enhancement, the base design should probably just include the whole table, which means that the user will have to scroll horizontally to see the whole thing in many cases. On top of this, we can employ CSS and JavaScript, when they’re available, to do some magic for us. Blockable and chartable tables can be <em>blocked</em> with CSS and <em>charted</em> with JavaScript. Plenty of designers and developers have experimented with many different options for tables, from simply making the table itself scrollable to exchanging columns and rows.</p> <p>The fun part is that what you do on small screens isn’t necessarily what you’ll do on larger screens. That’s why now—when all you have to do is sketch and it won’t take much time—is the time to think about the changes you’ll be making at each breakpoint.</p> <h2>What to do if you get stuck</h2> <p>Every designer gets stuck at some point. It’s no big deal unless you treat it like one. There are countless ways to deal with it, from asking yourself <em>what if</em> questions (“What if it weren’t a table, but a list?” is what I asked myself before “blockifying” the attendees table for the Mobilism site) to the cliché <em>taking a shower</em>, which you hopefully do on a regular basis anyway. The reason this chapter focuses so much on sketching is because the act of drawing itself can actually stimulate your brain to come up with more ideas, provided you push it hard enough by sketching past your comfort zone of first-come ideas.</p> <p>If your problem is that you’re stuck creatively, there are many inspiring books and resources to get your creative engine started during the bitter cold of designer’s block. Although there are plenty of resources on design and creativity itself (try such classics as Edward de Bono’s <i>Lateral Thinking</i>), the greatest inspiration can come from sources outside the realm of design.<sup data-footnote>1</sup> Trying to combine things that normally aren’t combined can lead to surprising results. It’s a simple little trick, but I’ve often used Brian Eno and Peter Schmidt’s <i>Oblique Strategies</i> to force me to take a different approach.<sup data-footnote>2</sup> Worst case, it’s a lot of fun. Best case, you’ve got a great idea!</p> <p>If your problem is that you’re not sure how to handle something in the context of responsive design, there’s no harm in researching how others have solved problems like yours. Just be sure to use your creativity and tailor any ideas you might find to your own situation; after all, you’re a designer. At the time of this writing I find Brad Frost’s <i>This Is Responsive</i> to be one of the most exhaustive collections of responsive design patterns and resources available.<sup data-footnote>3</sup> You can spend hours going through there and you’ll certainly come across something that will get you unstuck.</p> <p><small>Excerpted from <i>Responsive Design Workflow</i> by Stephen Hay. Copyright © 2013.<br /> Used with permission of Pearson Education, Inc. and New Riders.</small></p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/zFkOLCNW-WE" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<a href="http://cognition.happycog.com/article/maps-should-be-crafted-not-plugged-in" style="font-size: 18px;">» Maps Should Be Crafted, Not “Plugged In”</a><br><br>Web designers: erase the line between “the map” and “the content“ by harnessing the power of open-source Leaflet and your own fresh creative thinking. In the tradition of ALA’s recent “Hack Your Maps,” Happy Cog’s Brandon Rosage shares how to make location a central aspect of the content experience—not just a visual aid. <br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/MYIFRr9DzKI" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

W3C announced today Get Smart: Smart Homes, Cars and Devices on the Web, a W3C Workshop on Rich Multimodal Application Development, 22-23 July 2013, Metropolitan New York/NJ, USA. The event is hosted by Openstream. The goal of this workshop is...[mehr] (Quelle: W3C News)

On 18 June the MultilingualWeb-LT Working Group holds a showcase event in Dublin about the upcoming Internationalization Tag Set (ITS) 2.0 specification. Group participants demonstrate implementations for authoring ITS 2.0 data categories, for using them in localization workflows, and for...[mehr] (Quelle: W3C News)

<a href="http://aws.typepad.com/aws/2013/05/aws-iam-now-supports-amazon-facebook-and-google-identity-federation.html" style="font-size: 18px;">» Amazon Web Services Introduces a New API</a><br><br>Amazon Web Services Identity and Access Management (IAM) is expanding to support web identity federation. Developers can integrate Amazon.com, Facebook, or Google identity into their app by using the new AWS Security Token Service (STS) API, <code>AssumeRoleWithWebIdentity</code>, to request temporary security credentials. <br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/MXux5aUPqRA" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

In accordance with the W3C Patent Policy, W3C has launched a Patent Advisory Group (PAG) in response to a disclosure related to the Push API specification published by the Web Applications Working Group; see the PAG charter. W3C launches a...[mehr] (Quelle: W3C News)

<p>Three years ago in these pages, ALA technical editor <a href="http://alistapart.com/author/emarcotte">Ethan Marcotte</a> fired the shot heard &#8217;round the web. ALA designer <a href="http://alistapart.com/author/mikepick">Mike Pick</a> thought it might be fun to celebrate the third anniversary of &#8220;<a href="http://alistapart.com/article/responsive-web-design">Responsive Web Design</a>&#8221; (<cite>A List Apart</cite> Issue No. 306, May 25, 2010) by secreting an Easter Egg in the original article; our illustrator, <a href="http://alistapart.com/author/kcornell">Kevin Cornell</a>, rose to the challenge. </p> <p>To see it in action, visit <a href="http://alistapart.com/article/responsive-web-design">alistapart.com/article/responsive-web-design</a>, grab the edge of the browser window (device permitting), and perform the responsive resize mambo. (ALA&#8217;s <a href="http://alistapart.com/author/murtaugh">Tim Murtaugh</a>, who coded the Easter Egg, has provided a <a href="http://d.alistapart.com/misc-images/responsive-illos-b.mp4">handy video demo</a> of what you&#8217;ll see.)</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/fnj2UIH-fVc" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<a href="http://boagworld.com/content-strategy/website-news/" style="font-size: 18px;">» Do Users Care About Your Latest News? (Spoiler: No.)</a><br><br>Paul Boag takes a look at some analytics to see what it can tell us about the effectiveness of putting your "latest news" on your home page.<br><br>℅ <a class="attribution-link" href="https://twitter.com/DiaryCS/status/339469261082882048">@DiaryCS</a><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/NYo3YYDB34Y" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

Registration is open for the W3C HTML5 training course that starts 3 June 2013 and lasts six weeks. Experienced trainer Michel Buffa will cover the techniques developers and designers need to create great Web pages and apps. Topics include...[mehr] (Quelle: W3C News)

The Government Linked Data Working Group has published two Group Notes today: Registered Organization Vocabulary. The Registered Organization Vocabulary is a profile of the Organization Ontology for describing organizations that have gained legal entity status through a formal registration process,...[mehr] (Quelle: W3C News)

The Cascading Style Sheets (CSS) Working Group and the SVG Working Group have published a Working Draft of Filter Effects 1.0. Filter effects are a way of processing an element's rendering before it is displayed in the document. Typically, rendering...[mehr] (Quelle: W3C News)

<p>We hear it mostly from proud CEOs and recruiters, as a sweet nothing designed to tempt candidates to drop their counter-offers, or a statement in a desperate pitch deck. We’re changing the world! All it takes is a few hundred fearsome intellects and laptops. Are you in or out?</p> <p>It’s a bold claim, and when it crops up in more laughable contexts it’s easy to discount as hubris. But consider the claim more closely and it’s harder to deny. Technology loves to demolish the status quo, and it’s doing it with aplomb.</p> <p>The world is struggling to come to terms with the implications of such rapid change. So far, specific industries&#8201;—&#8201;music, news, film&#8201;—&#8201;have had to pick up most of the debris, but now technology is destabilizing some of society’s central pillars: law, finance, education, defense, and politics. We’ve recently seen the rise of a rogue currency outside the global financial system. Crowdsourced vigilantism. The further erosion of the concept of ownership. State-sponsored hacking. Technologists are already making buildings busier than any hospital, and cities ten times the size of Tokyo. We’re hacking around the limitations of space and time. It’s sci-fi stuff, unevenly distributed straight into our inboxes. Today we label these feats “digital,” but before long that qualifier will no longer make much sense. </p> <p>It’s hardly surprising that work on this scale challenges existing systems and behaviors. </p> <figure class="quote"> <blockquote>Once you have something that grows faster than education grows, you’re always going to get a pop culture.</blockquote> <figcaption><a href="http://queue.acm.org/detail.cfm?id=1039523">Alan Kay</a></figcaption> </figure> <p>From the inside, it’s exciting to see technology race ahead of the social frameworks that surround it. Our industry is in thrall to disruption, just so long as it happens to someone else. And although we can feign disinterest&#8201;—“It’s not our fault you can’t keep up…”—&#8201;power is a fresh, intoxicating phenomenon for geeks like us.</p> <p>Outside our bubble, the change is more worrying. Technology is becoming the lingua franca of the modern elite, but it’s a language the world doesn’t yet fully understand. Today, a tiny clique has disproportionate influence on global culture. This group is largely young, male, white, and concentrated around wealthy urban regions, particularly the San Francisco Bay Area.</p> <p>Doubtless many readers identify with this group, as do I. But we must admit it’s not a group that’s terribly well versed in the ways of the world. Therefore, those of us in the privileged position of affecting the course of technology have a duty to inform others of our intentions and listen to their feedback.</p> <p>Grass-roots schemes like the UK’s <a href="http://www.codeclub.org.uk">Code Club</a> encourage digital literacy by introducing the public to the fundamentals of programming. These are important and welcome initiatives. But as well as raw technical knowledge, we need to stir up public debate on the societal implications of technology. Who controls our data? How does <abbr title="Digital Rights Management">DRM</abbr> affect commerce and the public’s possessions? What will privacy mean in a Glass-wearing era?</p> <p>The tech industry is well placed to begin these conversations—not because we understand the likely cultural impact (frankly, we’re pretty clueless there) but because we have advanced warning of emerging technologies.</p> <p>As <a href="http://www.billbuxton.com/">Bill Buxton</a> has argued, new technologies take roughly 20 years to reach the mainstream. The mouse, the touchscreen, the mobile phone, wearable computers: none was an overnight success. All existed as prototypes in <abbr title="research and development">R&amp;D</abbr> labs and thought experiments in academic papers long before they were commercialized.</p> <p>Industry insiders can all take a strong guess at what will be the next generation’s disruptive digital technologies. It’s time to talk about the potential impact of 3D printing, voice inputs, pervasive networks, and embedded computing today, not when the products hit the shelves.</p> <p>We already have the tools required to begin these discussions: blogs, tweets, conference talks, conversations with friends outside the industry. We can also reach further by taking up the issues with government representatives or the media, writing books, and starting public campaigns. But soapboxes and councils aren’t the only way to raise these issues: our products can also speak for us.</p> <p>One way we can clarify the function and implications of new technology is to design self-disclosure into it. Innovative products should help users form accurate mental models of how they work, and discuss consequences the user may not have considered. For example, a voice-operated technology could explain how to prevent others from triggering it, or remind the user to be conscious of her environment before issuing sensitive commands. A networked car telemetry system could notify the user exactly who has access to this data, and why sharing it with the insurance company could lead to lower premiums.</p> <p>This notion of self-disclosure doesn’t sit too well with the modern preference for seamlessness. I’ve previously questioned whether the <a href="http://alistapart.com/column/looking-beyond-user-centered-design">“invisible interface” deprecates style</a> and risks homogenizing design. But there are broader questions too.</p> <p>The black box model&#8201;—&#8201;a device or product that hides its mechanics and complexity&#8201;—&#8201;can be useful for designing appealing, marketable products. However, it can also act against users’ interests.</p> <p>First, black boxes are harder to diagnose and debug. Without an entry point (serviceable hardware, an API, or even just some flashing LEDs) and knowledge of how the thing works, a black box can be stubborn and uncommunicative when something goes wrong. Imagine a house full of co-operating devices that all fail because an OS somewhere in that network has crashed. The designer of this system must provide some visibility into the workings of the network, allowing the user to resolve the problem.</p> <p>Second, black box devices have the potential to reduce the user’s agency. It’s hard to understand a device that seems to act of its own accord. A seamless device demands trust, but offers no way for the user to decide if that trust is warranted. There’s a risk that invisible interfaces could therefore become breeding grounds for unethical design. Since the user has little insight into the workings of the system, it becomes easier to slip personal data to an unknown IP, connect to a premium-rate phone line, or perform some other hostile act.</p> <p>So seamlessness may not be the right model for new genres of technology. Perhaps it’s better for the first wave of innovative devices to be explicit about their workings and implications, helping the public to understand and react appropriately. Once people become more familiar with the technology, designers can carefully taper this self-disclosure off.</p> <p>It may be harder to design a slick user experience if we expose the workings of a device, but advocating transparency is about designing a good experience for humankind, not just a single user. It demonstrates an ethical, holistic mindset that’s becoming ever more important as technology becomes central to people’s lives.</p> <p>For ethical values to thrive in our field, we can’t let the pace of change seduce us into thinking we&#8217;ve no time for them. Designers and engineers alike need to think deeply about the implications of the things we make, and appreciate the value of doing so. We also need role models. I long for our industry to stop fetishizing entrepreneurs and billion-dollar buyouts, and instead to praise technologists who inform the public about new technology, or companies that make tough decisions for the greater good.</p> <p>Individuals within the tech industry also need the courage to do the right thing. The job market is so strong that the only response to unethical pressure from employers should be a hearty middle-fingered farewell. And where <a href="http://alistapart.com/article/dark-patterns-deception-vs.-honesty-in-ui-design">dark patterns</a> do emerge, the industry must highlight these dirty tricks, and explain to the public how they can avoid being taken for a ride.</p> <p>Finally, the tech community should educate itself about global issues. Our tiny elite needs to understand the world in order to affect it positively. Efforts to travel, to learn about other cultures and contexts, and to consider use cases beyond those of our nearest neighbors will help reduce the risk of technological imperialism. It would be a mistake to assume that a solution that works for a Western techie will work for a North African trader.</p> <p>These are complex times for the tech industry, and the consequences of taking a wrong step could be severe. Let’s dedicate thoughtful time to ensure the effect we’re having on the world is positive. The results will also be good for our own industry: an informed public means a greater trust of and appetite for our work.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/PfzRNQJZag4" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<p>We’ve all been there: that bit of JavaScript functionality that started out as just a handful of lines grows to a dozen, then two dozen, then more. Along the way, a function picks up a few more arguments; a conditional picks up a few more conditions. And then one day, the bug report comes in: something’s broken, and it’s up to us to untangle the mess.</p> <p>As we ask our client-side code to take on more and more responsibilities—indeed, whole applications are living largely in the browser these days—two things are becoming clear. One, we can’t just point and click our way through testing that things are working as we expect; automated tests are key to having confidence in our code. Two, we’re probably going to have to change how we write our code in order to make it possible to write tests.</p> <p>Really, we need to change how we code? Yes—because even if we know that automated tests are a good thing, most of us are probably only able to write integration tests right now. Integration tests are valuable because they focus on how the pieces of an application work together, but what they don’t do is tell us whether individual <em>units of functionality</em> are behaving as expected.</p> <p>That’s where unit testing comes in. And we’ll have a very hard time <em>writing unit tests</em> until we start <em>writing testable JavaScript</em>.</p> <h2>Unit vs. integration: what’s the difference?</h2> <p>Writing integration tests is usually fairly straightforward: we simply write code that describes how a user interacts with our app, and what the user should expect to see as she does. <a href="http://docs.seleniumhq.org/">Selenium</a> is a popular tool for automating browsers. <a href="https://github.com/jnicklas/capybara">Capybara</a> for Ruby makes it easy to talk to Selenium, and there are plenty of tools for other languages, too.</p> <p>Here’s an integration test for a portion of a search app:</p> <pre><code class="language-javascript">def test_search fill_in(&#39;q&#39;, :with =&gt; &#39;cat&#39;) find(&#39;.btn&#39;).click assert( find(&#39;#results li&#39;).has_content?(&#39;cat&#39;), &#39;Search results are shown&#39; ) assert( page.has_no_selector?(&#39;#results li.no-results&#39;), &#39;No results is not shown&#39; ) end</code></pre> <p>Whereas an integration test is interested in a user’s interaction with an app, a unit test is narrowly focused on a small piece of code:</p> <figure class="quote"> <blockquote>When I call a function with a certain input, do I receive the expected output? </blockquote> </figure> <p>Apps that are written in a traditional procedural style can be very difficult to unit test—and difficult to maintain, debug, and extend, too. But if we write our code with our future unit testing needs in mind, we will not only find that writing the tests becomes more straightforward than we might have expected, but also that we’ll simply <em>write better code</em>, too.</p> <p>To see what I’m talking about, let’s take a look at a simple search app:</p> <figure><img src="http://d.alistapart.com/375/app.png" alt="Srchr"></figure> <p>When a user enters a search term, the app sends an XHR to the server for the corresponding data. When the server responds with the data, formatted as JSON, the app takes that data and displays it on the page, using client-side templating. A user can click on a search result to indicate that he “likes” it; when this happens, the name of the person he liked is added to the “Liked” list on the right-hand side.</p> <p>A “traditional” JavaScript implementation of this app might look like this:</p> <pre><code class="language-javascript">var tmplCache = {}; function loadTemplate (name) { if (!tmplCache[name]) { tmplCache[name] = $.get(&#39;/templates/&#39; + name); } return tmplCache[name]; } $(function () { var resultsList = $(&#39;#results&#39;); var liked = $(&#39;#liked&#39;); var pending = false; $(&#39;#searchForm&#39;).on(&#39;submit&#39;, function (e) { e.preventDefault(); if (pending) { return; } var form = $(this); var query = $.trim( form.find(&#39;input[name=&quot;q&quot;]&#39;).val() ); if (!query) { return; } pending = true; $.ajax(&#39;/data/search.json&#39;, { data : { q: query }, dataType : &#39;json&#39;, success : function (data) { loadTemplate(&#39;people-detailed.tmpl&#39;).then(function (t) { var tmpl = _.template(t); resultsList.html( tmpl({ people : data.results }) ); pending = false; }); } }); $(&#39;&lt;li&gt;&#39;, { &#39;class&#39; : &#39;pending&#39;, html : &#39;Searching &amp;hellip;&#39; }).appendTo( resultsList.empty() ); }); resultsList.on(&#39;click&#39;, &#39;.like&#39;, function (e) { e.preventDefault(); var name = $(this).closest(&#39;li&#39;).find(&#39;h2&#39;).text(); liked.find(&#39;.no-results&#39;).remove(); $(&#39;&lt;li&gt;&#39;, { text: name }).appendTo(liked); }); });</code></pre> <p>My friend <a href="https://twitter.com/ajpiano">Adam Sontag</a> calls this <cite>Choose Your Own Adventure</cite> code—on any given line, we might be dealing with presentation, or data, or user interaction, or application state. Who knows! It’s easy enough to write integration tests for this kind of code, but it’s hard to test individual <em>units of functionality</em>.</p> <p>What makes it hard? Four things:</p> <ul> <li>A general lack of structure; almost everything happens in a <code>$(document).ready()</code> callback, and then in anonymous functions that can’t be tested because they aren’t exposed.</li> <li>Complex functions; if a function is more than 10 lines, like the submit handler, it’s highly likely that it’s doing too much.</li> <li>Hidden or shared state; for example, since <code>pending</code> is in a closure, there’s no way to test whether the pending state is set correctly.</li> <li>Tight coupling; for example, a <code>$.ajax</code> success handler shouldn’t need direct access to the DOM.</li> </ul> <h2>Organizing our code</h2> <p>The first step toward solving this is to take a less tangled approach to our code, breaking it up into a few different areas of responsibility:</p> <ul> <li>Presentation and interaction</li> <li>Data management and persistence</li> <li>Overall application state</li> <li>Setup and glue code to make the pieces work together</li> </ul> <p>In the “traditional” implementation shown above, these four categories are intermingled—on one line we’re dealing with presentation, and two lines later we might be communicating with the server.</p> <figure><img src="http://d.alistapart.com/375/code-lines.png" alt="Code Lines"></figure> <p>While we can absolutely write integration tests for this code—and we should!—writing unit tests for it is pretty difficult. In our functional tests, we can make assertions such as “when a user searches for something, she should see the appropriate results,” but we can’t get much more specific. If something goes wrong, we’ll have to track down exactly where it went wrong, and our functional tests won’t help much with that.</p> <p>If we rethink how we write our code, though, we can write unit tests that will give us better insight into where things went wrong, and also help us end up with code that’s easier to reuse, maintain, and extend.</p> <p>Our new code will follow a few guiding principles:</p> <ul> <li>Represent each distinct piece of behavior as a separate object that falls into one of the four areas of responsibility and doesn’t need to know about other objects. This will help us avoid creating tangled code.</li> <li>Support configurability, rather than hard-coding things. This will prevent us from replicating our entire HTML environment in order to write our tests.</li> <li>Keep our objects’ methods simple and brief. This will help us keep our tests simple and our code easy to read.</li> <li>Use constructor functions to create instances of objects. This will make it possible to create “clean” copies of each piece of code for the sake of testing.</li> </ul> <p>To start with, we need to figure out how we’ll break our application into different pieces. We’ll have three pieces dedicated to presentation and interaction: the Search Form, the Search Results, and the Likes Box.</p> <figure><img src="http://d.alistapart.com/375/app-views.png" alt="Application Views"></figure> <p>We’ll also have a piece dedicated to fetching data from the server and a piece dedicated to gluing everything together.</p> <p>Let’s start by looking at one of the simplest pieces of our application: the Likes Box. In the original version of the app, this code was responsible for updating the Likes Box:</p> <pre><code class="language-javascript">var liked = $(&#39;#liked&#39;); var resultsList = $(&#39;#results&#39;); // ... resultsList.on(&#39;click&#39;, &#39;.like&#39;, function (e) { e.preventDefault(); var name = $(this).closest(&#39;li&#39;).find(&#39;h2&#39;).text(); liked.find( &#39;.no-results&#39; ).remove(); $(&#39;&lt;li&gt;&#39;, { text: name }).appendTo(liked); });</code></pre> <p>The Search Results piece is completely intertwined with the Likes Box piece and needs to know a lot about its markup. A much better and more testable approach would be to create a Likes Box object that’s responsible for manipulating the DOM related to the Likes Box:</p> <pre><code class="language-javascript">var Likes = function (el) { this.el = $(el); return this; }; Likes.prototype.add = function (name) { this.el.find(&#39;.no-results&#39;).remove(); $(&#39;&lt;li&gt;&#39;, { text: name }).appendTo(this.el); };</code></pre> <p>This code provides a constructor function that creates a new instance of a Likes Box. The instance that’s created has an <code>.add()</code> method, which we can use to add new results. We can write a couple of tests to prove that it works:</p> <pre><code class="language-javascript">var ul; setup(function(){ ul = $(&#39;&lt;ul&gt;&lt;li class=&quot;no-results&quot;&gt;&lt;/li&gt;&lt;/ul&gt;&#39;); }); test(&#39;constructor&#39;, function () { var l = new Likes(ul); assert(l); }); test(&#39;adding a name&#39;, function () { var l = new Likes(ul); l.add(&#39;Brendan Eich&#39;); assert.equal(ul.find(&#39;li&#39;).length, 1); assert.equal(ul.find(&#39;li&#39;).first().html(), &#39;Brendan Eich&#39;); assert.equal(ul.find(&#39;li.no-results&#39;).length, 0); });</code></pre> <p>Not so hard, is it? Here we’re using <a href="http://visionmedia.github.io/mocha/">Mocha</a> as the test <em>framework</em>, and <a href="http://chaijs.com/">Chai</a> as the <em>assertion library</em>. Mocha provides the <code>test</code> and <code>setup</code> functions; Chai provides <code>assert</code>. There are plenty of other test frameworks and assertion libraries to choose from, but for the sake of an introduction, I find these two work well. You should find the one that works best for you and your project—aside from Mocha, <a href="http://qunitjs.com/">QUnit</a> is popular, and <a href="http://theintern.io/">Intern</a> is a new framework that shows a lot of promise.</p> <p>Our test code starts out by creating an element that we’ll use as the container for our Likes Box. Then, it runs two tests: one is a sanity check to make sure we can make a Likes Box; the other is a test to ensure that our <code>.add()</code> method has the desired effect. With these tests in place, we can safely refactor the code for our Likes Box, and be confident that we’ll know if we break anything.</p> <p>Our new application code can now look like this:</p> <pre><code class="language-javascript">var liked = new Likes(&#39;#liked&#39;); var resultsList = $(&#39;#results&#39;); // ... resultsList.on(&#39;click&#39;, &#39;.like&#39;, function (e) { e.preventDefault(); var name = $(this).closest(&#39;li&#39;).find(&#39;h2&#39;).text(); liked.add(name); });</code></pre> <p>The Search Results piece is more complex than the Likes Box, but let’s take a stab at refactoring that, too. Just as we created an <code>.add()</code> method on the Likes Box, we also want to create methods for interacting with the Search Results. We’ll want a way to add new results, as well as a way to &#8220;broadcast&#8221; to the rest of the app when things happen within the Search Results—for example, when someone likes a result.</p> <pre><code class="language-javascript">var SearchResults = function (el) { this.el = $(el); this.el.on( &#39;click&#39;, &#39;.btn.like&#39;, _.bind(this._handleClick, this) ); }; SearchResults.prototype.setResults = function (results) { var templateRequest = $.get(&#39;people-detailed.tmpl&#39;); templateRequest.then( _.bind(this._populate, this, results) ); }; SearchResults.prototype._handleClick = function (evt) { var name = $(evt.target).closest(&#39;li.result&#39;).attr(&#39;data-name&#39;); $(document).trigger(&#39;like&#39;, [ name ]); }; SearchResults.prototype._populate = function (results, tmpl) { var html = _.template(tmpl, { people: results }); this.el.html(html); };</code></pre> <p>Now, our old app code for managing the interaction between Search Results and the Likes Box could look like this:</p> <pre><code class="language-javascript">var liked = new Likes(&#39;#liked&#39;); var resultsList = new SearchResults(&#39;#results&#39;); // ... $(document).on(&#39;like&#39;, function (evt, name) { liked.add(name); })</code></pre> <p>It’s much simpler and less entangled, because we’re using the <code>document</code> as a global message bus, and passing messages through it so individual components don’t need to know about each other. (Note that in a real app, we’d use something like <a href="http://backbonejs.org">Backbone</a> or the <a href="https://github.com/tildeio/rsvp.js">RSVP</a> library to manage events. We’re just triggering on <code>document</code> to keep things simple here.) We’re also hiding all the dirty work—such as finding the name of the person who was liked—inside the Search Results object, rather than having it muddy up our application code. The best part: we can now write tests to prove that our Search Results object works as we expect:</p> <pre><code class="language-javascript">var ul; var data = [ /* fake data here */ ]; setup(function () { ul = $(&#39;&lt;ul&gt;&lt;li class=&quot;no-results&quot;&gt;&lt;/li&gt;&lt;/ul&gt;&#39;); }); test(&#39;constructor&#39;, function () { var sr = new SearchResults(ul); assert(sr); }); test(&#39;display received results&#39;, function () { var sr = new SearchResults(ul); sr.setResults(data); assert.equal(ul.find(&#39;.no-results&#39;).length, 0); assert.equal(ul.find(&#39;li.result&#39;).length, data.length); assert.equal( ul.find(&#39;li.result&#39;).first().attr(&#39;data-name&#39;), data[0].name ); }); test(&#39;announce likes&#39;, function() { var sr = new SearchResults(ul); var flag; var spy = function () { flag = [].slice.call(arguments); }; sr.setResults(data); $(document).on(&#39;like&#39;, spy); ul.find(&#39;li&#39;).first().find(&#39;.like.btn&#39;).click(); assert(flag, &#39;event handler called&#39;); assert.equal(flag[1], data[0].name, &#39;event handler receives data&#39; ); });</code></pre> <p>The interaction with the server is another interesting piece to consider. The original code included a direct <code>$.ajax()</code> request, and the callback interacted directly with the DOM:</p> <pre><code class="language-javascript">$.ajax(&#39;/data/search.json&#39;, { data : { q: query }, dataType : &#39;json&#39;, success : function( data ) { loadTemplate(&#39;people-detailed.tmpl&#39;).then(function(t) { var tmpl = _.template( t ); resultsList.html( tmpl({ people : data.results }) ); pending = false; }); } });</code></pre> <p>Again, this is difficult to write a unit test for, because so many different things are happening in just a few lines of code. We can restructure the data portion of our application as an object of its own:</p> <pre><code class="language-javascript">var SearchData = function () { }; SearchData.prototype.fetch = function (query) { var dfd; if (!query) { dfd = $.Deferred(); dfd.resolve([]); return dfd.promise(); } return $.ajax( &#39;/data/search.json&#39;, { data : { q: query }, dataType : &#39;json&#39; }).pipe(function( resp ) { return resp.results; }); };</code></pre> <p>Now, we can change our code for getting the results onto the page:</p> <pre><code class="language-javascript">var resultsList = new SearchResults(&#39;#results&#39;); var searchData = new SearchData(); // ... searchData.fetch(query).then(resultsList.setResults);</code></pre> <p>Again, we’ve dramatically simplified our application code, and isolated the complexity within the Search Data object, rather than having it live in our main application code. We’ve also made our search interface testable, though there are a couple caveats to bear in mind when testing code that interacts with the server.</p> <p>The first is that we don’t want to <em>actually</em> interact with the server—to do so would be to reenter the world of integration tests, and because we’re responsible developers, we already have tests that ensure the server does the right thing, right? Instead, we want to &#8220;mock&#8221; the interaction with the server, which we can do using the <a href="http://sinonjs.org/">Sinon</a> library. The second caveat is that we should also test non-ideal paths, such as an empty query.</p> <pre><code class="language-javascript">test(&#39;constructor&#39;, function () { var sd = new SearchData(); assert(sd); }); suite(&#39;fetch&#39;, function () { var xhr, requests; setup(function () { requests = []; xhr = sinon.useFakeXMLHttpRequest(); xhr.onCreate = function (req) { requests.push(req); }; }); teardown(function () { xhr.restore(); }); test(&#39;fetches from correct URL&#39;, function () { var sd = new SearchData(); sd.fetch(&#39;cat&#39;); assert.equal(requests[0].url, &#39;/data/search.json?q=cat&#39;); }); test(&#39;returns a promise&#39;, function () { var sd = new SearchData(); var req = sd.fetch(&#39;cat&#39;); assert.isFunction(req.then); }); test(&#39;no request if no query&#39;, function () { var sd = new SearchData(); var req = sd.fetch(); assert.equal(requests.length, 0); }); test(&#39;return a promise even if no query&#39;, function () { var sd = new SearchData(); var req = sd.fetch(); assert.isFunction( req.then ); }); test(&#39;no query promise resolves with empty array&#39;, function () { var sd = new SearchData(); var req = sd.fetch(); var spy = sinon.spy(); req.then(spy); assert.deepEqual(spy.args[0][0], []); }); test(&#39;returns contents of results property of the response&#39;, function () { var sd = new SearchData(); var req = sd.fetch(&#39;cat&#39;); var spy = sinon.spy(); requests[0].respond( 200, { &#39;Content-type&#39;: &#39;text/json&#39; }, JSON.stringify({ results: [ 1, 2, 3 ] }) ); req.then(spy); assert.deepEqual(spy.args[0][0], [ 1, 2, 3 ]); }); });</code></pre> <p>For the sake of brevity, I’ve left out the refactoring of the Search Form, and also simplified some of the other refactorings and tests, but you can see a finished version of the app <a href="https://github.com/rmurphey/testable-javascript">here</a> if you’re interested.</p> <p>When we’re done rewriting our application using testable JavaScript patterns, we end up with something much cleaner than what we started with:</p> <pre><code class="language-javascript">$(function() { var pending = false; var searchForm = new SearchForm(&#39;#searchForm&#39;); var searchResults = new SearchResults(&#39;#results&#39;); var likes = new Likes(&#39;#liked&#39;); var searchData = new SearchData(); $(document).on(&#39;search&#39;, function (event, query) { if (pending) { return; } pending = true; searchData.fetch(query).then(function (results) { searchResults.setResults(results); pending = false; }); searchResults.pending(); }); $(document).on(&#39;like&#39;, function (evt, name) { likes.add(name); }); });</code></pre> <p>Even more important than our much cleaner application code, though, is the fact that we end up with a codebase that is thoroughly tested. That means we can safely refactor it and add to it without the fear of breaking things. We can even write new tests as we find new issues, and then write the code that makes those tests pass.</p> <h2>Testing makes life easier in the long run</h2> <p>It’s easy to look at all of this and say, &#8220;Wait, you want me to write more code to do the same job?&#8221;</p> <p>The thing is, there are a few inescapable facts of life about Making Things On The Internet. You will spend time designing an approach to a problem. You will test your solution, whether by clicking around in a browser, writing automated tests, or—<em>shudder</em>—letting your users do your testing for you in production. You will make changes to your code, and other people will use your code. Finally: there will be bugs, no matter how many tests you write.</p> <p>The thing about testing is that while it might require a bit more time at the outset, it really does save time in the long run. You’ll be patting yourself on the back the first time a test you wrote catches a bug before it finds its way into production. You’ll be grateful, too, when you have a system in place that can prove that your bug fix really does fix a bug that slips through.</p> <h2>Additional resources</h2> <p>This article just scratches the surface of JavaScript testing, but if you’d like to learn more, check out:</p> <ul> <li><a href="http://lanyrd.com/2012/full-frontal/sztqh/">My presentation</a> from the 2012 Full Frontal conference in Brighton, UK.</li> <li><a href="http://gruntjs.com/">Grunt</a>, a tool that helps automate the testing process and lots of other things.</li> <li><cite><a href="http://www.amazon.com/Test-Driven-JavaScript-Development-Developers-Library/dp/0321683919/ref=sr_1_1?ie=UTF8&amp;qid=1366506174&amp;sr=8-1&amp;keywords=test+driven+javascript+development">Test-Driven JavaScript Development</a></cite> by Christian Johansen, the creator of the Sinon library. It is a dense but informative examination of the practice of testing JavaScript.</li> </ul><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/EcxNHDRHkTM" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<p>Great design is a product of care and attention applied to areas that matter, resulting in a useful, understandable, and hopefully beautiful user interface. But don’t be fooled into thinking that design is left only for designers.</p> <p>There is a lot of design in code, and I don’t mean code that builds the user interface—I mean the design <em>of</em> code.</p> <p>Well-designed code is much easier to maintain, optimize, and extend, making for more efficient developers. That means more focus and energy can be spent on building great things, which makes everyone happy—users, developers, and stakeholders.</p> <p>There are three high-level, language-agnostic aspects to code design that are particularly important.</p> <ol> <li>System architecture—The basic layout of the codebase. Rules that govern how various components, such as models, views, and controllers, interact with each other.</li> <li>Maintainability—How well can the code be improved and extended?</li> <li>Reusability—How reusable are the application’s components? How easily can each implementation of a component be customized?</li> </ol> <p>In looser languages, specifically JavaScript, it takes a bit of discipline to write well-designed code. The JavaScript environment is so forgiving that it’s easy to throw bits and pieces everywhere and still have things work. Establishing system architecture early (and sticking to it!) provides constraints to your codebase, ensuring consistency throughout.</p> <p>One approach I’m fond of consists of a tried-and-true software design pattern, the module pattern, whose extensible structure lends itself to a solid system architecture and a maintainable codebase. I like building modules within a jQuery plugin, which makes for beautiful reusability, provides robust options, and exposes a well-crafted API.</p> <p>Below, I’ll walk through how to craft your code into well-organized components that can be reused in projects to come.</p> <h2>The module pattern</h2> <p>There are a <em>lot</em> of design patterns out there, and equally as many resources on them. <a href="https://twitter.com/addyosmani">Addy Osmani</a> wrote an <a href="http://addyosmani.com/resources/essentialjsdesignpatterns/book/">amazing (free!) book</a> on design patterns in JavaScript, which I highly recommend to developers of all levels.</p> <p>The <a href="http://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript">module pattern</a> is a simple structural foundation that can help keep your code clean and organized. A “module” is just a standard object literal containing methods and properties, and that simplicity is the best thing about this pattern: even someone unfamiliar with traditional software design patterns would be able to look at the code and instantly understand how it works.</p> <p>In applications that use this pattern, each component gets its own distinct module. For example, to build autocomplete functionality, you’d create a module for the textfield and a module for the results list. These two modules would work together, but the textfield code wouldn’t touch the results list code, and vice versa.</p> <p>That decoupling of components is why the module pattern is great for building solid system architecture. Relationships within the application are well-defined; anything related to the textfield is managed by the textfield module, not strewn throughout the codebase—resulting in clear code.</p> <p>Another benefit of module-based organization is that it is inherently maintainable. Modules can be improved and optimized independently without affecting any other part of the application.</p> <p>I used the module pattern for the basic structure of <a href="http://jpanelmenu.com/">jPanelMenu</a>, the jQuery plugin I built for off-canvas menu systems. I’ll use that as an example to illustrate the process of building a module.</p> <h2>Building a module</h2> <p>To begin, I define three methods and a property that are used to manage the interactions of the menu system.</p> <pre><code class="language-javascript">var jpm = { animated: true, openMenu: function( ) { … this.setMenuStyle( ); }, closeMenu: function( ) { … this.setMenuStyle( ); }, setMenuStyle: function( ) { … } };</code></pre> <p>The idea is to break down code into the smallest, most reusable bits possible. I could have written just one <code>toggleMenu( )</code> method, but creating distinct <code>openMenu( )</code> and <code>closeMenu( )</code> methods provides more control and reusability within the module.</p> <p>Notice that calls to module methods and properties from <em>within</em> the module itself (such as the calls to <code>setMenuStyle( )</code>) are prefixed with the <code>this</code> keyword—that’s how modules access their own members.</p> <p>That’s the basic structure of a module. You can continue to add methods and properties as needed, but it doesn’t get any more complex than that. After the structural foundations are in place, the reusability layer—options and an exposed API—can be built on top.</p> <h2>jQuery plugins</h2> <p>The third aspect of well-designed code is probably the most crucial: reusability. This section comes with a caveat. While there are obviously ways to build and implement reusable components in raw JavaScript (we’re about 90 percent of the way there with our module above), I prefer to build jQuery plugins for more complex things, for a few reasons.</p> <p>Most importantly, it’s a form of unobtrusive communication. If you used jQuery to build a component, you should make that obvious to those implementing it. Building the component as a jQuery plugin is a great way to say that jQuery is required.</p> <p>In addition, the implementation code will be consistent with the rest of the jQuery-based project code. That’s good for aesthetic reasons, but it also means (to an extent) that developers can predict how to interact with the plugin without too much research. Just one more way to build a better developer interface.</p> <p>Before you begin building a jQuery plugin, ensure that the plugin does not conflict with other JavaScript libraries using the <code>$</code> notation. That’s a lot simpler than it sounds—just wrap your plugin code like so:</p> <pre><code class="language-javascript">(function($) { // jQuery plugin code here })(jQuery);</code></pre> <p>Next, we set up our plugin and drop our previously built module code inside. A plugin is just a method defined on the jQuery <code>($)</code> object.</p> <pre><code class="language-javascript">(function($) { $.jPanelMenu = function( ) { var jpm = { animated: true, openMenu: function( ) { … this.setMenuStyle( ); }, closeMenu: function( ) { … this.setMenuStyle( ); }, setMenuStyle: function( ) { … } }; }; })(jQuery);</code></pre> <p>All it takes to use the plugin is a call to the function you just created.</p> <pre><code class="language-javascript">var jpm = $.jPanelMenu( );</code></pre> <h2>Options</h2> <p>Options are essential to any truly reusable plugin because they allow for customizations to each implementation. Every project brings with it a slew of design styles, interaction types, and content structures. Customizable options help ensure that you can adapt the plugin to fit within those project constraints.</p> <p>It’s best practice to provide good default values for your options. The easiest way to do that is to use jQuery’s <code>$.extend( )</code> method, which accepts (at least) two arguments.</p> <p>As the first argument of <code>$.extend( )</code>, define an object with all available options and their default values. As the second argument, pass through the passed-in options. This will merge the two objects, overriding the defaults with any passed-in options.</p> <pre><code class="language-javascript">(function($) { $.jPanelMenu = function(options) { var jpm = { options: $.extend({ 'animated': true, 'duration': 500, 'direction': 'left' }, options), openMenu: function( ) { … this.setMenuStyle( ); }, closeMenu: function( ) { … this.setMenuStyle( ); }, setMenuStyle: function( ) { … } }; }; })(jQuery);</code></pre> <p>Beyond providing good defaults, options become almost self-documenting—someone can look at the code and see all of the available options immediately.</p> <p>Expose as many options as is feasible. The customization will help in future implementations, and flexibility never hurts.</p> <h2>API</h2> <p>Options are terrific ways to customize how a plugin works. An API, on the other hand, enables extensions to the plugin’s functionality by exposing methods and properties for the implementation code to take advantage of.</p> <p>While it’s great to expose as much as possible through an API, the outside world shouldn’t have access to all internal methods and properties. Ideally, you should expose only the elements that will be used.</p> <p>In our example, the exposed API should include calls to open and close the menu, but nothing else. The internal <code>setMenuStyle( )</code> method runs when the menu opens and closes, but the public doesn’t need access to it.</p> <p>To expose an API, return an object with any desired methods and properties at the end of the plugin code. You can even map returned methods and properties to those within the module code—this is where the beautiful organization of the module pattern really shines.</p> <pre><code class="language-javascript">(function($) { $.jPanelMenu = function(options) { var jpm = { options: $.extend({ 'animated': true, 'duration': 500, 'direction': 'left' }, options), openMenu: function( ) { … this.setMenuStyle( ); }, closeMenu: function( ) { … this.setMenuStyle( ); }, setMenuStyle: function( ) { … } }; return { open: jpm.openMenu, close: jpm.closeMenu, someComplexMethod: function( ) { … } }; }; })(jQuery);</code></pre> <p>API methods and properties will be available through the object returned from the plugin initialization.</p> <pre><code class="language-javascript">var jpm = $.jPanelMenu({ duration: 1000, … }); jpm.open( );</code></pre> <h2>Polishing developer interfaces</h2> <p>With just a few simple constructs and guidelines, we’ve built ourselves a reusable, extensible plugin that will help make our lives easier. Like any part of what we do, experiment with this structure to see if it works for you, your team, and your workflow.</p> <p>Whenever I find myself building something with a potential for reuse, I break it out into a module-based jQuery plugin. The best part about this approach is that it forces you to use—and test—the code you write. By using something as you build it, you’ll quickly identify strengths, discover shortcomings, and plan changes.</p> <p>This process leads to battle-tested code ready for open-source contributions, or to be sold and distributed. I’ve released my (mostly) polished plugins as open-source projects on <a href="https://github.com/acolangelo">GitHub</a>.</p> <p>Even if you aren’t building something to be released in the wild, it’s still important to think about the design of your code. Your future self will thank you.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/x0nEW66nHaE" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<a href="http://ma.tt/2013/05/yahooblr/" style="font-size: 18px;">» Matt Mullenweg on Yahoo-Tumblr</a><br><br>“We’re at the cusp of understanding the ultimate value of web publishing platforms, particularly ones that work cross-domain.”–Matt Mullenweg of WordPress.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/mtIeSUFNVF0" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<a href="http://mapbox.com/blog/vector-tiles/" style="font-size: 18px;">» MapBox Develops an Open Source Vector Format for Maps</a><br><br>MapBox's new vector-based map tiles are more stable, more scalable, and customizable to an amazing degree.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/6RkzuwjWbwM" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<p class="question"><b>I know you’ve been asked this plenty of times already, but: no new vendor prefixes, right? <em>Right?</em></b></p> <p>Nope, none! They’re great in theory but turns out they fail in practice, so we’re joining <a href="http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0731.html">Mozilla</a> and the <a href="http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/">W3C CSS WG</a> and moving away them. There’s a few parts to this.</p> <p>Firstly, we won’t be migrating the existing <code>-webkit-</code> prefixed properties to a <code>-chrome-</code> or <code>-blink-</code> prefix, that’d just make extra work for everyone. Secondly, we inherited some existing properties that are prefixed. Some, like <code>-webkit-transform</code>, are standards track and we work with the CSS WG to move ahead those standards while we fix any remaining issues in our implementation and we’ll unprefix them when they’re ready. Others, like <code>-webkit-box-reflect</code> are not standards track and we’ll bring them to standards bodies or responsibly deprecate these on a case-by-case basis. Lastly, we’re not introducing any new CSS properties behind a prefix.</p> <p class="question"><b>Pinky swear?</b></p> <p>Totes. New stuff will be available to experiment with behind a flag you can turn on in <code>about:flags</code> called &#8220;Experimental Web Platform Features&#8221;. When the feature is ready, it’ll graduate to Canary, and then follow its ~12 week path down through Dev Channel, Beta to all users at Stable.</p> <p>The <a href="http://www.chromium.org/blink#vendor-prefixes">Blink prefix policy</a> is documented and, in fact, WebKit just nailed down their <a href="https://lists.webkit.org/pipermail/webkit-dev/2013-May/024850.html">prefix policy</a> going forward. If you’re really into prefix drama (and who isn’t!) Chris Wilson and I discussed this a lot more on <a href="http://5by5.tv/webahead/51">the Web Ahead podcast</a> [37:20].</p> <p class="question"><b>How long before we can try Blink out in Chrome?</b></p> <p>Blink’s been in Chrome Canary as of the day we announced it. The codebase was 99.9% the same when Blink launched, so no need to rush out and check everything. All your sites should be pretty much the same. </p> <p>Chrome 27 has the Blink engine, and that’s available on the beta channel for Win, Mac, Linux, ChromeOS and Android. (See the <a href="https://googledrive.com/host/0B8R1QvA3x5IbWll3M0hIYXVLZlk/">full beta/stable/dev/canary view</a>).</p> <p class="question"><b>While the internals are apt to be fairly different, will there be any radical changes to the rendering side of things in the near future?</b></p> <p>Nothing too alarming, layout and CSS stuff is all staying the same. Grid layout is still in development, though, and our Windows text rendering has been getting a new backend that we can hook up soon, greatly boosting the quality of webfont rendering there.</p> <p>We’re also interested in better taking advantage of multiple cores on machines, so the more we can move painting, layout (aka reflow), and style recalculation to a separate thread, but the faster everyone’s sites will render. We’re already doing multi-threaded painting on ChromeOS and Android, and looking into doing it on Mac &amp; Windows. If you’re interested in these <a href="http://www.chromium.org/blink/developer-faq#TOC-What-sorts-of-things-should-I-expect-from-Chrome-">experimental efforts</a> or watching new feature proposals, take a look at the <a href="https://groups.google.com/a/chromium.org/forum/?fromgroups#!forum/blink-dev">blink-dev mailing list</a>. A recent proposed experiment is called <a href="https://groups.google.com/a/chromium.org/d/topic/blink-dev/V1vJmirHUGE/discussion">Oilpan</a>, where we’ll look into the advantages of moving the implementation of Chrome’s DOM into JavaScript.</p> <p class="question"><b>Will features added to Blink be contributed back to the WebKit project? Short term; long term?</b></p> <p>Since Blink launched there’s been a few patches that have been landed in both Blink and WebKit, though this is expected to decline in the long-term, as the code bases will diverge.</p> <p class="question"><b>When are we likely to start seeing Blink-powered versions of Chrome on Android? Is it even possible on iOS, or is iOS Chrome still stuck with a Safari webview due to Apple’s policies?</b></p> <p>Blink is now in the <a href="https://play.google.com/store/apps/details?id=com.chrome.beta&amp;hl=en">Chrome Beta for Android</a>. Chrome for iOS, due to platform limitations, is based on the WebKit-based WebView that’s provided by iOS. </p> <p class="question"><b>Part of this move seems to be giving Google the freedom to remove old or disused features that have been collecting dust in WebKit for ages. There must be a few things high on that list—what are some of those things, and how can we be certain their removal won’t lead to the occasional broken website?</b></p> <p>A few old ’n crusty things that we’re looking at removing: the <a href="http://www.w3.org/wiki/HTML/Elements/isindex">isindex attribute</a>, <a href="https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/5mNHirgyOzM">RangeException</a>, and <a href="https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/JoerJvQlWFY">XMLHttpRequestException</a>. Old things that have little use in the wild and just haven’t gotten a spring cleaning from the web platform for ages. </p> <p>Now, we don’t want to break the web, and that’s something that web browser engineers have always been kept very aware of. We carefully gauge real-world usage of things like CSS and DOM features before deprecating anything. At Google we have a copy of the web that we run queries against, so we have a pretty OK idea of what CSS and JavaScript out there is using. </p> <p>Blink also has over 32,000 tests in its test suite, and manual confirmation that over 100 sites work great before every release ships. And we’re working closely with the W3C and Adobe to share tests and testing infrastructure across browsers, with the goals of reducing maintenance burden, improving interoperability, and increasing test coverage. Eventually we’d like all new features to ship with shared conformance tests, ensuring interoperability even as we add cutting-edge stuff.</p> <p>Still, any deprecation has to be done responsibly. There’s now a draft Blink <a href="https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/nmIDo1w9dwg">process for deprecating features</a> which includes:</p> <ul> <li>Anonymous metrics to understand how much any specific feature is used “in the wild”</li> <li>”Intent to deprecate” emails that hit blink-dev months before anything is removed</li> <li>Warnings that you’ll find in your DevTools console if you’re using anything deprecated</li> <li>Mentions on the Chromium blog like <a href="http://blog.chromium.org/2013/04/chrome-27-beta-speedier-web-and-new.html">this Chrome 27 wrap-up</a>.</li> </ul> <p class="question"><b>Did part of the decision to branch away from WebKit involve resistance to adding a Dart VM? WebKit’s goals <a href="http://www.webkit.org/projects/goals.html">explicitly mention JavaScript</a>, and Apple representatives have been <a href="https://lists.webkit.org/pipermail/webkit-dev/2011-December/018806.html](https://lists.webkit.org/pipermail/webkit-dev/2011-December/018806.html">fairly vocal</a> about <a href="https://lists.webkit.org/pipermail/webkit-dev/2011-December/018822.html](https://lists.webkit.org/pipermail/webkit-dev/2011-December/018822.html">not seeing a need</a>.</b></p> <p>Nope, not at all. The decision was made by the core web platform engineers. Introducing a new VM to a browser introduces considerable maintenance cost (we saw this with V8 and JavaScriptCore both in WebKit) and right now Dart isn’t yet ready to be considered for an integration with Blink. (more on that in a sec). Blink’s got strong <a href="http://www.chromium.org/blink#compatibility">principles around compatibility risk</a> and this guides a lot of the decisions around our commitments to potential features as they are proposed. You can hear a more <a href="https://www.youtube.com/watch?feature=player_embedded&amp;v=TlJob8K_OwE#at=1046">complete answer here from Darin Fisher</a>, one of the Chrome web platform leads.</p> <p class="question"><b>Have any non-WebKit browsers recently expressed an interest in Dart? A scripting language that <a href="https://gist.github.com/paulmillr/1208618#file-dart-txt-L320">only stands to work in one browser</a> sounds a little VBScript-y.</em></b></p> <p>Not yet, but since Dart compiles to JavaScript and runs across the modern web, it’s not gated by other browsers integrating the VM. But it’s still early days, Dart has not yet reached a stable 1.0 milestone and that there are still technical challenges with the Dart VM around performance and memory management. Still, It’s important to point out that Dart is an open source project, with a bunch of external contributors and committers.</p> <p>Let me take a moment to provide my own perspective on Dart. :) Now, as you know, I’m a JavaScript guy, so early on, I took a side and and considered Dart an enemy. JavaScript should win; Dart is bad! But then I came to realize the Dart guys aren’t just setting out to improve the authoring and scalability of web application development. They also really want the web to win.&nbsp; Now I’ve recently spoke about how <a href="http://www.lukew.com/ff/entry.asp?1716">The Mobile Web Is In Trouble</a>, and clarified that my priorities are seeing it provide a fantastic user experience to everyone. For me, seeing the mobile web be successful trumps language wars and certainly quibbling over syntax. So I’m happy to see developers embrace the authoring advantages of Coffeescript, the smart subset of JavaScript strict mode, the legendary Emscripten &amp; asm.js combo, the compiler feedback of TypeScript and the performance ambitions of Dart. It’s worth trying out technologies that can leapfrog the current expectations of the user experience that we can deliver. Our web is worth it.</p> <p class="question"><b>Will Opera be using the Chromium version of Blink wholesale, as far as you know? Are we likely to see some divergence between Opera and Chrome?</b></p> <p>As I understand it, Opera Mobile, Opera Desktop, and Opera Mini will all be based on Chromium. This means that they’ll not only share the exact version of Blink that Chrome uses, but also the same graphics stack, JavaScript engine, and networking stack. Already, Opera has contributed some great things to Blink and we’re excited about what’s next.</p> <p class="question"><b>Why the name “Blink,” anyway?</b></p> <p>Haha. Well&hellip; it’s a two parter. First, Blink evokes a certain feeling of speed and simplicity—two core principles of Chrome. Then, Chrome has a little tradition of slightly ironic names. Chrome itself is all about minimizing the browser chrome, and the Chromebook Pixel is all about not seeing any pixels at all. So naturally, it fits that Blink will never support the infamous <code>&lt;blink&gt;</code> tag. ;)</p> <p>&lt;3z</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/_FjSLm1-zBM" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<a href="http://www.w3.org/QA/2013/05/perspectives_on_encrypted_medi.html" style="font-size: 18px;">» W3C to Publish Encrypted Media Extensions Specification</a><br><br>The W3C announced today that it intends to publish the controversial Encrypted Media Extensions extension specification despite highly outspoken resistance, paving the way for native web DRM. <br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/f7uMGgccqS4" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<a href="http://cognition.happycog.com/article/better-stakeholder-interviews" style="font-size: 18px;">» Research Tips For Designers and Developers</a><br><br>How is the waterfall web design process like the childhood game of “Telephone,” and how can we fix it? Bringing designers and developers into the discovery and research phase is a good start, says Happy Cog creative director Chris Cashdollar, who shares stakeholder interviewing tips in this helpful Cognition post.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/Qq8IuA20lkY" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<p>In any given day I can find myself reading up on a new W3C proposal, fixing an issue with our tax return, coding an add-on for our product, writing a conference presentation, building a server, creating a video tutorial, and doing front end development for one of our sites. Without clients dictating my workload I’m in the enviable position of being able to choose where to focus my efforts. However, I can’t physically do everything.</p> <p>I’m one half of a two-person web development business—the team behind the little CMS, Perch. I’m also an author and speaker on subjects that range from CSS to technical support, and I enjoy all of it.</p> <p>When we were a service business, what I was actually working on was largely dictated by the requirements of our clients. Whether they wanted to pay me to build servers, manage projects, or write code didn’t really matter. I was exchanging my time for money, doing a range of things I enjoyed. Now that we’re a product company, my greatest challenge is working out where I am best spending my time, while avoiding falling down a rabbit hole of interesting things I have discovered while performing some other task.</p> <p>The quote that I opened this column with reflects the dilemma I seem to face daily. I can choose to place my attention anywhere. But if I dart around between tasks, none of them get my full attention. At the very least, progress on everything becomes painfuly slow as I spend an hour on one thing and two on another, inching them all forward. I can’t claim to have the perfect solution to managing this problem, but I have started to develop a process for deciding what needs to be done, and whether I am the best person to be doing it.</p> <p>First and foremost you need to identify what needs doing. I am a great fan of <a href="http://en.wikipedia.org/wiki/Getting_Things_Done">Getting Things Done</a> and regularly review our business and my personal goals, and the tasks that will go into meeting them. Once I have a list of tasks, I can assess them against the following criteria:</p> <ul> <li>Am I the only person who can do this?</li> <li>Does the business or product benefit from me in particular doing this?</li> <li>Is this a task I really enjoy doing?</li> <li>Will I learn anything new by doing this?</li> <li>What am I not doing if I choose to do this?</li> </ul> <h2>Am I the only person who can do this?</h2> <p>Things that fall into group one, the things that only I can do, need investigating. It isn’t ideal for any business to have things that only one person can do. It might be that I need to deal with that task <em>today</em>, but how can I make it so that in the future someone else could? Until the middle of last year, our accounts were a case in point. Although we had an accountant do our end of year tax returns, I was the only person who fully understood the complex processes developed to deal with the many incoming small payments for Perch licenses. Taking on a bookkeeper meant I had to formalize and document all of those processes. As a result I don’t have to do the day-to-day books, but perhaps more importantly the business isn’t reliant on knowledge that is only in my head.</p> <h2>Does the business or product benefit from me in particular doing this?</h2> <p>It can make sense to keep some tasks internal. I wouldn’t completely outsource our technical support, or our social media activity, or even our marketing. The public face of our product is very much about us being a small, friendly business. Our customers get to talk to us, the product developers; we share their frustrations and they help us decide on where to put time into new features. There may well be real reasons to keep certain tasks as a role of the core person or team, even if they would seem straightforward to outsource.</p> <h2>Is this a task I really enjoy doing?</h2> <p>Running a business can involve hard work and long hours. If you feel you have to outsource bits of your job that you love doing because it makes most sense as a business, you may end up pretty miserable. For those of us running small software companies, it’s likely we have ended up here because we like to code. So it’s important to me that I spend some of my time actually writing code—even if it might be more sensible from a business perspective for me to just manage other people who are writing code.</p> <p>I believe that our products and businesses are better when we love being involved with them. To have a successful business, it’s likely that you will always have important things to do that you find less enjoyable than designing or writing code, however I don’t think we should be beating ourselves over the head. Doing what we love is really what has been behind the success of our product. It is completely ok to hang onto some tasks because you simply enjoy doing them.</p> <h2>Will I learn anything new by doing this?</h2> <p>I might really enjoy a particular project, but I find a helpful way to decide if I should do something or contract it out is to see whether I will learn anything new by doing it myself. For example, I have just sent out a sizeable chunk of front-end development. It is a rebuild of an existing site, and I think there are lots of practical and performance gains to be had by rebuilding it. It would have been nice to have done that work myself, but I wouldn’t have learned anything by doing it. Therefore I made the decision that this would be a good piece of work to outsource to a contractor. I can manage that project and make sure that I’m happy with the end result, but I don’t need to actually write the code.</p> <p>Our business benefits by us having knowledge and understanding. I’m currently spending quite a lot of time learning about automation (using <a href="https://puppetlabs.com/">Puppet</a>) and modern ways of managing systems while rebuilding our infrastructure. I could have brought someone in to do this work for me, and may well do so in future. Yet by updating my systems administration skills, I’m ensuring that within the business we maintain a good level of knowledge about our infrastructure.</p> <h2>What am I not doing if I choose to do this?</h2> <p>As part of a tiny team of two, I’ll always have a number of tasks on the go. Ultimately, choosing to take on one task means not doing something else. It might be another task in the business that gets pushed back. It might be personal things like exercise, or spending time with family and friends. To be able to understand the implications of selecting one thing to work on over another, you need to have a really good overview of all the things that are trying to get your attention.</p> <p>Having clear business goals and objectives in the first place can make this decision-making so much easier. When you find yourself in the position of being able to do anything, it is so easy to run around picking up tasks and trying to do everything. The trick is to take that step back; to see where you can be more strategic with which tasks you tackle and which you delegate. This approach can help you be far more productive and give you space to enjoy the work you are doing while meeting your business goals.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/yiLQQ29l58s" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<p>Ilya Grigorik discusses in detail how to construct a mobile website that loads as quickly as possible. A site that not only renders in 1 second, but one that is also visible in 1 second. With hard statistics as evidence to show why this matters, Ilya discusses techniques to deliver a 1000 millisecond experience.</p> <figure> <iframe width="696" height="392" src="http://www.youtube.com/embed/Il4swGfTOSM?rel=0" frameborder="0" allowfullscreen></iframe> </figure><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/VpCuD_mMqCU" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

<p>Arguing for “separation of content from presentation” implies a neat division between the two. The reality, of course, is that content and form, structure and style, can never be fully separated. Anyone who’s ever written a document and played around to see the impact of different fonts, heading weights, and whitespace on the way the writing flows knows this is true. Anyone who’s ever squinted at HTML code, trying to parse text from tags, knows it too.</p> <p>On one hand, the division of labor between writing and presentation can be seen at every point in our history. Ancient scribes chiseling stone tablets, medieval monks copying illuminated manuscripts, printers placing movable type—we’ve never assumed that the person who produces the document and the person who comes up with the ideas must be one and the same.</p> <p>And yet, we know that medium and message are intertwined so tightly, they can’t be easily split apart. Graphic designers rail against the notion that “look and feel” can be painted on at the end of the process, because design influences meaning. The more skilled we are as communicators, the more we realize that the separation of content from presentation is an industrial-age feint, an attempt to standardize and segment tasks that are deeply connected.</p> <p>Today, we try to enforce the separation of content and form because it’s good for the web. It’s what makes web standards possible. It enables social sharing and flexible reuse of content. It supports accessibility. It’s what will keep us sane as we try to get content onto hundreds of new devices and form factors.</p> <p>When talking about how best to separate content from presentation, designers and developers tend to focus on front-end code—which makes sense, because that’s what we have the most control over. But, as with so many challenges we have with content on the web, the real issue lies in the tools we give content creators to help them structure, manage, and publish their content. The form that content takes depends as much on CMS as it does on CSS.</p> <p>How should content management tools guide content creators to focus on meaning and structure? What’s the right amount of control over presentation and styling in the CMS? And how should these tools evolve as we break out of the web page metaphor and publish content flexibly to multiple platforms? Let’s look at three tools that sit at the intersection of content and form.</p> <h2>Preview button</h2> <p>Even the most die-hard structured content editors still like seeing what their work is going to look like. Writers print out documents for editing to give them a different view from what they see on the screen. Bloggers instinctively hit the preview button to look at their work the way a user will see it.</p> <p>Whoops. Decades of work refining the emulators between desktop publishing programs and laser printers means that writers can feel confident that their document will look virtually identical, regardless of where it’s printed. We’ve carried that assumption over to the web, where it’s categorically untrue. Different browsers render content in their own vexingly special way. Users can change the font size—even add their own custom style sheet. Today, the same document will render differently on desktops, tablets, and mobile devices. The preview button is a lie.</p> <p>Yet we can’t just throw the baby out with the bathwater. In fact, seeing content in context becomes even <em>more</em> important as our content now lives across devices and platforms. Instead of throwing up our hands and saying “preview is broken,” it’s time to invent a better preview button.</p> <p>One publishing company I know of has built its own custom preview rendering interface, which shows content producers an example of how each story will appear on the desktop web, the mobile web, and an app. Is it perfect? Far from it. Content will appear in many more contexts than just those three. Is it better than nothing? Absolutely.</p> <h2>WYSIWYG</h2> <p>The desktop publishing revolution ushered in by the Macintosh allowed the user to see a document on screen in a form that closely mirrored the printed version. The toolbar at the top of the screen enabled the user to add formatting—change the font, insert an image, add typographic effects like headings and bullets, and much more.</p> <p>In an effort to carry over this ease of use to the web, we allow content creators to embed layout and styling information directly into their content. Unfortunately, the code added by content creators can be at odds with the style sheet, and it’s difficult for developers to parse what’s style and what’s substance. When it comes time to put that content on other platforms, we wind up with a muddled mess.</p> <p>What is the right amount of formatting control to give content creators? That’s a difficult question to answer, because it pierces right to the heart of what’s stylistic and what’s semantic. Even something as simple as adding bold and italic text forces us to ask if we’re really just styling the text, or adding semantic meaning (say, a book title or a warning message.)</p> <p>Better content modeling can solve some of these problems, encouraging content creators to appropriately “chunk” their text. By banishing blobs of text with formatting embedded and replacing them with chunks of clean, presentation-independent content, we’re building in the distinction between content and form right from the start.</p> <p>But imagining that each “chunk” of content is a field in the database (with its own input field) rapidly devolves into the absurd. That way lies madness. The real solution isn’t necessarily to “banish blobs,” but to replace the WYSIWYG toolbar with semantic markup. Rather than entering all text into discrete fields, content authors wrap text that describes what it is. Our book title doesn’t need to be a separate field if we can wrap it in the proper tags.</p> <p>Defining what goes in a field and what goes in a tag requires a tighter collaboration between content authors, CMS architects, and front-end developers. It’s time we started having these conversations.</p> <h2>Inline editing</h2> <p>We’re evolving. Not satisfied to rely just on tools that are vestiges of the desktop publishing era, we’re developing new and innovative ways to mix up content and formatting that are unique to the way the web works. There’s no better example of this than inline editing.</p> <p>Inline editing allows content creators to directly manipulate content in the interface, with no separation between the editing screen and the display. Medium offers an editing interface that’s <a href="https://medium.com/about/df8eac9f4a5e">identical to the desktop display</a> and in-place editing is being <a href="http://drupal.org/project/spark">added to Drupal 8 core</a>.</p> <p>One of the questions I get asked most frequently is “how can I get my content creators to understand why it’s so important to add structure and metadata to their content?” This, I believe, is one of the fundamental challenges we’re facing on the web, particularly as we adapt to a multi-channel future. Inline editing encourages content creators to focus on the visual presentation of the desktop interface. Just at the moment when we need content creators to think about the underlying structure, we’re investing in tools that obscure the “connective tissue.”</p> <p>Jeff Eaton sums up this problem nicely in a post called <a href="https://www.lullabot.com/articles/inline-editing-and-cost-leaky-abstractions">Inline Editing and the Cost of Leaky Abstractions</a>:</p> <figure class="quote"><blockquote><p>The editing interfaces we offer to users send them important messages, whether we intend it or not. They are affordances, like knobs on doors and buttons on telephones. If the primary editing interface we present is also the visual design seen by site visitors, we are saying: “This page is what you manage! The things you see on it are the true form of your content.”</p> </blockquote> </figure> <p>The best solution isn’t to build tools that hide that complexity from the user, that make them think that the styling they’re adding to the desktop site is the “real” version of the content. Instead, our goal should be to communicate the appropriate complexity of the interface, and help guide users to add the right structure and styling.</p> <p>The era of “desktop publishing” is over. Same goes for the era where we privilege the desktop web interface above all others. The tools we create to manage our content are vestiges of the desktop publishing revolution, where we tried to enable as much direct manipulation of content as possible. In a world where we have infinite possible outputs for our content, it’s time to move beyond tools that rely on visual styling to convey semantic meaning. If we want true separation of content from form, it has to start in the CMS.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/8MK6ULY0bLI" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)

In an email to the WHATWG mailing list Ian Hickson explained how the relationship between the WHATWG and W3C effort around HTML has evolved. It is recommended reading if you want to know the details. In summary, we will remain focused on improving HTML and related technologies to address the needs of users, developers, and [...][mehr] (Quelle: The WHATWG Blog)

A new release of the Validator.nu HTML Parser is available. The new version 1.4 contains minor adjustments to spec compliance and fixes for notable Java-specific problems (of the crash and infinite loop sort). Also, the parser is again available from the Maven Central Repository (groupId: nu.validator.htmlparser, artifactId: htmlparser, version: 1.4). Upgrading to the newest version [...][mehr] (Quelle: The WHATWG Blog)

I apologize for the longer than expected wait for this article, but now, we may continue. The article below will pick up where Part 1 left off. Article 1: Websites and SectioningPart 2: Styling &#60;warning&#62;Warning: This article discusses the topic of &#60;semantics&#62;semantics&#60;/semantics&#62;&#60;/warning&#62; As we began with previously, we now have the basics down as to [...][mehr] (Quelle: The WHATWG Blog)

Like probably many others who read this blog, I am a web design enthusiast, web standards advocate, and web designer by trade. I have been working with HTML since the early 2000s, and have enjoyed it ever since. Over the years, the web has evolved around me. I have watched it grow and adapt. And [...][mehr] (Quelle: The WHATWG Blog)

The WHATWG now has a patent policy, the WHATCG. We will keep using the same mailing list, the same IRC channel, the same web sites, but now sometimes we will publish through the WHATCG as well for patent policy purposes per the W3C Community Final Specification Agreement. If you could previously not join the WHATWG [...][mehr] (Quelle: The WHATWG Blog)

Ian Hickson made a proposal to unify Web Intents with registerProtocolHandler() and registerContentHandler(). The Encoding Standard now has all its decoders defined. This is the WHATWG Weekly. The big news this week is the new dialog element. Introduced in revision 7050, along with a new global attribute called inert, a new form element method attribute [...][mehr] (Quelle: The WHATWG Blog)

The StringEncoding proposal is getting closer to consensus. It now consists of a TextEncoder and a TextDecoder object that can be used both for streaming and non-streaming use cases. This is the WHATWG Weekly. Some bad news for a change. It may turn out that the web platform will only work on little-endian devices, as [...][mehr] (Quelle: The WHATWG Blog)

Jonas Sicking proposed an API for decoding ArrayBuffer objects as strings, and encoding strings as ArrayBuffer objects. The thread also touched on a proposal mentioned here earlier, StringEncoding. This is the mid-March WHATWG Weekly. Revision 7023 added the Path object to HTML for use with the canvas element, and the next revision made it possible [...][mehr] (Quelle: The WHATWG Blog)

Apple's Safari team provided feedback to the Web Notifications Working Group. That group, incidentally, is looking for an active editor to address that and other feedback. Opera Mobile shipped with WebGL support. This is March's first WHATWG Weekly. Simon Pieters overhauled much of HTML5 differences from HTML4 and the document now provides information on added/changed [...][mehr] (Quelle: The WHATWG Blog)

A draft for the SPDY protocol has been submitted, the W3C HTML WG mailing list goes crazy over media DRM. This is the WHATWG Weekly. In response to feedback Adam Barth changed the getRandomValues() method to return the array the method modifies. The method is part of the window.crypto proposal. Ian Hickson has been busy [...][mehr] (Quelle: The WHATWG Blog)

Die Barrierefreiheit von Webseiten wird in Deutschland durch die &#8220;Barrierefreie Informationstechnik-Verordnung&#8221;, kurz BITV geregelt. Wenngleich sich der Wirkungsbereich nur auf Seiten von Behörden erstreckt, hat die BITV auch eine große Bedeutung für Unternehmensseiten bekommen. Die BITV ist naturgemäß stellenweise abstrakt, ähnlich wie die verwandten englischen Texte des W3C. Um die Verständlichkeit zu erhöhen, haben wir [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)

Als Ergänzung zu den Zugänglichkeitsrichtlinien für Web-Inhalte steht ab heute auch die BITV hier zur Verfügung.

(Quelle: <edition W3.de> Neuigkeiten)

Dem im März 2009 erschienenen Internet Explorer 8 wurde von Anfang an eine bessere Unterstützung von Webstandards bescheinigt. Wer Websites macht, wird das bestätigen können. Wer allerdings Javascript-Bibliotheken entwickelt, die von anderen auf ihren Seiten eingesetzt werden sollen, kann ein anderes Bild bekommen. Mit dem IE6 hat Microsoft die Unterscheidung in &#8220;Quirks Mode&#8221; und &#8220;Standard [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)

Am 3. Dezember hat die Ecma die Verabschiedung von ECMAScript5 bekanntgegeben. Im Gegensatz zu manch anderem Standardisierungsgremium, bietet die Ecma ihre Standards kostenfrei zum Download auf der Webseite an: Für ECMAScript siehe Ecma-262. ECMAScript ist die standardisierte Form von Javascript und damit ein wichtiger Baustein für die Weiterentwicklung des Web. Über die wichtigsten neuen Features [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)

Einmal mehr dürfen wir uns über Bestnoten für unseren XSLT-Workshop freuen. In der vergangenen Woche haben wir eine XSLT-Schulung für einen neuen Kunden durchgeführt. Die Kundenbewertungen auf den Feedbackbögen zeichnet uns und unsere Leistung aus. In allen Punkten, von &#8220;Inhalt&#8221; über &#8220;Präsentation&#8221; und &#8220;Übungen&#8221; bis zur &#8220;Gesamtbewertung&#8221; bekommen wir sehr gute Noten. Darüber hinaus sagen [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)

Heute geht eine überarbeitete Version der <edition W3.de> online.

(Quelle: <edition W3.de> Neuigkeiten)

Zum Jahresende wird die Verabschiedung von EcmaScript 5 erwartet. In der aktuellen Ausgabe der iX schreibe ich über die wichtigsten neuen Features. Für alle Leser des Artikels oder diejenigen, die sich selbst einen Eindruck verschaffen möchten, stelle ich im Folgenden die Quellen zusammen. Wikipedia: ECMAScript Allen Wirfs-Brock: Steps Toward Creating Compatible ECMAScript 5 Implementations Allen [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)

Heute habe ich bei der Arbeit mit einer XSLT-Engine an meinem Verstand gezweifelt. Die Aufgabe war einfach: Ein kleines Verarbeitungsskript für eine Webseite. Doch leider brach die Verarbeitung immer ab, weil der XSLT-Interpreter die DTD nicht vom Server des W3C laden konnte. Natürlich sollte man besser eine lokale DTD verwenden, dennoch war es überraschend, dass [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)

Die ursprüngliche Idee der Adressen im Web beinhaltet auch, dass man über eine Adressangabe eine Seite finden kann. Schließlich heißt der Fachbegriff nicht umsonst URI &#8212; Uniform Resource Identifier. Es gibt aber zahlreiche Beispiele, bei denen das nicht der Fall ist. Oft sind Session-IDs, Query-Parameter oder andere temporäre Informationen in der Adresse enthalten. Die machen [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)

Es ist schön zu sehen, dass Semantic Web Technologien zunehmend zum Thema werden. Jüngster Zuwachs im Bereich der Semantic Web Community ist wohl semanticoverflow.com, eine Seite die sich ganz im stile ihres grossen Bruders stackoverflow.com der Aufgabe widmet Fragen rund um das Thema Semantic Web Community-basiert zu beantworten. Ich wünsche der Seite zumindest vergleichbaren Erfolg [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)

Na ja, ganz so weit ist es noch nicht. Aber sollte ich mal einen persönlichen, autonomen und wirklich intelligenten Software-Agenten mein Eigen nennen, könnte er ja auch mal Angst haben, sich überlastet oder ausgebrannt fühlen. Das W3C arbeitet jedenfalls schon mal an der passenden Auszeichnungssprache: EmotionML. Wer jetzt glaubt, die Initiative sei genauso sinnvoll wie [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)

&#8230;und der ein oder andere mag sich fragen, was ist &#8220;GeoCities&#8221;? In der Frage ist zumindest die Antwort auf die Frage zu finden, weshalb Yahoo die Site dicht macht. &#8220;Wow, eine geschlossene Website, das ist&#8217;n Blogartikel wert!&#8221; &#8212; Die Tatsache ist wohl nicht bemerkenswert, allerdings ist der Artikel der L.A. Times lesenswert für alle, die [...][mehr] (Quelle: blog.linkwerk.com » edition W3.de)