<edition W3.de>

Web-Standards in deutscher Sprache

Auf <edition W3.de> findest Du Web-Standards in deutscher Sprache. Es handelt sich um Übersetzungen der englischen Originaltexte, zum Teil mit fachlicher Kommentierung.

Ein Linkwerk-Projekt

Webnews Feed Die wichtigsten Webfeeds auf einem Blick - zusammengestellt von <edition W3.de>

22. Jul 2014
First Draft of Mixed Content Published
The Web Application Security Working Group has published a First Public Working Draft of Mixed Content. This specification details how user agents can mitigate risks to security and privacy by limiting a resource???s ability to inadvertently communicate in the clear, or to expose non-public resources to the web at large. This specification describes how and [&#8230;][mehr] (Quelle: W3C News)
21. Jul 2014
W3C Launches Push for Social Web Application Interoperability
W3C today launched a new Social Activity to develop standards to make it easier to build and integrate social applications with the Open Web Platform. Future standards —including vocabularies for social applications, activity streams, embedded experiences and in-context actions, and protocols to federate social information such as status updates— will address use cases that range [&#8230;][mehr] (Quelle: W3C News)
17. Jul 2014
W3C Invites Implementations of Polyglot Markup: A robust profile of the HTML5 vocabulary
The HTML Working Group invites implementation of the Candidate Recommendation of Polyglot Markup: A robust profile of the HTML5 vocabulary. It is sometimes valuable to be able to serve HTML5 documents that are also well formed XML documents. An author may, for example, use XML tools to generate a document, and they and others may [&#8230;][mehr] (Quelle: W3C News)
17. Jul 2014
This week's sponsor: Bigstock
<p><a href="http://bit.ly/1qzJq5U">Bigstock</a> is now offering a 7-day free trial. Get 35 free hi-res, royalty-free images. <a href="http://bit.ly/1qzJq5U">Download now!</a></p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/TCqgFxphqOY" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
17. Jul 2014
Laura Kalbag on Freelance Design: I Don&#8217;t Like It
<p>“I don’t like it”—The most dreaded of all design feedback from your client/boss/co-worker. This isn’t so much a matter of <a href="http://alistapart.com/column/me-and-my-big-fat-ego">your ego being damaged</a>, it’s just not useful or constructive criticism.</p> <p>In order to do better we need feedback grounded in understanding of user needs. And we need to be sure it’s not coming from solely the client’s aesthetic preferences, which may be impeccable but may not be effective for the product.</p> <p>Aesthetics are a matter of taste. <a href="http://insideintercom.io/the-dribbblisation-of-design/">Design is not just aesthetics</a>. I’m always saying it, but it’s worth repeating: there are aesthetic decisions in design, but they are meant to contribute to the design as a whole. The design as a whole is created for an audience, and with goals in mind, so objectivity is required and should be encouraged.</p> <p>Is the client offering an opinion based on her own taste, trying to reflect the taste of the intended audience, or trying to solve a perceived problem for the user? Don’t take “I don’t like it” at face value and try to respond to it without more communication.</p> <h2>How do we elicit better feedback?</h2> <p>To elicit the type of feedback we want from clients, we should encourage open-ended critiques that explain the reasons behind the negative feedback, critiques that make good use of conjunctions like “because.” “I don’t like it because…” is already becoming more valuable feedback.</p> <figure class="quote"> <blockquote> <p><b>Designer:</b> Why don’t you like the new contact form design?</p> <p><b>Client:</b> I don’t like it because the text is too big.</p> </blockquote> </figure> <p>Whether that audience can achieve their goals with our product is the primary factor in its success. We need clients to understand that they may not be the target audience. Sometimes this can be hard for anyone close to a product to understand. We may be one of the users of the products we’re designing, but the product is probably not being designed solely for users like us. The product has a specific audience, with specific goals. Once we’ve re-established the importance of the end user, we can then reframe the feedback by asking the question, “how might the users respond?”</p> <figure class="quote"> <blockquote> <p><b>Designer:</b> Do you think the users will find the text too big?</p> <p><b>Client:</b> Yes. They’d rather see everything without having to scroll.</p> <p><b>Designer:</b> The text will have to be very small if we try to fit it all into the top of the page. It might be hard to read.</p> <p><b>Client:</b> That’s fine. All of our users are young people, so their eyesight is good.</p> </blockquote> </figure> <p>Throughout the design process, we need to check our hidden assumptions about our users. We should also ensure any feedback we get isn’t based upon an unfounded assumption. If the client says the users won’t like it, ask why. Uncover the assumption—maybe it’s worth testing with real users?</p> <figure class="quote"> <blockquote> <p><b>Designer:</b> Can we be certain that all your users are young people? And that all young people have good eyesight? We might risk losing potential customers unless the site is easy for everyone to read.</p> </blockquote> </figure> <p>How do we best separate out assumptions from actual knowledge? Any sweeping generalizations about users, particularly those that assume users all share common traits, are likely to need testing. A thorough base of <a href="http://alistapart.com/article/interviewing-humans">user research</a>, with evidence to fall back on, will give you a much better chance at spotting these assumptions.</p> <h2>The design conversation</h2> <p>As designers, we can’t expect other people to know the right language to describe exactly why they think something doesn’t work. We need to know the right questions that prompt a client to give constructive criticism and valuable feedback. I’ve <a href="http://alistapart.com/column/good-designers-good-clients">written before</a> on how we can pre-empt problems by explaining our design decisions when we share our work, but it’s impossible to cover every minute detail and the relationships between them. If a client can’t articulate why they don’t like the design as a whole, break the design into components and try to narrow down which part isn’t working for them.</p> <figure class="quote"> <blockquote> <p><b>Designer:</b> Which bit of text looks particularly big to you?</p> <p><b>Client:</b> The form labels.</p> </blockquote> </figure> <p>When you’ve zeroed in on a component, elicit some possible reasons that it might not be effective.</p> <figure class="quote"> <blockquote> <p><b>Designer:</b> Is it because the size of the form labels leaves less space for the other elements, forcing the users to scroll more?</p> <p><b>Client:</b> Yes. We need to make the text smaller.</p> </blockquote> </figure> <h2>Reining it in</h2> <p>Aesthetics are very much subject to taste. You know what colors you like to wear, and the people you find attractive, and you don’t expect everyone else to share those same tastes. Nishant wrote <a href="http://alistapart.com/column/good-taste-doesnt-matter">a fantastic column about how Good Taste Doesn’t Matter</a> and summarized it best when he said:</p> <figure class="quote"> <blockquote> good and virtuous taste, by its very nature, is exclusionary; it only exists relative to shallow, dull…tastes. And if good design is about finding the most appropriate solution to the problem at hand, you don’t want to start out with a solution set that has already excluded a majority of the possibilities compliments of the unicorn that is good taste. </blockquote> </figure> <h2>Taste’s great</h2> <figure class="quote"> <blockquote> <p><b>Designer:</b> But if we make the text smaller, we’ll make it harder to read. Most web pages require scrolling, so that shouldn’t be a problem for the user. Do you think the form is too long, and that it might put users off from filling it in?</p> <p><b>Client:</b> Yes, I want people to find it easy to contact us.</p> <p><b>Designer:</b> How about we take out all the form fields, except the email address and the message fields, as that’s all the information we really need?</p> <p><b>Client:</b> Yes, that’ll make the form much shorter.</p> </blockquote> </figure> <p>If you’re making suggestions, don’t let a client say yes to your first one. These suggestions aren’t meant as an easy-out, allowing them to quickly get something changed to fit their taste. This is an opportunity to brainstorm potential alternatives on the spot. Working collaboratively is the important part here, so don’t just go away to work out the first alternative by yourself. </p> <p>If you can work out between you which solution is most likely to be successful, the client will be more committed to the iteration. You’ll both have ownership, and you’ll both understand why you’ve decided to make it that way.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/dOrEG9P8E7w" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
21. Jul 2014
Web Annotations on the Horizon
Annotation, the act of creating associations between distinct pieces of information, is a widespread activity online in many guises but currently lacks a structured approach. People comment about online resources using tools built into the hosting web site, external web services, or the functionality of an annotation client. When reading eBooks, people make use the [&#8230;][mehr] (Quelle: W3C News)
15. Jul 2014
Character Model for the World Wide Web: String Matching and Searching Draft Published
The Internationalization Working Group has published a Working Draft of Character Model for the World Wide Web: String Matching and Searching. This document builds upon on Character Model for the World Wide Web 1.0: Fundamentals to provide authors of specifications, software developers, and content developers a common reference on string identity matching on the World [&#8230;][mehr] (Quelle: W3C News)
15. Jul 2014
Kids 4–6: &#8220;The Muddy Middle&#8221;
<p>I call kids between ages 4 and 6 the “muddy middle,” because they’re stuck right in between the cute, cuddly preschool children and the savvy, sophisticated elementary-schoolers. They’re too old for games designed for toddlers, but they can’t quite read yet, so they struggle with sites and apps geared toward older kids. Unfortunately, you rarely see a digital product designed specifically for this age group, because they’re hard to pin down, but these little guys are full of ideas, knowledge, creativity, and charisma.</p> <p>Like the 2&#8211;4s, these children are still in the preoperational stage, but they present their own set of design challenges based on where they are cognitively, physically, and emotionally.</p> <h2>Who are they?</h2> <p>Table 5.1 shows some key characteristics that shape the behavior and attitudes of 4–6-year-olds and how these might impact your design decisions.</p> <p>You’ll find that 4–6-year-olds have learned “the rules” for how to behave, how to communicate, and how to play. Now they’re looking for ways to bend and break these rules. They understand limitations—angry parents, broken toys, and sad friends have taught them well—but they still take every opportunity to test these limitations. Digital environments provide a perfect place for these active kids to challenge the status quo and learn more about the world around them.</p> <figure> <table> <tr> <th width="26%">4–6 year-olds&#8230;</th> <th width="37%">This means that&#8230;</th> <th width="37%">You’ll want to&#8230;</th> </tr> <tr> <td>Are empathetic.</td> <td>They’re beginning to see things from other perspectives.</td> <td>Make interactions feel more “social,” even if the kids aren’t actually communicating with others.</td> </tr> <tr> <td>Have an intense curiosity about the world.</td> <td>They’re very interested in learning new ideas, activities, and skills, but may become frustrated when that learning takes longer than they would like.</td> <td>Set attainable goals for the tasks and activities you create. Provide context-based help and support so kids have an easier time processing information.</td> </tr> <tr> <td>Are easily sidetracked.</td> <td>They sometimes have trouble following through on a task or activity.</td> <td>Keep activities simple, short, and rewarding. Provide feedback and encouragement after milestones.</td> </tr> <tr> <td>Have wild imaginations.</td> <td>They prefer to create on their own rather than following strict instructions or step-by- step directions.</td> <td>Make “rules” for play/engagement as basic as possible and allow for a lot of invention, self-expression, and storytelling.</td> </tr> <tr> <td>Are developing increased memory function.</td> <td>Can recall complex sequences of events just by watching someone perform them.</td> <td>Include multi-step activities and games, with more than one main goal (for example, touch the red stars and green apples to get points of different values).</td> &nbsp; </tr> </table> <figcaption>Table 5.1: Considerations for 4–6-year-olds</figcaption> </figure> <h2>Make it social</h2> <p>When you think of social design for adults, you may think of experiences that let users communicate and interact with others. The same is true of social design for kids, but in this case, “others” doesn’t have to mean other kids or even other humans. It means that kids need to feel like part of the experience, and they need to be able to observe and understand the interactions of characters in the experience, as players and contributors. Kids at this age understand that individual differences, feelings, and ideas are important and exciting. Showcasing these differences within the experience and directly communicating with users allows this social aspect to come through and provide additional depth and context to interactions.</p> <p>Sometimes, making something feel social is as easy as presenting it in the first person. When characters, elements, and instructions speak directly to kids, it makes it easier for them to empathize and immerse themselves in the experience.</p> <p>Let’s take a look at an example from <em><a href="http://www.seussville.com/">Seussville</a></em>. The designers of this highly engaging site keep the uniqueness of Dr. Seuss’s characters vibrantly alive in their lovely character chooser. Every character (and I do mean <em>every</em>) from every Dr. Seuss book glides by on whimsical conveyor belts, letting the user pick one to play with (see Figure 5.1). </p> <p>This character chooser provides a strong social experience for kids, because it allows them to “meet” and build relationships with the individual characters. Kids can control the viewer, from a first-person perspective, to see the visual differences among the characters, as well as personality details that make the characters unique, much like how they’d go about meeting people in real life (without the conveyor belt, of course).</p> <p>When users choose a character, they are shown a quote, a book list, and details about the character on the pull-down screen to the right. On the left side of the screen, a list of games and activities featuring the character magically appears.</p> <figure> <img src="http://d.alistapart.com/398/fig05.01.jpeg" alt="Screenshot of the Seussville homepage"> <figcaption>FIGURE 5.1: <em>Seussville</em> presents a first-person perspective to kids.</figcaption></figure> <figure> <img src="http://d.alistapart.com/398/fig05.02.jpeg" alt="Screenshot of Seussville's games and activities page"> <figcaption>FIGURE 5.2: <em>Seussville</em> feels social, even though kids don’t interact with other humans.</figcaption></figure> <p>This social experience is carried through across most of the games on the site. For example, when users pick the “Horton Hears a Tune” game from Horton the elephant’s list of activities, they can compose their own melody on the groovy organ-like instrument under the supportive eyes of Horton himself. Then, in true social fashion, they can save their tune and share it with family and friends.</p> <figure> <img src="http://d.alistapart.com/398/fig05.03.jpeg" alt="Screenshot of “Horton Hears a Tune” on Seussville"> <figcaption>FIGURE 5.3: “Horton Hears a Tune” lets kids compose music and share it.</figcaption></figure> <h2>Make learning part of the game </h2> <p>As a designer, you know that providing help when and where your users need it works better than forcing them to leave the task they’re trying to complete to get help. This is especially true for 4–6-year-olds, who have a strong curiosity for why things are the way they are and want to know everything <em>right away</em>. Unlike the “school stinks” mentality of earlier generations, today’s kids are fascinated with learning and want to soak up as much information as possible. </p> <p>This new attitude could be because learning is more dynamic, more hands-on, and more inventive than it’s been in the past, or because computers, tablets, and other digital teaching tools make learning fun. However, younger kids still lack patience when learning takes longer than they’d like. You’ll want to provide short, manageable instructions to make learning fast, easy, and pleasurable, and to incorporate learning into the experience itself.</p> <p>The <em>Dinosaur Chess</em> app does a great job with structured teaching, as well as on-the-spot assistance to help kids learn how to play chess (see Figure 5.4). Upon launching the app, children get to choose what they want to do. The great thing about <em>Dinosaur Chess</em> is that it’s not just all about chess—kids can take lessons, check their overall progress, and even participate in a “dino fight!”</p> <p>One perk is how the app links the activities via a treasure-hunt-style map on the menu screen. It gently recommends a progression through the activities (which older kids will follow), but is subtle enough to allow exploration. This feature is great for kids who like to break the rules, because it establishes a flow, yet invites users to deviate from it in a subtle yet effective way.</p> <figure> <img src="http://d.alistapart.com/398/fig05.04.jpeg" alt="Screenshot of the Dinosaur Chess homescreen"> <figcaption>FIGURE 5.4: <em>Dinosaur Chess</em> offers many opportunities for learning.</figcaption></figure> <p>When users select the “learn” option, they are taken to a screen where an avuncular dinosaur (who, for some reason, is Scottish) talks kids through the mechanics of chess in a non-intimidating way. Since these kids are still learning to read, the designers used voice-overs instead of text, which works really well here.</p> <p>The lessons are broken up into short, manageable chunks—essential for learning via listening—which let the 4–6s learn a little at a time and progress when they are ready. The children can also try out various moves after learning them, which is particularly effective with younger users who learn by seeing and doing (see Figure 5.5).</p> <p>If this app were designed for an adult audience, the lessons would be a little longer and would probably include text explanations in addition to the audio, since a combination of listening and reading works best for grown-ups. However, the brief audio segments coupled with animated examples are perfect for younger users’ short attention spans and desire to learn as much as quickly as possible.</p> <figure> <img src="http://d.alistapart.com/398/fig05.05.jpeg" alt="Screenshot of a chess game"> <figcaption>FIGURE 5.5: <em>Dinosaur Chess</em> teaches kids how to play chess in short, informational chunks.</figcaption></figure> <p>My favorite aspect of <em>Dinosaur Chess</em> is its guided playing. At any point during the game, kids can press the “?” button for help. Instead of popping a layer, which many sites and apps do (even those designed for a younger audience), <em>Dinosaur Chess</em> uses subtle animation and voice-overs to show the users what their next moves should be, as shown in Figure 5.6.</p> <figure> <img src="http://d.alistapart.com/398/fig05.06.jpeg" alt="Screenshot of a chess game showing contextual help arrows"> <figcaption>FIGURE 5.6: <em>Dinosaur Chess</em> uses animation and voice-overs to provide contextual help.</figcaption></figure> <h2>Give feedback and reinforcement</h2> <p>As anyone knows who has dealt with this age group, 4–6-year-olds have short attention spans. This is particularly true of the younger ones, because kids ages 6 and up are able to pay attention for longer periods of time and absorb more information in a single session. What’s interesting (and challenging) about these younger ones is that they get frustrated at themselves for not being able to focus, and then they channel that frustration onto the experience.</p> <p>A common response to this from designers is: “Well, I’ll make my app/game/site super fun and interesting so that kids will want to play longer.” That’s not going to happen. A better approach is to identify opportunities within the experience to provide feedback, in order to encourage kids to continue. </p> <p>Here are some ways to keep children focused on a particular activity:</p> <ul> <li><b>Limit distractions</b>. With a child audience, designers tend to want to make everything on the screen do something, but if you want your 4–6s to complete a task (for example, finish a puzzle or play a game), then remove extra functionality.</li> <li><b>Break it up</b>. As when you’re designing for 2–4s, it’s best to break activities for 4–6s into manageable components. The components can be a bit bigger than ones you might design for a younger audience, but many clear, simple steps are better than fewer, longer ones. While adult users prefer to complete as few steps as possible, and scroll down to finish a task on a screen, 4–6s like finishing a step and moving to a new screen.</li> <li><b>Make it rewarding</b>. Provide feedback after each piece of an activity is completed, which will help your users stay motivated to continue. If you have the time and budget, use a combination of feedback mechanisms, to keep an element of surprise and discovery in the task-completion process.</li> </ul> <h2>Keep it free-form</h2> <p>The 4–6-age bracket gravitates toward activities that are open and free-form, with simple, basic rules (and lots of opportunities to deviate from the rules). This changes pretty dramatically when kids hit age 7 or so. At that point, they become quite focused on staying within boundaries and need a certain level of structure in order to feel comfortable. However, these younger kids like to break the rules and test limits, and digital environments are the perfect places to do this.</p> <p><em><a href="http://www.zoopz.com/">Zoopz.com</a></em> has a great mosaic-maker tool, which lets kids enhance existing mosaic designs or create their own from scratch (see Figures 5.7 and 5.8).</p> <figure> <img src="http://d.alistapart.com/398/fig05.07.jpeg" alt="Screenshot of a Zoopz.com mosaic"> <figcaption>FIGURE 5.7: An existing mosaic design from <em>Zoopz.com</em>, which lets kids experiment and test limits.</figcaption></figure> <figure> <img src="http://d.alistapart.com/398/fig05.08.jpeg" alt="Screenshot of a Zoopz.com mosaic being created"> <figcaption>FIGURE 5.8: <em>Zoopz.com</em> mosaic-creator enables kids to create their own cool designs.</figcaption></figure> <p>The nice thing about <em>Zoopz</em> is that it requires little to no explanation in order to make mosaics—kids can jump right in and start playing. This feature is important, as younger ones will get frustrated if they need to listen to detailed instructions before getting started and will likely move on to something else before the instructions are complete. Typically, 4- and 5-year-olds will leave websites and close apps that they can’t immediately figure out. Older kids will hang around and pay attention to directions if the perceived reward is high enough, but young ones abandon the site right away. So if your game allows for free exploration, make sure that it’s really free and doesn’t require lots of information in order to play.</p> <p>An important thing to note about open exploration/creation: If you’re designing something with a “takeaway,” as <em>Zoopz</em> is, make sure that kids can either print or save their creations. The only thing kids like better than playing by their own rules is showing their work to others. <em>Zoopz</em> misses an opportunity here, because it doesn’t offer the ability for kids to share their work, or print it out to show to friends and family. This feature becomes even more important as kids get older. We’ll talk at length about sharing, saving, and storing in Chapter 6, “Kids 6–8: The Big Kids.”</p> <h2>Keep it challenging</h2> <p>The worst insult from a child between the ages of 4 and 5 is to call something “babyish.” They’re part of the big-kid crowd now, and the last thing they want is to feel like they’re using a site or playing a game that’s meant for younger kids. Unfortunately, it’s hard to pin down exactly what “babyish” means, because the definition changes from kid to kid, but in my experience, children call something “babyish” when it’s not difficult or challenging enough for them. Since kids show increased memory function (and more sophisticated motor skills) starting at around age 4, adding multiple steps to games and activities helps keep them on their toes.</p> <p>As designers, we instinctively want to make stuff that users can master immediately. If you’re designing for elementary-school kids, you’ll want to move away from that mindset. While it’s true that children need to be able to easily figure out the objectives of a game or app right away, they don’t necessarily have to do it perfectly the first time. Instead, build in easier layers early on so that kids can complete them quickly, but throw in some extras that might be a little harder for them. For example, if you’re designing a game where kids have to shoot at flying objects, send in a super-fast projectile they have to catch to win extra points or add a harder “bonus round.” Kids will be less likely to call something “babyish” if it takes them several tries to master. And they’ll appreciate the vote of confidence you’re giving to their memory and agility.</p> <h2>Parents are users, too</h2> <p>When adding complexity to your game or app, you’ll still need to make the basic premise simple and clear. A little parental intervention is sometimes necessary, in order to explain rules and demonstrate interactions, but when parents or siblings have to become very involved in game mechanics, it’s frustrating for all parties. </p> <p>Try not to place too much emphasis on “winning” and keep the perceived “rewards” small and unexciting, if you have them at all. Kids tend to ask parents to step in and help with the trickier parts if the reward for winning is really high. While I believe that a parent should be in the room when kids are online and should check on kids frequently when they’re using a device, too much involvement takes away some autonomy from the kids and prevents them from learning as much as they could and should. </p> <h2>Chapter checklist</h2><p> <br /> Here’s a checklist for designing for 4–6-year-olds.</p> <p>Does your design cover the following areas?</p><ul> <li>Feel “social”?</li> <li>Break up instructions and progression into manageable chunks?</li> <li>Provide immediate positive feedback after each small milestone?</li> <li>Allow for invention and self-expression?</li> <li>Include multi-step activities to leverage improved memory function?</li> </ul><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/aaOoiPJBNsQ" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
11. Jul 2014
This week's sponsor: Applause
<p>Applause ensures your web and mobile apps work every time, everywhere, for every user! <a href="http://bit.ly/1oBXFr5">Learn how we can help.</a></p> <p>Applause has a free ebook for our readers that covers:</p> <p>Overcoming Common QA Challenges: Avoid the frequent hang-ups of functionality, design and more<br /> Mobile Web vs. Native Apps: Both mobile, but very different testing challenges<br /> Expanded Testing Coverage: The testing matrix covers OS, device, carrier and more</p> <p><a href="http://bit.ly/1oBXFr5">Grab the free ebook.</a></p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/dc-92g-lKTg" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
21. Jul 2014
Last Call: W3C DOM4
The HTML Working Group has published a Last Call Working Draft of W3C DOM4. DOM defines a platform-neutral model for events and node trees. Comments are welcome through 31 July 2014. Learn more about the HTML Activity.[mehr] (Quelle: W3C News)
21. Jul 2014
Draft Model for Tabular Data and Metadata on the Web, and a Draft Metadata Vocabulary for Tabular Data Published
The CSV on the Web Working Group, part of the Data Activity, has published two Working Drafts today: The Model for Tabular Data and Metadata on the Web outlines a basic data model, or infoset, for tabular data and metadata about that tabular data. The document also contains drafts for various methods of locating metadata; [&#8230;][mehr] (Quelle: W3C News)
17. Jul 2014
Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 Note Published
Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 was published today as a W3C Note by the Web Content Accessibility Guidelines Working Group (WCAG WG) and Evaluation and Repair Tools Working Group (ERT WG), through the joint WCAG 2.0 Evaluation Methodology Task Force (Eval TF). WCAG-EM describes an approach for evaluating how websites, including Web applications [&#8230;][mehr] (Quelle: W3C News)
9. Jul 2014
Longform Content with Craft Matrix
<p>Jason Santa Maria recently shared some thoughts about <a href="https://the-pastry-box-project.net/jason-santa-maria/2014-june-15">pacing content</a>, and my developer brain couldn’t help but think about how I’d go about building the examples he talked about.</p> <p>The one fool-proof way to achieve heavily art-directed layouts like those is to write the HTML by hand. The problem is that content managers are not always developers, and the code can get complex pretty quickly. That’s why we use content management systems—to give content managers easier and more powerful control over content.</p> <p>There’s a constant tension between that type of longform, art-directed content and content management systems, though. It’s tough to wrangle such unique layouts and styles into a standardized CMS that scales over time.</p> <p>For a while, the best we could do was a series of custom fields and a big WYSIWYG editor for the body copy. While great for content entry, WYSIWYG editors lack the control developers need to output the semantic and clean HTML that make the great experiences and beautiful layouts we’re tasked with building.</p> <p>This tension leaves developers like myself looking for different ways to manage content. My attention recently has been focused on <a href="http://buildwithcraft.com">Craft</a>, a new CMS that is just over a year old.</p> <p>Craft’s solution for longform content is the <a href="http://buildwithcraft.com/features/matrix">Matrix field</a>. With Matrix, developers have the flexibility to <a href="http://buildwithcraft.com/docs/matrix-fields#settings">provide custom fields</a> to be used for content entry, and can <a href="http://buildwithcraft.com/docs/matrix-fields#templating">write custom templates</a> (using <a href="http://twig.sensiolabs.org/">Twig</a>, in Craft’s case) to be used to render that content.</p> <p>A Matrix field is made up of blocks, and each block type is made up of fields—anything from text inputs, to rich text, dropdowns, images, tables, and more. Here’s what a typical Matrix setup looks like:</p><figure><img src="http://alistapart.com/d/misc-images/Blog_images/matrix-config.jpg" alt="Configuring a Matrix field"></figure> <p>Instead of fighting with a WYSIWYG editor, content managers <a href="http://buildwithcraft.com/docs/matrix-fields#the-field">choose block types to add to the longform content area</a>, fill out the provided fields, and the content is <a href="http://buildwithcraft.com/docs/matrix-fields#templating">rendered beautifully using the handcrafted HTML</a> written by developers. I use the Matrix field to drive longform content on my own site, and you can see how much flexibility it gives me to create <a href="http://acolangelo.com/blog/unsung-success">interesting layouts</a> filled with images with captions, quotes with citations, and more.</p> <p>To pull back the curtain a bit, here’s how my blog post <a href="http://acolangelo.com/blog/unsung-success">Unsung Success</a> is entered into the Matrix field:</p><figure><img src="http://alistapart.com/d/misc-images/Blog_images/matrix-field.png" alt="Entering Content with the Matrix field"></figure> <p>Three block types are used in the post seen above—an image block, a quote block, and a text block. Notice that the text block is using a WYSIWYG editor for text formatting—they’re still good for some things!</p> <p>The Matrix field is endlessly customizable, and provides the level of flexibility, control, and power that is needed to achieve well-paced, art-directed longform content like the examples Jason shared. This is a huge first step beyond WYSIWYG editors and custom fields, and as we see more beautifully designed longform pieces, our tools will only get better.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/c_Zwgi1tTcY" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
17. Jul 2014
Last Call: Content Security Policy Level 2
The Web Application Security Working Group has published a Last Call Working Draft of Content Security Policy Level 2. This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced. [&#8230;][mehr] (Quelle: W3C News)
3. Jul 2014
Nishant Kothary on the Human Web: In Pursuit of Facebook Happiness
<p>The outrage being directed at Facebook right now centers on its experiment in manipulating the emotions of 689,003 users in 2012.</p> <p>Regardless of where you stand on the issue, there’s no denying the phantasmagorical irony that we’re upset (and sad) about how Facebook affects our emotions thanks to learning about a study where Facebook affected our emotions through someone on Facebook. Maybe that, too, was <a href="http://www.theawl.com/2014/06/this-social-network-changed-how-news-works-but-then-it-made-some-news-of-its-own">to be expected</a>.</p> <p>One of the motivations for Facebook’s controversial study was to debunk the notion that seeing our friends’ happy posts in our news feeds actually makes us sadder. And according to <a href="https://www.facebook.com/akramer/posts/10152987150867796">a post by Adam Kramer</a>, the primary author of the study, it did exactly that, “We found the exact opposite to what was then the conventional wisdom: Seeing a certain kind of emotion (positive) encourages it rather than suppresses it.”</p> <p>But, how profound is this effect on users’ overall enjoyment while they’re using Facebook? That remains unknown, and in my experience, it’s not much at all.</p> <p>We already know that social media has a profound effect on our emotions. I’ve personally struggled with the emotional rollercoaster for years now. My Achilles’ heel used to be Twitter because I used to be a heavy user. I even <a href="http://visitmix.com/writings/dear-twitter">quit the service</a> for a whole year to regain my bearings. And while <a href="http://rainypixels.com/words/life-after-twitter/">the hiatus turned out to be very positive</a>, I didn’t quite get to the bottom of what inevitably turns me off about Twitter. And then, of course, there was Facebook.</p> <p>Facebook affected my mood so dramatically that I’d stopped using it entirely for years until a few months ago. I used to refer to Facebook as, “The place my Instagram pictures go to die.” This was partly in jest, partly serious. My Instagram account is dedicated to my dog, and it’s hard to not notice that a picture or video that can get a few hundred likes, spur over a hundred comments, and bring so much joy to both me and my followers is often met with dead silence or, worse, scorn on Facebook (and honestly, on Twitter as well). There are many reasons for this, several that I covered in one of my prior columns, <a href="http://alistapart.com/column/the-real-real-problem-with-facebook">The REAL Real Problem with Facebook</a>. But there is one above all: Not everyone is interested in pictures of my dog.</p> <p>*Blasphemy!*</p> <p>OK, so this isn’t really news, and it’s hardly blasphemous. It’s understandable that people wouldn’t want to see images of someone else’s dog every day. But then why the disparity between how enthusiastically my content is received on Instagram as opposed to Facebook (or even Twitter)? Therein lies the key to the puzzle.</p> <p>It’s really quite simple: people follow me on Instagram specifically for pictures of my Weimaraner (yes, it’s a <a href="http://www.johnnywander.com/files/comics/254.jpg">notoriously difficult to pronounce</a> dog breed).</p> <p>I never intended on turning my Instagram account into a dog account. It just happened. And in the process I met loads of Weimaraner (and dog) people from around the world (some whom, true story, I’ve subsequently met in real life). I now honor an informal contract to only post pictures of my dog. And what happens when I break that contract and post the occasional picture of something else? I’m rewarded with crickets in terms of engagement.</p> <p>What escaped me back when I quit Twitter or when I silently shunned Facebook was that the negativity or the positivity of the posts wasn’t even relevant to the compounding effect of the social network on my emotional well being. What was more to blame was the lack of engagement; the lack of feeling a connection. As much as we do in all life, online we want to meet, engage, and be engaged by others who share our passions and interests. And when that doesn’t happen, well, it can be a bummer.</p> <p>Over the past few months I’ve joined numerous groups related to my interests on Facebook (yes, including a Weimaraner group). The result is that my Facebook news feed is now flooded with content I enjoy far more. I’ve essentially hacked my Facebook world to feel a lot more like my Instagram world—more focused on my interests and pastimes. Sharing and talking with folks who care about the same things has made Facebooking infinitely more enjoyable. In an unexpected way, I think it has also helped me understand the mid-conversation exclamations I receive from some people about how much they love Pinterest.</p> <p>One would think that Pinterest would be the ideal social network for most of us, especially me. After all, on Pinterest you can follow someone’s Weimaraner board, and dodge all their gardening, baby, culinary, and political content. What’s not to like? Well, clearly something, because like loads of people, I’ve never quite gotten into Pinterest. I have some theories why that’s the case, but my disinterest is beside the point. What seems clear to me is that Pinterest is really onto something. We need a social network that acknowledges that we all have facets, and that it’s OK for us to pick and choose each other based on our interests. In my experience, the amount of happiness you feel on a social network seems to relate more closely to how much the content caters to your interests.</p> <p>So, if you&#8217;re looking to maximize your happiness on social networks, here&#8217;s the short-term solution: fill your account with content that&#8217;s interesting to you. Like or follow your favorite sports teams, TV shows, clubs, non-profits, news organizations, web design magazines, and anything else you&#8217;re into. In other words, make your feeds about things you genuinely like, happy or sad, instead of about your real-world social obligations.</p> <p>And that may also mean muting or unfollowing the people filling your feed with posts about their gardens, babies, food, or politics.</p> <p>Or, god forbid, their dogs.</p> <figure> <img src="http://d.alistapart.com/Column-Nishant/yoshi_happy.jpeg"> </figure><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/aLblbir20A4" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
15. Jul 2014
CSV on the Web: Use Cases and Requirements Draft Published
The CSV on the Web Working Group has published a Working Draft of CSV on the Web: Use Cases and Requirements. A large percentage of the data published on the Web is tabular data, commonly published as comma separated values (CSV) files. The CSV on the Web Working Group aim to specify technologies that provide [&#8230;][mehr] (Quelle: W3C News)
1. Jul 2014
Structuring a New Collaborative Culture
<p>When I was a junior designer, my creative director asked me to design a mascot with the rather uninspiring instruction to reorder the shapes of the famous 2012 Olympics logo. Having little choice but to accept my task, I threw myself into it with all the boundless, panicked energy that comes from needing to impress the powers above, trusting my superior to steer me in the right direction. </p> <p>Three weeks later I was distraught, the entire weight of our complete and utter failure to win the pitch resting on my shoulders. </p> <p>It would be easy to put that loss down to inexperience—after all, I totally missed the brief, and every other pitch was better. But when I think about it a little more thoroughly, I can see that the real problem was one of access. I longed to understand the full project details, but was instead privy to mere bits and pieces of projects, attempting to cobble together an unknown whole. It was like trying to put together a jigsaw puzzle whilst looking at it through a keyhole.</p> <p>Many organizations—faced with the challenge of bringing together multiple projects, departments, and skillsets—fall back on the traditional combination of hierarchy, method, and structure. This can breed a culture of complacency, leading to outcomes that are narrow in their vision, team members who feel restricted and undervalued, and a workforce that operates under ceaseless pressure to either get it right, or get out.</p> <p>When I look back on my ill-fated Olympic experience, I can see that I didn’t have the full picture. I was unable to bring my own ideas to the table, powerless to create change. I was subordinate; my relationship with my superiors was distant, and the most integral aspects of the design process—research, exploration, and discussion—were entirely absent. It wasn’t collaboration of any kind. No wonder that I lost both the pitch and the plot! </p> <p>It doesn’t have to be that way. When I co-founded the creative studio <a href="http://www.gravita.co/">Gravita</a>, I learned what collaboration really looks like: multiple minds working together to solve problems. By doing this, our complementary skillsets are free to blend together in surprising ways—unconstrained, we’re better equipped to deliver inventive solutions.</p> <p>This kind of collaborative culture is possible, whether you’re freelancing, in an agency environment, or in-house. You only need to do three things:</p><ol> <li>Remove assumptions</li> <li>Emphasize project roles over job titles</li> <li>Create a supportive environment for new ideas</li> </ol> <p>Here’s how we’ve accomplished each one at Gravita. </p> <h2>Assumption: the cyanide of collaboration</h2> <p>When I first established Gravita with two other designers, we found that there was real synergy between us. The feedback was exceptional. We had stumbled across a dynamic that worked, even in our earliest projects. </p> <p>However, the path to uninhibited working was far from smooth, because I started making assumptions about my value to the team. I weighed my own skills against theirs and—deciding that I came up short—assumed my ideas weren’t as good. Agency life had drilled into me that my contributions weren’t worthwhile. </p> <p>My insecurities created walls. I became terrified of showing my work, afraid of failure. I found any excuse not to contribute. This created frustration and tension in our working space, and hindered progress on my first project.</p> <p>The only way out of this debilitating dead-end was to lay out my insecurities and discuss them. Once I was brave enough to open up to my colleagues about how I was feeling, and accept a gradual process of support and positive feedback, we were able to move forward. </p> <p>On our next project, we began by talking openly about how we all felt. I was amazed to discover that I was not alone in feeling apprehensive; having everyone’s cards on the table was cathartic. We sat together as a team and worked out what we could each bring to the task, what we were afraid of, and how we could work together to get around potential problems. </p> <p>Collaboration offers a vehicle through which assumptions of the self can be overridden. Don’t bottle up what you’re feeling, and don’t be afraid to ask questions you assume others will find stupid. Voicing the concerns you have about yourself opens up an ongoing dialogue—one that can identify your strengths, encourage praise, and allow your confidence to blossom.</p> <h2>Prioritizing roles over jobs</h2> <p>Job titles can be useful, but they’re also confining. They can stifle entire projects and hold back personal development. They’re labels, and just like on a can of soup, they create a clear expectation of what is inside—if anything else emerges, it comes as a nasty surprise. </p> <p>I had the first inkling it didn’t have to be this way when I was working for a large charity, stuck with the title “web master.” The management noticed how confining this was for me; they gave me the green light to take on new responsibilities that allowed me to branch out. I realized it was perfectly feasible for organizations to adopt this kind of open, flexible thinking. </p> <p>I&#8217;ve found this way of thinking works at Gravita too. We recognize that it’s the role, not the label, which should be the focus of the work. We don’t have job titles at all, opting instead to rotate roles. We sit down over a cup of coffee and see who fancies doing what on a new project, whether that be project manager, information architect, iconographer, or anything else. </p> <p>Removing permanent titles is liberating. Suddenly, like a long-distance runner, you’re only ever really competing with yourself. It becomes more about self-improvement, less about climbing the ladder. You’re free to bring whatever you want to the table, and to grow as a designer. </p> <h2>Chance favors the connected mind</h2> <p>Ideas should always be heard, regardless of what form they’re in or how complete they are. Instincts and hunches—proto-ideas, neurons sparking with other neurons—need a free environment where they can mingle, collide, and flourish, ultimately producing something greater than the sum of their parts. After all, as Steven Johnson explains in his talk, “<a href="https://www.youtube.com/watch?v=NugRZGDbPFU#t=13">Where Good Ideas Come From</a>,” “chance favors the connected mind”—connectivity and flow between people create stronger ideas.</p> <p>It can be challenging to <a href="/article/getting-to-flow">achieve flow</a>, but it’s very worthwhile. Mihaly Csikszentmihalyi defines flow as “the internal state of energised focus which characterises the mind at its most productive.” We look past the separate spaces that we inhabit as individual bodies and come together as minds. It’s a form of intense, unified working where people relax from their inhibitions and see themselves as being fundamentally interconnected on a project. </p> <p>Recently we were evaluating concept designs for a healthcare project. It just wasn’t quite working, and individually none of us had figured out what was wrong with it. Together, we began passing ideas back and forth, until someone uttered the words “less cold.” Suddenly we could see what we needed: a new and more gentle typeface, a softer and more comfortable palette. It took all of us, working together in a connected way, to hit on the solution. </p> <p>Flowing mind-to-mind in this way allows us to fuel an idea in a shared headspace. Collaborative thinking enhances the brain’s natural capacity to make new links, which in turn strengthen the initial idea. There’s no place for ego—it’s important to be open and welcome this flow of others’ thoughts.</p> <h2>A new way of thinking</h2> <p>Collaboration means bringing different minds and skillsets together in a way that doesn’t make assumptions about what someone is or isn’t good at. It means dispensing with limiting roles, and introducing a fluidity of thought and activity into the design team. Above all, it means putting interconnectedness at the heart of every action.</p> <p>So is collaborative working the elusive Holy Grail? Certainly a lot of people aim for it, and like to think that they do it even if there is a wide variance in form. What I do know is that by changing the way I think, I’ve helped bring about a safe, assumption-free space with an even distribution of authority that allows ideas to flow freely. </p> <p>Collaborative culture helps us discover unique solutions—and continuously redefine ourselves. Designing for the online community means operating in an ever-changing environment, where adaptability is key for keeping up with new technology and scenarios.</p> <p>A collaborative culture can push us into spaces more conventional practices fear to tread. Everything is open to question. Ideas are heard. People feel empowered to make real change. </p> <p>Finally, I feel like I’m seeing the full picture.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/QmPNCpU5MIo" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
1. Jul 2014
Persuasion: Applying the Elaboration Likelihood Model to Design
<p>Persuasion is part of every aspect of our lives. Politicians want our vote, businesses want us to buy their products, and people want us to like them. Even altruistic nonprofits want us to change our behaviors around environmental issues and public safety, or give them our money to help fight hunger and disease (the nerve!). </p> <p>This reality is no different for websites and other digital properties. Persuasion is a necessary component of good design, ensuring that users will engage with your product in the way you intended, leading to the outcome you intended. </p> <p>Understanding persuasion will highlight the importance of developing strong messages, help you better incorporate and refine effective persuasive techniques into your design, and allow you to explain to others (potential clients, peers) how and why your design is effective at persuading users.</p> <h2>The really nice elephant in the room</h2> <p>Persuasion has a bad reputation—the word itself often evokes thoughts of being swindled or pressured to do something we really don’t want to do. But persuasion isn’t inherently negative—it’s just a process of influence, for better or worse. With some help from Richard Perloff’s <cite><a href="http://books.google.com/books/about/The_Dynamics_of_Persuasion.html?id=pytBF-QVw6wC">The Dynamics of Persuasion</a></cite>, here are five ways of understanding persuasion:</p><ul> <li><b>Persuasion is communication.</b> At its core, persuasion needs a strong, clear message sent from one party to another. </li> <li><b>Persuasion is an attempt to influence.</b> Understanding your audience and what makes them tick makes your attempt more likely to succeed—though the outcome is never guaranteed.</li> <li><b>Persuasion involves more than words.</b> Aesthetics, interactions, ease of use, and other factors can make a website or application more persuasive to potential users.</li> <li><b>Persuasion is not coercion.</b> It is up to individuals to form or change their own attitudes. Utilizing dark patterns or purposely tricking a user into doing something they wouldn’t otherwise do is not persuasion. It’s being an asshole.</li> <li><b>Persuasion can reinforce attitudes.</b> Your audience has opinions that need to be strengthened from time to time. If you don’t preach to the choir, someone else will, and eventually your faithful followers will be led astray.</li> </ul> <p>Academics have attempted to explain how persuasion works on individuals for decades. The Elaboration Likelihood Model (<a href="http://link.springer.com/chapter/10.1007/978-1-4612-4964-1_1#page-1">Petty and Cacioppo, 1986</a>), one of the most frequently cited models of persuasion, explains how shaping attitudes also shapes behaviors. Incorporating the principles of the Elaboration Likelihood Model into your messages and design will maximize your influence on user attitudes and, therefore, behaviors. That, my friend, is what persuasion is all about.</p> <h2>The Elaboration Likelihood Model</h2> <p>The Elaboration Likelihood Model attempts to explain how attitudes are shaped, formed, and reinforced by persuasive arguments. The basic idea is that when someone is presented with information, some level of “elaboration” occurs. Elaboration, in this context, means the effort someone makes to evaluate, remember, and accept (or reject) a message.</p> <p>The model suggests that people express either high or low elaboration (that is, their level of effort) when they encounter a persuasive message. The level of elaboration then determines which processing route the message takes: central or peripheral.</p><figure><table> <tr> <th>&nbsp;</th> <th>Central route processing</th> <th>Peripheral route processing</th> </tr> <tr> <td style="font-weight: bold;">Elaboration</td> <td>High</td> <td>Low</td> </tr> <tr> <td style="font-weight: bold;">Information processing</td> <td>Contents of message are closely examined by the receiver</td> <td>Receiver is influenced by factors other than the contents of the message</td> </tr> <tr> <td style="font-weight: bold;">Attitude</td> <td>Will change or be reinforced based on message characteristics such as strength of argument and relevancy</td> <td>Might change or be reinforced based on the effectiveness of factors other than the message</td> </tr> <tr> <td style="font-weight: bold;">Strength of attitude formed/reinforced</td> <td>More enduring and less subject to counterarguments</td> <td>Less enduring and subject to change through future persuasive messages</td> </tr></table> <figcaption>Table 1: Comparison of central route processing and peripheral route processing.</figcaption> </figure> <p><em>Central route processing</em> means your audience cares more about the message. They’ll pay more attention and scrutinize the quality and strength of the argument. Any attitudes formed or reinforced this way are thought to be more enduring and resistant to counter-arguments. </p> <p><em>Peripheral route processing</em> happens on a more superficial level. Your audience will pay less attention to the message itself while being influenced by secondary factors, such as source credibility, visual appeal, presentation, and enticements like food, sex, and humor. Attitudes formed or reinforced this way are thought to be less enduring, subject to change through counter-arguments, and in need of continual reinforcement.</p> <p>To illustrate the difference between central and peripheral route processing—and how messaging and design can be used to simultaneously address each route—let’s look at the behemoth that is online retailer Amazon.com. </p> <h2>A tale of two paths</h2> <p>Imagine two potential customers, both in need of a new television. Suzanne is a technophile and regular Amazon user, while Kevin rarely makes purchases online, and is mostly interested in finding a quality television at a good price. Amazon wants to persuade both users to purchase a television (any television) through its website.</p> <h3>Central route processing</h3><p> </p> <p>While both users will have some level of central route processing (especially for pricing), it is more likely that Suzanne, with her interest in technology, will be attentive to the messages and design. Assuming she agrees with what she sees, she’ll be more inclined to purchase through Amazon versus a less persuasive competitor. </p> <p>For Amazon, this is critical; its competitors include stores where potential customers can interact face to face with knowledgeable sales reps. So it has to make product information easy for users to access by including multiple options for searching and sorting, offering detailed product descriptions, and providing in-depth product reviews written by fellow shoppers. </p> <figure> <img src="http://d.alistapart.com/397/figure1.png" alt="Image of Amazon search results"> <figcaption>Amazon search results can be sorted and filtered by numerous variables.</figcaption></figure> <p>Suzanne searches for high-end TVs, filters them from high to low ratings, and reads the reviews. After making her decision, she uses the “Buy now with 1-Click” option, since all of her information is already up to date in Amazon’s system; Amazon’s reliability and service over the years has earned her trust. </p> <p>Suzanne was not a hard sell for Amazon; this is due in part to years of persuasive factors that have shaped her buying habits. If central route processing has occurred in a positive direction, Suzanne is also likely to purchase from Amazon again in the future, while Amazon’s competitors will have a harder time persuading her to purchase from them.</p> <h3>Peripheral route processing</h3><p> Amazon does not leave the casual user hanging when it comes to persuasive design. Many elements of its design are meant to appeal to peripheral route processing. </p> <p>First, look at its use of visual hierarchy. The product page’s focal point, a nice large photo of the product itself, is perfect for holding attention—no reading necessary to see that gem. It also offer options to view the product from multiple angles. The numerous filtering options allow potential customers to choose from a broad range of categories that can serve as a shortcut to selecting a product they have little interest in researching in-depth (e.g. price, rating, age of product). </p> <figure> <img src="http://d.alistapart.com/397/figure2.png" alt="Screenshot of Amazon product page, showing product details"> <figcaption>Amazon provides a detailed product description, highlights potential savings, and makes adding to the cart obvious and simple.</figcaption></figure> <p>Let’s say that Kevin, our less motivated potential customer, is curious to see how much TV he can get for his money. After searching for televisions in the impossible-to-miss search bar on the homepage, he immediately sorts the results by price from low to high. Next, using the filters offered on the left of the screen, he selects to view only TVs with four stars or more. (Why spend time reading a review when you can see four shiny stars at a glance?)</p> <p>Kevin notices the percentage saved and the low-price guarantee that comes with his purchase. Additionally, free shipping is offered in bold type directly next to the price. Appealing to a user’s pocketbook is an excellent form of peripheral route persuasion. This penny-pincher won’t even have to pay for the convenience of having the product shipped to his front door. </p> <p>Utilizing visual hierarchy at its finest, the second most eye-catching element of this page is the blatantly obvious “Add to Cart” button. You can guess how the scenario unfolds from here.</p> <p>Notice that both routes lead to the same outcome—and that design elements are not exclusive to one route or the other. People often process information using some level of both routes—the routes can complement each other. For example, Suzanne would be more likely to process the information in the product description through the central route, but utilize the star-rating filter as a peripheral route shortcut to viewing TVs highly rated by likeminded shoppers. She was persuaded by elements from both routes. High-five to Amazon! </p> <p>Suzanne is more likely to maintain her positive attitude towards making purchases on Amazon.com, thanks to central route processing, whereas Kevin will need some convincing in the future not to go check out the big box store down the street (the free shipping should help!).</p> <p>Persuasion goes hand-in-hand with messaging and design, but there are also ways to do it wrong: distractions can undermine your persuasive techniques just as quickly as you can develop them. If your potential user encounters nine pop-ups, long loading time, or three pages of disclaimers to get to the meat of your message, they are never going to choose to taste it. Distractions, whether physical, visual, or intangible, can temporarily halt the whole elaboration process.</p> <h2>Could you please elaborate on that?</h2> <p>What promotes central route processing and high elaboration? Researchers have explored two main factors: motivation and ability.</p> <p><em>Motivation</em> is often influenced by the relevance of a topic to an individual. A user who feels directly impacted by a topic is more likely to process a message through the central route. This explains why Facebook asks why a user blocked an ad; not everyone finds a free trial of Viagra compelling, but eventually Facebook intends to crack the code on what each user finds relevant. You can account for this in your own work with a strong message that shows your users why your product is relevant to their lives.</p> <p><em>Ability</em> is exactly what you think it is. For central route processing to occur, your message must be in line with the thinking abilities of your audience. If an individual does not have the mental ability to process your message, they will not be able to critically evaluate it, and are guaranteed to process it through the peripheral route. Yes, if you want to effectively persuade someone, your message actually has to be conveyed in a way they understand. Shocking.</p> <p>In other words: if you want users to actually pay attention to your message, make it directly relevant and easy to understand.</p> <h2>What does this mean for working on the web?</h2> <p>How can you put the Elaboration Likelihood Model and other tenets of persuasion into practice? First, you need to account for the following elements to effectively persuade your users:</p><ul> <li><b>Message:</b> what’s being said, marketing efforts, content, and copy</li> <li><b>Design:</b> visual hierarchy, navigation, and layout</li> <li><b>Delivery:</b> load time, user experience, rewards, and bells and whistles</li> </ul> <p>This all seems simple enough—provided you know a lot about your target audience and what motivates them. This is where it is best to sit down with a professional user researcher and develop a list of questions about what your audience values; what their fears, hopes, and dreams are; and what existing challenges you face in persuading them. A researcher can also conduct a brief review of past research on persuasion in your field, which will help back your current efforts.</p> <p>Then, take a closer look at your work. A lot of what we have discussed can be boiled down to clarity and simplicity:</p><ul> <li>Is your message clear?</li> <li>Are you telling people exactly why your product/website is relevant to their lives (or could be) in an easily understood way? </li> <li>Are you guiding people to the actions you want them to take? Does your design facilitate this?</li> <li>Does your design incorporate elements of persuasion that will help potential users become users?</li> </ul> <p>Asking these questions of your work will help you be laser-sharp when it comes to persuading your users.</p> <h2>Have I been persuasive?</h2> <p>For some of your users, you may only need to provide a convincing message—that is, one that shows the relevancy of your work to their life and helps shape or reinforce a positive attitude. However, many will probably process your message through low levels of elaboration. They will need clear content, good design, and efficient delivery to bolster their receptiveness to your message or product. </p> <p>Being persuasive requires a conscious effort. Conducting user research, incorporating the tenets of good design, and understanding how persuasion works will help you appeal to more users through both central and peripheral processing routes. </p> <p>Designing for both paths of the Elaboration Likelihood Model isn’t just good in theory; it’s good in practice. This purposeful incorporation of persuasion will bring a new level of effectiveness to your craft, eventually enabling you to move your audience to process your messages through the central route—the sign of a truly persuasive design.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/5WJ8ZbguJcw" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
27. Jun 2014
Ten Years Ago in ALA: Dynamic Text Replacement
<p>Ten years ago this month, <cite>A List Apart</cite> published Stewart Rosenberger’s “<a href="http://alistapart.com/article/dynatext">Dynamic Text Replacement</a>.” Stewart lamented text styling as a “dull headache of web design” with “only a handful of fonts that are universally available, and sophisticated graphical effects are next to impossible using only standard CSS and HTML.” To help ease these pains, Stewart presented a technique for styling typography by dynamically replacing text with an image.</p> <p>I began working on the web five years after Stewart’s article was published, right around the time when <a href="http://alistapart.com/article/on-web-typography">web fonts were gaining popularity</a>. It was an exciting time, with a slew of new typefaces, foundries, and new techniques for styling text with CSS3 cropping up frequently. It seemed—for a moment—that we could finally “control” typography in a way that we never could before.</p> <p>I was recently looking at the <a href="http://www.jordanm.co.uk/tinytype">state of default system fonts</a> and realized that we’re never going to have as much control over typography as we want. But that&#8217;s ok. </p> <p>Instead, I’ve been seeing more nuanced discussions about typography, focused on striking a balance between having beautiful typography without taking a huge <a href="http://css-tricks.com/preventing-the-performance-hit-from-custom-fonts/">performance hit</a>. I appreciate that as an industry we’re <a href="http://www.thenerdary.net/post/75826597863/disabling-typekit-on-mobile">dedicated to creating the best experiences possible</a>, regardless of device or connection speed.</p> <p><a href="http://blog.typekit.com/2013/10/09/on-weights-styles/">It’s easy to get carried away with web fonts</a>, and slow our sites down significantly as a result. While we may no longer need to use dynamic image replacement, the deliberate approach Stewart advocated is worth revisiting:</p><figure class="quote"><blockquote>“Sticking with the traditional typefaces is smart for body text, but when it comes to our headings—short, attention-grabbing blocks of text—it would be nice to have some choice in the matter.”</blockquote></figure> <p>In another five years, we’ll have completely different techniques and a host of other considerations. If we are thoughtful and deliberate with our (type) decisions, we’ll be able to evolve much more easily.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/7ET9C97PR1I" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
26. Jun 2014
Ask Dr. Web with Jeffrey Zeldman: The Doctor Is In
<p><i>A note from the editors:</i> Way back in the early days of web design—back before, even, <cite>A List Apart</cite>—there was <a href="http://www.zeldman.com">Zeldman.com</a>, where thousands of us spent hour after hour soaking up every bit of web design knowledge we could. Between 1995 and 1999, Jeffrey Zeldman himself even answered your questions—or at least, his alter ego Dr. Web did.</p> <p>The days where one column can cover “Everything You Ever Wanted To Know About HTML, CSS, Graphics, &amp; Multimedia” are long gone (except on the <a href="https://web.archive.org/web/19970711171732/http://www.zeldman.com/maqf.html">Internet Archive</a>), but Dr. Web is back. This time, our fearless leader is here to help you find your place and build a satisfying career in this big, weird, changing industry we call the web.</p> <p>Read on for Dr. Web’s advice, and don&#8217;t forget to <a href="#submit">submit a question</a> of your own.&nbsp; </p> <figure> <img src="/d/misc-images/Ask_Dr_Web.gif" alt="An Ask Dr. Web logo from the 1990s"> </figure> <figure class="quote"> <blockquote> <p>Dear Dr. Web,</p><p>I’m a print designer trying to transition into the web world, but the resources out there seem to be endless. It’s overwhelming trying to figure out where to start. Do you have any suggestions for what to read, who to listen to, or how to otherwise take careful sips from the firehose?</p> </blockquote><figcaption><cite>Just Getting Started</cite></figcaption> </figure> <p>Dear Just,</p> <p>Funny you should ask. Four score and 13 years ago, I wrote a book for designers transitioning to the web. That book is now available free of charge, and while some of the sites it references are no longer with us, and more than a few of its browser references and front-end techniques are amusingly dated, the basic premises are as true today as they were in 2001. Enjoy <cite><a href="http://takingyourtalenttotheweb.com">Taking Your Talent To The Web</a></cite>, Dale Cruse’s HTML rendition of the book, or download the <a href="http://www.zeldman.com/2009/04/16/taking-your-talent-to-the-web-is-now-a-free-downloadable-book-from-zeldmancom/">PDF version</a>, containing the original layout, typography, and artwork. (Thanks to <a href="http://www.peachpit.com/imprint/?st=61074">New Riders</a>, my original publishers, for believing in the book, and for allowing me to give it away online after its best-used-by date expired.)</p> <p>If you are willing to learn HTML and CSS—and, at least until <a href="http://macaw.co/">Macaw</a> is in its 5.0 version, every web designer should learn those things, at least well enough to understand the principles behind them—read <cite><a href="http://www.amazon.com/Designing-Web-Standards-3rd-Edition/dp/0321616952">Designing With Web Standards</a></cite> followed by <cite><a href="http://www.simplebits.com/publications/bulletproof/">Bulletproof Web Design</a></cite> and <cite><a href="http://www.abookapart.com/products/html5-for-web-designers">HTML5 for Web Designers</a></cite>. </p> <p>Then dive into Aaron Gustafson’s modern classic, <cite><a href="http://easy-readers.net/books/adaptive-web-design/">Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement</a></cite>. Though compact and approachable, it is jam-packed with the collective wisdom of literally thousands of modern web designers, developers, and consultants, all filtered through Aaron’s expertise, practicality, and friendly style. Nobody has ever done a better job of explaining progressive enhancement and why it is the basis of universal web design. </p> <p>Of course, web designers do not live by code alone. So next, or simultaneously, I recommend getting your mitts on Steve Krug’s classic, <cite><a href="http://www.sensible.com/dmmt.html">Don’t Make Me Think</a></cite>, which is the quickest and friendliest way I know for a print designer to grasp all those things about usability and interaction design that you’d never, ever pick up in a traditional graphic design curriculum or career. In print for 13 years, it&#8217;s been translated into 20 languages and sold over 400,000 copies—and now it&#8217;s available in a fully revised edition.</p> <p>As a print designer, you’re familiar with type—and on the web, interfaces consisting almost entirely of type are used to present content consisting almost entirely of type. Bone up on what type means for the screen with Ellen Lupton’s newly released <cite><a href="http://www.papress.com/html/book.details.page.tpl?isbn=9781616891701">Type on Screen</a></cite>, and Jason Santa Maria’s upcoming <cite><a href="http://www.abookapart.com/products/on-web-typography">On Web Typography</a></cite>.</p> <p>While you’re reading these books, you should also be visiting websites, viewing source, selecting all, and copying into a text editor. The more you study other people’s HTML markup and CSS, the better you will begin to understand how to structure web content so people and search engines can find it, and browsers and devices can display it. Short of working as part of a front-end development team with experienced colleagues, viewing source is the best front-end web development education you can have. (“Front-end” is what we call it to distinguish from the heavier kinds of coding that go into the “back-end” of most sites today.)</p> <p>Of course, it helps if the sites whose source code you’re viewing are well-made. Besides viewing source on <cite>A List Apart</cite> (cough), you’ll find fine source code on Chris Coyier’s <a href="http://css-tricks.com">CSS Tricks</a>. (You&#8217;ll also learn a <em>lot</em> about CSS, the visual language of web design.) You’ll learn loads more about CSS, and get more great source code to boot, in the articles section of <a href="http://sarasoueidan.com">Sara Soueidan’s</a> website. </p> <p>Other great resources—for education, inspiration, great source code, and just plain good reading—include:</p> <ul> <li><a href="http://jasonsantamaria.com">Jason Santa Maria</a>: design inspiration and strategy; dual-focused on print and web</li> <li><a href="http://www.lukew.com/ff/">LukeW: Writings on Digital Product Strategy</a>: keep up with mobile web design stats and strategy</li> <li><a href="http://maban.co.uk">Anna Debenham</a>: freelance front-end developer and <cite>ALA</cite> tech editor</li> <li><a href="https://the-pastry-box-project.net">The Pastry Box Project</a>: writings by your web design peers</li> <li><a href="http://cognition.happycog.com">Cognition</a>: more writings by your web design peers</li> <li><a href="http://frankchimero.com/intros/quilt/">Frank Chimero</a>: design inspiration</li> <li><a href="http://farukat.es">Faruk Ateş</a>: for a more inclusive web</li> <li><a href="http://airbagindustries.com">Airbag Industries</a>: the personal site of Greg Storey</li> <li><a href="http://meyerweb.com">Meyerweb</a>: the personal site of CSS expert Eric Meyer</li> <li><a href="http://jakearchibald.com">Jake Archibald</a>: tech-savvy writings on web performance</li> </ul> <p>This is barely a distracted start; readers, <i>please</i> list your favorite sites in the comments section.</p> <p>Don&#8217;t study or work in isolation. If you&#8217;re freelancing or working remotely, Twitter can be your best friend (or can help you find your new best friends). After a week of working at home, make time for a meetup in your hometown, and if your city offers free or inexpensive design, development, or user experience (UX) events, take advantage of those offerings and get out there. This is a warm community full of passionate practitioners who love to share tips and make connections.</p> <p>Lastly and perhaps most importantly, take the time to become deeply familiar with a few websites that you love and use all the time. Analyze what design decisions and special touches (whether of interactivity, or visual hierarchy, or copy, or whatever) make the experience of using the site so special. Likewise, when you encounter an unpleasant-to-use site (online banking, anyone?), instead of fleeing in frustration, force yourself to spend <em>extra</em> time on that site, to discover which particular interaction design decisions are responsible for your bad experience. And then never, ever make decisions like that on the sites <em>you</em> design.</p> <p>Design on the web is a combination of aesthetics and usability, control and surrender, constraint and endless creativity. Designing books is wonderful, but designing for the web is a whole ’nother thing. Welcome, friend!</p> <p><a name="submit"></a><em>Have a question about professional development, industry culture, or the state of the web? This is your chance to pick Jeffrey Zeldman’s brain. Send your question to Dr. Web via <a href="https://twitter.com/alistapart">Twitter</a> (#askdrweb), <a href="https://www.facebook.com/alistapart?ref_type=bookmark">Facebook</a>, or <a href="mailto:contact@alistapart.com?subject=Ask Dr. Web">email</a>.</em></p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/2qjsXslHTyQ" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
15. Jul 2014
Using WAI-ARIA in HTML Draft Published
The HTML Working Group has published an updated Working Draft of Using WAI-ARIA in HTML. Using WAI-ARIA in HTML is a practical guide for developers on how to to add accessibility information to HTML elements using the Accessible Rich Internet Applications (WAI-ARIA) specification, which defines a way to make Web content and Web applications more [&#8230;][mehr] (Quelle: W3C News)
10. Jul 2014
Last Call: Geometry Interfaces Module Level 1
The CSS Working Group and the SVG Working Group have published a Last Call Working Draft of Geometry Interfaces Module Level 1. This specification provides basic geometric interfaces to represent points, rectangles, quadrilaterals and transformation matrices that can be used by other modules or specifications. CSS is a language for describing the rendering of structured [&#8230;][mehr] (Quelle: W3C News)
10. Jul 2014
First Public Working Draft of IndieUI: User Context for web interface preferences
The IndieUI Working Group today published a First Public Working Draft of IndieUI: User Context 1.0 – Contextual Information for User Interface Independence. It defines a set of preferences that users can choose to expose to web applications, and an API for user agents to access the preferences and listen for changes. Users can set [&#8230;][mehr] (Quelle: W3C News)
10. Jul 2014
Linked Data Platform 1.0 Primer Draft Published
The Linked Data Platform (LDP) Working Group has published a Working Draft of Linked Data Platform 1.0 Primer. This primer provides an introduction to the Linked Data Platform (LDP), with examples illustrating the principal concepts such as the notion of an LDP resource and the LDP container and how they can be used by Web [&#8230;][mehr] (Quelle: W3C News)
1. Jul 2014
Last Call: Beacon, Resource Timing Candidate Recommendation Updated
The Web Performance Working Group has published a Last Call Working Draft of Beacon. This specification defines an interoperable means for site developers to asynchronously transfer small HTTP data from the User Agent to a web server. Comments are welcome through 29 July 2014. The group also updated the Candidate Recommendation of Resource Timing. This [&#8230;][mehr] (Quelle: W3C News)
1. Jul 2014
RDF 1.1 Primer Note Published
The RDF Working Group has published a Group Note of RDF 1.1 Primer. This primer is designed to provide the reader with the basic knowledge required to effectively use RDF. It introduces the basic concepts of RDF and shows concrete examples of the use of RDF. Learn more about the Data Activity.[mehr] (Quelle: W3C News)
20. Jun 2014
Rachel Andrew on the Business of Web Dev: Lessons Learned by Being the Client
<p>I ran a web development consultancy from mid-2001 through to early 2013. By 2006, the company I had started alone was busy enough for my husband, Drew McLellan, to join the business full time. The vast majority of our work was as an outsourced team, developing projects for design agencies. But now, in 2014, we find ourselves on the other side of the client/developer relationship.</p> <p>We launched our first product, <a href="http://grabaperch.com">Perch</a>, as a side project of that business. It’s now the whole of what we do, yet we have managed to remain a team of two by making use of freelancers and other agencies. At first we only outsourced design, but increasingly we are also using outside help for development.</p> <p>Here are some of the things I have learned by being the client.</p> <h2>Give regular progress updates</h2> <p>I always felt we were good at communicating with our clients. We asked questions and updated the staging version of the project regularly. And so, when clients would ask for an update, I would feel irritated and pestered. We felt as if we were constantly communicating with them and we were rarely late delivering something, so I assumed that the client would understand that if we didn’t mention there was a problem, everything was running on time.</p> <p>As the client, I now know that even if I can see code being committed and the developer is talking to us, I don’t always get a sense of whether they are on track or not. I&#8217;ve seen how other business milestones may depend on the completion of an outsourced project. For example, you might buy advertising to go live at the same time that a planned feature launches. If the ad buy has to be booked in advance, but the project runs late, that advertising spend will have been wasted. Due to the stress of the unknown and fear of losing out financially, it is easy to end up being that client who seems to be constantly asking if the work is completed.</p> <p>Of course when you are providing a service it is important that you do what you say you will do, in the time you said it could be done in. However, in addition to that basic requirement, building in regular status updates helps your client to plan things that rely on the work you are doing to be completed. It stops the constant is-it-done-yet? type emails and phone calls.</p> <h2>Explain what to review</h2> <p>We often used to grumble that clients never looked over or tested any of the work we had done, although we deployed work to staging servers and made it available for review as often as possible. Looking back, I think we made an assumption that not only would the client have the time to immediately look at everything we had deployed, but would understand for themselves the progress.</p> <p>We’re working with a developer currently who uses <a href="http://www.trello.com">Trello</a> not just to organize tasks but as a way for us, his client, to see what he is working on and where he is at. I can take a look at Trello at any point and see that a certain feature is being worked on, or has been moved to done. I can then go take a look on the staging version and I know what I’m looking for.</p> <p>Even if your client is able to see your commits or updates to a system, give them a way to know which bits they should be looking at at any one time. This will save your client wasting their time pointing out things that you haven’t addressed yet, and also help them feel part of your progress.</p> <p>In addition to gaining a new insight into what really makes for great client and developer communication, I’ve discovered other ways in which freelancers can really contribute to the businesses they do work for.</p> <h2>Make costs foreseeable</h2> <p>As a business owner with a product, there are many things that I would love to find help with. But hiring a consultant at an hourly rate when I don’t fully understand the scope of the task at hand is a bit scary. What if it costs far more than I imagined, or what if what I really need is ongoing support?</p> <p>If you can make your consultancy services more product-like in terms of how you market them, you can make life a lot simpler for business owners who aren’t sure what work needs doing and whether it is in their budget. This approach has been termed “productized consulting” and involves packaging up services that typically would be completed on an hourly rate into fixed-price—one-off or monthly—purchases.</p> <p>For examples of how some companies have turned their freelance services into products, see Brennan Dunn’s post <a href="http://planscope.io/blog/3-great-examples-of-productized-consulting-services/">3 Great Examples of Productized Consulting Services</a>.</p> <h2>Put business aims before perfection</h2> <p>Possibly the biggest thing I have learned from being the client is that often “good enough” is enough. As a developer, I wanted the time to do a really amazing job, yet often felt that we were being asked to cut corners and to not develop the perfect solution we knew we could come up with. As the client, though, I know I have to make the decision to ship. I need to be the person who says, <em>this will do for now</em>.</p> <p>I’d still love everything to be perfect. Sometimes, however, it is more important to get something out there, even if that means accepting slightly rough edges. As an example, we recently rebuilt the internal system that allows people to pay for our product and be issued with a license. We moved away from a legacy PSP to Stripe and made other changes that are going to enable things we have planned for the future. We shipped this with the most rudimentary reporting dashboard, and with a number of tasks that could be automated via various APIs not yet finished. For the business and our customers, the important thing was the parts they interact with; the rough edges were only a problem to us, and we can tidy up as we go along.</p> <p>To be able to work in this way with freelancers requires a change in mindset and in approach to defining and quoting for jobs. One of the reasons we hated feeling that we were shipping things with rough edges was because we were often contracted just to build a particular product. Our job ended when the project launched; we knew that whatever state the project launched in would often be the state in which it stayed. Now that we hire developers, we try to find people who are interested in an ongoing relationship. We hope this relationship helps them feel confident that when we say we need to ship something they have worked on, it’s not the end of their work on it.</p> <p>If I were writing code for other people now, I think I would foster these types of relationships far more than we did then. Instead of railing against the client who wanted to ship something I felt was not ready, I would try to help them to get to a shipping point that didn’t also mean we hand over the work.</p> <h2>Invoicing: the relationship killer</h2> <p>Many of the issues outlined above were exacerbated by the agency model of building, shipping, and invoicing for projects. Since our final invoice couldn’t be sent in until the work was complete, clients often saw that invoice as a way to hold us over a barrel until some element (that perhaps wasn’t initially quoted for) was done. It’s a pretty toxic way to work if you want to create great ongoing relationships.</p> <p>Many of our freelancers now bill weekly or every two weeks when they are working on things for us. I really like that as a model. If the scope creeps and the work takes longer, we simply pay for more days of work—potentially with a delay if our contractor has booked some other work in—but the entire job doesn’t need renegotiating. There are no awkward discussions about whether they are allowed to submit an invoice.</p> <p>There is a huge imbalance in many client/developer relationships. The client often wields power in the shape of owing the developer money that won’t be paid until hoops have been jumped through. The developer may be privy to, and often may be the only person who fully understands, a large part of the client’s business. The developer can feel as if their work is not being valued, while the client feels that the developer is spending far too much time on unimportant things.</p> <p>Of course there are people who will treat developers badly no matter how hard they work and how well they communicate. However, I think that many relationships become strained because of the lack of balance created by the agency billing model. </p> <h2>Better together</h2> <p>Ultimately the best client/developer relationships should be mutually beneficial; two businesses working together for the benefit of both, understanding each others’ communication needs and business aims. It sounds like perfect sense, and it is—but it’s only by being the client that I have really come to appreciate that.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/BNbpUko7IQo" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
26. Jun 2014
W3C Invites Implementations of Linked Data Platform 1.0
The Linked Data Platform (LDP) Working Group invites implementation of the Candidate Recommendation of Linked Data Platform 1.0. This document describes a set of best practices and simple approach for a read-write Linked Data architecture, based on HTTP access to web resources that describe their state using the RDF data model. Learn more about the [&#8230;][mehr] (Quelle: W3C News)
26. Jun 2014
Last Call: Vibration API, Ambient Light Events, HTML Media Capture
The Device APIs Working Group has published three Last Call Working Drafts today: Vibration API. This specification defines an API that provides access to the vibration mechanism of the hosting device. Vibration is a form of tactile feedback. Ambient Light Events. This specification defines a means to receive events that correspond to a light sensor [&#8230;][mehr] (Quelle: W3C News)
15. Jul 2014
W3C Announces Program, Opens Registration for 20th Anniversary Symposium
W3C today announced the program and opened registration for W3C20 Anniversary Symposium: The Future of the Web, which takes place 29 October in Santa Clara, California. Confirmed speakers are: Tim Berners-Lee, Inventor of the Web and W3C Director Vinton Cerf, Vice President and Chief Internet Evangelist at Google Fadi Chehadé, Chief Executive Officer of ICANN [&#8230;][mehr] (Quelle: W3C News)
26. Jun 2014
W3C Invites Implementations of DOM Parsing and Serialization
The Web Applications Working Group invites implementation of the Candidate Recommendation of DOM Parsing and Serialization. This specification defines various APIs for programmatic access to HTML and generic XML parsers by web applications for use in parsing and serializing DOM nodes. The group also published a Working Draft of Shadow DOM. This specification describes a [&#8230;][mehr] (Quelle: W3C News)
26. Jun 2014
Last Call: HTML5
The HTML Working Group has published a Last Call Working Draft of HTML5. This specification defines the 5th major revision of the core language of the World Wide Web: the Hypertext Markup Language (HTML). In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing [&#8230;][mehr] (Quelle: W3C News)
24. Jun 2014
Core Accessibility API Mappings 1.1 (Core-AAM) First Public Working Draft and WAI-ARIA 1.1 updated Working Draft
The Protocols and Formats Working Group today published a First Public Working Draft of Core Accessibility API Mappings 1.1 (Core-AAM), which supports the updated Working Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.1. WAI-ARIA provides an ontology of roles, states, and properties that define accessible user interface elements. WAI-ARIA is designed to improve the accessibility [&#8230;][mehr] (Quelle: W3C News)
24. Jun 2014
Three Specifications Published by the Web Applications Working Group
The Web Applications Working Group has published three documents today: A First Public Working Draft of DOM Level 3 KeyboardEvent key Values. This specification defines the values for the KeyboardEvent.key attribute, which is defined as part of the Document Object Model (DOM) Level 3 Events Specification. The key attribute contains information about the character generated [&#8230;][mehr] (Quelle: W3C News)
11. Jun 2014
Apple and Responsive Design
<p>Apple has always had a funny relationship with responsive design. They’ve only sparingly used media queries to make minor visual tweaks on important pages, like <a href="http://apple.com">their current homepage</a>.</p> <p>Though a “handcrafted for all devices” approach seems like the “Apple way,” it’s almost as if they’ve avoided it because of the iPhone’s original pitch—giving users the ability to pinch and zoom their way through the “full” web, as opposed to being shuttled off to the <a href="http://en.wikipedia.org/wiki/Wireless_Application_Protocol">mobile web</a>.</p> <p>Apple could afford that stubbornness when the only thing running iOS was the 3.5-inch iPhone. Over the past few years, though, they’ve introduced the 10-inch iPad, the 4-inch iPhone, the 7-inch iPad mini, and reports point to an even larger iPhone coming this fall.</p> <p>The approach that Apple and their community of developers have taken to build apps for these new device sizes closely resembles the way we did it for the web over the last decade or so: adaptive first, then slowly building to responsive.</p> <p>When the iPad was first announced, developers built separate View Controllers for iPhones and iPads—on the web, that’d be like building separate pages for each. Layouts, styles, and interactions were built to target each device specifically. This was an adaptive way of thinking, and it worked because of the limited number of targets.</p> <p>With iOS 6, and the subsequent release of the taller iPhone 5, Apple introduced something called <a href="https://developer.apple.com/library/ios/documentation/userexperience/conceptual/AutolayoutPG/Introduction/Introduction.html">Auto Layout</a>—a relationship-based layout engine. Unlike the iPad, which required a separate build, apps for the taller iPhone were the same build with layout adjustments applied. Auto Layout was Apple’s first true foray into responsive design within native applications since, much like the web, different layout rules were applied to the same base code.</p> <p>Last week, Apple introduced iOS 8, and with it, something they’re calling <a href="https://developer.apple.com/videos/wwdc/2014/#216-video">Adaptive UI</a>. The main feature of Adaptive UI is the ability to specify layout rules based on <a href="https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS8.html#//apple_ref/doc/uid/TP40014205-SW30">Size Classes</a>, which are really just breakpoints set by Apple. </p> <p>Developers can now use a single View Controller (or page, in our world) with various layout rules applied across Size Classes (or breakpoints) to accommodate devices of all sizes. While there are only two Size Classes right now, compact and regular, Apple has left a lot of room to add more, or to even let developers set breakpoints themselves in the future.</p> <p>It may be adaptive in name, and hard-coded breakpoints may seem like adaptive thinking, but the groundwork has been laid for responsive design within native iOS applications. It’s been interesting to watch Apple’s path from static, to adaptive, to responsive, and it’ll be even more interesting to watch third-party developers take advantage of the workflow benefits of responsive design that we’ve become accustomed to.</p> <p>Apple has finally come around on responsive design, and to top all that off, there was even <a href="https://developer.apple.com/videos/wwdc/2014/#517-video">a session about it last week at WWDC</a>. I wouldn’t be surprised if, in the next year, we finally see the responsive redesign of <a href="http://apple.com">apple.com</a> that we’ve been waiting for all these years.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/JpUaNt5u0n8" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
19. Jun 2014
Workshop Report: Linking Geospatial Data
Today the W3C announced the final report from the Linking Geospatial Data workshop that was held in London 5 &#8211; 6 March 2014. The report contains a summary of each of the major themes discussed and conclusions arising from them. The workshop was supported by the Open Geospatial Consortium (OGC), Google, the UK mapping agency [&#8230;][mehr] (Quelle: W3C News)
12. Jun 2014
Web Animations 1.0 Draft Published
The Cascading Style Sheets (CSS) Working Group and the SVG Working Group have published a Working Draft of Web Animations 1.0. This specification defines a model for synchronization and timing of changes to the presentation of a Web page. This specification also defines an application programming interface for interacting with this model and it is [&#8230;][mehr] (Quelle: W3C News)
4. Jun 2014
Testing Responsive Images
<p>At long last, the native <code>picture</code> element isn’t just coming: it’s here. The <code>picture</code> element has landed in Canary—Google’s “beta” channel for upcoming Chrome releases—and we can try it out for ourselves right now. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=870022">Firefox isn’t far behind</a>, and <a href="https://bugs.webkit.org/show_bug.cgi?id=133480">WebKit work is officially underway</a>.</p> <p>We got the <code>picture</code> element this far, and now that we’re in the final stages we have another opportunity to help things along: testing and filing bugs. <a href="http://twitter.com/yoavweiss">Yoav Weiss</a> is hard at work, testing and patching as much as possible before this ships in Chrome stable—but the more eyes we have on this, the better.</p> <h2>Ready to get started?</h2> <ol> <li><a href="http://www.google.com/intl/en/chrome/browser/canary.html">Download Chrome Canary</a></li> <li>Copy and paste the following into Canary’s address bar: <code>chrome://flags/#enable-experimental-web-platform-features</code></li> <li>Click “enable”</li> </ol> <p>The page at <code>chrome://flags</code> allows you to tinker with the browser’s internals a bit, enabling and disabling features that might not quite be ready for prime time: the <code>picture</code> element is, for now, behind the “experimental web platform features” option—including <code>sizes</code> and <code>srcset</code>. Don’t worry: changing this option in Canary won’t have any effect on your regular Chrome app.</p> <h2>Kicking the tires</h2> <p>And now—finally—we can try out the native <code>picture</code> element for ourselves. The <a href="https://github.com/scottjehl/picturefill/">Picturefill</a> demos are a great place to get started, since Picturefill only takes over in the event that the element isn’t natively supported. One thing to note is that this early version of <code>picture</code> doesn’t re-evaluate when the viewport resizes—at least until <a href="https://codereview.chromium.org/287163010/">the next major patch lands</a>—so you’ll need to reload the page to see things change, for now.</p> <p>Experiment with the new markup for yourself, either by forking the <a href="https://github.com/scottjehl/picturefill">Picturefill repo</a> and making changes to the existing demos, or by <a href="http://codepen.io/RICG/pen/moxHs">writing your own</a> from scratch. If something seems wrong, <a href="https://github.com/yoavweiss/Blink/issues">file an issue on Yoav’s fork of the Google Blink code</a>, or join us in the <a href="irc://irc.w3.org:6665/#respimg">RICG IRC channel</a> to discuss what you’re seeing—or just to share your test cases with us, so we can test the Firefox and Safari implementations against them when the time comes.</p> <p>We couldn’t have made it this far without the hard work of <a href="https://gist.github.com/Wilto/547b88c657b511fb1dc5">the design and development community</a>—and the more testing we do now, the better responsive images will be for it.</p> <p>&nbsp;</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/UGxEUIDnmCc" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
3. Jun 2014
Prototyping Your Workflow
<p>Last year the digital agency I work for, <a href="http://bluecadet.com">Bluecadet</a>, started a website redesign project for <a href="http://fi.edu">The Franklin Institute</a>—a renowned Philadelphia science museum undergoing the largest expansion in its history. My colleagues and I were excited because not only were we getting to work with an iconic local institution, but the project represented an opportunity to incorporate a number of techniques into our responsive web design practice: atomic design, HTML wireframes, style tiles, element collages, and front-end style guides. We envisioned a series of quick prototypes that lent momentum to a harmonious back-and-forth between design and development. We felt like this was an opportunity to overhaul the way we created for the web, from start to finish.</p> <p>And then we got stuck.</p> <p>We couldn’t figure out where we would fit all of these new techniques into our preferred way of working. I don’t think we’re alone in this. The way we create for the web is changing so rapidly that if you’ve attended enough conferences or read enough books and blogs these last couple of years, you may feel like we did: excited but a little overwhelmed, and worried that your organization is the only one that hasn’t yet adopted <em>the</em> expert-approved way to create for a device-agnostic web.</p> <p>There’s a seductive danger present whenever you see someone else outline their way of working, however. It’s easy to take their process as a rigid, universal truth. The trouble is, you and your team aren’t like everyone else—you have different strengths and weaknesses. Borrowing someone else’s process wholesale ignores the fact that it probably took them lots of fumbling to get to that point, and it’s going to take plenty of experimentation on your team’s part to figure out what works for you.</p> <p>So perhaps the solution isn’t to transplant someone else’s guidelines in an attempt to fix the entire thing all in one shot. Maybe there’s a way to take the same iterative spirit of these new techniques and apply it to the overall workflow itself. To prototype your workflow, in other words. In some ways, it’s a mental trick—a way of giving yourselves permission to try things, even if you’re unsure of the outcome. It also lowers the stakes to a comfortable level: <em>if we mess this up, we’re still okay</em>.</p> <p>What follows, then, isn’t a tidy recipe or a formula. It’s a collection of observations I hope will help you re-cast workflow change as an ongoing process of small, imperfect steps.</p> <h2>Technique is easy, talking is hard</h2> <p>It’s easy to get fixated on the benefits of specific tools and techniques, and to assume that those benefits are self-evident to everyone. But over the course of the past year, it’s dawned on us that meeting the demands of our multi-device web is less a problem of technique, and more one of communication. Sometimes people just need to understand why you want them to change how they work.</p> <p>Prior to the Franklin Institute project, my colleagues and I had been pooling all of these new techniques, but we instinctively focused on pieces that affected our part of the process. Designers and developers were talking and dreaming—but largely within the echo chamber of their respective disciplines. So when it came time to kick off the project, we had to have some hard conversations about how new techniques would work for us as an entire team, and sometimes we were downright skeptical of each other’s suggestions. On more than one occasion we asked each other: “That’s great, and it works for that agency, but how would that work <em>here</em>?”</p> <p>You will probably need to make your case differently for each person on your team, then. If you’re a designer, it could mean explaining to your developer teammate that you would like to start breaking things into a design system so that you don’t have to do 20 different iterations of the same page layout. For developers, you might have to convince your boss that a style prototype will be the best way to present a site to your client.</p> <p>Whatever the rationale, realize that change represents a very real cost (at least in the short term) to your teammates&#8217; time and comfort, and their skepticism may be their reaction to that cost, rather than to the less-immediate benefits you say will follow. Focusing on the <em>why</em> instead of <em>how</em> can help balance those two competing forces.</p> <h2>Limit your focus</h2> <p>As of this writing, Bluecadet has 22 full-time staff members. That’s just big enough to make it hard to work on intricate, shifting process details at a company-wide level. So we’re starting small, at the project level, instead of trying to craft a monolithic process that gets handed down from above.</p> <p>Look at the projects you have on the horizon. Think about the portions of your workflow that you want to improve, and pick just <em>one</em> of those things to introduce into your project. Why just one? It allows you enough space to experiment without endangering your project.</p> <p>A mentor of mine once told me that programming (and especially programming for the web) boils down to reducing the number of “unknowns” on a project to a manageable number. One is fine, two is a stretch, and three is asking for trouble. If you think exploring HTML/CSS wireframes could have a positive impact on your work, introduce just that one thing. Most projects have enough built-in friction without adding or changing multiple processes at the same time.</p> <p>For the Franklin Institute project, we ended up deciding that the added wrinkle would be a front-end style guide. It wasn’t the biggest thing, but it was one small step that we thought could have a big benefit without affecting our schedule.</p> <p>We made this decision based on two factors—factors that might be helpful as your team thinks about what that “one thing” could be:</p> <ul> <li>A good idea that didn’t quite work in the past: we had created a static style guide for a previous project that had quickly become outdated and was ultimately discarded. But we still thought the idea had merit. So when you gather as a team, think about past good ideas that might have stalled, and whether they could work if you approached them differently.</li> <li>(A little) experience mixed with (a lot of) enthusiasm: a new front-end developer joined our team, and he had already been experimenting with different style-guide generators like <a href="http://barebones.paulrobertlloyd.com/">Barebones</a> and <a href="http://patternlab.io/">Pattern Lab</a>. More importantly, he was excited about building one. Does someone have something they’ve been testing on a personal project, or that they’ve used successfully at a previous job? If so, you’re already halfway there—you might just need to figure out how to make space for it.</li> </ul> <h2>Align your tools and techniques with your team</h2> <p>One of the recurring discussions we have at our studio is: “Should our designers learn markup and start doing some of this design in the browser?” We’ve heard a lot of persuasive arguments for it, but in the end, we decided that the main focus should be <em>how</em> to get our designs into the browser earlier in the process, instead of <em>who</em> should be doing that work.</p> <p>This led us to try pairing designers and developers early on in a project, and having the developer create markup that “waterskis” behind the designer’s sketches and Photoshop explorations. We’ve found that doing it this way takes advantage of our team’s individual strengths. It also means that our developers are providing feedback that makes it into design iterations while they are still malleable.</p> <p>We’re currently in the middle of a redesign project for a literary magazine, and we’ve found that the rough HTML/CSS mockups created by our developer helped us pose the right questions to our team’s designer. Giving our designer a specific problem to solve (“These titles take up too much space at narrow widths”) allowed her to judge the problem in the context of the entire design. She could then explain what she was trying to accomplish visually, and even find solutions that extended beyond the immediate issue we were trying to solve. She’d look at the screen while we squished the browser back and forth, and then say something like, “If you move the titles below the photos this whole problem goes away.” Stepping away from dogmatic ideas of who should be doing what allowed her to focus on doing what <em>she</em> did best, which was solving visual problems.</p> <h2>Distinguish between internal and external needs</h2> <p>When you start moving things around, you may start producing deliverables that are important, but only for an internal audience. That might be because they’re of limited use to the client, or they simply may not be mature enough. Managing expectations is as important as trying a new technique, so if the client is going to see something new, you’ll have to invest time preparing them for what they will receive—especially if it’s not how they’re used to working.</p> <p>For a current project we are producing HTML/CSS wireframes to get an idea of how long they actually take to make. Since we don’t know (yet), the first rounds of client deliverables are still going to be static wireframes done in Photoshop. If we feel like the HTML/CSS prototypes are mature enough, we will introduce them to the client in the final round.</p> <p>As you work, then, give yourself enough room to adjust: what if it takes twice as long to produce that wireframe? What if the client is resistant to parallel wireframe and design conversations? What if the thing you’ve produced has value, but only if accompanied by other deliverables?</p> <h2>Focus on products, not presentations</h2> <p>One of the things we’ve had to do was clarify the ultimate goal. This seems obvious: “We’re making a website.” But if your process is anything like ours, you actually spend a lot of time making anything but a website. Mostly you make pictures of a website.</p> <p>Recently, while working on a beta build of a website, we found out that the majority of our client’s team members were using older versions of Internet Explorer and Firefox. Those people were surprised to see something that differed from the comps they’d been presented earlier in the process.</p> <p>That experience taught us a lot. Setting client expectations is one way to avoid those surprises, but we’re also slowly agreeing as a team: the browser is the final arbiter of what we do, so let’s stop shoving it to the end of the line. The components of our process need to support the final product at every step of the way.</p> <h2>Put your process prototype on the agenda</h2> <p>It’s easy to nod and agree on something: “We’re going to do this!” But when you get immersed in detail work, it’s just as easy to forget that one new thing you all agreed to put in the mix. So task someone with making sure that you revisit your process prototype repeatedly. This might mean you start meeting more frequently. We’ve found it helpful to have official meetings, but our hope is that eventually we start doing this in a less-structured way, choosing to meet informally when we feel the need to discuss something.</p> <p>If you’re working on a project-based team, remember to share what you’re doing with other groups. For example, on a recent project, we implemented modular content blocks that could be reordered as needed, inspired by a <a href="http://www.newfangled.com/the_way_you_design_web_content_is_about_to_change">post by Christopher Butler of Newfangled</a>. We then showed what we were doing to a colleague, and she integrated some of what we learned into her next project. She also had some incisive questions for us that helped us improve the content-authoring experience for our client.</p> <p>By sharing with others, everyone wins: your colleagues will pick up your new skills, and you’ll be forced to clarify your goals and assumptions.</p> <h2>Iterate your workflow (play the long game)</h2> <p>When you’re reworking your process, it’s good to keep a running log of the things (both good and bad) that you encounter with each new change you introduce:</p> <ul> <li>Did something take more (or less) time than you expected?</li> <li>Were there people who were negatively affected by the change?</li> <li>How did the client react? If you’ve worked with them before, were they receptive to change?</li> </ul> <p>By breaking things into focused pieces, you’ll be able to evaluate how effective they were. You can keep the stuff that worked, and refine (or throw away) what didn’t. Having a forum to share those pieces is important, too—at Bluecadet, we’ve made sharing lessons from completed projects with one another a regular part of our monthly all-staff meeting.</p> <p>Over the course of three separate projects, we’ve now field-tested:</p> <ul> <li>Atomic/modular content and layout</li> <li>Front-end style guides</li> <li>HTML/CSS wireframes</li> </ul> <p>Here’s the thing: each of those things that we tried? We’ll probably do them just a <em>little</em> bit differently the second time around, because of all the data we gathered from the first go-round. If we had sat around until we were sure about The New Way of Doing Things, well, we’d still be sitting around today.</p> <p>One of the things I’m most proud of is that by working piece-by-piece, we’ve pushed our workflow forward while being honest with our clients. One of our internal guidelines is that our clients shouldn’t be bankrolling our workflow remodeling project—our fine-tuning should result in tangible internal benefits for us, but, more importantly, a better product for our clients.</p> <h2>Try something new, now</h2> <p>As I finish writing this, we’re trying out yet another thing that we hope to add to that list: HTML/CSS prototypes as a design deliverable. Maybe they will replace static comps, or simply accompany them—we don’t know yet. But it’s okay that we don’t know. By the fall, we’ll probably be building things far differently than we are right now, informed by the experimentation we’re doing piece-by-piece along the way.</p> <p>I hope that this encourages you and your team to take some small steps, too. Get together and talk about the parts of your workflow that can be improved, pick one thing to try together, and figure out where you can make space for it. Like us, you’ll probably never be able to draw a line on the calendar and say, “That’s when we started doing things the right way.” But you’ll find yourself much further along—one thing at a time.</p> <p>&nbsp;</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/DHnEb0Tl1wU" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
3. Jun 2014
Living up to Your (Business) Ideals
<p>I believe that most people are good. Most people really want to live up to their ideals. So why do companies fall short on living up to their missions, credos, mantras, or ideals? </p> <p>For example, why does a company that says it supports local businesses jump at the chance to work with Walmart just to get a “big name” client on its roster? I have started to believe it is because they haven’t taken the time to clearly articulate company values and, more importantly, establish routines and practices that intentionally frame their decisions to factor in their values.</p> <p>At our design firm, <a href="http://punkave.com/">P’unk Ave</a>, we decided to change that by developing a model for evaluating potential clients, giving us a practical, standardized way to make decisions that stay truer to our values. While it may seem like being picky about who we work with is bad for business, we’ve found the opposite to be true: the more we’ve stuck to our ideals, the stronger our business has become. In this article, I’ll show you how it worked for us—with the hope you can learn from it and do the same for your business.</p> <h2>Establishing your values</h2> <p>You can’t live up to your ideals until you have a clear grasp of them. If you have been in business for some time, you might be surprised to realize that they already exist and are just waiting for you to be more intentional about identifying and writing them down.</p> <h3>Set a timer</h3> <p>My partner and I began our process with some borrowed time on a layover heading back from a conference. We took out our journals, set a timer for 10 minutes, and began writing down our core values. The ideas took form quickly because they had already been part of our DNA. This allowed us to make a rough list of values that resonated with decisions we had made in the past—values like “innovation,” “trust,” and “responsibility.” We’ve since refined these somewhat general ideas using an exploratory process that includes all members of the team, but setting a timer during this early phase forced us not to overthink things, and helped us to get started with ideas that came more from the gut than from the brain.</p> <h3>Take inventory</h3> <p>Then we did a whiteboard audit of our current and past clients to look for trends and to test how our values applied (or not). We paid particular attention to those clients we were most excited about. Through this process we identified a pattern of partnerships with people who work to strengthen our cities (urban planning, local food, bicycle advocacy, waterfront improvement), create knowledge (universities, education initiatives), improve people&#8217;s health (advocacy, research), and enhance our quality of life through arts and culture (museums, photography collectives, arts organizations).</p> <h3>Get outside perspective</h3> <p>We followed this up with a workshop led by a friend, which allowed us to further explore our values, strengths, and goals. This led us to create a series of active phrases about our work, including <em>we are part of a community</em> and <em>we dream</em>. These phrases now form the basis of the P’unk Guide, which includes our shared values and principles to run the business we all want to work in. As part of our ongoing reflection, we have also evolved the guide to include “guiding metaphors.” One of those metaphors is based on the notion of sailing upwind: “The shortest distance is not always the quickest.”</p> <h2>Building a framework</h2> <p>Becoming more aware of our values helped us make more intentional choices with prospective projects, but it didn’t necessarily provide us with a framework for quickly evaluating potential projects and relationships. That came when we read the book <cite>Drive</cite>, by Daniel Pink.</p> <p>In <cite>Drive</cite>, Pink talks about the principles of autonomy, mastery, and purpose as powerful motivational elements for modern workers. For Pink, jobs that require deep thinking and applied analytical skills are not easily simplified to an assembly line process, and measuring productivity within a certain time limit isn’t an effective way to track their success. Rather, people who have the freedom to work in the way they see fit (autonomy), who are constantly honing their skills (mastery), and who understand the intention of their work (purpose) perform best in these positions.</p> <p>There was no turning back. We used Pink’s principles as a starting point to create our own framework for evaluating potential relationships with partners and clients: the AMP scoring system. Evaluating projects through our new lens of autonomy, mastery, and purpose helped us ask whether or not that relationship would <em>motivate</em> us to do good work and help us live up to <em>our</em> ideals of trust, innovation, and impact.</p> <h2>The AMP score</h2> <p>In considering a new project, we take the time to get to know the client, with the goal of determining whether we will we be truly pumped (or “AMPed”) if the project is a success—not because the project is done, but because of the impact it has on something we care about. Then we score it, using a series of questions in each of the three categories. Each category then gets a score from 1 to 5, and we total up the results at the end.</p> <h3>Autonomy</h3> <ul> <li>Will this client respect us?</li> <li>Will they seek our counsel?</li> <li>Will they give us the space to bring our experience and knowledge to impact the project positively?</li> <li>Do they trust us?</li> <li>Basically, will they let us do what we do best in service to their project?</li> </ul> <p>It is always a good sign when a potential client is genuinely interested in understanding how you work. If they take the time to ask you about how and why you make decisions, they’re telling you that they respect your experience, and are seeking a partnership that is productive and valuable. It is an especially good sign—usually a 4 or 5 on the AMP scale—if they listen carefully and ask thoughtful follow-up questions, since it indicates that they are genuinely interested in working towards a relationship built on understanding and trust.</p> <h3>Mastery</h3> <ul> <li>Is there space to practice our skills and grow as craftspeople?</li> <li>Is there time to do the project well?</li> <li>Does the client value a job done well?</li> </ul> <p>For example, if a client emphasizes how simple a project is by saying something like, “All we need is to code this page. It is simple. How long will that take? A week?” or “Do we have to do the research? Couldn’t we just copy the design of this website?” then they may not respect the work we do—especially if this perspective persists after we explain the value of a thoughtful and measured approach. In this scenario, we would rate the mastery score a 1 or 2, since they seem more interested in rushing than in allowing us the time to do thoughtful and considered work.</p> <h3>Purpose</h3> <ul> <li>Do we understand the purpose of their project?</li> <li>Equally important, do <em>they</em> understand the purpose of their project?</li> <li>What kind of impact will this project make?</li> <li>Do we feel aligned with that impact?</li> </ul> <p>For example, sometimes a webmaster at a larger organization contacts us, but is only interested in technology. This is common when an organization puts the management of their website solely in the hands of their technical or IT team, instead of seeing it as a communication tool for the entire organization. When this happens, we try to bring leadership into the process and educate them before signing an agreement—but if that cannot be done, the project would score low on the purpose scale. It is particularly difficult to walk away from an organization that is doing work we find interesting and aligns well with our values, but we have learned that when leadership isn’t involved, the project is not likely to be a success.</p> <p>What does all this actually look like? Practically speaking, we post a message with details about all potential projects in Basecamp, and each member of the team has the opportunity to respond with their thoughts and personal AMP score for the project. Once everyone has weighed in, we compare scores, looking for a total of 12 or higher. We will consider lower scores, but not below 10.</p> <p>This system creates a paradigm where we are asking ourselves if there is a compelling reason we <em>should</em> work with a client, rather than just looking for a reason <em>not</em> to work with them. That distinction may seem subtle, but it has powerful implications, supporting a proactive versus reactive culture.</p> <h2>Intentional projects are successful projects</h2> <p>This may seem one-sided and only to our benefit, and maybe an unsustainable business practice. However, being thoughtful and intentional in this way has turned out to be a great thing for our clients as well. Once we commit to a project, we are truly committed. We even share how this benefits them in our project proposals:</p> <figure class="quote"> <blockquote>Most projects will hit bumps in the road that will require persistence and dedication to see it to a successful completion. With that in mind, our philosophy is to only work on projects where there is a strong alignment of values. We truly care and you can see the difference in that approach.</blockquote></figure> <p>They get that. It resonates with them because anyone that has some business experience knows that unanticipated problems will inevitably rear their head at some point. Because we took the time to evaluate the project using the AMP score, we’ve already decided that we are committed to the success of the project, and any bumps in the road will be tackled with gusto and passion. This knowledge gives our clients greater confidence in working with us.</p> <h2>What&#8217;s good for the goose…</h2> <p>As a consultancy, much of our “everyday” revolves around clients and projects. This is the lifeblood of our company and sets the tone for our interactions. If we are not in sync with our clients, our lives can turn miserable pretty quickly.</p> <p>We always cared about our work and had good relationships with our clients before, but intentionally pursuing projects that align with our business values has brought a higher level of investment and internal motivation from all members of our team. We have become true partners in the success of our clients’ projects.</p> <p>A lucrative project that doesn’t align well with your values is like the siren’s call to start your day with a sugary doughnut. Of course, getting sidetracked is easy. Using a framework to evaluate potential business has become a way to stay on course—a way to make healthier choices.</p> <p>When we made compromises in the past, it never resulted in great work and often had other unintended consequences, like burning out our team. The attitudes you develop working on a project you don’t care about can carry over into all of your work. Our framework has helped us stick to our guns and not work on even a single project where we don’t see an alignment of values.</p> <h2>Ideals are good for business, too</h2> <p>The AMP system has had a positive ripple effect throughout our company. Everyone knows that we make decisions based on our shared <em>and agreed upon</em> values. We have chosen not to pursue work that does not garner a high AMP score, and we have even stopped working with clients when they turn out not to allow us to live up to our ideals. In the short term, we may have turned down some potential business, but in the long term we have increased our revenue while working with clients we respect. That growth comes from our participatory culture, where everyone is invested in and focused on their projects—leading to happier clients and a lot more word-of-mouth referrals and opportunities.</p> <p>This is not something that can happen overnight. If you want to live up to your business ideals, you have to take the time to authentically identify your values, the things you care about. You also have to commit to the ongoing tending and cultivation of those values in your organization. It is not a “set it and forget it” scenario. At P’unk Ave, we think about this regularly, and especially during our quarterly “<a href="http://punkave.com/window/2014/04/29/states-of-punks">State of P’unk</a>” and twice-yearly retreats. Building in those rituals, as well as creating tools like the AMP score, helps us stay on track in creating the kind of company we want for ourselves.</p> <p>But the commitment is worth it. Once you have a framework for evaluating the kinds of people you want to work with, you have power: the power to say “no”—and the power to do the work you know matters.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/53Z_zmUdlls" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
30. May 2014
On Styled Form Elements
<p>For <a href="http://en.wikipedia.org/wiki/HTML#HTML_versions_timeline">almost 20 years</a>, we’ve had the same input types and form elements we still use today: text fields and areas, password fields, select dropdowns, radio buttons, checkboxes, file fields, hidden fields, and the menagerie of button types including <code>submit</code>, <code>reset,</code> <code>image</code>, and plain old <code>button</code>.</p> <p>All of these input types brought with them some styles and functions from both the operating system and browser in use. Much to our own chagrin, we (mostly) figured out how to fight that to achieve custom styles for <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Styling_HTML_forms">basic</a> and <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Advanced_styling_for_HTML_forms">advanced</a> elements.</p> <p>Custom styling usually meant background images, pseudo-classes, weird vendor prefixes, and selectively hiding certain elements. I’m not going to get into the accessibility concerns of styling inputs with those tactics (this post can only be so long), but the complexity of input types and their implementation amplified cross-browser and platform issues. Each possible combination of browser and operating system brings its own styles and functions, some of which are hard to control, and all of which are inconsistent.</p> <p>Even with that amount of stylistic complexity, the interactions of these early input types were pretty simple—click this, type into that box, check the other thing. Simplistic interaction allowed us to get a little crazy with custom styles without hurting the experience. Only the select dropdown, with its list of options, had a more advanced interaction.</p> <p>As the web moved forward, though, we grew hungry for better interfaces. We built <a href="http://jqueryui.com/datepicker/">JavaScript-driven components</a> on top of these basic input fields to achieve better experiences, and that worked fine for a while, up until everything changed when the modern mobile environment exploded in 2007.</p> <p>The changing environment led to changing interactions—our adorable little calendar-like date picker was an absolute nightmare to use on a 3.5-inch touchscreen, and even dropdowns needed to be rethought.</p> <p>The iPhone’s native drop-down control was a full-screen wheel-type interface, which was a much more natural interaction at its size. It’s not the perfect interface, especially when the number of options exceeds ten or so (don’t get me started on a listing of countries), but it was a big improvement over fiddling with a tiny, in-page drop-down list.</p><figure><img src="http://alistapart.com/d/misc-images/apple-select.jpg" alt="The Various Dropdown Interfaces of Apple Devices" /></figure> <p>Android’s drop-down interface was similar, but ever so slightly different—a modal listing of options which closes on selection.</p><figure><img src="http://alistapart.com/d/misc-images/android-select.png" alt="Android’s Native Dropdown Interface" /></figure> <p>There was a native date picker in iOS—a three-segment drop-down interface, which was much better to use than its calendar-based predecessor.</p><figure><img src="http://alistapart.com/d/misc-images/ios-date.png" alt="The iOS Date picker" /></figure> <p>Standard <code>select</code> elements were well-supported on these new devices, but we didn’t have a way to leverage other built-in, native components, like the iOS date picker, on the web. Luckily, HTML5 came along and brought us some <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input">fantastic new input types</a>. Types like <code>date</code> and <code>range</code> set the stage for browsers and operating systems to begin handling more and more complex interactions. Apple quickly introduced support for <code>date</code> in iOS 5, and gave us the ability to expose the native iOS date picker in the browser.</p> <p>As support for these new input types grows, we can <a href="http://tjvantoll.com/2012/06/30/creating-a-native-html5-datepicker-with-a-fallback-to-jquery-ui/">begin implementing them today</a> with fallbacks when appropriate (or at least helpful hints, since unsupported input types become text fields). Dropdowns and date pickers are just a sampling of the things that are better handled by systems themselves—a device will always be able to make better decisions about its use than the device-agnostic web.</p> <p>The simplistic interactions of early input types gave us room to experiment, but the more complex interactions of modern fields leave little room for that. There’s only so much we can control before the browser and operating system take over, and then we’re at their whim. The web isn’t stopping any time soon—we’re headed for more complex input types with even less control exposed.</p> <p>That makes me wonder how much longer we’ll be fighting to style these elements. It’s time we stop breaking and faking input types and <a href="http://alistapart.com/article/dao/">accept the ebb and flow of things</a>.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/KKr2oDzp1vs" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
29. May 2014
We Have Work to Do: #yesallwomen and the Web
<p>Last week, I plucked an article from our submission inbox. It was about getting stuck in the “friendzone,” and likened women not wanting to date men to both the Holocaust and terrorism.</p> <p>It was obviously ridiculous—a terrible article terribly suited to our magazine. I told the author it was sexist, made a joke about it on the <cite>ALA</cite> Slack channel, and moved on with my life.</p> <p>We’re <cite>A List Apart</cite>, after all. We published “<a href="/article/responsive-web-design/">Responsive Web Design</a>.” “<a href="/article/thedisciplineofcontentstrategy">The Discipline of Content Strategy</a>.” “<a href="/article/dao/">A Dao of Web Design</a>.” We’re here to help you make better websites and digital products, not get bent out of shape about every stupid example of sexism we see.</p> <p>And yet. Someone thought that was right for us.</p> <p>I woke up Saturday morning to <a href="http://www.npr.org/blogs/thetwo-way/2014/05/24/315425094/shooting-near-uc-santa-barbara-leaves-3-dead">news of tragedy</a>, and watched as that tragedy turned into <a href="https://twitter.com/search?q=%23YesAllWomen&amp;src=tyah">#yesallwomen</a>, a Twitter conversation about sexism and violence against women so large, so powerful, that <em>most of the women I know</em> contributed to it.</p> <p>The women <em>I</em> know, by and large, work in tech. They’re your designer, your developer, your content strategist, your user researcher. They’re our authors. And more often than any of us wants to believe, they’re getting groped at tech meetups. They’re receiving death and rape threats for speaking at a conference. Their bodies are being made the targets of office jokes.</p> <p>They’re being talked down to, fired, catcalled, harassed, abused, and raped—and blamed for it, too.</p> <p>But of course, that’s not our subject matter. <cite>A List Apart</cite> is about publishing the Next Big Thing in design. It’s about shaping standards. It’s about the business of building websites.</p> <p>And yet. When I look at those articles that most influenced my career (and probably many of yours), I see our mission, clear as day: to encourage a more thoughtful, curious, and engaged web industry—one that pushes past easy answers and encourages ongoing growth and learning.</p> <p>Technical skills—and by that I mean everything from JavaScript to typography to taxonomy—will take us part of the way there, but they’re not enough anymore. Not now, not when we’re facing the big, messy problems that come with designing for an increasingly web-connected world.</p> <p>We need as many brains and hearts as possible to solve these problems. And if we do not make this a welcoming place for people of all kinds of backgrounds—women, as #yesallwomen clearly shows, but also people of color and younger people and older people and people who don’t speak English as a first language and people with disabilities and even people who don’t think gifs are funny—then we, as an industry, will miss out. We’ll miss out on talent, on perspective, on ideas.</p> <p>So we, the staff of <cite>A List Apart</cite>, are putting a stake in the ground: we will be part of this conversation, too. Sexism and discrimination and diversity are not fringe issues—not problems that should be relegated only to niche sites or individuals’ blogs. They’re mainstream issues that have found far too comfortable a home in our industry. An industry we’ve worked too damn hard to grow, guide, and collaborate with to watch it falter and flail now.</p> <p>We’re not going to stop publishing articles about <a href="/article/css-shapes-101">CSS Shapes</a> or <a href="/article/dry-ing-out-your-sass-mixins">Sass mixins</a>, not for a second. But as we do, we’re also going to be thinking about our responsibility to this community. And that means a few things:</p> <ul> <li>We expect the people we publish to be respectful to their community, and we will not publish those we see doing otherwise.</li> <li>We will be vigilant about the voices we choose to amplify, and those we do not.</li> <li>We will actively, purposefully seek out diverse <a href="/about/contribute">contributors</a>.</li> <li>We’ll be spending more time talking about sexism, racism, and other forms of discrimination, even if it makes some readers uncomfortable.</li> </ul> <p>Most of all, we’re here, and we’re on the record: the web industry has a diversity problem. It’s got a misogyny problem. It’s standing in the way of the web we want, and we are all—every one of us—responsible for changing that.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/f78F76JZ6QE" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
20. May 2014
Ten Years Ago in ALA: Art Direction and Drop Shadows
<p>Writing for web designers is a tricky blend of trying to predict and shape the near-future while keeping your feet firmly grounded in the practical concerns of the here-and-now. Ten years ago this month in <a href="/issue/180">Issue 180</a>, <cite>A List Apart</cite> published Stephen Hay’s <a href="/article/artdirweb">Art Direction and the Web</a>, a tidy piece that still resonates today.</p> <p>For those who have grown weary of the Great Flatness Debates of the present, Stephen’s piece is refreshingly rooted in communication design. The article provides a solid outline of the principles of art direction by discussing the importance of creative themes and rhetorical devices in your work, and follows up with some practical tips on how to implement these concepts into your workflow. It’s a good read for today’s designer, as it is mainly focused on thoughtfulness and process, and unencumbered by jaggy screenshots of the pre-anti-aliased web.</p> <p>On the other hand, <a href="/article/onionskin">Onion Skinned Drop Shadows</a>, written by Brian Williams for <a href="/issue/182">Issue 182</a>, is a direct example of a technique that is now utterly obsolete. Like <a href="/article/fauxcolumns">Faux Columns</a> and <a href="/article/slidingdoors">Sliding Doors</a>, this technique demonstrates an incredible amount of ingenuity that seems ridiculously kludgey today, when drop shadows are so easily created with a single line of CSS that an entire movement has spawned to argue against them.</p> <p>Also from May 2004: <a href="http://alistapart.com/article/printyourway">Print It Your Way</a> by Derek Featherstone, a guide to creating custom user print stylesheets for Firefox, and <a href="http://alistapart.com/article/separationdilemma">Separation: The Web Designer’s Dilemma</a>, a rumination from Michael Cohen on the ongoing concern over keeping content separate from layout.</p> <p>Finally, a bonus flashback: <a href="http://www.zeldman.com">zeldman.com</a> from 10 years ago, with Issue 182 featured in the sidebar!</p> <blockquote class="twitter-tweet" lang="en"><p>10 years ago this month, <a href="https://twitter.com/zeldman">@zeldman</a> linked to my site for the first time. I was such a fan that I took a screenshot. <a href="http://t.co/Kz4rWgKZFG">pic.twitter.com/Kz4rWgKZFG</a></p>&mdash; Mr. Andrew Clarke (@Malarkey) <a href="https://twitter.com/Malarkey/statuses/466182177940848640">May 13, 2014</a></blockquote> <script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/I5L9fVIYpPU" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
15. May 2014
Global Accessibility Awareness Day: Getting the Word Out
<p>Today is Global Accessibility Awareness Day. To mark the day and promote the goal of the day, groups of developers and designers interested in accessibility offer webinars, presentations, and networking events to interest and educate more people about why accessibility is important and how to address accessibility in web content, documents, and software. <abbr title="Global Accessibility Awareness Day">GAAD</abbr> is a community-driven event, and engaging is a simple as visiting the <a href="http://www.globalaccessibilityawarenessday.org"><abbr title="Global Accessibility Awareness Day">GAAD</abbr> web site</a>, <a href="http://www.facebook.com/globalaccessibilityawarenessday">Facebook page</a>, or <a href="http://www.twitter.com/gbla11yday">Twitter feed</a> and taking a few minutes to read an article that someone posts or joining a webinar to learn new techniques or get up to speed on current trends.</p> <p>At <cite>A List Apart</cite>, we started this week by posting Andrew Hoffman’s new article, <a href="http://alistapart.com/article/accessibility-the-missing-ingredient/">Accessibility, The Missing Ingredient</a>. The article highlights techniques used to make an interactive shopping application and cart experience more accessible, and discusses how use of the W3C <abbr>ARIA</abbr> specification provides useful tools for a developer to use. Most articles about accessibility attract lots of passionate discussion, and this one is no different. </p> <p><abbr>ARIA</abbr> is a specification with support that is developing still, and there is often some measure of subjectivity in decisions related to accessibility and there is always variability in support offered by the mix of browser and assistive technology support for accessibility, so it&#8217;s helpful to see examples and talk about them.</p> <p>Discussion about any accessibility topic is a good thing, and helps engage people who are new to the topic. While it can be intimidating to wade into discussions on accessibility and it&#8217;s true that the accessibility community can be quick to criticize, there&#8217;s so much value in these discussions—for participants and onlookers alike—that the signal makes a little noise worthwhile.</p> <p>When I started on accessibility, my sometimes ignorant questions were met with welcoming advice and with dismissive remarks. I’m glad I focused on the former, and the many people interested in advancing accessibility who shared their knowledge, advice, and passion continue to help me develop my knowledge. Almost 15 years later, as a dyed-in-the-wool accessibility wonk myself, I need to continually remind myself that not everyone has worked on accessibility for as long as some of my colleagues but that there are a lot of people that are interested in helping make the web more accessible and as a community we need to pull them in, not push them away. </p> <p>On Global Accessibility Awareness Day, I applaud the many efforts being made to expand the number of people who know about accessibility, as it&#8217;s a problem that can’t be solved without expanding our community. It&#8217;s a big web, and we need as many voices doing as much educating as they can. Whether you’re writing for yourself or <a href="http://alistapart.com/about/contribute">submission page</a>: let’s get the word out!</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/KLb5T1lE8SQ" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
15. May 2014
“Dear FCC,”
<a href="https://dearfcc.org" style="font-size: 18px;">» “Dear FCC,”</a><br><br>Every voice counts! Please share your thoughts with the FCC before they vote later today to destroy net neutrality. This is an issue of justice and access. Save our shared web and help ensure that others can access it.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/1to12Qtz1fs" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
15. May 2014
Global Accessibility Day
<a href="http://globalaccessibilityawarenessday.org/" style="font-size: 18px;">» Global Accessibility Day</a><br><br>Today, 15 May, is Global Accessibility Awareness day. Please see if there is a live accessibility event near you. And take an hour of your day to experience accessibility online.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/zQrY5jvCTfg" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
14. May 2014
Design Tools for Today’s Web
<p>Even though I learned about designing for the web in what most would consider the modern era, I still learned (what I would consider) the old way of doing things. No, I’ve never made a table-based site, but I learned how to build a site without all of today’s CSS techniques. I remember slicing gradient images into repeatable, 1-pixel-wide background images, I remember how annoying it was to make a scalable container with rounded corners, and I remember adding classes of <code>even</code> and <code>odd</code> to list items and table rows.</p> <p>I learned the ways of Photoshop, Illustrator, and other Creative Suite applications, but I had no set processes or preferences early on—I was bias-free, and nothing was sacred. There’s no arguing that the Creative Suite applications are powerful, feature-rich, and have the intangible value of being industry standards—the PSD format is almost as universal as PDF—but, they just didn’t feel like the right tool for the job, especially to someone who was new to it all.</p> <p>As browsers became more advanced and rendering shifted from images to native CSS, the old, established applications fell out of step. A weird divide grew between how things were done in Photoshop and how they were implemented in code. The time was ripe for an application that was built, from the ground up, focused on the new era of interface design. And that’s when I found <a href="http://bohemiancoding.com/sketch">Sketch</a>.</p> <p>I was drawn to Sketch for its interface—it’s a truly native Mac application, not just an application packaged up to be compatible. It’s <a href="http://bohemiancoding.com/sketch/features/#precision">vector-based, yet pixel friendly</a>, which makes a huge difference in a world filled with displays of varying pixel density.</p> <p>The thing I love most about Sketch’s interface is that it’s consolidated and focused. All of an object’s properties can be tweaked directly in <a href="http://bohemiancoding.com/sketch/features/#the-inspector">the inspector</a>. No more traversing through menu after menu, or toolbar after toolbar, to get to important things.</p> <p>Navigating around Sketch is a breeze, and it doesn&#8217;t stop at the interface. Documents are broken down into pages, and pages are broken down into artboards. With an unlimited number of each, there’s a lot of flexibility to be had. There&#8217;s no right or wrong way to use pages and artboards, so bend them to fit your process.</p> <p>I’ve created Sketch pages to match each site page, with artboards to show responsive states. I’ve created pattern library pages, with artboards for things like type styles, control elements, and other general styles. I’ve made pages for icon sets, with an artboard for each individual icon. I find navigating through pages and artboards is a lot easier than opening multiple files and dealing with somewhat strange naming conventions.</p> <p>Back in the days of slicing designs, one size and format of each image would do just fine. But today, it’s not uncommon to have multiple sizes and formats of each image asset to support different viewport sizes and display pixel densities. Though we&#8217;re using images for less, exporting has become much more complex, tedious, and important.</p> <p>Sketch is built with a modern workflow in mind. Every single object and artboard in a document <a href="http://bohemiancoding.com/sketch/features/#exporting">can be made exportable</a>, and configured with multiple export rules. For each rule you can set a specific size, filename suffix, and image format. <figure> <img src="http://alistapart.com/d/misc-images/sketch-export-panel.png" alt="Sketch Export Rules"> <figcaption>My most frequently used export rules: high-PPI-ready and standard-sized PNGs, as well as SVGs for supporting browsers.</figcaption></figure> <p>Exporting assets is generally time-intensive, and future updates require a complete re-export. Once export rules have been set up in Sketch, all assets (or a chosen subset of assets) can be exported, formatted, and renamed with one click.</p> <p>There are a ton of workflow improvements to be discovered in Sketch—things like global text and layer styles, <a href="https://www.youtube.com/watch?v=DLQ1BAvJYNE">reusable elements</a>, square and layout grids, <a href="http://bohemiancoding.com/sketch/features/#mirror">iOS mirroring</a>, and a powerful <a href="https://gist.github.com/bomberstudios/7694497">third-party plugin system</a> (my favorite of which is this <a href="https://github.com/timuric/Content-generator-sketch-plugin">content generator plugin</a>).</p> <p>Sketch isn’t without its flaws and pain points. Being focused on interface design, there aren’t many fine-tuned controls for image editing or manipulation, which often has me jumping between Photoshop and Sketch. Brush tool fans: you’ll still be using Creative Suite for the time being, because Sketch has nothing to offer on that front. It’s not the best tool for things outside of interface design, and I’ve heard many people who do photorealistic or heavily-detailed icon work say that they still prefer Adobe’s offerings.</p> <p>While this can be seen as a positive or a negative, the <a href="http://bohemiancoding.com/about-us">Sketch team</a> is just four people. Small teams like that obviously can’t move as fast as a team like Adobe, but their support is top notch and personal. It’s still a young tool, so there are <a href="http://sketchisbest.tumblr.com">some funny bugs</a> that pop up every now and then, but Sketch is maturing really well, and version 3 has been an incredibly solid release.</p> <p>The prospect of changing design applications is intimidating, especially in fast-moving environments. It slowed me down at first, but ultimately led to a better, smoother design-to-development workflow. If you&#8217;ve got a small or internal project coming up, maybe take advantage of their free trial and see if it works for you.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/asBZy3ohndE" height="1" width="1"/>[mehr] (Quelle: A List Apart: The Full Feed)
14. Oct 2013
CSS Books &amp; CSS Figures
Today we're happy to add two more specs to the WHATWG stable, Books and Figures! These are specifications focused on CSS features. Books provides ways to turn HTML document into books, either on screen or on paper. Using Books, authors can style cross-references, footnotes, and most other things needed to present books on screen or [&#8230;][mehr] (Quelle: The WHATWG Blog)
20. Jul 2012
Relationship update on HTML Living Standard and W3C HTML5
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 [&#8230;][mehr] (Quelle: The WHATWG Blog)
8. Jun 2012
Validator.nu HTML Parser 1.4 Available
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 [&#8230;][mehr] (Quelle: The WHATWG Blog)
26. May 2012
The Future of the Web: My Vision (May 23, 2012)
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 [&#8230;][mehr] (Quelle: The WHATWG Blog)
1. May 2012
The Future of the Web: My Vision (May 1, 2012)
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 [&#8230;][mehr] (Quelle: The WHATWG Blog)
24. Apr 2012
Patent Policy
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 [&#8230;][mehr] (Quelle: The WHATWG Blog)
11. Apr 2012
WHATWG Weekly: Fullscreen dialog
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 [&#8230;][mehr] (Quelle: The WHATWG Blog)
29. Mar 2012
WHATWG Weekly: HTML canvas version 5 has arrived
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 [&#8230;][mehr] (Quelle: The WHATWG Blog)
14. Mar 2012
WHATWG Weekly: Path objects for canvas and creating paths through SVG syntax
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 [&#8230;][mehr] (Quelle: The WHATWG Blog)
7. Mar 2012
WHATWG Weekly: http+aes URL scheme, control Referer, …
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 [&#8230;][mehr] (Quelle: The WHATWG Blog)
8. Jan 2010
BITV mit Links zu HTML und CSS
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)
7. Jan 2010
BITV auf <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)
11. Dec 2009
Cross-Browser: es wird immer besser – oder doch nicht?
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)
7. Dec 2009
ECMAScript 5 verabschiedet
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)
2. Dec 2009
XSLT-Schulung von Linkwerk – von Kunden ausgezeichnet
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)
2. Dec 2009
Relaunch von <edition W3.de>

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

(Quelle: <edition W3.de> Neuigkeiten)
22. Nov 2009
Das neue JavaScript — EcmaScript 5 kommt
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)
20. Nov 2009
W3C sperrt Java aus
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)
18. Nov 2009
Canonical Link
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)
3. Nov 2009
Talk Semantic Web, auf semanticoverflow.com
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)
2. Nov 2009
Hilfe, mein Software-Agent hat Angst
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)
27. Oct 2009
GeoCities schließt…
&#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)