Feed aggregator

The Death of the Web Design Agency?

A List Apart - Thu, 04/17/2014 - 15:19

Others have gone as far to say that the very concept of a user experience-focused agency simply isn’t a long-term play, largely because of what the big folks are up to. Facebook and Google went on a design/product buying spree specifically because they needed to figure out how to own this thinking themselves, and other tech companies have followed. And more traditional industries, like insurance, media, and retail? They’ll develop robust in-house capabilities soon, if they haven’t already.

Ready to pack up your things and start a landscaping business? Not so fast.

Greg Hoy, Differentiate or Die?

In The Pastry Box Project today, Greg Hoy of Happy Cog talks honestly about why the first quarter of this year sucked for most web design agencies (including ours), assesses the new and growing long-term threats to the agency business model, and shares his thinking on what we in the client services design business can do to survive, and maybe even thrive.

Categories: Mobile learning

Cennydd Bowles on UX & Design: Letter to a Junior Designer

A List Apart - Thu, 04/17/2014 - 12:30

I admit it: you intimidate me. Your work is vivid and imaginative, far superior to my woeful scratchings at a similar age. The things I struggle to learn barely make you sweat. One day, you’ll be a better designer than me.

But for now, I can cling to my sole advantage, the one thing that makes me more valuable: I get results. I can put a dent in cast-iron CEO arguments. I can spot risks and complications months in advance. In the wager that is design, I usually bet on the right color. People trust me with their stake.

So, if you’ll humor me, maybe I can offer a few suggestions to speed you toward the inevitable.

Slow down

You’re damn talented. But in your eagerness to prove it, you sometimes rush toward a solution. You pluck an idea from the branch and throw it onto the plate before it has time to ripen. Don’t mistake speed for precocity: the world doesn’t need wrong answers in record time.

Perhaps your teachers exalted The Idea as the gem of creative work; taught you The Idea is the hard part. I disagree. Ideas aren’t to be trusted. They need to be wrung dry, ripped apart. We have the rare luxury that our professional diligence often equates to playfulness: to do our job properly, we must disassemble our promising ideas and make them into something better.

The process feels mechanical and awkward initially. In time, the distinction between idea and iteration will blur. Eventually, the two become one.

So go deeper. Squander loose time on expanding your ideas, even if you’re sure they’re perfect or useless. Look closely at decisions you think are trivial. I guarantee you’ll find better solutions around the corner.

Think it through

We’d love to believe design speaks for itself, but a large part of the job is helping others hear its voice. Persuasive rationale—the why to your work—is what turns a great document into a great product.

If you haven’t already, sometime in your career you’ll meet an awkward sonofabitch who wants to know why every pixel is where you put it. You should be able to articulate an answer for that person—yes, for every pixel. What does this line do? Well, it defines. It distinguishes. But why here? Why that color? Why that thickness? “It looks better” won’t suffice. You’ll need a rationale that explains hierarchy, balance, gestalt—in other words, esoteric ways to say “it looks better,” but ways that reassure stakeholders that you understand the foundations of your craft. Similarly, be sure you can explain which alternatives you rejected, and why. (Working this through will also help you see if you have been diligent or if you’ve been clinging to a pet idea.) This might sound political. It is. Politics is just the complex art of navigating teams and people, and the more senior you get, the more time you’ll spend with people.

Temper your passion

Your words matter: be careful not to get carried away. Passion is useful, but you’ll be more effective when you demonstrate the evidence behind your beliefs, rather than the strength of those beliefs. Softer language earns fewer retweets but better results. If you have a hunch, call it a hunch; it shows honesty, and it leaves you headroom to be unequivocal about the things you’re sure of.

Similarly, your approach to your work will change. Right now design is an ache. You see all the brokenness in the world: stupid products, trivial mistakes, bad designs propped up with scribbled corrections. That stupidity never goes away, but in time you learn how to live with it. What matters is your ability to change things. Anyone can complain about the world, but only a good few can fix it.

That fury, that energy, fades with time, until the question becomes one of choosing which battles to arm yourself for, and which to surrender. Often this means gravitating toward the biggest problems. As you progress in the field, your attention may turn from tools and techniques to values and ethics. The history of the industry is instructive: give it proper attention. After all, all our futures shrink with time, until finally the past becomes all we have.

You’ll come to appreciate that it can be better to help others reach the right outcomes themselves than do it yourself. That, of course, is what we call leadership.

Finally, there may come a point when you realize you’re better served by thinking less about design. Work and life should always be partially separate, but there’s no doubt that the experiences you have in your life shape your work too. So please remember to be a broad, wise human being. Travel (thoughtfully) as much as you can. Read literature: a good novel will sometimes teach you more than another design book can. Remind yourself the sea exists. You’ll notice the empathy, sensitivity, cunning, and understanding you develop make your working life better too.

But you’re smart, and of course you realize this is really a letter to the younger me. And, alongside, it’s a lament at my nagging sense of obsolescence; the angst of a few grey hairs and the emerging trends I don’t quite understand. Which is mildly ridiculous at my age—but this is a mildly ridiculous industry. And you’ll inherit it all, in time. Good luck.

Yours,
Cennydd

Categories: Mobile learning

This week's sponsor: Harvest

A List Apart - Wed, 04/16/2014 - 16:48

Have you ever billed hourly? A List Apart is brought to you this week by Harvest, a beautifully crafted time tracking tool for creative shops.

Start a trial before the year slips away.

Categories: Mobile learning

Top 5 Ways Companies Are Using Mobile Learning Technology

Mobile learning from MLearnopedia - Wed, 04/16/2014 - 13:39
'If engaged in the learning industry long enough, you gain a keen understanding and appreciation for the direction that learning is headed. Mobile Learning Developing Mobile Learning eLearning on mobile

Brought to you by: Mobile Learning
Categories: Mobile learning

Podcast: No Kid Hungry Explains How Text Messaging Connects Families to Free Lunches

Mobile learning from MLearnopedia - Tue, 04/15/2014 - 17:29
'The real power of mobile isn’t in mobile web pages or applications – it’s in text messaging. In After collecting and analyzing data from their programs across the country, Wilson realized that the families who were in critical need of their resources didn’t have access to the Internet or own smartphones. ”We

Brought to you by: Mobile Learning
Categories: Mobile learning

4 Ways to Nail Your Mobile Learning Game Plan at ASTD 2014

Mobile learning from MLearnopedia - Tue, 04/15/2014 - 11:47
'After setting your goals for enterprise mobile learning, learn about how to follow through with them at an event of this size. Conferences Mobile Strategy ASTD 2014 ASTD ICE mobile learning goals

Brought to you by: Mobile Learning
Categories: Mobile learning

Style Guides On Parade

A List Apart - Fri, 04/11/2014 - 16:00
» Style Guides On Parade

If you loved this week’s “Creating Style Guides” piece by Susan Robertson, you’ll thrill to Susan’s follow-up posting, on her personal site, of style guide links galore!

Categories: Mobile learning

Pew Study Shows that Texting Outpaces All Other Cell Phone Functions

Mobile learning from MLearnopedia - Fri, 04/11/2014 - 15:30
'Today’s cell phones allow people do everything on the go: check their bank account, send emails, take photos, look up their favorite restaurants. But a recent Pew Report shows that when it comes to a phone’s various functions, users in almost every age category overwhelmingly prefer to use their phones for text messaging.

Brought to you by: Mobile Learning
Categories: Mobile learning

#Diabetes, Sue Townsend, Easter a personal mix

Mobile learning from MLearnopedia - Fri, 04/11/2014 - 10:30
'This morning sad news was announced as the author Sue Townsend died (well known for her Adrian Mole books, but all round prolific and wonderful writer). really enjoyed the book. As I read the back end of the book two facts sparked an extra, personal interest: blind, kidney transplant. That fact scared the hell out of me. Life is in the living.

Brought to you by: Mobile Learning
Categories: Mobile learning

University Business Magazines Ranks Mobile Commons as a Top Product

Mobile learning from MLearnopedia - Fri, 04/11/2014 - 00:27
'University Business Magazine has named Mobile Commons as one of their Readers’ Choice Top Products in 2013 , alongside the iPad. The magazine, which covers news and advances in higher education management, draws their annual ranking from nominations that come directly from educators and administrators.

Brought to you by: Mobile Learning
Categories: Mobile learning

This week's sponsor: New Relic

A List Apart - Thu, 04/10/2014 - 16:38

Thanks to our sponsor, New Relic.

New Relic helps web and mobile app developers improve app performance by showing you bottlenecks and making it easy to spot code bugs. Do your apps a favor, try New Relic.

Categories: Mobile learning

Matt Griffin on How We Work: My Life with Email

A List Apart - Thu, 04/10/2014 - 12:30

I’d like to take a moment to address something decidedly unsexy. We all do it. And it’s never pretty. You guessed it: I’m talking about email.

No, I don’t mean responsive design approaches for email newsletter templates. Nope. Not even that much fun. I’m talking about reading and responding to that everyday, humdrum, never-ending stream of communication that flows through the inscrutable ether to your very own inbox.

Staying in control of your life with email is a challenge (look no further than your friends’ triumphant cries of “inbox zero!”). When you run your own business, as I do, there is every motivation to always stay on top of these messages. It is, after all, your thing. You own it. Shouldn’t you be addressing every issue as it crops up, and responding with lightning speed?

This lifestyle really caught up with me a year or so ago. It was affecting my sleep and productivity, and saddling me with all kinds of extra cognitive overhead. It was no fun at all. Over the course of several months, I worked at establishing rules and procedures for email that helped me regain my sanity and improve the quality of my workdays (not to mention my weekends). In no particular order, here they are:

We don’t need no stinking badges

One of the first and most obvious things I did was turn off notifications and badges for email. Turning on email notifications is like asking to be interrupted by anyone at any time, no matter what you’re doing. If you must have notifications, consider adding essential people to a VIP list, and hiding all other notifications. Ask yourself, “who would I need to drop everything for, no matter how important my task is at that moment?”

Filters, filters, filters

OMG, filters, guys! Filters that route the endless stream of notifications (for instance Basecamp updates, or emails from your ticketing system) are great. They keep things organized neatly so that you can address like emails all at once. Since these sorts of emails will often be project-specific—this also makes it easier to remember to track your time while you’re doing it (hint, hint).

More apps!

On the weekend, I really don’t want to accidentally open a troublesome work email. To keep a clear distinction between my personal and work emails, I started using a separate app for personal email. Personally, I’m quite happy with Mailbox, but I also know some smart folks who like Boxer. I’m sure there are plenty of other great ones, too (reader comments, activate!).

Say when

Just like the ticket queue of tasks, you’re never really finished answering emails. To help me focus on my home life when I’m not at work, I use a timed “do not disturb” setting in iOS to make sure that I get no notifications of anything between 7 p.m. and 7 a.m.

Save your brainpower

I find that my mind is sharpest and I do my best work in the morning, and yet I used to start each work day with email—a task that arguably requires the least of my creativity and mental acuity. So now I set aside the first hour of my day for something challenging. I often write these columns during that time slot. Or tackle a particularly gnarly IA or design problem. But email? Email can wait till 10 a.m.

It’s all in the timing

And when you’ve finished that batch of email responses and are ready to return to your work? Close that email client, friend! Don’t open it back up until you’re ready to dedicate your attention to it again. Otherwise, it’s just a distraction. I find it useful to set times for checking my email throughout the day, for instance 10 a.m., 1:30 p.m., and 4 p.m.

Inaction leads to rumination

Ever check your email while you only have a few seconds or minutes to spare? You get some troublesome message, but don’t really have time to read through it carefully or respond. Then you spend the next few hours with that static buzzing around your brain, distracting from whatever it is you’re working on. I now have a simple rule: if I don’t have time to sit down and directly address whatever messages may be waiting for me, I don’t check my email. Making reading and responding to email a dedicated task keeps you out of that vague cognitive limbo, and can reduce the anxiety of opening the inbox.

Expectations for the medium

Remember: email is asynchronous communication. By its nature, it encourages a lag in response, and everyone expects that. If there’s a real emergency, someone will doubtless pick up a phone. Email can wait a few hours, even a day. The world won’t explode, and you won’t get fired. Give those messages their proper place in the hierarchy of your day.

And on and on

There are doubtless many other ways to keep the great beast email under control. These are the ones that have helped me hold on to my sanity and reduce email-induced anxiety. These little strategies make me happier and more productive every day.

How about you? What are your email troubles? What have you tried that’s worked? Get in those comments, people, and share what you’ve learned. Something tells me we could all use a little help in this department.

Categories: Mobile learning

Complacency, failure, improvement cycle and #pearltrees #pkm14

Mobile learning from MLearnopedia - Thu, 04/10/2014 - 10:00
'For what ever reason, I seem to have a personal complacency => failure => improvement cycle. Which means that every few years something that I was good at turns into mush. Messed up more then one presentation The latest one concerns presentation skills. Again feedback forms). This does not happen. Either present, or offer booklets I guess).

Brought to you by: Mobile Learning
Categories: Mobile learning

Easy Color Contrast Testing

A List Apart - Wed, 04/09/2014 - 12:30

We have plenty of considerations to design for when crafting web sites. Web accessibility is not a new design consideration, but is still very important, no matter the size or speed of device we’re testing on. The Web Content Accessibility Guidelines (WCAG) tells us our content should be distinguishable and requires we “[m]ake it easier for users to see and hear content including separating foreground from background.”

We know that our color contrast ratio should be 3:1 for non-decorative text, sized larger than 18-point or larger than 14-point if bold. Text smaller than that should meet a contrast ratio of at least 4.5:1.

Maybe you have amazing eyeballs that can help you recognize contrast levels. If, like me, you do not have magical corneal calculators, then you probably have utilized one of the tools out there to check contrast, such as: WebAIM’s color contrast checker, Snook’s contrast slider, Check my colors URL input check, or a WCAG checker add-on for Firefox.

I recently switched to using Chrome’s Accessibility Developer Tools built in contrast checker and I love it. Take a look at the audits being run by the tools and let’s look at how to begin using it once installed.

Load up the website you’d like to check and bring up the Developer Tools. I’ll pick on myself and use my own site for this example. Once open, click over to the “Audits” tab and make sure “Accessibility” is checked. Click “Run”.

Expand the “Text elements should have a reasonable contrast ratio” section. This will show you the HTML of the elements that don’t have sufficient contrast. Identify one to examine further.

Select the chosen offender in the browser and inspect it. If you can’t see the contrast values, use the menu to pull up the “Accessibility Properties.” You’ll see the current contrast ratio of your element. You’ll also see a suggested color value pair to match the WCAG AA or AAA recommendation. Select the swatch to the right of those values to see the preview of that change. In this case, we’ll see what grey we’d have to adjust our background to in order to keep the white text.

As you can see in this second example, I could make the date text darker to meet the guidelines, which is very helpful in making a fast change.

When it’s this quick and simple to check contrast, there’s no reason not to add this accessibility test into our workflow.

Categories: Mobile learning

Proceedings from recent #MOOC conference

Mobile learning from MLearnopedia - Wed, 04/09/2014 - 10:27
'Just a quick post linking to a set of conference proceedings worth reading. eMOOC2014 proceedings of the research track (European MOOC summit in Switzerland, February 2014) which are fully online here. But the proceedings link to some magnificent global MOOC cases and experiences and lots of papers on learner drop-out and retention.

Brought to you by: Mobile Learning
Categories: Mobile learning

Filtering for Future ProFessional Frontiers #pkm14

Mobile learning from MLearnopedia - Wed, 04/09/2014 - 09:40
'As the Personal Knowledge Management (PKM14) course moves into its second week, all the participants are asked to filter their social media / their networks. We are suggested to use more advanced filters: e.g. using feeds from people or/and groups, using automated filters of choice (e.g. Again. mLearning, learning analytics).

Brought to you by: Mobile Learning
Categories: Mobile learning

The Heartbleed Bug (or: You Should Consider SSL Unsafe for a While)

A List Apart - Tue, 04/08/2014 - 19:00

If you run a server that uses SSL and the OpenSSL library, you need to update it. If you regularly visit a site that uses SSL (and I can’t imagine you don’t), you should try to limit your visits today. Once the dust has settled, we should all change our passwords. Pretty much everywhere.

In short, yesterday the OpenSSL Project released an update that addresses a vulnerability in the OpenSSL library. Officially named CVE-2014-0160, the Heartbleed bug has been around—and un-identified—for a long time. It’s not known if the vulnerability has been exploited, but it’s theoretically possible that someone has been snooping on transmissions we thought were secure. It’s very likely that bad guys are snooping on un-patched servers now, so be careful which services you log in to today.

Visit Heartbleed.com for a lot more information, and anyone running a server should consider these words from Cody Sorland:

Ubuntu servers running nginx/SSL? sudo apt-get update && sudo apt-get dist-upgrade sudo restart nginx Do it now. #heartbleed

— Cody Soyland (@codysoyland) April 8, 2014

Be careful out there.

Categories: Mobile learning

Creating Style Guides

A List Apart - Tue, 04/08/2014 - 12:00

Several years ago, I was working on a large, complex application. It was a bit of a legacy project: many different designers and front-end developers had come and gone, each appending a new portion to the sprawling application. By the time I arrived, the CSS was huge, the styles were varied, and it took a lot of effort to find out if anything was reusable.

During all this, I discovered style guides—a way to control markup and CSS so neither veered out of control or ballooned. In jobs since, I’ve seen firsthand how style guides save development time, make communication regarding your front end smoother, and keep both code and design consistent throughout the site. It has been a revelation, and in this article, I want to show you how to build and maintain them, too.

What is a style guide?

To me, a style guide is a living document of code, which details all the various elements and coded modules of your site or application. Beyond its use in consolidating the front-end code, it also documents the visual language, such as header styles and color palettes, used to create the site. This way, it’s a one-stop place for the entire team—from product owners and producers to designers and developers—to reference when discussing site changes and iterations. Several companies have even put their guides online; Starbucks is the most well known of the bunch, but others exist.

Starbucks style guide.

(I should also mention that what I call a style guide, some people call a pattern library. Many of the guides I reference use the term style guide, but pattern library is gaining in popularity.)

When I started working at Editorially, one of the first things I did was tackle the style guide. Creating the guide was probably the most useful thing I’ve ever done when settling into a new job: it forced me to go through every single line of CSS and read it, digest it, understand how it was used, and then document it for my own, and the team’s, future reference. In addition to catching inconsistencies and errors by poring through the CSS, if I didn’t understand how certain pieces of code were being used, I annotated the guide with questions (which my teammates graciously answered).

Why should I use a style guide?

As your team grows and changes over time, your style guide will help you in several ways. First, creating your guide will take some time up front, but I’ve found that this pays off with faster build times for new sections and pages, because anyone joining an ongoing project can refer to the guide for the exact styles to use.

Imagine starting a page build with information like this from the South Tees Hospital guide; a donation box would be done in seconds.

Second, a guide allows us to standardize the CSS, keeping it small and quick to load. By using the guide as an inventory of modules and code, both designers and developers can quickly see if new designs deviate from established standards, and decide as a team if it’s worth expanding the codebase or if something already written is easily extended. When you have no guide, this is impossible, which in my experience usually means that new styles are written—resulting in bloated CSS.

Third, design consistency is easier to maintain, as the designer can look in one place to reference the site’s components and ensure a cohesive look and feel throughout. This is especially helpful on larger teams and at enterprise-level companies where you may have an entire team of designers working on the site. And when design consistency is maintained, the codebase is also kept smaller.

Yelp clearly states how buttons are used, keeping button styles consistent across the site.

Fourth, communication becomes clearer as well. When I built out pages in a large-scale project and passed them off to the designer, she used the language of the various classes in the guide to ask for changes. This meant that we didn’t have any confusion on either of our parts as we sped through revisions. It also gave the entire team a shared vocabulary, like the names of modules, to use in talking about the designs once they were coded.

The final benefit I’ve found is that you can use your guide to do a quick QA pass. The guide may not be identical to the pages you eventually build out, but it can point out issues you may have in various browsers. By tackling these early on, you’ll avoid them in later testing.

Steps to build out your guide

Below, I’ll take you through starting your own guide, based on my first few weeks at Editorially. (Because when I work on a project without a guide, I’m soon jonesing to make one—just ask my colleagues).

Assemble your site’s basics

Start your guide with some of your site’s foundations. A foundational element may include the color palette, your grid layout system, or the basic type styles for headers and body text: whatever you feel are the very basic elements to create a page. For Editorially, the most foundational part of our site was the color guide, so I began with that and went from there. I created an HTML document with the markup, linking to the application CSS, so any CSS changes would be automatically reflected in the style guide.

When you look at the style guide created by Yelp, you can see how it starts with the basics: typography, grid, and colors, adding more patterns as it goes along.

Yelp. Add in more patterns

A pattern is any self-contained set of markup and styles to make some of your site’s basic objects, like a call-out box used repeatedly, buttons, or the way you lay out a list of links horizontally. At Editorially I documented all the variations possible of button and link styles. So go ahead and add the exact markup you need for each element to your guide.

For example, for a button in the Editorially guide, I simply put <label for="btn" class="btn" href="#">.btn <input type="submit" name="btn" value=".btn" /></label>. And because we link to the same CSS as the application does, the CSS shows correctly in the style guide. Should we change the .btn style, the style guide would change as well.

Keep going through your site and add in patterns as you see them; you may use particular layouts over and over, or a media-object pattern, or a vertical list pattern. Below is an another example from South Tees Hospital, showing some of their patterns for what they call feature blocks. Look for similar things on your own site to document in your guide.

South Tees Hospital.

This is also a good time to ask your team what else would be helpful to have in the style guide. Share it, let them take a look, and hopefully they’ll help you fill out all the patterns and modules needed. Don’t forget to have the entire team help you round it out, as it’s a resource for everyone.

Document interactivity

If possible, add the bits of interactivity that your site uses, such as dropdowns, modals, or tooltips, which are small hovers with helpful text that gives the user more information. This lets your team see not just the static versions of these things, but the animations as well. So when you’re looking at the guide and hover over or click on items, they’ll actually act as they would on your site.

Tooltips in the Editorially guide. Make maintenance easy

If you have to do extra work to update your style guide when making changes to your look and feel, the likelihood of it staying up to date is pretty slim. I’ve said it a few times now, but that’s why we linked the Editorially guide to the same CSS as the application—that way, we didn’t have to manually update the guide ourselves. It can be difficult to make updating the guide a priority, but maintenance is critical. Depending on how quickly you iterate on your site or application, you should check up on the guide as a regular task, whether it’s weekly or monthly. When you’re making changes to your site, update your style guide as part of the workflow.

Iterate your guide

Once you have the bulk of your site’s or application’s components listed in your guide, you’ve got a wealth of tools to make it even more handy. As I built out the style guide for Editorially, a colleague pointed out the fantastic tool by Filament Group, X-rayHTML, which is a small JavaScript library to help you build out documentation. X-rayHTML takes the styled objects on your page and generates a nicely formatted code block below them, without any further code from you. You can also add prism.js for syntax highlighting, which color-codes the code for greater readability.

A look at the Editorially style guide with X-rayHTML at work.

If you’re interested in automation, there are other tools that can make creating the guide even smoother. Two of these include KSS and Hologram. Both tools use things like commenting or YAML inside your stylesheets in combination with something like Ruby to automatically generate your style guide. It would take some work to go back and retrofit your stylesheets with the appropriate comments or YAML for these approaches, but you’d save time in the long run, as these tools make maintenance much, much easier. In addition, A List Apart has put their pattern library on GitHub and featured a blog post on its creation, demonstrating yet another method of building a style guide. The possibilities of what you can do are far greater than what I’ve outlined here; you might poke around to see what may be most helpful for you and your team.

Using the guide

Phew. You’ve done all this work and you’ve created this guide, so now what? How do you get people to use it? The first step is to talk about it. If a new team member comes on board, introduce her to the guide as a way of orienting her with the site, since the guide encompasses so much of both the visual and code languages of your front end.

As long as you’re iterating on a site or application, your style guide will never truly be finished. But having something documented early on, and showing it to teammates and getting their feedback, is a huge help. Involving the whole team in building the guide also makes it feel more like the team’s guide—and gets everyone invested in maintaining and using it on a regular basis.

We’ve made the Editorially guide available as both a public repo on GitHub and online. This was very much a work in progress and an internal team document, so we’ve also got notes, patterns, and a lot of messiness. But the reason for showing it is to reinforce the fact that a style guide doesn’t have to look perfect to be useful. Despite the mess, all of this was incredibly helpful for me and other team members as we continued to work on the application.

So, are you convinced? Are you wishing you had a style guide for your site or application? It will be well worth the effort: make the time, get your team on board, start the build—and be rewarded with a document that speeds up the discussion and development of your site.

Categories: Mobile learning

The Z-Axis: Designing for the Future

A List Apart - Tue, 04/08/2014 - 12:00

For years we’ve thought about the web as a two-dimensional space filled with pages that sit side by side on a flat, infinite plane. But as the devices we design for take on an increasingly diverse array of shapes and sizes, we should embrace new ways of designing up and down. By building interfaces using a system of layers, we solve tricky design problems, flexibly adapt to a variety of screens, and create new patterns that will point the way to future interactions.

In geometric terms, the z-axis is the vertex that measures space above and below the x- and y-axes. Translation for those of us who napped through geometry: it’s how we describe panels and layers that sit above or below one another.

Designing on the z-axis simply means incorporating three-dimensional physics—as represented by the z-axis—into our interface designs. Not the faux-depth of skeuomorphic text shadows and button highlights, but an interface made of components that exist on distinct layers and move independently of one another.

As Andy Clarke has noted, the page is an outdated metaphor for what we’re designing today. Unlike the permanence of ink on paper, a website is a series of dynamic views that can occur in many combinations. Applications require us to consider numerous happy and unhappy paths, and even static marketing sites need reusable design components that can adapt to different content needs.

By using the z-axis to place interface elements above or below one another, we can create better design systems that are more flexible and intuitive to use.

Using the z-axis to solve design problems

While juggling the constraints of making an interface work across many different screens, I often encounter the same problems. Where do I put this? How do I make this effective for touchscreens? What can I show right away, and what can I hide?

The answers aren’t easy, but fortunately we can count on the z-axis to be there when extra pixels aren’t. Got an options panel that just won’t fit? Trying to add filters but the excess UI clutter doesn’t seem worth it? When you’re running out of space and searching for a clever solution, remembering that you have three dimensions to design in can save the day.

Creating an interface that seamlessly works across the z-axis requires two important elements: layers and transitions.

1. Layers

Incorporating layers is the key to designing on the z-axis, since layers are the way we differentiate levels above and below one another. A layer might contain a single UI element that sits above the rest of the view, or it might be a full screen that appears and disappears as necessary. However you incorporate layers, each should have a purpose—a reason it exists—and be used consistently throughout your site in a way that helps users better understand your design.

A panel that covers up the entire interface, for example, should be one of the most important functions on a site. On the other hand, an option in a secret panel that slides out from behind another object should relate to whatever sits above it, but be less important.

Menus

Generally speaking, the higher something sits on the z-axis, the more important it is. Primary navigation menus are usually placed on a higher level than other elements; they might pop over the rest of the view, they might stick to the top of the screen, or they might be accessed by zooming out to a larger menu presentation.

Teehan + Lax takes this to the extreme with the menu overlay on its website. It’s more than a popover; it’s like a page takeover. Look at our menu! it shouts. The sliding animation combined with a new screen layer grabs the user’s attention, while huge font sizes and a larger-than-usual menu of links deliver more content than a typical primary nav bar and (probably) justify the need for a separate layer.

Do I love this bold menu presentation? Yes. Do I think it’s a best practice we should incorporate into every site we build? No way. Not every site needs that much dramatic flair.

But I love how this inspires me to think about a menu as a piece of content in and of itself, and not just more interface cruft. Teehan + Lax highlights the act of presenting a menu to the user and how it can be more than popping up or sliding over from the left—it can be an opportunity for surprise and delight.

Action buttons

Primary action buttons, such as checking in or adding a new post, are often placed above other elements on the z-axis. It’s easy to tell what an app thinks is its most important feature when it’s sitting on top of everything else. Just take a look at Facebook’s chat heads.

Right now, Facebook clearly thinks that messaging is its most important feature. (If you’re unconvinced, Facebook also has a separate Messaging app, and recently paid $19 billion for What’s App.) Since layers allow elements to remain fixed in one place while everything else moves around them, floating action buttons are an easy way to make them more prominent without taking up a lot of valuable screen real estate.

The z-axis gives Facebook an easy way to keep messaging front and center, and even if I don’t like tapping on the disembodied faces of my friends and family, it seems to be working. For clients who want a button to “pop” a bit more, using the z-axis to give it its own layer is one of the more elegant possibilities.

Storytelling

Objects on different layers of the z-axis can move at asynchronous speeds during scrolling. This effect—usually called parallax—was pioneered in video games, but it’s become quite popular in interactive design. When objects move at different speeds, it creates the appearance of depth and simulates the passing of time, making parallax a powerful tool for online storytelling.

Superfluous use of parallax as a trendy eye-catcher has been rightfully criticized, but the ability to move layers independently of one another allows us to animate stories on the web in a way that hasn’t been as effective without the use of video. Sites like Let’s Free Congress and Inception Explained use asynchronous scrolling to turn what could have been flat infographics into visual narratives. By breaking elements apart using layers, each thread can unfold at its own speed while the user controls the pace of the action.

Web designers have always worked within the confines of flat, pixel-based screens, forcing complex interactions onto two visual axes. Layers on flat screens are a hack, but an important one; they’re the first step toward the true multidimensional interactions that are only a few years away. By creating layered patterns in our interfaces now, we help prepare users—and ourselves—for what’s ahead.

2. Transitions

When you use layers in an interface design, it’s important to include animations that smooth the transitions between them. Animated transitions serve several important functions: they help soften what could otherwise be a jarring moment of change, they describe where you came from and where you’ve arrived, and they provide cues about how information on the new layer relates to everything else.

Sliding

Sliding is one of the most common animated transitions because it’s relatively easy to execute and simple to understand. Navigation menus, hidden panels—just slide them out quickly whenever you need them, right? But like anything “simple,” sliding requires more care than you might expect.

The ubiquitous left-hand menu, used in many mobile apps including Gmail, is a perfect example. When activated, Gmail’s menu doesn’t slide anywhere; it’s actually the main window that slides to the right, revealing the menu on the left underneath your inbox.

The distinction is important, because the ability to see the first few words of each subject line keeps the inbox functional even when the menu is engaged; without that persistence, there’s little point to the inbox remaining there at all. Mobile websites that seek to mimic this interaction should take note—sliding a left menu over the top of a webpage usually feels clunky and intrusive compared to sliding the main view over instead.

You can also slide existing elements out of view to reveal hidden panels. Tweetlist slides the keyboard down to show additional tweet options like geotagging or attaching a photo. It’s a clever way to display secondary features that don’t need to be visible at all times, and using the back of the keyboard reinforces the relationship between these options and sending a tweet.

Zooming

Zoom animation has been around for a while, but its frequent use in Apple’s iOS 7 has increased both its popularity and its infamy. Some people have said the zooming used throughout the operating system—particularly when opening and closing apps—makes them nauseous. While this may be the case, it’s worth understanding the different ways we can use zooming to transition from one layer to another, and why some types of zoom may be more stomach-churning than others.

Enlarging or shrinking single objects has been a common animation in the Apple universe since the release of Mac OS X and the introduction of the dock. It naturally found its way into the mobile world on the iPhone, and users quickly grew accustomed to tapping a photo and zooming into it to see more detail.

In the case of photos, zooming is a simple illusion created by enlarging the image. Everything around the photo remains in place; only the photo itself moves.

The zoom effect used in iOS 7 is more complex. It works by moving the “camera” in and out as you open and close apps so that everything on the screen changes, not just one object. When you close an app, for example, the app window shrinks down into its icon on the homescreen. Watch the background behind the window and you’ll see all the other homescreen objects zoom back into the view as well.

This key difference—zooming the camera rather than a single element—creates a much more immersive illusion. It shifts the viewer’s perspective to a new level on the z-axis. That simulated perspective-shift adds to the wow factor by introducing an element of super-realism: it mimics real-world physics, while producing an effect that would be impossible in real life. It’s no wonder designers are eager to take advantage of the possibilities it offers, in spite of the potential side-effects.

This design experiment from Creative Dash shows how zooming the camera all the way out allows us to use the liminal space around a window. Our canvas is both deep and wide, and this takes advantage of both—though the extreme zoom depth would probably make quite a few users feel sick.

Foursquare has used a much more subtle version of zooming the camera to reveal map details. You don’t travel very far forward, but the zoom-in reinforces the notion that you’re going to a deeper level of information.

Whether you apply zoom to a single object or an entire view, it’s important for the animation to be consistent with the information hierarchy you’re using. When you move the camera out, you should be at a higher level, while zooming in should provide more detail.

Other transitions

Sliding and zooming are two of the most common animated transitions used today, but there are other options, including flipping or folding.

Three-dimensional objects have two (or more) sides, but most user interfaces are like the moon: they have a “light” side that’s always visible and a “dark” side we never see. Flipping an object over creates a new visual space that’s easy for users to understand. The only downside? Flipping is, well, flipping slow.

While flipping is sometimes applied to create a more magazine-like feel, 180 degrees is a big transition; it often feels slow and disruptive. In contexts where speed is critical, the time a flip adds to interactions usually isn’t worth it. That said, if deployed in the right place in the right way, it could be flipping fantastic. Card-based layouts offer plenty of opportunities to flip objects over and reveal additional information.

What comes next

Gesture-based command centers, holographic interfaces—whatever technology lies over the horizon, we’ll be better prepared to adapt our skills if we understand the principles of designing for information, not just visual tricks for laying things out with boxes and color. Just as print designers once learned to take their talents to the web, we need to learn to take our talents beyond the screen—and getting comfortable with the z-axis is a great place to start.

Categories: Mobile learning

3 Examples of How to Use Google Glass for Performance Support

Mobile learning from MLearnopedia - Tue, 04/08/2014 - 11:03
'Firefighters, surgeons, and medical professionals are some of the first to pilot Google Glass to help them do their jobs better. Industry News Mobile Devices Google Glass performance support

Brought to you by: Mobile Learning
Categories: Mobile learning
Syndicate content