web

User Experience Interface Design

Welcome to the UX/UI Design Fundamentals Prep Course for the Bitmaker Labs User Experience & Interface Design 12 week immersive.

This course is intended to develop you as a strong Product Designer with front-end development knowledge. You’ll examine the fundamentals of user-centred design, including user research, information architecture, interaction design, UI design, and usability testing. By the end of the course, you will be able to design and build basic prototypes using Adobe Illustrator, HTML, CSS, basic JavaScript and jQuery.

Structure of this Prep Course


There are five main parts to this prep-course. They are not intended to replace the actual curriculum, but are just here to get you started. It’s essential that you complete each part in order:

Part 1: An Introduction

Part 2: Tools of the Trade

Part 3: Researching Design

Part 4: Learning the Basics of Code

Part 5: Design and Code Your First Homepage

Part 1: An Introduction


Once the course gets started, we’ll have a lot to cover, so it’s important to get a good understanding of the fundamentals to start strong.

While you complete this prep course, you might have questions and may need a hand— that’s awesome. These are three resources to help you out.

Your most important support resource: us  each other


Get to know your classmates, and work through designing things together. That’s what the entire course is about. Connect through Twitter, Facebook, or Google+. Open communication is key.

Feel free to reach out to @bitmakerlabs or @tailoredUX with the hashtag #DesignPrep for questions about this prep course over Twitter. We’ll make sure you’re using your resources, but will be happy to point you in the right direction and help out along the way.

If you have questions about enrolling in the course, or find yourself having a hard time with the prep course, don’t hesitate to reach out to Bitmaker Labs (design@bitmakerlabs.com) or tailoredUX (design@tailoredux.com) with the subject “Design Prep”.

Part 2: Tools of the Trade


We’ve broken down this section of the tutorial between all the tools you’ll need to know to make sure you’re well equipped with a jump start into getting down to design & development from Day 1.

Part 3: Researching Design


So what is UX?

The definition of User Experience Design, UX, or Experience Design, can be really controversial. UX is a way of thinking, can involve (but doesn’t necessarily have to) use “Design Thinking” (which is a major topic in and of itself), and can be approached in a lot of different ways.

During the course, we’re going to focus on practical applications of “UX” to web and mobile apps, and cut through the fuzziness of the meta conversation around UX. Our definition for UX is through the perspective of its’ application in designing software, or digital products.

In preparing for this, we will research and reflect ourselves on what we believe the definitions are for User Experience, and the disciplines that surround UX that are practiced in their own right:

Section 1: User Experience Design

Section 2: User Research

Section 3: Information Architecture

Section 4: Interaction Design

Section 5: User Interface Design

Section 6: Usability

Your first task is to research and write about these elements of UX Design:

Research on each of these topics, and structure your findings in any way you’d like.

But do write them down on a piece of paper, or post-its, or a notebook.

Then write a series of blog posts on Medium with your findings. Take pictures of your research and include them in your posts.

To help you with structuring your topics, and get you thinking about questioning design, here are the topics of your blog posts. The ultimate point is to take away the ambiguity so that we’ll all be talking the same thing when we kick off the course, and actually tangbile conclusions to with each other.

Blog post #1: User Experience Design


What is UX? Who defines UX? Whose job is “UX Design”? Are there “UX Designer” jobs out there? What are the differences between them? Use images in your post talking about this, and write about them.


See Gube, Jacob (2010). What is User Experience Design? Overview, Tools and Resources. Published in Smashing Magazine http://bit.ly/1iRrob9

Blog post #2: User Research


What is User Research? Are there any jobs dedicated to solely User Research? What does a User Researcher do for product design?


See Kuniavsky, Mike (2003). Crafting a User Research Plan. Published in Adaptive Path http://www.adaptivepath.com/ideas/e000107/

Blog post #3: Information Architecture


What is Information Architecture? What’s a job description for an Information Architect? What does an Information Architect do day to day? What does Information Architecture look like? Use images in your post talking about this, and write about them.

See Wodtke, Christina (2009). The Elements of Social Architecture. Published in A List Apart. http://alistapart.com/article/theelementsofsocialarchitecture

Blog post #4: Interaction Design


What is an interaction Designer? What’s the job description of an Interaction Designer? What does an Interaction Designer do day to day? What does interaction design look like? Use images in your post talking about this, and write about them.


See Maier, Andrew (2009). Complete Beginner’s Guide to Interaction Design. Published in UX Booth. http://www.uxbooth.com/articles/complete-beginners-guide-to-interaction-design/

Blog post #5: UI Design


What is UI Design? What does a UI Designer do day to day? What does UI Design look like? Find examples of 5 beautiful home pages for design agencies. Find examples of 5 beautiful home pages of designers. Use images in your post to reflect on why you liked them.

See Usability.gov (2011). User Interface Design Basics. Published on Usability.govhttp://www.usability.gov/what-and-why/user-interface-design.html



Blog post #6: Usability


What is Usability? Whose job is it to manage the usability of an application? What’s the difference between “User Research” and “Usability”? What are the different types of usability testing you can carry out? Hint: start with Heuristic Testing.


See Nielsen, Jakob (2012). Usability 101: Introduction to Usability. Published in NNGroup.com. http://www.nngroup.com/articles/usability-101-introduction-to-usability/

Note: your research skills, and the way you approach thinking about design is the #1 thing that will help you be successful in this course. These blog posts have one real purposes: challenge your research skills and how you communicate your work.

We’d like you to publish each blog post on Medium and share with your peers, and with us over Twitter.

Part 4: HTML & CSS


We don’t like to think of things in terms of hours, or tasks. We’d just like you to take the time to really dive into, and have fun with a web environment that teaches HTML & CSS.

Our UX/UI Fundamentals course will cover the same concepts that are introduced in this Code Academy course. The magic will be in applying them to real, hands on projects with a design focus.

To prepare, CodeAcademy has a great interactive tutorial to run you through the basics:

http://www.codecademy.com/tracks/web

Completing this code academy prep course is mandatory to start our program. Send section completion screenshots to design@bitmakerlabs.com

Part 5: Design & Code Your First Homepage


After you’ve completed the HTML/CSS course on CodeAcademy, you should be familiar with the basics of how to build a profile page for yourself.

1. Create a narrative

Your profile page should answer the following questions:

i. Who are you? Where are you from? 
ii. What do you currently do? What do you want to do? 
iii. Let’s see you! Do you have an avatar / picture?

iv. Have you done any type of design related work? 
v. Have you built anything lately?
vi. Have you completed a non-design related project?

Answer these questions for that work:

i. Show us a picture / image of it 
ii. Give it a title 
iii. Describe what it is? 
iv. What did you learn from this project?
v. How do you think it relates to UX Design?

2. Sketch a rough layout on paper

Sketch how you’d lay this content out on a single page site. Use your blog post #5 as inspiration and look for examples on Dribbble of designers home pages. Mine for example is pretty old right now (I can’t wait to design a new one with you when the course starts!), but it still tells a pretty good story.

3. Design directly in code

Once you’re done designing, using your sketches of the layout you’d like, and using the inspiration from your research in blog post v, develop a basic 1 page layout with your answers from task 1. Pay attention to things like: font-size for headers, sub-headers, and body copy, and font weight for all of these things as well.

We don’t want you to dwell too much on the prettiness of the colours, so use when deciding on a colour scheme, use this for inspiration (and actual colours!)http://flatuicolors.com/

4. Publish your site on Dropbox

Follow the instructions on this page to host your site on dropbox. It’s the fastest way to get your page out there. Share it on twitter with the hashtag #helloworldUX

http://www.maclife.com/article/howtos/how_host_your_website_dropbox

That’s it!


This all completes your prep course requirements for the User Experience & Interface Design Prep Course.

If you have any questions about the full course, feel free to e-maildesign@bitmakerlabs.com.

If you’d like to speak to the designers, you can find us on twitter here: @tailoredUX,@mustefaJ, and @sidramatik. We’re happy to chat, and look forward to seeing you in July.

Source

The Year of Interaction Design Tools

A brief survey on the state of interaction + prototyping

We’re six months in to 2014, and designers have the widest selection of interaction and prototyping tools to date. The community is blossoming, and bridging the gap from mockup to working prototype is now easier than ever.
Inspired by the upcoming Pixate, I’ve compiled a brief breakdown of the state of interaction design tools in 2014.


Webflow

https://webflow.com/
$16+ a month | Web app
Webflow is a web app that allows users to design websites in the browser and that are completely coded and live. Webflow’s friendly WYSIWYG editor gives designers full control over the output, including the appearance on mobile devices.

Webflow is continuously adding new features — including web fonts, video support, continued W3C compliance, interactive states — and it even includes hosting, too.

Marvel

https://marvelapp.com/
Free | Web app
Marvel is a free web app for prototyping for web and mobile designs. With Marvel, work is done entirely online — but syncs with your Dropbox, allowing you to easily pull in mockups from your private or company files. Marvel also supports PSD files — so you don’t have to convert files before creating prototypes.

Macaw

http://macaw.co/
$99 | Mac & Windows
Macaw is a desktop WYSIWYG design tool that outputs working, live code. It’s particular strength lies in creating responsive designs: Macaw’s built-in breakpoint editor makes it easy to create pixel-perfect designs at any screen size.
Although no coding knowledge is required, basic experience with HTML and CSS certainly enhances the final product.

InVision

http://www.invisionapp.com/
Free | Web app
InVision is not strictly an interaction design tool. InVision is used for prototyping and productivity. For prototyping, InVision allows you to add interactive events to static images to demo user interaction. At the same time, InVision’s project management features allow both stakeholders and designers to interact with prototypes before development begins.

Flinto

https://www.flinto.com/
$20 a month | Web app

Flinto allows you to create interactive prototypes that are useable both on the web and on a mobile device. Flinto allows designers to take static images and create prototypes that can be scrolled, rotated, and interacted with however you want.
One particularly enticing feature: Flinto prototypes can be used natively on Android and iOS devices — so, you can interact with your latest Instacart-for-Cats prototype on your own iPhone or Android device.

Quartz Composer

Quartz Composer is a developer tool created by Apple for use in motion graphics. Although not its original purpose, Quartz Composer has been adopted by the interaction design community as a code-free option for showing animation and state change in designs.
Quartz Composer can be daunting at first glance —with a significant learning curve. Luckily, support is growing. Facebook and IDEO have recently released new Quartz Composer libraries to make the program more accessible to first time users.

Origami

http://facebook.github.io/origami/
Free | Mac only
Origami is a Quartz Composer library created by the Facebook Design team to help prototype interaction on mobile devices. It allows designers to easily replicate common animation and interactions that occur on mobile devices — think animating image transitions or button presses.
Like Quartz Composer, Origami is particularly useful for prototyping, but it doesn’t output useable code. Its claim to fame: Origami was instrumental in designing Facebook’s most recent mobile app, Paper.

Avocado

http://labs.ideo.com/2014/05/27/avocado/
Free | Mac only
Like Origami, Avocado aims to improve Quartz Composer by adding a library that mimics common interaction on mobile devices.
While Origami focuses on interaction and animation, Avocado focuses on replicating common UI elements for iOS — for example, a working iOS keyboard — allowing users to prototype ideas for iOS without using any code.

Framer.js

http://framerjs.com/
Free | Javascript framework
Framer.js is a Javascript framework for prototyping event-triggered animation. Framer boasts many features — one being a built-in generator that processes layer groups from your own PSD files and outputs each group into layers that form the basis of your project.
Framer is a Javascript framework — so unlike other options here, it doesrequire an understanding of HTML, CSS, and Javascript. However, it’s not bound to any specific program. You can host it and interact with it anywhere and everywhere.

Source

How designers can create interactive prototypes with Illustrator

At the start of a product idea the designer uses wireframes, mockups and prototypes to get feedback as fast as possible. Balancing the amount of time spent creating these temporary assets and reducing misinterpretation is key.

Tools like Illustrator give the designer the flexibility to experiment and draw without being forced to think about technical constraints early in the process. It’s great for quickly outputting static mockups, though Illustrator does not have great tools built-in to express interactions or different states in the product.

This article explains how you can quickly go from Illustrator to an interactive clickable prototype in the browser without the need for a developer, without writing HTML, in about 10 minutes.

The goal

As an example we’re going to prototype a small fruit application. The end result of this process is embedded below. Try hovering and clicking the first row.

The example contains some common interaction elements like hover states, tooltips, and dialogs. This is all easily layed out in one artboard. There’s no need to export and maintain different PNGs for each state of the product. You don’t have to upload your assets to a 3rd party tool. The technique that is about to be explained just exports one SVG with all the states in it. Sounds good? Let’s get our hands dirty.

Preparing your Illustrator document

There are two things to keep in mind when you’re going make a prototype out of your Illustrator document;

  • Create a logical hierarchy and name the important elements (layers, groups and shapes) in your "Layers" palette. Keep in mind that we’re going to export the whole document in one SVG file.
  • All elements should live in the same artboard. Hidden elements can later be made visible after a mouse event in the browser. e.g., a dialog can be hidden, but it should be the topmost element.

The name of an element will be used as its ID. This ID is later used to attach mouse event listeners to its element. This is what makes SVG so interesting for prototyping compared to bitmaps; every shape or group is its own element in the browser.

A group’s click area will be exactly the area its child shapes cover. To avoid potential gaps in its hit target you can add a big invisible rectangle (zero opacity) to the group. That rectangle should cover what you want the group’s hit target to be.

When you’re done mocking up you can export the document as an SVG file using"Save as…" and select "SVG" from the file format list. In the export dialog you can optionally embed the images and fonts used inside the document. If you’re not going to manipulate the text or numbers using JavaScript you can select "Create outlines". This makes sure the fonts look the same on all computers.

The visual part is ready to go. The next step is creating a small separate document to which we’ll add the interactivity.

Setting up the playground

As promised there will be no converting to HTML, but we do need a place to connect the SVG to the interactive instructions. The easiest way to add interactivity through JavaScript and CSS to your document is by having a separate HTML load the SVG into it. By not directly editing the SVG file you can just keep exporting the Illustrator document without overwriting your additions. This will make it possible to iterate fast while still be able to quickly test the different states.

Create an HTML file called “fruit.html” in the same directory as the SVG file with the following contents:

<!doctype html>
<script src="http://code.jquery.com/jquery-1.11.0.min.js"></script>
<script>
  $.get('fruit.svg', function(data) {
    $(document.body).append(data.documentElement);
    init();
  });
  function init() {
    /* Add JavaScript here */
  }
</script>
<style>
  /* Add CSS here */
</style>

You don’t have to understand what’s going on in here. You do have to make sure ‘fruit.svg’ is the actual name of the file you exported from Illustrator. The comments point to where you’re going to paste the instructions from the next chapter.

You now created all three necessary files:

  • An Illustrator file in which you can edit the visual part of the prototype.
  • An exported SVG file that will be loaded by the browser (do not edit).
  • An HTML file that contains the JavaScript.

The HTML is set up to load jQuery. jQuery will later help us add mouse event listeners and animations. The call to $.get() will load the specified SVG document you exported in the previus chapter. Inside the “style” element you can optionally apply CSS to the SVG elements. You could also use it to add a background or other branding to the page.

We’re almost at the fun part. Because the HTML embeds the SVG; both files need to be loaded from the same webserver. This is because of browser security restrictions. If you’re already editing on a webserver you don’t have to do anything. If you are working on your local computer you can use your favorite webserver or open your terminal and go to (type “cd” and drag the folder onto the terminal) the directory the files are in and run:

python -m SimpleHTTPServer

You can now open your browser and go to http://localhost:8000 . You should see a link to the fruit.html file. Let’s get ready for the final step and add some interactions to the prototype.

Creating interactivity

A typical interaction you’ll want to create is showing a dialog when you click a certain button. We already drew and positioned a dialog in Illustrator and put it in a group called “dialog” and then hid the group.

You can easily show and hide layers, groups and shapes using jQuery’s $() selector. To create some great interactive prototypes you can get a long way with just usingclickshowhidemouseenter and mouseleave.

In the following code example we make the “dialog” group visible when the “row1” group is clicked.

$('#row1').click(function() {
  $('#dialog').show();
});

When the “closebutton” group in the dialog is clicked we hide the dialog again.

$('#closebutton').click(function() {
  $('#dialog').hide();
});

Another typical mouse interaction is showing a tooltip when a certain element is hovered over. The tooltip is completely mocked up in the Illustrator file so all we have to is make it visible when the “mouse enters” the “row1” group area. We hide it again when the mouse leaves that area.

$('#row1').mouseenter(function() {
    $('#tooltip').show();
});
$('#row1').mouseleave(function() {
    $('#tooltip').hide();
});

By copy and pasting these two examples you’ll be able to express a lot of different states in a normal application.

Download

I hope you enjoyed learning about this easy way of prototyping. If you love Illustrator like I do, I think you’ll find this process keeps a good balance between iteration speed and expressiveness.

Source

Workflow for Designers

’m currently working on no shortage of responsive projects, all of which have great need for resolution-independent imagery. Since all the cool kids are going the SVG route, I figured I’d try my hand at it too. I seem to have arrived at a decent workflow for creating quick vector assets with really small file sizes. If anything, I’m just writing this down so I can remember it for next time.

A few quick notes

  1. I’m just focusing on the asset creation here and not details about implementation on either front- or back-end.
  2. I still do Photoshop comps, so the majority of my workflow centers around Photoshop visualization of elements and/or screens.
  3. There are a ton of great solutions that can automate this for you. However, if you’re anything like me, some of them may seem either overly complex or feel like a black box, or both. The workflow I describe below is mostly born of my desire to be anal-retentive about asset creation. Hmph.

As an example, let’s try and create the ever-popular social media navigation bar. However, you decide to do it—I assemble mine in Photoshop—my comp looks something like this:

Social media navigation

I’ll then go through an measure the size of each icon in Photoshop by using the marquee tool wih the Info palette to get the actual pixel dimensions (shown zoomed in at 1200%):

Measuring dimensions in Photoshop

I’ll then jump into Illustrator and create my vector graphic at that exact size:

Measuring dimensions in Illustrator

I’ll make my document size the exact size of the graphic by choosing Object > Artboards > Fit to Selected Art.

Fitting to selected art in Illustrator

From here, File > Save As… and choose “SVG” as the Format.

“Save As…” in Illustrator

Keep the default options checked.

Default SVG options in Illustrator

You’re going to have to create fallback PNG graphics, so now is a good time to do that. In Illustrator, Select > All and then Edit > Copy to copy the shape to your clipboard.

Switch back to Photoshop and choose File > New…. Photoshop will assume the new dimensions of the new file to be the dimensions of the shape in your clipboard, so just double check that those are the same dimensions of your vector shape.

New Document dialog box in Photoshop

Choose Edit > Paste. When the dialog box appears, choose “Pixels.”

Paste options in Photoshop

Disable the visibility of the Background layer.

Disabling background visibility in Photoshop

Choose File > Save for Web…. Choose the PNG-24 Preset and make sure “Transparency” is enabled.

Save for Web in Photoshop


Edit: in the comments below, Jamie Reynolds mentions generating the PNGfrom Illustrator as opposed to Photoshop. However, I’ve noticed a difference between the output; I find that Illustrator doesn’t do as well as Photoshop does with the aliasing. Check out the bottom row of pixels here; Illustrator makes some poorer choices for clarity, hence my desire to add one more step to generate a better graphic.

Difference between exporting PNGs from Photoshop and Illustrator


You should now have 2 raw files: an SVG and a PNG.

Two file in Finder: an SVG and a PNG

Time to optimize. If you don’t already have them, download and installImageAlpha and ImageOptim. Open ImageAlpha and drag your PNG into the window.

ImageAlpha

Choose File > Save As… and make sure “Optimize with ImageOptim” is enabled. Decide whether you want to overwrite your image or create a new one. Choose Save.

If ImageOptim isn’t open, this will launch ImageOptim. You’ll see that our original file size of 1KB has been reduced to 574 bytes. Huzzah! Let’s do this for our SVG as well.

ImageOptim

Lucky for us, there are some really smart people out there that make our jobs easy. Check out SVGO, a great command line tool for optimizing SVGs. If you’re not into command line, there’s also a GUI called SVGO GUI. That’s my weapon of choice.

Just like ImageAlpha, crack open SVGO GUI and drag your SVG file in.Warning: this will automatically process your file, so if you still want to preserve your original, duplicate it before dragging into SVGO GUI. Voilà! Our 1KB SVG dropped down to 713 bytes.

SVGO GUI

And there you have it: a manual workflow for designers to create optimizedSVGs and PNGs. Enjoy!

Source

14 Different Ways of Product Design

After my dribbble post with picture of a Diagram with very positive feedback and lot of questions, I was motivated to create this article about my process and what I’ve learned after 2 years of this journey.

It’s a bit hard to say that I’m always using this same process, but you can read it similar to an ideal process. I’ve divided this process into 4 parts — Pre-process, Work process, Post-process and tips for Productivity.

Pre-Process

1. I’m drawing

It doesn’t matter if it’s paper, a notebook or just a small piece of something. I need to share the ideas in my head. I need to put these ideas down where they can be saved and not forgotten. Consequently this means that I have some sketches on my bank statements, bills from restaurants, book covers etc.

Sketch of old idea

However, for me it is ideal to have something tangible, for example, on Moleskine. It’s always nice to go through these lists from time to time, look at my old ideas and try to reinvent or recreate something for this particular project or different idea.

2. Collecting Pictures

“An artist is a collector. Not a hoarder, mind you, there’s a difference: hoarders collect indiscriminately, the artist collects selectively. They only collect things that they really love.” — Steal like an Artist (Austin Kleon)

Another pre-process phase is the collecting of pictures, I do this everyday. There is definitely hundreds of styles on how to collect and view these images, however I particularly prefer old school style — Dropbox folder separate to different categories (Dashboards, iOS, Illustrations etc.). Then, when I receive an inquiry or project, I’m going through these images and I’m trying to find inspiration. Dropbox is pre-caching low quality previews of files so you’re able to list them without an internet connection.

3. Moodboard and Preparation

We have plenty of sites for inspiration — Dribbble, Behance, Pttrns, Pinterest etc. and it’s really easy to find similar projects like the one you have. Additionally, it could be a solution for a problem that you’re experiencing and you’re trying to solve.

So when I begin working on a new project, I always prepare a folder with — PSD, Screens, Inspiration and Resources folders. I’m saving everything to the Inspiration folder that I find on the internet and is related to this project.

It should be everything from swatches to full case studies from Behance. Yet it also could be pictures of attractive people if the app has users’ profiles. It sometimes happens that I don’t even use that folder but that’s different story!

Work Process

4. I don’t care about wireframes quality.

I’m not a big fan of spending half a year on wireframes. I also prefer it if a client has prepared wireframes.

A good client is one who has prepared his ideas on paper.

I’m taking wireframes as just more about understanding the purpose and not the actual final result. The final result matters about you and your UI / UX skills and ideas which you want to present. Wireframes can help with the imagination of how many screens you’ll need and what’s the client’s idea.

On another page of the wireframes is a nightmare for the designer in which someone wants just the replication of prepared wireframes and to use the right details from the wireframes. That’s monkey’s job not the designer’s. In this case, every designer would just quickly finish that job and run away from the project like Usian Bolt.

5. PSD — Big Canvas (back to the Illustrator)

When I started 7 months ago at Badoo, I saw how my colleague works (Hi Sasha!), I thought that he didn’t understand how Photoshop works. However, now I’m trying to get into this technique, and in fact this style make sense to me. It’s good to use this style when you’re working on something really big, for example, a web application or a rich dashboard.

Basically, I work with a big canvas for example 8000*5000 pixels. Furthermore, my work isn’t more than just creating one big UI kit. The work is much faster because you see every element together and I can easily see what’s happening in every state. Additionally, it is much quicker to make a screenshot for developers with a small flow or just one states for one thing.

6. All screens in one PSD

In another case, which is not that revolutionary or different. If I’m working on a mobile app I’m working in different extremes. That means — All screens are in one PSD.

In folder 14 is another 12 designs of graphs

I know in this case it will be better to use Sketch, which could be really helpful with work. But I prefer one instead of 40 because it’s hugely quicker, I can easily pick one element from a different screen and copy that to another folder/screen. So that means if I change the background or a few icons on the top bar, I don’t need to change hundreds of other PSD’s.

7. Folders and Etiquette

I’m a tidy person in every respect — I have one icon on my desktop, folders per clients, per projects. Every folder is structured in the same way as I mentioned before. The same as in PSD. Every of my PSD’s is nicely structured in every folder. I use the rule that if you have more than 8 layers in folder then you should create a new folder. I think about my PSD’s like I’m preparing them for someone else. I’m not a big fan of naming layers because you can easily go through my folders.

But lately I’ve started working with @LukášKus and he always complains that he doesn’t have these folders in AE. Therefore, a particular situation always matters.

If you would like to know anything else about PSD Etiquette you can look at this — http://photoshopetiquette.com/

8. Communication with friends

A network of people who can provide you with relevant feedback is something critical for me. I can easily do mini user testings and listen to what people think about these specific problems This usually opens the doors to other solutions and other points of view for these problems. I do these calls/tests as much as I can in every state of my project or screen. Moreover, it doesn’t matter who you are testing. It could be anyone, I prefer to combine two segments — people from the community, the UX designers and normal regular users. This is because you’re usually working on project for regular users not for designers and UX principals.

9. Diagram

After my client or I prepare wireframes, I prefer to take them and merge them in one PSD. Then I try to think about interactions, what happens when I click here or there. Usually, we find a lot of missing screens and additional errors which clients or I don’t realise, when I was thinking about just one particular screen when I was preparing wireframes. For me, it’s this pre-prototype phase which I don’t consider a double job. It’s actually also a visual overview of all the screens and the elements. When I’m working on 15+ screens project it’s hard to keep the same visual style across the whole app and I can easily break the guidelines.

3 different types of lines — first a normal line with the number of next screen. Second in app screen. Third — an external app or linkHow it looks with contentComplete overview

About style — I use the same style similar to a lot of designers, however instead of spending a lot of time with creating these lines across whole canvas, I use circles with the numbers of the next screen. It’s a little bit like gamebooks which I was reading back in the days, but it’s a better solution than creating of printed circuit boards. You can see more states on the picture.

I add a link for the Diagram PSD for a better understanding these diagrams(The iPhone render is done by GraphicBurger)

Post Process — Guidelines

And we are finally close to end of the process, the last part is the creation of the guidelines and the final check for visual consistency. It turns out for me like such an important part of the process for small and also for big projects. Usually, when I work on a big project I want to change something in this part of process and I’m never a 100% sure that I’ve changed every of these properties. I use these for myself and also for developers to be sure that they won’t use 50 shades of grey or 14 different sizes of fonts.

10. Colour Specs

The specification of colours is one of the first thing which I try to keep in mind. It’s really nice in these flat design age to keep as few colours as possible for the buttons and for text. It’s nice to prepare this in your PSD like a painter’s palette or like swatches in Photoshop, which is basically the same.

11. Typo Specification

One other thing which can remind you of the logo specification is the guide for text sizes and the weight of fonts across the application. Again, it’s good for developers, but also for your overview.

12. UI Kits

The UI kit is a really important thing if we are talking about consistency across company apps and websites. It’s also important when you’re working in team of designers or you have more front-end developers who work on that project. I can use a UI kit in way that I’m always taking these elements from UI Kits. Also the developers can easily see how this button will look on hover and they don’t need to ask about everything.

Note: I’ve realised that in big companies, it is a big problem that nobody has heard about these things and teams basically re-create these same CSS lines again and again. Then you realised that you have 3 different interpretations of one button in 3 different applications. So you can’t forget about consistency.

Productivity

13. Todo

My key aspect of tidiness is working with todo lists. It doesn’t matter what type of app or paper you use. I prefer Things by Cultured Code and sometimes piece of the paper. That feeling of completing lists is always great. I was possessed with accepting every project which ends up in my email inbox, but now I’ve realised that it is much too comfortable to focus on 1-2 projects and 100% focus just on these 2 projects and then go to another one instead of fighting with 5 different ones.

“If you chase two rabbits, you will not catch either one.” — Russian Proverb

14. Goals

It’s really nice to know what you want to achieve, but also don’t be too bound to them. I make goals for 14 days (like a sprint) and quarterly goals. Also, I try to set these goals in way that I can achieve some new experiences (for example: make my first animation in After Effects) and also keep working on current things (finish 2 Behance case studies).

And what else?

I don’t use a mouse, just a tablet, I don’t have Tools panel I have learned all keyboard shortcuts. For streaming Photoshop to iPhone I use Skala Preview and I want to learn After Effects and Sketch. For prototyping, I use InVision App for web projects and the newly MarvelApp for iOS designs. It’s quicker for me to work with a pen instead of dragging and swiping on the iPhone screen. I sometimes still work with PopApp for some early prototypes, when I have time on the Tube for clicking and dragging on Screen.

The last few words

It’s really hard to say that I will always complete and follow the exact process for each project, because I sometimes skip some steps or I start in Photoshop if I see that the design in my mind and I have an exact idea about that.

In companies where I have worked, I’m still not experiencing real feedback, user testing and these things where designers can profit and take and experience them for thinking about new projects or updates for the current one. Especially User Testings, these change the thinking about all the things and show us that regular users usually work in completely different ways than we expect.

The End

I’d be happy to hear about your work processes, which steps you usually take in your personal projects or your thoughts about additional steps in my process.

Source

Two Keys to Building a Great Product

image

In the product group at HubSpot there are two guiding principles to building amazing products, they come from David Cancel and he’s 100% right in my experience:

  1. Be customer-driven
  2. Show meaningful progress

Each of these means different things at different stages in the product lifecycle, but they are strong guiding principles from early stage research through MVP to mature product.

Here’s a starting point to think about how to lean into each of these principles, and a view of how that changes as a product comes to market and matures.

Pre-prototype
  1. Customer-driven: Narrow your focus to your target go-to-market end user. Find where they spend their time, where their pain is. Watch them in their natural environment. 
  2. Meaningful progress: Consider doing a minimum of X interviews, and/or defining the output as being the top Y painpoints to start addressing.
MVP
  1. Customer-driven: Be insanely impatient to get an early working product in front of one user. That’s the hardest part, getting one person to the point where they would pay, or be seriously disappointed if you took the product away from them. super hard stage, from zero to one user. Then move from one user to ten, another extremely hard stage. Put your cell phone in the product, follow up with people as they use the product, and watch every motion they take using it. Start doing user testing as well.
  2. Meaningful progress: Live and die by activated user count. From zero to one, and from one to ten. 
Growth phase
  1. Customer-driven: The product team should directly support their customers. When applicable work with sales to understand how to iterate on *validated* learnings - not “all i need to close every deal is XYZ” requests but actual records of painpoints, blockers, competitive landscape, potential for product differentiation, shortcomings against existing solutions, etc. It helps here to have consultative sales folks who don’t do “feature dumps” but rather do a great, scalable job of customer pain discovery. If product/dev can overhear these conversations some magic can happen :)
  2. Meaningful progress: Measure, chart and distribute to the team: active users, activation rate, recurring revenue, net churn, referral loop, tickets/customer (whatever makes the most sense as a yardstick for product/market fit). Company demo (monthly) of new features LIVE for real customers, not mockups or qa.
Mature product
  1. Customer-driven: Record and distribute top support inquiry drivers, measure decrease in these drivers month over month. Heavy use of user testing to optimize the core flows and usage patterns in the product.
  2. Meaningful progress: Measure, chart and distribute to the company: tickets/customer, call drivers (and delta month-over-month), uptime/availability, performance/speed. Continue company demos, include performance improvements in addition to features.

Hope someone out there finds this useful, it’s been a breakthrough for me and my colleagues to embrace these principles and to dive deeper and deeper on both.

Customizing Help & Tips By Input Type

On today’s multi-device Web, your audience might be using a mouse, keyboard, touchscreen, trackpad, or increasingly, more than one of these input types to interact with your service. Given all these possibilities, how do you let people know how they can get things done in your app?

A common way to provide relevant bits of guidance inside an application is throughinline help. Inline help is positioned where it’s most useful in an interface and made visible by default so people don’t have to do anything to reveal it. This makes it an effective way to tell people how to use an interface. But what happens when those instructions vary by input type?

For instance, we recently built a fully responsive Web application that can be used on smartphones, tablets, desktops, and more. In this application, people can add and manipulate images by zooming, resizing, and moving these images around. Depending on the input type their device supports, however, they have different ways of accomplishing these tasks.

To position an image using touch, you simply drag it with your finger. Zooming-in and zooming-out is accomplished through pinch and spread gestures. Sizing an image to fit happens through a double-tap action.

Mobile Image Manipulation on Polar

These same features are supported on mouse and keyboard devices as well. To move an image around, click and hold to drag it. Zooming in and out happens with the scroll wheel or a multi-touch gesture on the trackpad. Sizing an image to fit takes a double-click of the mouse.

As you can see, the touch and mouse actions are similar but not the same. We were also concerned that while touch users are quick to pinch and spread when trying to zoom an image, mouse users are less familiar with using scroll wheels and two-finger trackpad gestures to accomplish the same thing. So we wanted to let our mouse users know what’s possible with a few simple bits of inline help.

Desktop Image Manipulation on Polar

Easy, right? Just check if someone’s device has a mouse or trackpad attached and reveal the tip. Well, no.

On an earlier project, we faced a similar situation. While our smartphone and tablet users could easily interact with our lists of polls by scrolling and voting with their thumbs, mouse and keyboard users had more work cut out for them. They couldn’t simply keep their fingers in one place and vote, scroll, vote.

Polar topic pages on small medium screens

So we developed a keyboard interaction that allowed people to vote with left/right keys and move through polls with up/down keys. While this made keyboard users much faster and effective, we again were faced with a hidden interface: people didn’t know keyboard voting was possible unless we told them.

Polar topic pages on large screens

That meant we had to detect if a keyboard was present and surface a simple inline tip that explained the voting interface. After a few failed attempts at doing this, I reached out to friends on the Internet Explorer team at Microsoft. After all, if anyone would have a good handle on how to manage different input types on the Web, it would be the company with a Web browser that not only runs on phones, tablets, laptops, and desktops but hybrid devices and even game consoles as well.

Polar keyboard call to action

Sadly, we learned there’s not a great way to do this in Web browsers today and browser makers are hesitant to reveal information like this in a navigator.hardware object because of concerns it could be used to fingerprint users. So instead, we opted to proxy the presence of a keyboard using screen width. That is, if the screen is wide we assume there’s a higher chance of a keyboard being present and show the keyboard interface tip by default.

This is the same solution we now have in our new publisher tool. When the screen crosses a certain width, we reveal two inline tips explaining how to zoom and fit an image using a mouse.

As I’ve written before, using screen width as a proxy for available input types is not ideal and increasingly unreliable in today’s constantly changing device landscape. But the alternative solutions don’t seem much better.

For instance, we could provide a help section that explains how to do things with every input type. But then we loose the immediacy and effectiveness of concise inline help. We could wait until someone interacts with the app to determine if they are a touch or mouse user, save that information and display device-appropriate tips from that point on. But even if we get this info up front it can change as people switch between touch screens and trackpads or their mouse.

While the need for input-appropriate help text in a Web application may seem like a small detail, it’s reflective of the broader challenge of creating interfaces that not only work across different screen sizes but across many different capabilities (like input type) as well. Inline help is just one of many components that need be rethought for today’s multi-device Web.

Source

Is The Corporate Website Dead?

According to some trend watchers, a little research, and a few live examples, the corporate website as we know it may be ready for some disruptive evolution. 

To put it more plainly, the corporate website may be dying a slow and painful death.

Corporate website visits for most large brands are declining. Your best content is lost among too much product promotion. And more attention is being stolen away by more progressive brands who have started acting like publishers and displaying content that your customers actually want to consume.

This is not just headline bait. There appears to be a growing consensus that the corporate website as an online brochure displaying “About Us,” “Our Products,” “Latest News About Us,” and “Speak To A Representative” isn’t working.

There is some convincing research to support this:

  • According to Webtrends, nearly 70% of Fortune 100 corporate websites experienced declines in traffic, with an average drop of 23%.
  • 90% of website traffic comes from just 10% of the content and more than 50% of the traffic is from just 0.5% of the content. ~ InboundWriter
  • 60-70% of B2B marketing content goes unused. ~ Sirius Decision
  • 60% of the buyer journey is complete before prospects reach out to vendors.  ~ CEB

I guess this shouldn’t be a surprise. We’re all watching the slow death of the newspaper industry. We’ve heard a lot of talk about how brands need to act like publishers.  We’ve seen major advertisers talk about how their advertising is evolving into something more closely resembling content marketing.

Now that there is a steady drum beat decrying the death of the corporate website, I sought to get to the bottom of this to see if we’re actually going to see some real change. And after reviewing some of the research and reading up on the evidence, I think there just might be something to this trend.

Why Your Corporate Website Should Die

In early 2011, Forbes Contributor Christine Crandell wrote that the customer experience for most buyers is inconsistent and disconnected.

She pointed at the corporate website as a “traditional marketing vehicle” (ouch!) that companies should abandon due to the overwhelming evidence that most visitors scan the page and leave because they are not looking for information about your products. She believes corporate website visitors are looking for useful information such as best practices tips, human stories and the ability to interact with real people.

Her guidance to corporate website owners:

Rather than boring your customers to death, there is a clear opportunity to put the dull corporate website to rest.  Then resurrect it as a platform for true community engagement that functions as a hub for interaction.

Corporate Websites Should Facilitate Moments of Authentic Interaction

All the way back in January, 2010, Brand Consultant Simon Mainwaring penned “The death of corporate websites” blog. He declares that “the online presence of a brand will increasingly become the sum of its social exchanges across the web and not the website that many currently call home.”

He also defines a massive change in the role of the brand manager to become one of a “social officer, facilitating as many moments of authentic interaction with consumers each day as possible.”

Four years on Mainwaring contends that “this shift is largely complete as we see brands shifting their media weight from traditional to social media, sharing stories across multiple channels and responding in real time, and training their employees to become social media brand advocates. So while the corporate website persists, it has now been reframed as a point of departure for customer engagement, rather than a destination.”

Content Is King And The Corporate Website Is Dead

A few brands are getting into this game and they are not looking back. In November, 2012 the Coca-Cola company declared the death of its own corporate website.  They re-launched their website under the tagline of “The Coca-Cola Journey. Refreshing The World, One Story At A Time” which featured content driven by their “Unbottled” blog.

I had met their super-sharp Group Director of Digital Communications and Social Media, Ashley Brown a few months before this announcement and was just blown away by what they were doing.

Even more important, is that they paused 6 weeks in, looked at the data and realized that what they thoughtwould resonate with their audience wasn’t working.

They endured their way through an “editorial scramble” based on hard data and implemented a new design and content strategy based almost completely on the kinds of stories their audience wants. According to Ashley:

Replacing a transactional corporate website with a digital magazine upended how we work

He continued:

The corporate website is dead and “press release PR” is on its way out.

Michele Mehl agreed that the corporate website is dead when she talked about how Coke successfully turned their website into an online news channel in her article on Geekwire.

Brand Publishing Is Not Just For Consumer Brands

I know what you’re thinking. Coke is not a B2B Marketer. But I believe the evidence they pointed to, the cultural shift they implemented and the approach they took to make content their main product are all just as relevant to B2B marketing professionals.

Maybe even more so. The B2B decision process is harder, longer and more complex. Delivering effective information and telling stories that build trust are still the cornerstone of effective B2B marketing.

Luckily, just in time for my research on this article, Sam Fiorella at Sensei Marketing published “Why Build a Corporate Blog Instead of a Corporate Website?” According to Sam:

Our goal is not to promote ourselves but our thinking; our website is not a sales tool but an educational one.

They realize that the main goal of their site is to build relationships and trust. Not to promote their products. And they also realize that this is a gamble. I think they are onto something. And I wish them luck!

I realize this nearly 1,000 words is a lot to take in. Thank you if you made it this far! Now, please share your thoughts in the comments below. And please follow along on TwitterLinkedInFacebook  and Google+ or  Subscribe to the B2B Marketing Insider Blog for regular updates.

Source

When responsive design will make sense for your application

A few months ago, I found myself in a Twitter debate over whether or not responsive design can work for web apps.

While it was a fun debate, trying to answer the question of whether or not responsive design makes sense for your app is futile. Let me explain.

We don’t have a common understanding of what responsive means.

I wrote about my struggles with figuring out what is “responsive” recently. People think they know what others mean when they say something is responsive, but our definitions often differ.

The best responsive designs use much more than responsive design. When that is the case, it is easy to find faults with any given responsive implementation that can be used to say, “Well, that’s not really a responsive design.”

What happens when you use responsive web design, but add to it things that seem to be at odds responsive design? Is it possible to add something that make it no longer responsive? If so, where is the line?

What is a web app?

If responsiveness has a murky definition, “web app” is considerably worse. Jeremy Keith has long argued that “like obscenity and brunch, web apps can be described but not defined“.

Chris Coyier recently polled his readers about whether or not it was useful to distinguish between “web apps” and “web sites”.

While people agree that the distinction is important, there was little consensus on what the distinction was. Chris summarized his findings thusly:

I was kind of hoping we could get somewhere close to a solid distinction between these two classifications, but I don’t think it’s going to happen. There is very little agreement and heaps of opinion.

So any time we’re discussing web apps, we’re going to have trouble agreeing on what we’re talking about. Discussing responsive web apps is just asking for trouble.

A case study in different perspectives

Here is a timeline of articles and discussions that illustrates my point perfectly:

June 17, 2013 — Responsive design Web apps – good or bad?

On a content only site it [responsive design] probably is very wise to start small and scale up. But in a highly interactive functional UI the UX will be damaged by the time you scale up. Or vice versa. Take a demanding environment such as online betting or a tipping platform. The users needs are potentially very different between device environments.

July 4, 2013 — Why Responsive Web Design is a Must for Gambling Sites

I personally have no doubts that responsive web design will become an official standard for all good web pages and web content design to comply in the future, sonow is the right time for you to start using it on your gambling and sports betting sites.

June 13, 2013 — Case Study: Betting on a fully responsive web application

Kambi
 is one of the top sports betting providers and their services include popular sports from all over the world…At Kambi 
we went all-in on this bet and decided to build a web application that scales across the board. The value was clear, unified development process and consistent user experience on all platforms…Fully responsive web applications is not just a pipe dream anymore*. With the right mindset, tools and processes it all becomes possible.

July 9, 2013 — I point to Kambi as an example of responsive design being used for a web app. Nick Finck replies:

To summarize:

  1. Gambling apps are too complex to use responsive design.
  2. All gambling apps should be responsive.
  3. A case study of how a popular gambling app was built to be responsive.
  4. The gambling app in the case study is too light-weight.

Therein lies the problem. Even when we have a specific niche app/site (e.g., gambling), we can’t agree on the definitions. We have a case study of how a gambling app was made responsive, but we derive different conclusions about how applicable the case study is.

And I’m fine with that. I don’t mind ambiguity. People don’t have to agree.

I just think it points out how futile it is to try to convince others that responsive design for web apps makes sense.

My thoughts on responsive design for apps

For my own part, I believe responsive design for apps is a no-brainer. We’re building apps for clients that use responsive design. I’ve seen large, complex apps for Fortune 500 companies that are in development. I’ve seen what other agencies are working on.

This stuff is coming. And perhaps when enough of these projects launch, we’ll move on from the debate about whether or not responsive design works for apps like we’ve moved on from similar questions about responsive design for ecommerce. (We have moved onhaven’t we?)

But even if I wasn’t fortunate enough to get a behind the scenes look at upcoming responsive app projects, I would still argue that responsive design for apps is inevitable:

Once you start accepting the reality that the lines inside form factors are as blurry as the lines between them, then responsiveness becomes a necessity.

I’m not saying there isn’t usefulness in device detection or looking for ways to enhance the experience for specific form factors and inputs. This isn’t a declaration that everything must be built to be with a single html document across all user agents.

What I am saying is that even in scenarios where you’re fine-tuning your app code and UI as much as possible for a form factor, that the differences in screen size and the various forms of input within a form factor alone will be enough to require you to design in a responsive fashion.

Sure you can build a complex web app without responsive design that only targets tablets, but that app would be limited. There is too much variation in the screen sizes of tablets for a design that isn’t responsive to work on more than a handful of devices.

I’m much more interested in skating to where the puck is going to be, no matter how difficult, than to fixate on what is easiest to do now.

We’re focused on helping our customers make their apps work across devices. And that means taking on many complex challenges. Making apps responsive is just one of them.

So how will you know when responsive design makes sense for your app?

When you decide it does and put in the hard work to make it so. The rest of the discussion is just noise.

Source

TOPS OF 2013: DIGITAL Web, Brands, Apps

Digital media had another banner year in 2013, and some of this year’s trends may provide some clues as to what may lay ahead next year. As more Web users shift to mobile and tablet screens, Web activity using computer browsers declined slightly among the top 10 websites. Online video viewing, however, continued to grow, and YouTube remained the top source for streaming, as 128 million Americans viewed video content on the site each month.

Smartphone penetration grew from 56 percent at the start of 2013 to nearly two-thirds (65%) of U.S. mobile subscribers by October 2013, and a majority of subscribers used Android (52%) or iOS (41%) smartphones. Along with growing ownership came increased activity using smartphone apps: Facebook remained the most-used smartphone app across Android and iOS handsets, with more than 103 million unique users each month. Among the top 10 apps, Instagram was up 66 percent in terms of unique users, making it the fastest growing app over the past year.

TOP 10 U.S. WEB BRANDS FOR 2013

VIEW CHART

TOP 10 U.S. ONLINE VIDEO BRANDS OF 2013

VIEW CHART

TOP SMARTPHONE APPS OF 2013

VIEW CHART

Using Content To Define User Experience

In her presentation at Breaking Development in Nashville TN, Steph Hay talked about the importance of narrative in digital experiences. Here’s my notes from her talk on Using Content To Define User Experience.

  • The Sesame Street TV show was based on actual research of how kids learned and continually measured to make sure it was reaching their educational goals. They approached content development by isolating chunks of programming, testing it, and continually refining.
  • The big paradigm shift was learning first then writing second.
  • Content and technology that guides people over time forms a narrative that allows people to act.
  • Use cases in software design tend to be very flow-focused and high level. Requirements docs just focus on the what. Content is the missing piece in everything we’re doing.
  • When content really works, we can get from point A to B more quickly and easily.
  • Use content to explicitly set expectations then meet them regardless of device.
  • Design is only part of the narrative, the other half is the real human people that experience what we are designing.
  • The “you” orientation of content focuses on the user, not on the company. It positions the customer as the other half of the narrative.
  • Features by themselves won’t protect your narrative, you also need relevance.
  • There are two kinds of narratives online: setting expectations (through marketing), and functional requirements (through experience).
  • Write content first. This is the paradigm shift.
  • Many organizations are afraid to write content first because they are used to writing it last. But this results in missing pieces and incomplete experiences.
  • State your goal: what are you trying to accomplish, what are your users trying to accomplish.
  • You can use tools like Google Keyword builder and Google Analytics to find the language people are using to find you. What terms make sense for them? Use these terms to create a conversation.
  • The content is the structure. This is why it makes sense to start there.

Source

Relying Too Much on Screen Size

As people continue to go online using an ever increasing diversity of devices, responsive Web design has helped teams build amazing sites and apps that adapt their designs to smartphones, desktops, and everything in between. But many of these solutions are relying too much on a single factor to make important design decisions: screen size.

What’s Wrong With Screen Size?

It’s not that adapting an interface to different screen sizes is a bad thing. Quite the opposite. It’s so important that key metrics like conversion and engagement usuallyincrease substantially when Web sites adjust themselves to fit comfortably within available screen space. For proof, just look at how mobile conversion rates increase significantly more in responsive redesigns than PC conversions do.

So if adapting to different screen sizes can have that kind of positive impact for a business, what’s the risk? As the kinds of devices people use to get online continue to diversify, relying on screen size alone paints an increasingly incomplete picture of how a Web experience could/should adapt to meet people’s needs. Screen size can also lead to bad decision-making when used as a proxy for determining:

  • If a browser is running on a mobile device or not
  • If Network connections are good (fast) or bad (slow)
  • If a device supports touch, call-making, or other capabilities

None of these can actually be accurately inferred from screen size alone but they are comfortable assumptions that make managing device diversity substantially easier. The harsh truth however, is that output (screen size and resolution) is only one third of the equation -at best. Equally important to determining how to adapt an interface are input capabilities and user posture, which sadly screen size doesn’t tell us anything about.

Let me illustrate with a few specific examples.

Screen Size Limits

On tablets, PCS, and TVs, Microsoft’s Windows 8 platform allows any app, including the Web browser, to be “snapped” to the side of a screen thereby letting people interact with it while using another application in the primary view. As an example, the Windows 8 calendar application can be snapped alongside the weather app when making your daily plans.

Windows 8 Snap Mode

Notice though, that the default view of the calendar application on Windows Phone 8 is quite different than the snapped view of the same app on a tablet, PC, or TV. They are both using the same amount of screen width (in relative pixels), but the mobile interface starts with a daily agenda instead of a small month view by default. The controls are also adjusted to the mobile form factor as you can see in the image below.

Windows Phone Weather App

We can debate about why these differences exist and if they should or not but the bottom line is there’s more than screen size being taken into account in these application designs.

This simple example illustrates the challenge for Web designers. On Windows Phone devices, Internet Explorer uses 320 pixels for its device-width (the width it renders content at). On Windows 8 tablets, PCs, and TVs, snap mode uses the same 320 pixel device-width to lay out Web pages docked alongside other apps.

So with a responsive Web design, people get the same interface on a smartphone that they get in snap mode on a TV screen due to the same device-width (320 pixels). You can see this illustrated in the image below.

Polar on XBox One And Smartphone

But should the interface be the same? A TV is usually viewed from about 10 feet away, while the average smartphone viewing distance is about 12 inches. This has an obvious impact on legibility for things like font and image sizes but it also affects other design elements like contrast. So a user’s posture (in this case viewing distance) should be taken into account when designing for different devices.

The input capabilities of a TV (D-pad) can differ wildly from a those of a mobile device (touch) or in some cases be the same (voice). Designing a simple list interface for d-pads requires a different approach than a creating a similar listing for use with touch gestures. So available input types should also be considered in a multi-device design.

When you take user posture and input capabilities into account when designing, an interface can change in big or small ways. For instance, contrast the design below for Windows 8 snap mode on a TV compared to a mobile version of the same feature.

Polar Adapted to TV and Smartphone

While the screen size (320 pixel device-width) has stayed consistent, the interface has not. Larger fonts, a simplified list view, inverted colors, and a lot more have changed in order to support a different user posture (10 ft away vs. 12 inches), and different input types (d-pad vs. touch). As you can see, screen size doesn’t give us a complete picture of what we need to know to design an appropriate interface.

Before you dismiss this as an isolated use case on Windows 8 devices, note that Android smartphones and tablets also offer the ability to interact with multiple applications side by side and Android-powered TVs won’t be far behind. In fact, we’ve already got Android eyepieces like Google Glass that pose similar challenges.

Google Glass allows you to view applications and Web pages using a display that projects information just above your line of sight. The official specs describe the Glass display as a “25 inch HD screen viewed from 8 feet away.” So right up front, viewing distance matters.

Google Glass Screen Specs

Like most mobile Web browsers, Glass uses a dynamic viewport to resize Web pages for its screen. On Glass the default viewport size is set to 960 pixels and pages are scaled down accordingly. So if someone is viewing the Yahoo! Finance site, it displays like this in the Glass browser (below). Essentially, it is shrunk down to fit.

Source

Yahoo! Finance on Google Glass

The Web browser on Glass also allows pages built responsively to adapt to a more suitable device-width. In this case, 640 pixels. So a Web page designed to work across a wide range of screen sizes would render differently on Glass. Given that 600 pixels is a common device-width for 7 inch tablets, the page you’d see on Glass would look more like the following -adapted for a smaller viewport size.

Yahoo! Mobile on Google Glass

In addition to the Web browser, Google Glass also includes a number of “glassware” applications built with the same Web technologies used to create Web pages. One of these apps provides access to stock price changes -very similar to what you see displayed prominently on the Yahoo! Finance site. However, the presentation of this information is very different. As you can see in the image below it’s been designed as if you are viewing a 25” screen from 8 feet away. This design is much more suited to a wall-sized display than a small tablet screen.

Google Glassware for Finance

This Glassware interface is also designed to make scrolling through information using the touchpad on the side of Google Glass (which comfortably supports sweeping left/right and up/down gestures) fast and easy.

So again user posture and input capabilities inform how to design for a specific device. Screen size alone doesn’t tell us enough.

Supporting Everything

In order for an interface to adapt appropriately to different output, input, and user posture, we need to know what combination of the three we’re are dealing with at any given time. On the Web that’s been notoriously difficult. We can’t tell TVs from smartphones or what devices support touch without relying on some level of user agent detection, which is often looked at dubiously.

Because of this, Web developers and designers have smartly decided to simply embrace all forms of input: touch, mouse, and keyboard for starters. While this approach certainly acknowledges the uncertainty of the Web, I wonder how sustainable it is when voice, 3D gestures, biometrics, device motion, and more are factored in. Can we really support all available input types in a single Web interface?

A similar approach to user posture is increasingly common. That is, an interface can simply ask people if they want a lean-back 10 foot experience, a data dense 2 foot experience, or something more suited for small portable screens. This makes user posture something that is declared by people rather than inferred by device. Once again, this kind of “support everything” thinking embraces the diversity of the Web whole-heartedly. However it puts the burden on each and every user to understand different modes, when they are appropriate, and change things accordingly. (Personally I feel we should be able to provide an optimal experience without requiring people to work for it.)

Ultimately trying to cover all input types and all user postures in a single interface is a daunting challenge. It’s hard enough to cover all the screen sizes and resolutions out there. Couple that with the fact that an interface that tries to be all things to all devices might ultimately not do a good job for any situation. So while I embrace supporting the diversity of the Web as much as possible, I worry there’s a limit to the practicality of this approach long-term as the amount of possible inputs, outputs, and user postures continues to grow.

Don’t Assume Too Much

These examples are intended to convey one important point: don’t assume screen adaptation is a complete answer for multi-device Web design. Responsive Web design has given us a powerful toolset for managing a critical part of the multi-device world. But assuming too much based on screen size can ultimately paint you into a corner.

It’s not that adapting to screen size doesn’t matter, as I pointed out numerous times, it really does. But if you put too much stock in screen size or don’t consider other factors, you may end up with incomplete or frankly inappropriate solutions. How people interact with the Web across screens continues to evolve rapidly and our multi-device design methods need to be robust enough to evolve alongside.

Some design trend data

Great post and data deconstruction. Best viewed from Source

It took a surprisingly long time and about fifteen million get requests to scrape meta data for every upload (as of the end of August ‘13) on Dribbble, the popular design community. I ended up lopping off the first half-year-or-so of activity on the site as the community was growing in fits and spurts and the data were inconsistent and basically all over the place. In sum, my little Heroku-deployed Go app collected information about 638,271 uploads and 3,479,698 taggings, and stored it all in a PostgreSQL database.1

Fig. A: CLICK HERE TO VIEW

In the interest of being a good internet citizen, I rate-limited the hell out of it. Strangely, the scraper looped through the full range of unique upload IDs about a dozen times, and it seemed to pick up a few more uploads each run (albeit only a handful the final time through), which would indicate there was some kind of silent failure occurring. If these numbers seem off or my method seems flawed, I’m interested in hearing about it.

I’ve included the taggings-per-upload ratio in Fig. A to add meaning to the trend data that follows. Since 2010, the average Dribbble upload went from having less than 4 tags to over 6, so an increase in incidence of a particular tag could indicate nothing more than users’ increasingly prolific tagging (i.e. a change in Dribbble usage behaviour, not a trend in web design). I considered normalising the later spark-lines against that increase, but my eyeballing of the data suggests that the increase in tagging coincides with an increase in tags (the size of the tag set increased). There might be a clever way to properly normalise the data to diminish the change in Dribbbler usage and highlight actual data but until I figure that out or somebody emails it to me, be aware you’re looking through a glass darkly.2

The rise of ‘flat design’

Dark glass or not, there are a few striking vistas. The most spectacular is the rise of flat design. The community’s usage of the ‘flat’ tag was a rounding-error above zero until the late autumn of 2012 when it began a rapid ascent. (It’s probably not worth noting that Scott Forstall departed Apple on 29 October 2012 — but you don’t need to be Tim Cook to know which way the wind blows.)

Fig. B: Rise of ‘flat’ on Dribbble,  CLICK HERE TO VIEW

In August of 2013, more than one in every ten Dribbble uploads was tagged ‘flat’. But Fig. Bcharts two trends, really. One is the rise in a style of visual design that’s been called flat, which is typified by a lack of texture, gradient, drop shadow. And the other trend is the propagation of the term ‘flat’ to describe this style of design. Charting related stylistic tags (‘minimal’, ‘simple’, ‘metro’) suggests a trend that’s no less obvious, but perhaps a little less dramatic.

If the conversation within the software design community over the past year is any indication, we might expect the trend in Fig. B to be mirrored by a precipitous decline in the use of skeuomorphism. Of course the word skeuomorphism was really only introduced as a shibboleth among the proponents of so-called ‘flat design’, as a pejorative description of an outmoded look.

Fig. C: ‘Skeumorphism’ on Dribbble,  CLICK HERE TO VIEW

The word ‘skeuomorphism’ was first used as a tag in June of 2011 by Eugene Cheporov (and ‘skeuomorphic’ predated ‘skeuomorphism’ by a couple of months: Joshua Blankenship tagged an upload with itin September of that year). Its use since then has been extremely seldom (peaking in January 2013 with a meagre fourteen taggings out of more than 20,000 uploads), and often self-conscious (the first upload tagged ‘skeuomorphic’ was titled Because there aren’t enough skeuomorphic shots on Dribbble…).

Fig. D: Google Trends,  CLICK HERE TO VIEW

But uploads of the style that came to be pejoratively called ‘skeuomorphism’ were far more prevalent far earlier. Take a look through some Dribbble uploads from 2011: there’s a lot of carefully stitched upholstery, glossy leather, and slickly rendered machinery.3 So I tried to find some related tags to use as a proxy. ‘Noise’ and ‘texture’ both overlap with the style that I would call ‘skeuomorphic’ (not in its proper sense, but the gaudy, drop-shadow-y style it’s come to mean). They also constitute trends of their own (and even overlap with ‘flat’ more than never), so, as ever, it’s a dark glass.

Fig. E: Mobile computing platforms on Dribbble,  CLICK HERE TO VIEW

It is, I am sure, an extremely significant indicator of the developer ecosystems of the major mobile computing platforms of the moment that iOS is about ten times as popular as Android within the Dribbble design community. In Android’s best month, about one in a hundred uploads were so tagged; in iOS’s, about one in ten. And woe betide Windows Phone, for which there isn’t even enough data to mock.

Read from this what you will; I don’t have the heart for it. But the data is pretty definitive: iOS has the critical mass of designer mind-share.

The reason I began this little-big-data adventure was because I had a hunch we’d seeMark Simonson’s Proxima Nova suffer a dramatic decline in usage the moment Hoefler Frere-Jones made available for web-use the typeface for which Proxima so often has been called to mimic, Tobias Frere-Jones’s Gotham. I thought a) the entire project would be reasonably quick; b) it’d make a very satisfying graph; c) glory. Proxima Nova’s use on the web has often struck me as we-want-a-web-font-but-also-want-Gotham. I admit I’ve done the very same once or twice. It’s a poor imitation, but bold and in caps, it ticks a lot of the same boxes.

Fig. F: Sans-serifs on Dribbble,  CLICK HERE TO VIEW

Of course: the data are too subtle for my ham-fisted brain. Gotham’s usage since 2010 is basically in decline. I suppose it’s probably in decline since 4th November 2008. And, again, its decline here is not necessarily meaningful: this may be highlighting changes in the Dribbble community, changes in Dribbble usage patterns, or actual changes in the typeface’s relative popularity. And Proxima Nova does follow the sort of trend we might have expected. It rises, presumably roughly with Typekit’s own usage, and then tapers off much like Gotham, whose coat-tails it supposedly rides.

I’ve included a few other popular sans-serifs to round out the picture. Poor Helvetica, presumably in decline since its Hustwit-driven revival in 2007. Myriad gets surprisingly little attention on Dribbble, considering how much real-world usage it sees. That humanist Open Sans looks like it’s on the way up. There isn’t much data yet, but I imagine in another couple of years we’ll be able to chart it satisfyingly against Freight Sans and extrapolate some far-fetched conclusions about their respective platforms (Typekit vs Google Fonts).

Fig. G: Serifs on Dribbble,  CLICK HERE TO VIEW

My attempt to reproduceFig. F but for serif type families was a complete failure. Fig. G demonstrates just how unsatisfying the data are in this regard. Is serif usage more fragmented? Or less exciting to tag? I suppose people have been (this is just my own hunch, not based on any formal data) using serifs for text and sans-serifs for display type, and Dribbble tends to highlight display text more than nicely typeset paragraphs. Nevertheless, it’s curious.

Pardon our progress

This data took far too long to collect, and far too long to (very amateurishly) analyse. There’s a lot to be improved about the analysis, most of which I’ve mentioned as it’s come up above. Dribbble itself is a limited sample, and the data I’ve collected isn’t normalised against changes in Dribbble’s community or usage patterns. Similarly, I’ve collected all tags on all uploads to Dribbble. It might make more sense to limit our data to uploads or uploaders that have a modicum of credibility (i.e. somehow incorporate the ‘like’ or ‘follower’ counts), or even somehow weigh data-points correspondingly. It might be interesting to chart the spread of tags across the community. (Do tags begin in the periphery and spread inward, or do they begin with the dribbblerati and spread outward?) And finally: is there any way to address the fact that Dribbble uploaders don’t consistently tag in a useful or elucidatory way?

Fig. H: Big (American) holidays on Dribbble,  CLICK HERE TO VIEW

I can nowise claim any kind of even passing statistical know-how, so I’ve uploaded a ~70mb CSV to Github. Please do fork, analyse, graph, chart, blog, correct, augment.4 That beautiful and meaningful chart I was fantasising about (with the rise of ‘flat’, decline of ‘skeuomorphism’, resurgence of ‘Gotham’, and short-lived reign of ‘Proxima Nova’) didn’t quite materialise. But I’m reasonably happy with Fig. H.

Source

Infinite Scrolling: Let’s Get To The Bottom Of This

Infinite scrolling promises a better experience for users. However, the good is often accompanied by the bad and the ugly. Once weunderstand the strengths and weaknesses of infinite scrolling, we can begin to use it to enhance our interfaces.

Human nature demands hierarchy and structures that are easy to navigate. But infinite scrolling sometimes leaves users feeling disoriented as they travel down a page that never ends.

The NeverEnding Scroll

The Good

Long lists are not new, but the way in which we scroll these lists has fundamentally changed since the arrival of mobile interfaces. Due to the narrowness of mobile screens, list items are arranged vertically, requiring frequent scrolling.

Infinite scrolling is highly trending as an interaction behavior on pages and lists. The basic functionality is that, as the user scrolls through content, more content is loaded automatically. With the popularity of social media, massive amounts of data are being consumed; infinite scrolling offers an efficient way to browse that ocean of information, without having to wait for pages to preload. Rather, the user enjoys a truly responsive experience, whatever device they’re using.

Pagination vs. Infinite Scroll
Pagination versus infinite scrolling (Large version)

Websites with lots of user-generated content today are using infinite scrolling to handle content that is being generated every second. By unspoken agreement, users are aware that they won’t get to see everything on these websites, because the content is updated too frequently. With infinite scrolling, social websites are doing their best to expose as much information as possible to the user.

Twitter integrates infinite scrolling effectively. Its feed fits the criteria: a large amount of data (tweets) and a real-time platform. From the perspective of the user, all tweets are equally relevant, meaning that they have the same potential to be interesting or uninteresting; so, users will often scroll through all of the tweets in their feed. Being a real-time platform, Twitter is constantly being updated, even if the user leaves their feed unattended. Infinite scrolling seems to have been created especially for websites like Twitter, which successfully employs the technology.

Infinite scrolling appears to have found its niche on the Web. However, there are also drawbacks that must be considered before assessing its value.

The Bad And The Ugly

With so much data to browse, users must stay focused on the information they are searching for. (Remember about being goal-oriented?) Do users always want a never-ending stream of data? Analytics show that when users search for information on Google, only 6% advance to the second page. So, 94% of users are satisfied with receiving only 10 results, which suggests that users find Google’s ranking of results to be relevant.

TO CLICK OR NOT TO CLICK

Google has implemented infinite scrolling for image search results but has yet to implement it for its general results. Doing so would eliminate the need for users to click to reach the second page. Google will probably maintain pagination because this pattern is quite symbolic for its brand. If it does switch to infinite scrolling, when would users typically stop scrolling? After 20 results? 50? When does an easy browsing experience become more complicated?

Looking for the best search result could take a second or an hour, depending on your research. But when you decide to stop searching in Google’s current format, you know the exact number of search results. You can make an informed decision about where to stop or how many results to peruse because you know where the end is. According to studies conducted in the field of human-computer interaction,reaching an end point provides a sense of control; you know that you have received all relevant results, and you know whether the one you are looking for is there or not. Knowing the number of results available provides a sense of control and helps the user make a more informed decision, rather than be left to scour an infinitely scrolling list.

Pagination: The Click Barrier
Pagination is a barrier of clicks. (Large version)

When items are distributed across Web pages, they are framed and indexed and have a start and end point. The information is presented clearly and orderly. If we select an item from a paginated list and are taken from that page, we know that clicking “Back” will return us to that page (probably to the same scroll position). Our Web search will continue right where it left off.

If you scroll the same list of results with infinite scrolling, you are left without that sense of control because you are scrolling through a list that is conceptually infinite. Let’s say you count yourself among the 94% who stop reading after the first page (i.e. 10 results) of a Google search. When the list scrolls infinitely, there is essentially no end to the first page. Rather than look for the end of the page, which doesn’t exist anyway, you decide to stop scrolling at the 10th item. This poses a problem with infinite scrolling, because the 11th item is directly in sight. With a paginated list, on which you wouldn’t see the 11th result, deciding not to continue browsing is easier. However, when the next results are already there,you’d probably just keep on scrolling and scrolling.

As Dmitry Fadeyev points out:

“People will want to go back to the list of search results to check out the items they’ve just seen, comparing them to what else they’ve discovered somewhere else down the list. Having a paginated interface lets the user keep a mental location of the item. They may not necessarily know the exact page number, but they will remember roughly what it was, and the paginated links will let them get there easier.

Not only does the infinite scroll break this dynamic, it also makes it difficult to move up and down the list, especially when you return to the page at another time and find yourself back at the top, being forced to scroll down the list once again and wait for the results to load. In this way the infinite scroll interface is actually slower than the paginated one.”

— Dmitry Fadeyev, When Infinite Scroll Doesn’t Work

When Infinite Scrolling Fails

The best companies are constantly testing and studying new interactions with their users. Increasing numbers of these studies are showing that infinite scrollingdoes not resonate with users if it does not support their goal on the website.

TEMPTATION

When you’re looking for that perfect search result and are tempted to continue scrolling into a wasteland of irrelevant results, time is wasted. Chances are that the best result will appear in the first 10 items. Therefore, infinite scrolling merelytempts you to continue reading, wasting time and decreasing productivity in the process.

OPTIMISM

Even more annoying is that scroll bars do not reflect the actual amount of data available. You’ll scroll down happily assuming you are close to the bottom, which by itself tempts you to scroll that little bit more, only to find that the results have just doubled by the time you get there.

EXHAUSTION

Infinite scrolling overwhelms users with stimuli. Like playing a game that you can never win, no matter how far you scroll, you feel like you’ll never get to the end. The combination of temptation and optimism play a big role in exhausting the user.

POGOSTICKING

Infinite scrolling often causes your position on the page to get lost. “Pogosticking” happens when you click away from an infinitely scrolling list and, when you return by clicking “Back,” are brought to the top of the previous page, instead of to the point where you left off. This happens because the scroll position is lost when you navigate away from an infinitely scrolling page, forcing you to scroll back down each time.

LOSS OF CONTROL

Infinite scrolling leaves you with the feeling that you might be missing out on information. You continue scrolling because the results are right there, but you feel overwhelmed because you’re losing control over the amount of data being shown. There is something nice about defined pages on which the amount of content is quantified, where you can comfortably choose whether to click to view more or to stop. With infinite scrolling, you don’t have control over the amount of data on the page, which becomes overwhelming.

DISTRACTING

Etsy, an e-commerce marketplace, implemented infinite scrolling, only to find that it led to fewer clicks from its users. Infinite scrolling was unsuccessful because users felt lost in the data and had difficulty sorting between relevant and irrelevant information. While infinite scrolling provided faster and more results, users wereless willing to click on them, defeating its very purpose.

Etsy's Home Page
Etsy’s home page (Large version)

UNREACHABLE

Have you tried reaching the footer of Facebook lately? The footer block exists below the news feed, but because the feed scrolls infinitely, more data gets loaded as soon as you reach the bottom, pushing the footer out of view every time. Footers exist for a reason: they contain content that the user sometimes needs. In Facebook’s case, the user can’t reach it. The links are repeated elsewhere but are harder to find. Infinite scrolling impedes the user by making important information inaccessible.

Facebook auto-loading News Feed and the unreachable footer
Facebook’s auto-loading news feed makes the footer unreachable. (Large version)

Footers serve as a last resort. If users can’t find something or they have questions or want more information or explanation, they often go there. If they don’t find it there, they might leave the website altogether. Companies that implement infinite scrolling should either make the footer accessible by making it sticky or relocate the links to a sidebar.

NOT EXCLUSIVE

Pinterest does not have a footer at all, which makes sense given the problem we just saw with Facebook. Through infinite scrolling, Pinterest emphasizes its profusion of data, an endless sea of inspiration taken from all over the Web.

Pinterest Ocean of Pins
Pinterest’s ocean of pins (Large version)

Images are faster and easier to scroll than text, so Pinterest and Google Images succeed with infinite scrolling to an extent. However, billions of images are on the Web, and users would prefer to see only the best of them. There is something to be said for exclusivity, which seems to be lacking in Pinterest’s layout.

Limiting the number of images on Pinterest’s home page, with an “Editor’s picks” or “Most popular” list, might make the website more appealing. How exclusive can a pin be when a ton of other similar pins are next to it?

Pinterest’s tactic of using infinite scrolling for its plethora of data suffers because itoverwhelms users. The collection looks bottomless, but its immensity is somewhat daunting, and browsing it might seem a waste of time. Ultimately, Pinterest is trying to expose users to infinite inspiration, but that actually undermines thehuman need for control. The amount of data becomes intimidating, and users are left with mixed feelings.

When Usability Wins

As mentioned earlier, Twitter integrates infinite scrolling effectively. The user sees an infinitely growing list of tweets and can comfortably click on a tweet to expand it in place, preventing the page from refreshing and, as a result, maintaining their scroll position.

Twitter's torn feed
Twitter’s torn feed (Large version)

On its mobile version, Twitter even adds a “torn paper” marker, indicating to the user where to resume reading. This subtle and simple solution enables the user to scroll up and down the list, while having a recognizable point to return to. Psychologically, that marker reassures the reader by dividing read and unread content. Such markers give the user a sense of control and a better perception of the content’s depth and how far they’ve gotten into it.

Twitter is not the only one. Discourse, an emerging discussion platform, also has infinite scrolling that empowers the user. The company considered the importance of infinite scrolling to its user experience and implemented an intriguing and unique progress indicator. The indicator appears when needed and remains in view (without interfering) while the user reads the content. The indicator numbers the item currently being viewed out of the total number of items. This is a great way to make the user feel in control, even with a lot of data.

Smart progress indicator on Discourse.com
The smart progress indicator on Discourse (Large version)

GO HYBRID

A hybrid of infinite scrolling and pagination is also a good option in many cases. With this solution, you would show a “load more” button at the end of a preloaded list, which, when clicked, loads another batch of items onto the list. The same behavior that infinite scroll does automatically, this button does on demand. The interface gains some of the advantages of infinite scrolling, without some of its drawbacks.

Because infinite scrolling requires the website to fetch so much content, the hybrid solution is used at times to control the data load. In Facebook’s news feed and Google’s image search, the infinite scrolling is automatic at first but becomes on-demand once a certain number of items have loaded. This maintains the interface while limiting the load on the server.

Hybrid Infinite Pagination on Google Images
Hybrid infinite pagination on Google Images (Large version)

Infinite Pages

Infinite pages take the concept of infinite scrolling to a new level. Websites that employ this concept are “one-pagers.” To remove the barrier of clicking to the next page, the designer turns the entire website into one long scrollable page. Examples are Unfold and Lost World’s Fairs.

On these one-page websites, the sections are spread vertically, one after another. This makes the whole website less comprehensible — hence, less accessible. These websites might not have infinite scrolling, but the user might still have that feeling of a never-ending page.

On infinite pages, the height of each section will vary according to its contents. Although the approach can make for some creative interactions, it can leave users disoriented and unsure where to scroll for the next piece of information. The scroll bar is hidden on many such pages, leaving users feeling lost as they unconsciouslylook for the scroll position to track their progress. Hidden scroll bars deprive users of that chance for rescue. Users shouldn’t be left helpless; the interface should clearly show them how to navigate the page.

Infinite Page
Not knowing where they stand can leave the users disoriented.

UX engineers need to take extra care when designing infinite pages. They must take into account accessibility; tell users where they stand by showing the length of the page and how much they’ve viewed. Solutions could include a fixed menu, a map of the page or a scroll progress bar.

Another trick is the parallax effect, whereby different layers on the page move at different speeds according to the user’s scrolling, creating the illusion of depth (as seen on Andrew McCarthy’s website). While it can help to create beautiful andinnovative experiences, it is sometimes heavily overused, and users can get confused by how much they need to scroll for more content. When the parallax effect is combined with animation, the user can get confused about whether the page is being scrolled by their movement or is moving autonomously. It’s wise to use the technique to enhance content, not as the content itself.

Let’s Get To The Bottom Of This

Infinite scrolling can be an innovative feature that greatly improves an interface by exposing content and making performance more efficient. But it needs to be used correctly.

Avoid the following sinkholes to achieve a strong infinite scrolling experience:

  • Users want immediate access to exclusive data.
    Users don’t want to be left to explore all of a website’s data on their own. When implementing infinite scrolling, identify what data is exclusive to your website and elevate it to the top of the page, and filter less relevant information.
  • Users want to feel in control.
    Infinite scrolling sabotages that feeling of control. Add a smart progress indicator, a fixed menu or a map.
  • Users often look for landmarks when scrolling.
    When scrolling through long lists, users expect to be able to easily distinguish between new and viewed data. Add landmarks along the interface to keep users oriented.
  • Consider conventional pagination or a hybrid solution.
    Good old pagination is always an alternative to infinite scrolling. And if that doesn’t fit the context, then a hybrid solution, using a “load more” button, could greatly enhance the interface.
  • Provide interesting content without an ambiguous interface.
    Having to traverse a never-ending list is logical only if the user leaves feeling that it was worthwhile.
  • Users often expect a footer.
    If footer-type information is functional to the interface, then it should appear at the bottom of the page. A fixed footer is usually the way to go with infinite scrolling.
  • An infinite list is still a list.
    Infinite scrolling still needs to meet common interface standards. Whether users take their eyes off the screen for a moment or click a link and then click “Back,” they expect to return to the exact point where they left off. Whatever your interface, make sure it meets users’ expectations.
  • Effects are nice to have but not a must.
    Many infinitely scrolling interfaces have various effects to show more data (whether by sliding in new content or another method). Be mindful not to focus more on effects than on presenting data in the most effective way possible.

USE IT CORRECTLY

Users are goal-oriented and find satisfaction in reaching the end of their exploration. To be effective, infinite scrolling has to account for this. Nothing is really infinite, not even these infinitely scrolling lists we’ve looked at. Users should always know where they stand, even when the content has not finished loading. They should know what the total amount of data is and be able to easily navigate the list. Infinite scrolling has to be implemented in the best possible way so that users can always find their way.

Source

Sticky Menus Are Quicker To Navigate

Most designers would agree that navigation is one of the most critical components of a website. Despite this, it is not always easy to use or access. Traditionally, users must scroll back to the top of the website to access the navigation menu. I recently wondered whether sticky menus makes websites quicker to navigate, and I conducted a usability study to find the answer. Let’s look at the results of the study, a few implementation techniques and some related challenges.

Sticky Navigation Sign

Sticky Navigation Defined

Sticky, or fixed, navigation is basically a website menu that is locked into place so that it does not disappear when the user scrolls down the page; in other words, it is accessible from anywhere on the website without having to scroll. Although sticky navigation can be applied to any menu, such as the footer or social media buttons, we’ll focus on the main (or primary) navigation of a website. The image below shows the difference between standard and sticky navigation on a mobile device.

Standard Vs Sticky Navigation

Usability Study

RESEARCH CONDITIONS

For the study, I created two test websites that were nearly identical. The only difference was that one of them had standard navigation and the other had sticky navigation. Forty participants were timed in completing five tasks on the first website. Then they were asked to complete five different tasks on the second website. The order of the tasks was alternated between users to balance out the familiarity factor. The websites were tested on desktop machines, and participants were not told the differences between the websites until the end of their session. Data was not analyzed until the testing was completed. The results of the study yielded two interesting conclusions.

1. STICKY MENUS ARE 22% QUICKER TO NAVIGATE

The data from the study indicated that participants were able to find what they were looking for quicker when they didn’t have to scroll back to the top of the page. 22% might not seem like a big number, but it can have a big impact on visitors. According to this data, sticky navigation could cut 36 seconds off of a five-minute visit to a website. Of course, keeping visitors on the page longer is only a benefit if you are enhancing the user experience along with it. Forcing people to dig through a website to find something does not qualify as such.

2. 100% PREFERRED STICKY MENUS WITHOUT KNOWING WHY

At the end of each session, users were asked whether they noticed the difference between the two user interfaces. No one was able to identify it. The changes were subtle, and none of the users caught on because they were focused on completing their tasks. Participants were then asked whether one of the websites felt easier to use. Six of the 40 participants had no preference, but of the 34 that did have a preference, 100% of them indicated that the website with the sticky navigation was easier or faster to use. Many comments along this line were made, such as “I don’t know how the websites were different, but I felt like I was spending a lot less time clicking with the first one.” Such comments indicated overwhelming favor for the sticky navigation.

Desktop Software Navigation Menus

Imagine typing a document in Microsoft Word and having to scroll up to the top of the first page every time you wanted to bold a word or widen the margins. Just the thought of that sounds frustrating. Most desktop software provides access to the entire navigation menu no matter what you are doing in the application. The Web browser is no different; we would find it ridiculous to have to scroll to the top of a website to access the address bar of a browser.

Some Good Examples

Facebook and Google+ recently adopted sticky navigation, but they are among the minority. Of the 25 most visited websites in the US, only 16% currently have sticky navigation. Below are some examples of other websites that do an excellent job of pulling this off.

Fizzy Software
This is a perfect example of horizontal sticky navigation at the very top. Everything feels comfortable while you’re using the website.

Fizzy Software Navigation

Web Appers
The navigation here is vertical and on the left, somewhat resembling Google+’s navigation. The only downside here is that if the screen’s height is shorter than 560 pixels, then the bottom portion of the menu could become inaccessible, which was the case when I tested the website on a netbook.

Web Appers Navigation

MakeBetterApps
Here is another great example. Making the navigation slightly transparent, giving a hint of the content beneath it, is a nice touch.

Make Better Apps Navigation

Rodolphe Celestin
This sticky navigation spreads all the way across the top, but when you scroll down the page, the design of the menu changes slightly. Simplifying the design like this can be a good technique, as long as it doesn’t feel inconsistent. Also, the designer has taken an increasingly popular approach by making the entire website just one page; the menu links are anchors that bump you down the page. Some nice transitions and hover effects make this website enjoyable to use.

Rodolphe Celestin Navigation

Ryan Scherf
The navigation on this website is vertical and only icons. The creativity here is impressive.

Ryan Scherf Navigation

Web Designer Wall
The sticky vertical navigation works well on this website because the menu has only four items. This works well enough for blogs that I wonder why others don’t adopt this approach.

Web Designer Wall Navigation

While sticky menus aren’t the most popular form of navigation, more and more examples are popping up all the time.

Getting Started

AVOID IFRAMES

This might seem like a straightforward way to implement sticky navigation, but avoid this method. iFrames cause more problems than they solve, particularly with cross-browser compatibility, security and search engine optimization. iFrames have their place, but they shouldn’t be a major part of your HTML layout.

CSS

CSS is a great way to implement sticky navigation. It also seems to be the most straightforward, most lightweight and quickest to code. The three things to pay attention to are positionmargin-top and z-index. Setting the menu’s position tofixed disables the element from scrolling with the rest of the page. This will likely throw off your margins if your navigation is horizontal, so you’ll want to adjust for that. Finally, use z-index with a horizontal menu to make sure the navigation sits on top of everything; this will make the other content slide underneath the navigation as you scroll. Here is the general idea:

#navigation {
   position: fixed;
   z-index: 10;
}

#header {
   margin-top: 50px;
}

You will have to play around with the CSS to make this technique work right for your website. Additional information can be found on the W3C’s website.

JQUERY AND JAVASCRIPT

Smart Sticky Bar Navigation
The Simple Smart Sticky Navigation Bar is one of many good JavaScript implementations.

If you would prefer a jQuery or JavaScript solution to a CSS one, then you could try out one of the following options:

Many other solutions and scripts are out there. Please include your favorites in the comments below.

What’s The Bad News?

Give Me The Bad News

There are many opinions on this topic, and some would argue that sticky navigation isn’t worth it. Here are some things to be aware of.

DESIGN LIMITATIONS

Going with sticky navigation could rule out some design choices that your team might not be willing to give up. For example, the most logical place for horizontal sticky navigation would be at the very top of the page, above everything else. While easy to implement, it might not be what your users need.

DISTRACTING AND INTRUSIVE

If not done carefully, sticky navigation can be distracting. Some sticky elements get delayed when bouncing back into position as the user scrolls down the page. Others are so tall or wide that they dominate the layout and impede access to the content. Navigation should be easily accessible but should not compete with the content for attention.

MOBILE COMPATIBILITY

Fixed-position CSS and certain JavaScript implementations lack support in some mobile browsers, which is a cause for concern among some developers. The article “Organizing Mobile” by Luke Wroblewski has some great principles to keep in mind when creating navigation for mobile devices. Responsive design techniques also offer some solutions for adjusting the navigation based on the size of the screen.

Be aware of the level of support offered by each device. Knowing compatibility issues beforehand will save you time in the end. When Can I Use? has some interesting information on support for position: fixed. Brad Frost has also done some of his own testing and analysis, providing some interesting insight in his accompanying video.

Conclusion

Why do we Web designers and developers continually force our users to scroll up and down the page in search of the navigation? This is not a problem in desktop software, and we now have the statistics to show the benefits of sticky menus. Navigation on 84% of the top 25 most visited US websites could be made quicker by implementing sticky navigation.

Of course, it’s not appropriate in every situation, especially when real estate is tight. But do seriously consider sticky navigation, while always accounting for usability and the overall user experience.

Source

————————————————————————

Continued Discussion:

Is a website with a Fixed Header good for end-users of a Web2.0 website?

http://ux.stackexchange.com/questions/45519/is-a-website-with-a-fixed-header-good-for-end-users-of-a-web2-0-website

Web Performance 2.0

In March 2012, Guy Podjarny ran a test comparing the performance of hundreds of shiny new responsive websites across four different screen resolutions. The results were very dissapointing. (1)

Two years into the rise of Responsive Web Design, after every imaginable sort of designer and developer had jumped into the train, it took a test to almost rock the theory to its foundations.

Guy proved that almost every known responsive site was overweight.

We’ve made the internet in our image… ObeseJason Grigsby

But, most importantly, every mobile user was receiving the same kilobyte overload as a desktop user.

The community had different reactions to the fact. Some claimed Responsive design wasn’t the ultimate solution, perhaps not mature enough for the challenges web designers face today.

Thankfully, the Web community can always count on a number of people who will grab the bull by the horns and turn the situation around. Modern Web gurus likeBrad FrostLuke Wroblewski or Christian Heilmann saw opportunity where others shouted crisis and managed to turn the problem to the community’s advantage.

If your website is 15MB, it’s not HTML5, it’s stupidChristian Heilmann

Web performance has traditionally been built around (no offence) developer-exclusive jargon.

Terms like GZIPing, uglifying, minifying, DNS Lookup, file-concatenation… This obscure words push designers out of the ecuation.

Smart people in the community, though, have since realized that the problem has a deeper root. It really doesn’t matter if you optimize or compress an ultra-high-res image, if your plan is to hide it from a mobile user and still make him download it.

Good performance is good designBrad Frost (2)

To achieve truly lightweight sites, performance shouldn’t only be a concern. It should be treated as a design feature.

To them, performance is like any other issue. Sites that overcome it are the ones who acknowledged it from the start. And the ones that overlook it are the ones that suffer it in the end.

Performance is about respect. Respect your users and they will come back.Brad Frost

The Why

It’s not only that you want users to have a good experience. If that was the case you could easily swap performance for a more important concern in your agenda.

Page Abandonment

Research shows 57% of users will leave your site if it takes more than 3 seconds to load. (3)

Google, page speed & SEO

Back from the spring of 2010, Google takes speed as a ranking factor. (4)

The impact is not major for average-speed sites, but if the page falls behind a certain threshold, it will be punished by the company’s search algorythm.

This proves speed not only is a concern when talking about User Experience. Be aware of loading speed if your site is to be ranked well among the competition.

Bandwidth considerations

Back in the day, people used to talk about the very abstract concept of ‘Mobile Context’. Google´s famous theory breaks mobile users down to three types (5):

Repetitive Now

People that use their phone to stay up to date with ongoing, repetitive changes (sports scores, Facebook feeds or stock market)

Bored Now

Users that put their phone out while waiting for something to happen.

Urgent Now

Pretty self explanatory

Sounds assumable, right?

Well, the truth is there is no truth about this. There is no 'mobile context'. People will use their phone not only when they are walking in the street, travelling by train or relaxing in their home. They do everything at the same time!

Phones follow people everywhere, so people use them anywhere.

Mobile context is important, but first we need to figure out what the heck it is.Tim Kadlec

Luke Wroblewski shows some really interesting stats: (6)

Where are people using mobile devices?

  • 84% at home
  • 80% during miscellaneous downtime throughout the day
  • 76% waiting in lines of waiting for appointments
  • 69% while shopping
  • 64% at work
  • 62% while watching TV (alt. study claims 84%)
  • 47% during commute in to work

As new situations emerge, as new markets and different habits rise, mobile context will change. We can safely assume that the concept of mobile context will always be on the move, until people stop using mobile phones.

This leads us to keep an eye on bandwidth. There is only one scenario where you can serve users an obese website and get away with it: serve it to their macbook pros, while they are at home in UK or the USA with a full bandwidth.

But the rest of possible situations, which are a great many, have to be covered aswell. These include the seemingly endless stream of devices poured every day into the market, which people use to visit websites.

You don’t get to decide which devices access your site, your users doKaren McGrane

They include the countries which didn’t have that many smartphones a few years ago, but are ruthlessly getting ahead.

If your stuff, if your content, if your information, if your products, if your services are not available on mobile, they don’t exist for these peopleKaren McGrane

But more importantly, they include all the places people will be at when using your site. So you have to watch all bandwidths. It’s not only inhabitants of poor areas of the world clearly don’t have the same data-speed coming their way. People will try to access a site at work, with a 100mb/s connection; at home, with 2 to 30mb/s and also with 3G, and also with 4G, and also with a data plan, etc., etc.

To put it bluntly, Responsive design is not anymore about screen sizes but about different scenarios, so the solutions must be flexible, adaptable and thought out top to bottom.

And How?

Well, glad you asked.

We said before not to look at performance as a bunch of automated tasks run server side that help with an already doomed site. There are ways to undertake this concerns and turn them into a competitive advantage.

What to avoid

Guy Podjarny cites three main reasons for the number of bloated responsive websites we see out there: (1)

Download and Hide

Assets are still downloaded, but hidden.

Download and Shrink

High-res desktop-level images are downloaded, and shrinked to fit the users screen

Excess DOM

There is no way to avoid browsers parsing and processing all areas of the DOM, including the hidden ones

A preemptive approach

There’s a great deal of information out there about why websites keep failing to surpass expectations in performance. But what most people come to say is something like ‘Be responsible from the start’. All techniques I’m going to cover have been around for a while. To me the interesting part comes in how they mix and intertwine, covering each other’s flaws and combining their strenghts. It is now, deep in the mobile explosion that they show how powerful they are.

Progressive Enhancement…

…is all about providing a web experience reduced to the essential and take it from there.

A couple of years ago this theory was taken mostly from a browser point of view. With emerging technologies like HTML5, CSS3, jQuery and so on, the web makers had kind of forgotten about their users. Quite a big percentage of them were getting an incomplete form of their site, relying a bit too much on this shiny new tech.

Now that Webkit engines and Firefox and others have taken over much of the market share, the problem is the enormous quantity of devices with browsers that don’t have the capabilities of the brand new iPhone or Samsung. Again, Progressive Enhancement is the only approach which takes care of these forgotten players first and leave the shine for the ones that can take it.

Mobile First Development

Back in 2009, Luke Wroblewski proposed designing mobile first for three reasons: (7)

  • Mobile is exploding
  • Mobile forces you to focus (allowing you to get rid of the clutter that stems from having too much screen real estate)
  • Mobile extends your capabilities (with technology like GPS, geolocation, multi-touch gestures, accelerometer, cameras…)

Since then, Web design has been rapidly shifting to this approach. Along the way not only designers, also many developers, have pointed out that building mobile first gives you an edge over desktop development, very related to Luke W’s second point. Progressive Enhancement and Mobile First Development have suffered a fusion of sorts. Devs start building for mobile and progressively enhance from there, taking larger screen space as an enhancement over a mobile core foundation.

Jordan Moore makes a good summary of the reasons(8). He argues that, since 'we can't safely bet on connection speed''The 'responsible Web designer' would build for the lowest point of entry - a mobile-first approach, assuming for the slowest connection speed and building up from there to larger breakpoints for faster connections'. In the future, we will be able to rely on solid bandwidth detection, but for now it is a good idea to take it as a concern and try not to take any steps in the wrong direction.

To sum up:

Code the site for the lowest resolution and possibilities that you care about. Make true use of Progressive Enhancement from the start. Build extra functionality, enhanced visuals and interaction when it can be used.

RESS: REsponsive Web design + Server Side components

To many people, Responsive design had kind of an essential short-coming. It relied mainly in screen width detection.

As more and more types of devices emerge, hybrid devices like touch screen laptops and so on, feature detection has become essential for Responsive design. Libraries that provide it, mainly Modernizr, have bloomed and are now used on most projects. They help devs valuate whether the client’s browser supports certain functionality and provide it accordingly. But many times it’s tricky to rely on browsers, because ‘they’ will say they support features when, really, ‘they’ do whatever they want. Support for new features is usually partial.

RESS was born to provide a solution. Like Mobile First, the term was coined by Luke Wroblewski in 2011 (9). It relies on detecting the user’s device type, evaluating it and providing an experience taylored for it. To do this, there are heavy tools out there, like WURFLDeviceAtlas or lighter ones like Browser Gem, that read the user agent string and start from there.

Evaluating the device type has other advantages. It allows devs to serve different templates depending on the user’s device. Say you are building a ver large site, and you want your mobile navigation to be a simplified one, that doesn´t take half as much space as the desktop one. You could either play with content, showing and hiding stuff, moving divs around with JavaScript, or you could have different templates for mobile and desktop screens and have the server decide which one to serve.

This gives Responsive design an edge over Mdot sites. Mdot’s only advantage until RESS came along was providing an experience specific for mobile devices.

The BBC (very smart people, with millions of readers across the globe and a big responsibility toward their users) talk about how RESS and Progressive Enhancement could work as one and only. They call their approach Cut the Mustard! (10). It consists of creating a core experience that will work on every device you can imagine. After that, they evaluate the device on the server and they decide whether or not it ‘Cuts the mustard’. If it does, a progressively enhanced experience is handed out. But again, if it doesn’t, the user can still access the core content.

Conditional Loading

Mobile users want to see our menu hours and delivery number. Desktop users definitely want this 1mb png of someone smiling at saladMat ‘Wilto’ Marquis

Let’s take a couple of points of view into account:

  • Mobile users want THE content, as much as desktop users.

If your content is accessible from a URL, it will be accessed by mobile devices.Brad Frost

  • Mobile forces you to focus. There are some constraints designers have to embrace to serve the same content, like bandwidth and lesser screen size.

Also refered to as ‘Agressive Enhancement’, this development technique allows designers to focus on the core content and progressively enhance it for bigger screens. It provides basic access to certain content that can later be injected on the page when space becomes available.

It might be more accurate to think of conditional loading as a content-first approach. You don’t have the luxury of sidebars or multiple columns to fill up with content that’s just nice to have rather than essentialJeremy Keith

Use excellent tools like MatchMedia, that mimics CSS behaviour evaluating screen size in JavaScript.

Lazy Loading

Image and user heavy sites that need to be optimized for mobile, like Facebook, Twitter or Pinterest, make use of Lazy Loading to provide a better experience. When you first load the page, a number of posts is loaded. When you scroll down, the designer assumes it is because you want to browse through even more content, so it is injected in the page via Ajax. This makes the page load much faster by avoiding DOM excess.

Setting a performance budget

Tim Kadlec argues that setting a maximum page weight and being always aware of it is the ultimate way to keep page load down (11). ‘Set your goals and stick to them’. Steve Souders mentions three options to choose from, if you fall over your budget:

  • Optimize an existing feature or asset
  • Remove an existing feature or asset
  • Don’t add a new feature of asset.

To me this sounds a bit radical, but it makes a point of closely following the overall performance of a site over time and with each new feature.

Let’s get Technical!

There are certain methods to achieve speed, that work in a more technical and less conceptual level.

Image Techniques

Images constitute around 60% of websites. If you are serving mobile users with unknown bandwidth connections desktop-sized images, you are basically dooming your site to poor performance

The trick to overcome this is to serve different versions of images, depending on screen size or type. You would serve a small image to a mobile phone and a high-res one to a desktop. You would serve a double-sized image to a Hi-DPI device.

Responsive Images

Designers and developers all over the world have been fighting to get responsive images into the HTML specification. Mat ‘Wilto’ Marquis is one of the most outspoken. The battle is not yet won, but there are a number of solutions that rely on JavaScript to achieve a desired result. Scott Jehl, also from the Filament Group, wrote a plugin that mimics the markup proposed by the community and works like a charm: PictureFill

Compressive Images

Daan Jobsis, a dutch designer, found a very strange phenomenon when compressing images with Photoshop (12). He proved the following: Take an image, double its size (200%), compress it to 25% or less its original quality, resize it back in the browser(100%). The image will not only be lighter in size but already optimized for HiDPI screens, since its pixel density is already doubled.

The only observed problem is that the browser might have a hard time painting a double-sized image back to its original size (if it has to do it a hundred times, like in image-heavy sites), so a little bit of testing is required to see if this is the optimal solution.

Vectors VS Bitmaps

SVG images are the way to go at the time. They are completely scalable, so they will perform better in any screen. Providing fallback is very easy through Modernizr.

Icon Fonts

Technically they are vector based images, only served as a font. As Chris Coyier puts it, ‘Icon Fonts are Awesome because’:

  • You can easily resize
  • You can easily change the color
  • You can easily shadow their shape
  • They will work in IE6, unlike transparent PNGs
  • You can do everything you can do with images
  • You can do anything you would do with typography

HiDPI images

Dave Bushell wrote recently a very interesting article with some thinking on HiDPI images (12). He argues that, even if today we have the possibility of serving iPhones, iPads and other modern devices with images that will fulfill their screen capabilities, it is still too soon to assume a site is not going to get crippled by doing it.

Does a fast connection and high pixel density mean users even want higher quality? Not likely on mobile data plans.Dave Bushell

The point is to do it but do it sensibly, considering the case before jumping into 4x images.

What’s next

Google recently developed a new image format, WebP. It provides lossless and lossy compression for Web images, resulting in files 3x smaller, compared with PNG.

There are simple, lightweight JavaScript libraries that convert to and from WebP available today. Considering the impact of Google’s latest tools, it’s probably a good idea to start experimenting today in order to handle an image-heavy site .

Asset Loading

Load assets carefully and in order. Controlling this aspect provides a big advantage, by allowing the page to render the basic content and enhance it afterwards.

CSS, Images

Controlled loading through media queries, conditional or lazy loading and responsive / compressive image techniques

JavaScript

Make use of HTML5 functionality, like async or defer. There are also loading helpers like RequireJS that can handle loading and dependencies.

Advertising, Social Widgets or any third party assets

Just inject after load.

Old-school Performance Techniques

They have been around for a while, but are still as relevant today.

Reduce the number of HTTP Requests

To achieve this devs have to think resource by resource, but here are a number of guidelines:

  • Concatenate all CSS files or make use of CSS Preprocessors to compile them into one file.
  • Unify all JS Plugins under the same file and always load them in the footer, unless they really need to block the rendering of the page (if you load Typekit fonts in the footer, you will get the famous FOUT or ‘Flash of Unstyled Text’).
  • If you must use PNG images, use sprites. They unify all images in one and make use of CSS to cut the pieces. There are a number of online solutions to do this.
  • Make use of the data URI scheme where possible, that allows you to include images as inline data, getting rid of some more HTTP requests.

Reduce the number of Bytes

Uglify, minify every Script or CSS file you call from the page. Set your server up to allow GZIP compression and expansion and GZIP every asset.

In Summary

The importance of Web performance has been slightly overlooked since the birth of Responsive design.

Designers and developers have been focusing on how to solve the Responsive puzzle and, along their way, a new multi-bandwidth, multi-device, multi-location Web is starting to come into focus.

To be prepared for tomorrow’s problems, we have to include performance as an essential consideration, as the Desktop-centered Web is disappearing before our eyes. The mobile user is hastier and readier and won’t jump through hoops to get the content, and since more and more sites spring every day, being fast will mean being ahead.


Reference

1. Performance Implications of Responsive DesignGuy Podjarny

2. Performance as DesignBrad Frost

3. Website abandonment happens after 3 seconds

4. How Page Load Speed Impacts SEO And User ExperienceSpencer Yao

5. Organizing MobileLuke Wroblewski

6. When & Where Are People Using Mobile Devices?Luke Wroblewski

7. Mobile FirstLuke Wroblewski

8. Responsible Considerations For Responsive Web DesignJordan Moore

9. RESS: Responsive Design + Server Side ComponentsLuke Wroblewski

10. Cutting the mustardBBC´s Responsive News

11. Setting a Performance BudgetTim Kadlec

12. Retina Revolutie Follow UpDaan Jobsis

13. The Raster Image ParadoxDave Bushell

Follow the discussion 

Source

Five Responsive Web Design Pitfalls To Avoid

There are number of nasty traps to avoid when making your site responsive. Brad Frost of R/GA reveals five of the biggest ones and how to sidestep them

Creating great responsive experiences requires a hell of a lot more than media queries. If you think creating squishy layouts is all this responsive thing is about, you’re missing the point. The fact is we need to deliver a solid user experience to a growing number of web-enabled devices, and creating entirely separate device experiences simply isn’t scalable in the long run. Creating adaptive experiences is a smarter way forward, but that doesn’t mean this approach isn’t without its challenges.

Here are some of the pitfalls you want to avoid as you travel down the responsive road:

1. Hiding content

Because responsive sites share a single code base, they have a better chance of achieving content parity, which is great. However, that doesn’t mean that it’s all gumdrops and butterflies. There are still many responsive sites that hide or remove content for smaller screens in order to deal with screen real estate constraints.

Follow this simple guide: don’t penalise users for the device they happen to be browsing with. People are coming to our sites and services with expectations, and it’s our job to make sure they’re able to achieve their goals. Mobile users will do everything desktop users will do, but it must be presented in a usable way. So do all that you can to make sure as many people as possible can access your content and functionality.

It’s also worth noting that content that gets hidden with CSS still gets downloaded, which is terrible for performance and brings us to our next pitfall to avoid…

2. Bloating it up!

OK, so you’re not gutting content for small screens and you’ve made an effort to deliver a full experience regardless of context. All’s well with the world, right? Well no, because now you have a bunch of stuff to load and that takes time. 74% of mobile users will leave after 5 seconds (PDF) of waiting for a page to load, and the unfortunate reality is that only 3% of small screen versions of responsive sites are significantly lighter than their large screen counterparts. That means users bear the burden of a potentially massive download.

normal page on Barack Obama’s responsive site weighs over 4MB. Four. Megabytes. This is unacceptable by any standard, but especially falls apart when you consider users who may be on EDGE, 3G or poor WiFi connection.

Obama Mobitest Performance Results

For a site whose goal it is to reach out to the general population (all with different mobile races, mobile creeds, mobile colours and mobile religions), this causes serious accessibility issues:

Sure, part of this is RIM’s doing, but these are real constraints that we need to be aware of

Sure, part of this is RIM’s doing, but these are real constraints that we need to be aware of

One of the biggest challenges of creating responsive web designs is the balancing act of delivering a full experience while still maintaining a snappy user experience across the board. Cut away the cruft, follow performance best practices, don’t assume a strong connection by default, and look for ways to exploit great techniques like conditional loading to keep initial page sizes down.

3. Ignoring contextual conventions

A phone is not a tablet is not a laptop is not a desktop is not a TV.

Each device provides its own unique form factor, interface conventions, constraints and opportunities. We need to be considerate of all these variables in order to create experiences that feel natural to the user. Now I’m not recommending recreating every platform’s native UI in the browser, but we do need to be mindful of how people hold their devices, what icons they’re used to seeing, and so on and so forth. A good responsive experience reaches outside of the sandbox that is the browser and is sympathetic to the user and the device context.

Responsive web design by definition is not mobile design, so it’s up to us to introduce contextually-considerate elements to our designs. That means handling responsive navigation in a way that makes sense to visitors across contexts. That means designing for touch. That means avoiding forcing mobile users to sift through ridiculously long amounts of disparate content just to find what they’re looking for.

Let’s account for the many differences across these devices, understand that some compromise is inevitable, but put forth a solid effort to be more considerate of context.

4. Serving a one-size-fits-all experience

Mobile is much more than just various small screens, and these emerging contexts unlock entirely new use cases, patterns and possibilities. We shouldn’t sell ourselves short by only creating responsive layouts. For example, we sometimes forget that mobile phones can get user location,initiate phone calls, and much more. Hopefully soon browsers on all these gadgets will have access to even more device APIs, further pushing the boundaries of what’s possible on the web.

We should all we can to make the entire experience respond to what the device is capable of. Addressing constraints first gives us a solid foundation to stand on, then we can utilise progressive enhancement and feature detection to take the experience to the next level.

5. Relying on device dimensions

320px. 480px. 768px. 1024px. The fold. Oh God, the fold.

The fact of the matter is that we don’t control what our visitors’ browser sizes are, nor what dimensions manufacturers decide to make their devices. Believe me, they’re trying every size in the book.

Devices of all shapes and sizes

Why you should never rely on device dimensions

In addition, page height has always been even more of a moving target because of bookmarks bar, browser chrome and the Ask Jeeves toolbar. But now in the mobile web world, a web experience is often not seen through the lens of the browser at all. We visit links through Facebook, Twitter and other apps, each of which has its own custom chrome for containing web views. Of course hierarchy of content still matters and you want to get to the guts of the page as soon as possible, but you can’t get all worked up over the available pixel height, learn to let go.

In his article Fanfare for the Common Breakpoint, Jeremy Keith eloquently states that “it’s not about what happens at the breakpoints, it’s about what happens between the breakpoints.” That means our designs should hold together irrespective of any particular dimension.

Let the design itself sort out where breakpoints should occur. I absolutely lovethis advice from Stephen Hay:

“Start with the small screen first, then expand until it looks like shit. Time to insert a breakpoint!

By letting the content itself determine the breakpoints of our responsive designs, we’re preparing our designs to look great in not just today’s landscape, but tomorrow’s as well.

Do the evolution

We’re at the tip of the iceberg as far as creating adaptive experiences go. While these pitfalls (and many more not covered in this article) exist, they are no reason to shy away from creating adaptive experiences. With more connected devices of all shapes and sizes come onto the scene every day, we as web creators have an opportunity to be there when they arrive. While it’s admittedly a bit daunting, we should accept the challenge and embrace the opportunity to reach people wherever they may be.

Source

15 Years of Apple Homepages

I was looking at screenshots of Apple.com’s former homepages (using the Internet Archive Wayback Machine) and decided to compile them into a slideshow. With the exception of Apple’s homepage in 1997, it’s pretty remarkable how little the core design has changed:

After 15 years, the layout of Apple.com is still the same: prominently feature the latest product, with 3-4 little boxes below that highlight other recent products and company news. The homepage has become more evident and intuitive each year. Bigger pictures, less copy, bolder text, fewer items to click… It’s like a giant billboard. They stuck with a format that worked and continually refined it. [The two biggest changes: they moved the navigation bar to the top in 2000, then gave the entire site a facelift with the introduction of Leopard in 2007.]

It goes without saying that Apple’s strength is design, but their homepage deserves credit for being great for so long. Ever since its early days, Apple.com has moved in the direction of being more friendly, focused, simple, and beautiful.

Bonus: Take a look at how MicrosoftDellHPIBM, and Sony’s homepages have evolved over the years. Much bigger redesigns.

Why We Need Responsive Images

The topic of responsive images has been one of the most hotly debated topics amongst web developers for what feels like forever. I think Jason Grigsby was perhaps the first to publicly point out that simply setting a percentage width on images was not enough, you needed to resize these images as well. He showed that if you served appropriately sized images on the original responsive demo site, you could shave 78% off the weight of those images (about 162kB) on small screens.

The discussion has evolved since then with debates over what sort of solution we need (server-side, client-side), new markup (srcset vs picture) and even, in some cases, wondering whether we really needed to worry about it at all.

It’s a messy issue for sure. The current solutions for responsive images do come with some complexity and overhead. If you’re using a client-side solution and don’t want to make more than one request per image, then you end up breaking the preloader. As Steve Souders explained rather well, this can have a very negative impact on the time it takes for those images to actually start appearing to your visitors.

No doubt there are trade-offs. Complexity of solutions, preloader versus file size—these each have to be considered when making the determination of what solution to use. Eventually we’ll have a native solution which will take care of the preloader issue, but browsers sure seem to be dragging their feet on that.

In the meantime, I was curious just how much page weight could be saved with a responsive image solution in place. I know that on the projects I’ve worked on, the savings has often been huge, but I wanted to see how consistent my experience is with the web as a whole.

Experiment time!

Yoav Weiss created a bash script called Sizer-Soze that, with the help of ImageMagick and PhantomJS, determines just how much you could save in file size by serving optimized and resized images. The script is built for one url at a time, so I modified it slightly to let me loop through a list of 471 URLs (the same list used by Guy Podjarny for his analysis of responsive performance). My bash scripting skills are minimal (read: nearly non-existent), but thankfully Yoav is far more skilled there than I and was happy to help out and make the whole thing run much more efficiently.

The script looped through the 471 urls, spitting out the results into a CSV. Each site was tested at widths of 360px, 760px and 1260px. Numbers were collected for total original image size, size of images if they weren’t resized but were optimized, and size of images if they were both optimized and resized to match the size they actually displayed at (so if a 1200px image was displayed at 280px wide, the script resized the image to 280px and compared the two file sizes).

If Sizer-Soze came across an image set to “display:none” it would re-check the dimensions every 500 milliseconds (for a maximum wait of 25 seconds) to see if things had changed. This was done to account for image-based carousels where images may have been hidden initially but then later revealed. If the image became visible during that time, then the dimensions were used to process the file savings normally. If the image was never displayed, the entire weight of the image was counted as wasted.

Even with that tweak, there are few caveats about Sizer-Soze:

  • It does not make a distinction between 3rd party images and images served by the site itself. So some of the weight can be attributed to things like ads.
  • It does not analyze background images. That’s fine because that’s not what we want here anyway, but its worth noting that potentially even more bytes could be saved.
  • It won’t be able to pickup some clever lazy-loading techniques, so again, its possible that some sites would actually be able to save even more than the reported numbers.
  • It doesn’t include data-uri images in the totals as the file name exceeds the length limit for the script.

After looping through, the list shortened to 402 different responsive sites. Some of the original 471 moved to new URLs or apparently went AWOL so Sizer-Soze couldn’t follow along. Others had no images in the source code—either as a result of some sort of lazy-loading mechanism or by design. Still, 402 sites is a pretty good base to look at.

Results: Total Savings

On to the results! First up, the totals.

Viewport SizeSum of Original SizesSum of Optimized SavingsSum of Resized Savings360237.66MB12.86MB171.62MB760244.39MB13.30MB129.34MB1260250.08MB13.70MB104.31MB

It’s not too surprising to see that the original size (what’s being served now) is pretty consistent from screen size to screen size. Guy’s research, and many others, have already demonstrated this pretty well.

What is staggering is just how massive the savings could be if these sites served appropriately sized images. At 360px wide, these 402 sites combine to serve 171.62MB of unnecessary weight to their visitors . That’s a whopping 72.2% of image weight that could be ditched by using a responsive image technique.

It’s not just small screens that would benefit. For 760px and 1260px sized screens, 52.9% and 41.7% of image weight is unnecessary.

Results: Average Savings

Let’s look at the savings in terms of per-site averages.

Viewport SizeAvg. Original SizeAvg. Optimized SavingsAvg. Resized Savings360603.89kB32.68kB436.08kB760622.53kB33.88kB329.47kB1260635.43kB34.81kB265.06kB

Looking at it from the perspective of an individual site, the numbers feel even more impactful. For each screen size, sites on average would shed about 5% of the weight of their images (from 32-34kb) by simply doing some lossless optimization. Considering that this could be automated easily into a build process, or manually done with tools like ImageOptim with little effort—that’s an easy 5% improvement.

Unsurprisingly, the gains are much more significant if those images get resized to an appropriate size as well. At 360px, the average site would drop 436.08kb. Consider that for a second. One optimization (resizing images) dropping that large of a chunk of weight. That takes image weight for a page from 603.89kB to a mere 167.81kB. That’s a huge difference that shouldn’t be dismissed.

While the improvements are slightly smaller for larger screen sizes (as you would expect), using some sort of responsive image technique would still save 320kB for sites displayed at 760px and 265kB for sites displayed at 1260px.

Conclusion

We spend a lot of time talking about responsive images online—debating the approaches, trying out new solutions. Sometimes it can be a little discouraging that we still haven’t gotten it ironed out (I know I feel that way frequently).

But the web needs us to be diligent. It needs us to not settle for seemingly simple solutions that sacrifice performance. It is extremely rare where one optimization lets us knock off such a significant amount of page weight, but here we are staring one such technique right in the face.

72% less image weight.

That’s why we need a responsive image solution.

Source