ENTRIES TAGGED "UI"
A truly accessible website is both accessible and usable
Every time I give a talk about making accessible websites, I get the following question:
“What checklist do you use to make sure a site is accessible?”
My response always surprises them:
“I don’t use a list.”
Why not? There are so many lists out there that I could be using! Practically every US government agency has a checklist published on their site, and several non-government sites offer checklists of their own. With so many free resources, why do I ignore checklists?
Measuring impact and changing behavior
I had the opportunity to sit down with Laura Klein (@lauraklein) and talk about the importance of creating effective user experiences. Laura is a UX expert and consultant. She stresses the need to figure out what works by talking to users and determining what works through usability testing. She’s also author of O’Reilly Media’s UX for Lean Startups: Faster, Smarter User Experience Research and Design. It hit home when Laura told me, “If people aren’t getting it, you’re probably doing it wrong.”
Key highlights include:
- How to figure out what works, so you can avoid a poor user experience. [Discussed at 0:19]
- It’s important to avoid porting a traditional process to a new product and service. Instead you need to think about how to design a new and natural experience. [Discussed at 2:16]
- Think about context when designing new processes. [Discussed at 2:37]
- The first step in creating a successful UX is knowing and understanding your audience. [Discussed at 3:49]
- Using these principles beyond web sites. In all good UX applications, the goal is not to notice the interface. [Discussed at 5:16]
- It’s critical to observe people, so you’re not assuming a knowledge base. [Discussed at 7:35]
- The importance of A/B Testing. And how design is not an art; it’s trying to solve a problem. [Discussed at 9:54]
- How the build, measure, learn lean methodology fits with UX design. It’s all about measuring the impact and changing behavior. [Discussed at 11:11]
You can view the full interview here:
What to look out for when updating your code
As a bewildered Dorothy says in the movie The Wizard of Oz, “I don’t think we’re in Kansas anymore.” When you open your iOS 6 project in Xcode 5 and run it in the iOS 7 simulator, you’ll know instantly that things have changed:
Gone is the colored status bar background; the status bar is always transparent, and all apps are full-screen apps, underlapping the status bar. A button has no rounded rect bezel, unless you draw it yourself as the button’s background. Many interface objects are drawn differently, with different dimensions. The subtle bar gradient is gone; colors are flat, unless you draw a gradient background yourself.
How to design products and services that help users change behavior
Steve Wendel (@sawendel) is the Principal Scientist at HelloWallet where he develops applications that help users take control of their finances. He’s also currently writing Designing for Behavior Change. I recently sat down to talk with Steve about the importance of testing and iteration, role of psychology, and resources and tools.
Key highlights include:
OSCON 2013 Speaker Series
Jon Manning (@desplesda) and Paris Buttfield-Addison (@parisba) are co-founders of Secret Lab and authors of the forthcoming Learning Cocoa with Objective-C, 3rd Edition. They’ll be speaking at OSCON this week in Portland, OR. Here they explain how to rotate a UIView in 3D on iOS.
One of the simplest visual tricks you can do in iOS is to make a part of your UI pretend to be a 3D object. We’ve found that this is an excellent way to add some life and visual interest to both apps and games.
Below, you’ll learn how to make a view rotate in 3D and have a perspective effect.
First, your project needs to use the
Next, when you want the animation to begin, you do this:
CABasicAnimation* animation = [CABasicAnimation animation WithKeyPath:@"transform.rotation.y"]; animation.fromValue = @(0); animation.toValue = @(2 * M_PI); animation.repeatCount = INFINITY; animation.duration = 5.0; [self.rotatingView.layer addAnimation:animation forKey:@"rotation"]; CATransform3D transform = CATransform3DIdentity; transform.m34 = 1.0 / 500.0; self.rotatingView.layer.transform = transform;
To stop the animation, you do this:
How It Works
CABasicAnimation allows you to animate a property of a view from one value to another. In the case of rotating a view, the property that we want to animate is its rotation, and the values we want to animate from and to are angles.
When you create the animation using [
CABasicAnimation animationWithKeyPath:], you specify the property you want to animate. In this case, the one we want is the rotation around the Y axis.
CABasicAnimation* animation = [CABasicAnimation
The animation is then configured. In this example, we made the rotation start from zero, and proceed through to a full circle. In Core Animation, angles are measured in radians, and there are
2 * π radians in a full circle. So, the from value and to value are set thusly:
animation.fromValue = @(0); animation.toValue = @(2 * M_PI);
Next, the animation is told that it should repeat an infinite number of times, and that the full rotation should take 5 seconds.
animation.repeatCount = INFINITY; animation.duration = 5.0;
The animation is started by adding the animation to the view’s layer, using the
addAnimation:forKey: method. This method takes two parameters: the animation object that you want to use, and a
key (or name) that the animation should be referred by.
Don’t be confused by the similarity between the “
key” that you use when you add the animation, and the “
key path” you use when creating the animation. The former is just a name you give the animation, and can be anything; the “key path” describes exactly what the animation modifies.
[self.rotatingView.layer addAnimation:animation forKey:@"rotation"];
The last step to this is to give the rotating view a little perspective. If you run the code while omitting the last few lines, you’ll end up with a view that appears to horizontally squash and stretch. What you want is for the edge that’s approaching the user’s eye to appear to get bigger, while the edge that’s moving away from the user’s eye to get smaller.
This is done by modifying the view’s 3D transform. By default, all views have a transform matrix applied to them that makes them all lie flat over each other. When you want something to have perspective, though, this doesn’t apply, and we need to override it.
CATransform3D transform = CATransform3DIdentity; transform.m34 = 1.0 / 500.0; self.rotatingView.layer.transform = transform;
The key to this part of the code is the second line: the one where the
m34 field of the transform is updated. This part of the transform controls the sharpness of the perspective. (It’s basically how much the
z coordinate gets scaled towards or away from the vanishing point as it moves closer to or further from the “
Considering the "two pizza" team
One of the most common questions I get about applying lean ideas to product design and development is, “How can I make this happen in my organization?” Between entrenched corporate silos and existing team management structures, it can seem impossible for these ideas to take root in large companies. Over the course of a series of blog posts, I thought I’d share a few tactics I’ve used and have seen work with other teams to help get you started. In this first post in the series, I’d like to talk about how to structure your teams.
As much as who you hire, structuring your teams effectively is key to a lean team’s success. Many companies see the individual disciplines in their product development organization as service providers—internal agencies. The business reaches out to these agencies (engineering, UX/design, product management, et al.), expresses a need for staffing and the discipline lead provides the resources based on expertise, availability, and project fit. It sounds like a reasonable and efficient way to staff a project and to that extent it is—however, our goal should not be to simply staff a project but to build a team.
When building your team, focus on the following four criteria to maximize their chances for success:
Keeping your team small means everyone on the team knows each other—on a first name basis. It’s easier to manage a small team. It’s simpler for the team members to know who to go to when they need something specific. It’s easier to keep track of work accomplished and work left to do.
OSCON 2013 Speaker Series
Tony Santos, (@tsmuse) is a User Experience Lead at Mozilla and OSCON 2013 Speaker. We talk about Human-Centered Design and how it can make all the difference.
NOTE: If you are interested in attending OSCON to check out Tony’s talk or the many other cool sessions, click over to the OSCON website where you can use the discount code OS13PROG to get 20% your registration fee.
Key highlights include:
- Defining human-centered design. [Discussed at 0:20]
- Hey Developers, Want your app, software, or product to be a success? Then you need to care about this, seriously. [Discussed at 1:05]
- So, what do users actually want? [Discussed at 2:10]
- Some (user) research is better than no (user) research. [Discussed at 3:03]
- Open source sort of abides by human-centered design by its very nature, but can do even better. [Discussed at 4:01]
- A human-centered design success story. [Discussed at 6:26]
You can view the full interview here:
Why "flow" and "context" are more important than screen size
Are we done with the Mobile First meme, yet? Can we be? Please?
Look, don’t get me wrong. I fundamentally agree with a lot of the thoughts behind the annoying catchphrase “mobile first.” For example, I agree that mobile devices are now the primary (if not only) mode of connecting for many markets. I also think that having some sort of mobile strategy is absolutely required for almost every product.
The problem is that “mobile first” often equates “mobile” with “small screen” or “responsive layout” or “native vs. mobile web.” Now, those are all incredibly important decisions. But if you’re thinking about the size of your screen or the technology you’re going to use first, you are designing wrong.
Of course, if you’ve read anything else I’ve ever written, you know that the first thing you must figure out is an important customer problem or need that your product is aimed at solving for real people. We’re going to just skip over that whole part where you get to know your most important users. But that’s always first. Promise.
Once you’ve done all that though, you need to start designing. And there are two things that you should always know before you even start considering things like screen size or technology.
Those two things are: Flow and Context.
Four strategies to add microinteraction details to your product
Microinteractions are the small pieces of functionality that are inside or around features. They are brief, single use-case moments. Turning off the ringer on your phone is one example. While no one buys a phone for the ability to turn the ringer off, the ability to do that—and do it easily and enjoyably—make a huge difference to the overall user experience. Microinteractions are the “feel” half of “look and feel.” If you care about user experience, you should care about microinteractions. Refined microinteractions lead to a refined product.
For some people, particularly those working on large products like Facebook, microinteractions are a daily activity, but for many people one of the biggest challenges to designing microinteractions is convincing clients, product managers, and business stakeholders that they’re worth spending time on. How do you steal some time away to really make sure your product is polished? Here are some strategies.
Effectively combine characteristics and qualifiers for optimum layouts
DisplayMetrics Red Flag
A search of GitHub returns more than 42,000 hits for the class name
DisplayMetrics. This is a red flag. Although there are safe and valuable uses for this information, a quick look at the code using this class reveals that most programs query it to determine screen dimensions, using code like this:
DisplayMetrics displaymetrics = new DisplayMetrics(); ((WindowManager)context.getSystemService("window")).getDefaultDisplay().getMetrics(displaymetrics); int i = Math.max(displaymetrics.heightPixels, displaymetrics.widthPixels); sScreenNailSize = i / 2; sThumbNailSize = i / 5;
The programs then make decisions about how the program should present its user interface. This is dangerous, because it tempts the programmer to make decisions with awful long-range consequences, when these decisions should be left up to the Android run-time.
How to Break Lots of Apps in One Easy Step
How dangerous is it? Pull up a random app on your Android device, go to the Settings and select Font Size, then select Huge.
Now see how many apps break:
- How many have fixed-size views in their layouts where text overflows its bounds?
- How many “fixed” that bug by setting the font size, and ignoring your preferences?
- How many make incorrect layout decisions where objects don’t quite fit?
- How many lock the app’s UI to a landscape or portrait orientation?
When you make your own decisions, based on screen dimension and other parameters, about how to present the user interface, you enter a danger zone that spawns bugs that can easily escape detection in both automated and manual testing. If bugs are caught late in the game, they create pressure to implement lame fixes.
The Only Way To Win Is Not To Play the Game
Aren’t you forced to make decisions about presentation? The answer is “No.” You should not be asking “How high, how wide, how dense, what font,” etc.
You should let Android ask the questions and make decisions about presentation. The only question, then, is how many answers you need to provide. Using multiple layouts for different configurations, and avoiding fixed values in layouts, you can make a system of layouts and let Android choose which layouts to use for different screen sizes and orientations.