And that’s where this book comes in. The Book of CSS3, written by Peter Gasston, is all about CSS3 just as the title says. And it’s a book you more than likely should have, even if you think you already have a pretty good handle on everything CSS.

Read full post

Posted in CSS, Reviews.

Copyright © Roger Johansson

A couple weeks ago we talked about giving up on controlling our designs; understanding that from now on we won’t know what kind of device (with what constraints) users will be on — not without investing tremendous resources. Their constraints and capabilities will vary widely, in many different ways. Pixel perfection must become a thing of the past – so let’s talk about how you actually design for a world without pixels.

What We Can’t Do

For those of us accustomed to fixed-width design, we’re used to plotting out and planning for specific image sizes and rigidly defined spacing. Well, we can’t do that any more. That fine-grain control has also allowed us to substitute sweet-looking graphics and effects for really solid interaction and flow. We should never have tried that anyways, but now we have to move beyond it.

What We Can Do

When you’re designing a site or an app for multiple devices, consider these things:

• Use images sparingly. Images will need to be large enough in dimensions to fill the allotted space on a desktop browser, but small enough in file size to load quickly on a smartphone. Use CSS3 to your advantage here with generated gradients, CSS box and text shadows, and font-face for typography. We'll talk another time about using tricky solutions like Scott Jehl's Repsonsive Images code.
• Structure your page in the order someone will use it. Where possible, ensure that if the layout of your page changes, the flow of someone using it isn’t harmed. If your sidebar were to be placed after the rest of the page content, are you moving a critical action to the bottom of the screen?
• Plan to turn things off. Smaller devices require a more focused experience - don’t be afraid to turn things off for small screens, or to selectively show/hide elements that make sense in certain situations. Bonus: if you’re turning something off for mobile, do you really need it on a larger screen?
• Know your audience. Certain conventions make sense on the desktop, and on mobile, but they aren't always the same. Make sure you understand user expectations for common elements like modals, or toolbars — and how that applies to various devices.
• Think about your interactions. Are you putting something critical in a hover state? You don’t know if your user will be on a device that can hover. Planning to have a fixed login element? Be careful - not everything supports fixed positioning. Carefully consider what you want users to do, and think about how they’ll do it on different devices.
• Review with builders. If you're going to build out the design, review it with other front-end designers or engineers. If you're not going to build it, do design reviews with the people who are. They'll help you find the holes in your design, and then help find solutions.

Should I be doing this now?

Right now, you could still design pixel-perfect sites and apps, if you focus on particular devices. The iPhone is a fairly well known quantity, as are the iPad and some specific Android phones or tablets. Creating specific experiences still has some benefits - apps are a good example of this. The investment required is higher, but it can pay off.

That will change though — the balkanization of devices is unavoidable and already happening. The cost of creating specific experiences will only rise, and quickly.

This is Actually Awesome

It’s easy to think that designing for an unknown is difficult, or too much trouble - but this is exactly how we focus in on what matters. It’s not just pixels that make up great web design, it’s considered interactions, and solid benefits, and empowering users to do what they need to do on whatever device is at hand. That’s how we’ll design for the future.

In an upcoming post we’ll get into nuts and bolts and talk about actually building the front end without pixels.

The Job Description

Have you read Linked? Do you get excited whenever Twitter releases a new feature? Do you use Facebook and LinkedIn for professional purposes? Do you enjoy creating social products? Do you enjoy working in an iterative, collaborative environment?

If the answers are yes and you want to change the world for jobseekers, you need to join the Jobvite Product Team.

Jobvite is looking for a Contract Interaction Designer who can improve our already groundbreaking products within the recruitment market.  You must be excited about the user experience process, and love collaborating with Product Managers to build bleeding edge products in the social recruiting space. You must also understand Facebook, Twitter and the social ecosystem, and can bring that vision for next generation social product to Jobvite. You must love talking to recruiters, collaborating on product ideas, working with  developers to create great user experiences.

You get extra credit points if you like designing the product in wireframes and can complete visual designs in production level comps!

The Role

Candidates should have at least 5 years of successful interaction design experience developing consumer web applications, with experience integrating with social platforms. The ideal candidate will have the ability to  work with Product Managers to create well-designed solutions. Experience working with Agile; we are constantly iterating and work fast to stay one step ahead of the development team.

Responsibilities

• Translate requirements into concepts and elegant user experience design
• Create interaction models, user task flows, screen designs, and UI details that promote ease of use, improving and optimizing the user experience
• Develop and maintain high-level wireframes and navigation maps that communicate your design ideas
• Build prototypes to demonstrate and test your recommendations
• Gauge the usability of new and existing product features and make constructive critiques and, if needed, suggestions for change

Requirements

• Outstanding portfolio of proven, innovative, solid work
• Extensive experience developing complex web application interfaces and a passion for designing compelling, user experiences
• 2 to 5 years of experience designing for applications/systems
• Demonstrated experience in creating various prototype methods and knowledge of best practices
• Clear communication, organization, and writing abilities
• Ability to multi-task, prioritize projects, and communicate timelines
• Experience designing for social sites and applications
• Experience designing for B2B web applications
• Experience with Omnigraffle, PowerPoint and Photoshop
• Ability to mockup ideas in HTML/CSS

Pluses

• Visual Design Skills in the consumer space

Apply Here..

Technically, the only difference between an installed app and a website is that the app has access to more of your device’s hardware. Platonically, from a human-need perspective, they’re the exact same thing: A collection of tools and information that lets you do something.

• It’s a particular garden or destination.
• You have to learn that it exists.
• You have to understand what functionality it offers or what tasks it lets you accomplish.
• You have to know how to navigate to it.
• You have to learn how to use it.
• You have to establish a relationship with it: by downloading, creating an account; paying for it.
• You have to remember it the next time you want to use it.

When I launched the app yesterday there was a Firefox bug I left in which prevented clicks from registering. I fixed it soon after but as half the people who tried the app are on Firefox I’m guessing it left a lot of people confused as to why the app didn’t respond. Apologies if that happened to you, I hope you give it another shot.

Thank you to everyone who left feedback and suggestions in the previous post. Here are 3 updates:

1. More customization

I’ve added a couple of important features to the test creation page. Firstly, there’s now an option to make the test private to keep it out of the public test pool. This can be useful if you don’t want to reveal unreleased product interfaces, or more important, if you want a more targeted audience as in the case of foreign languages.

Secondly, you can now customize the maximum number of clicks a tester can make before the test ends. By default I used 4 clicks to allow people to set up tests that ask the user to click on multiple areas. Now you can trim that down to 1 if you just want one location, or more if you like. This will default to 1 from now on as this is what the majority of the tests focus on.

2. Improving test quality

A couple of people uploaded inappropriate stuff that’s clearly not testing anything useful (there was even one ad!). This is to be expected with an app that doesn’t have a registration barrier. I do want people who take tests to get relevant material so they can actually get value out of them by seeing the results. The public test pool needs to be cleaned up a little.

For this reason there’s now a “Flag abuse” button on every public test. If a few people click this button, the test is taken out of the public pool circulation. It’s a soft measure, so the test still remains up and can keep collecting results from the testers the user brings themselves, it’s just no longer part of the public test pool.

One thing I want to note about the public test pool is that it focuses on the more recent tests, so over time the older tests are also taken out of circulation. This ensures the inflow of testers are not spread out too thin.

3. Improving the flow

I’ve added more buttons to make it easier to take multiple tests. On the test page there’s now a skip button, which lets you go right ahead to another test if the one you’re on doesn’t make sense (e.g. it’s in another language—another problem I’ll need to try and fix). This button is hidden on private tests as they are more targeted.

When you complete a test you’re directed to a thank you page. Here again there’s a new button letting you take another test. Results page now has a link to the home page so you can jump to another test or the new test page quickly. So if you like taking click tests—and it can be fun—it’s now much easier to do.

What next?

One of the main things I still need to add is the ability to chain several tests together so people can test multiple screens or multiple versions in one go. This is a priority feature and will be added soon.

Also need to implement a better way to display time. This should be visual rather than just text, i.e. a diagram of a clock with every click as a little arrow so you can instantly get a feel for how long the test took most people to complete. Finally, will need show the drop-out out rate (i.e. people who loaded the test but didn’t click anywhere), which will be even more important now that there’s a “Skip” button.

As always, if you have any suggestions or feedback for Usaura please let me know.

We're in a strange spot currently where the term user experience designer can be used to describe a novice or an expert. There are tons of novice designers who discover usability testing and prototyping, practice it for a bit, and start calling themselves UX designers. At the same time a lot of folks who have truly mastered most of the practices under the umbrella of UX still call themselves "web designers. As a result it's hard to distinguish between the two.

Andy Budd recently wrote a great article in which he sets up the problem of how people perceive user experience:

Some designers think that user experience is just a made up name and that we’re all user experience designers really. Others think that User Experience is a term used by consultants to trick clients out of money and would prefer it we all just stuck to the title of web designer. Some feel that user experience is simply common sense design while others see it as a land grab to own the fun bit of the design process.

User experience isn't one thing, it's several things, it casts a wide net across many disciplines. It is really everyone's responsibility throughout an organization. A bad experience like the Blackberry is the result of an organization's lack of focus on exchanging value with their customer. Design process and methods are uniquely positioned to keep that focus tight while crafting the details that would save a product from mediocrity. Everyone in an organization should be empowered to use at least some of them.

For some aspects of product design companies should take a don't-try-this-at-home approach and hire a professional designer. As Andy goes on to point out, there are specific forms of craft involved here that are more specific than user experience:

Information Architecture, Interaction Design, Usability, Interface Design, Information Design. All of these practices go into designing good user experiences, so are part of the user experience cannon.

Experienced practitioners who have mastered many of these fields don't really see a distinction between these. For them web design or design make sense as a title. The problem arises when novice designers who have a fraction of the skills these experts have use the same title. In the early days when sites were very simple and did not require advanced skills this was fine. In today's day and age many large and complex sites require specialists with a single focus:

Experts in information categorisation, human computer interaction or interface design. They also need people who specialise in specific programming languages, databases, security, or application architecture. The history of all human progress can be counted by the increased specialisation of individuals amongst a group, and I see this as a good thing.

We agree with Andy, it's pretty useful for people to separate the skill sets and be able to tell experts from novices. Being able to define what you do and distinguish yourself from the rest is valuable for our whole industry. Just because the experts feel lazy and use the term "designer" it does not mean that those specific titles or practices do not exist.

We developers are a peculiar breed. In a way, I like to compare us to mad scientists—you know, the guys in movies huddled over glass beakers, trying to find the right mixture of red and green ooze to make a bizarre invention that goes horribly wrong.

Okay, maybe not quite that crazy, but we’re quite passionate about what we do. We love creating things. Building useful applications that people value brings a lot of fulfillment to a job that has us spending most of our time staring at a computer screen, and where we place ourselves at risk of carpal tunnels or mild obesity.

But back to the mad scientist bit. We spend a lot of time agonizing over peculiarities, trying to find the right mixture, formula, algorithm, or animation sequence. Who else but a developer would stay up till 2 a.m. working on the right formula for determining non-overlapping space between a masked loaded image and its container?

read more