Archives for Category / UX/IA/IXD
(Originally published on CDG Interactive/Innate blog,
edited by Emma Lehmann, republished December 9th, 2016)
Over the past few years, many of you have heard of the term responsive design. Basically, it’s an approach where we build web apps and websites to be usable across a wide range of devices, from mobile phones to laptops.
But instead of tricks, techniques, and more code (there are plenty of basic responsive design tutorial out there), I want to go in a different direction. Instead of asking ’how do we do this?’, I want to ask ’why do we do this?’.
Here at Innate, we recently designed our Accessibility Services website with responsive principles. Instead of answering basic questions, we want to delve into the types of problems we encountered that influenced how the design developed, as these are common problems for all responsive sites. It doesn’t matter if it was one person or a company like Innate; when we all build a responsive site, we are solving these problems at every step of the way.
So, let’s start solving some of these problems.
The Three ’C’s
Responsive design is like solving a puzzle. When someone asks me to describe it, I tell them the following three words: constraints, context, and content.
For brevity, I like to call them the three ’C’s. If I were to give them descriptions:
- Constraints –the conditions, restrictions, and parameters for the given problem
- Context – the situations or circumstances in which you have to work on the problem
- Content – the way in which information is displayed for the given problem
These three ‘C’s are needed in varying amounts when building a responsive site – sometimes, some more than others. But together these are necessary to solve responsive problems. The better the mix of each piece, the better the product. Each part contributes to the whole product.
So, how do we use the three ‘C’s?
Referring to the above graphic, think of Content as water. Constraints as a container. Depending on the amount of content, you will choose the appropriate constraints to display this content. If you have a long article, the viewing on a phone will require more scrolling than that of a wide screen monitor.
With Context, referring back to the water analogy, our problem can change depending on circumstances or environment. At room temperature, water is liquid. But change the temperature and we get either ice or steam. With design, that means adjusting our design to meet these changes.
Like all problems, we need constraints to get the best solutions and designs. Finding constraints allow us to make good assumptions about how to solve a problem. Let’s start by making a few right now.
The most obvious problem in responsive design is conforming to the screen sizes of numerous devices. How do we get a website or app to fit in the screen width of a phone, tablet, and laptop? When we consider the number of devices on the market, we see there is a large range of screen sizes. But by finding constraints, you narrow down the problem, making it manageable.
— Innate (@InnateAgency) June 9, 2015
What is our minimum screen size? Right now we’re not thinking about smart watches (at least not for the purpose of this demonstration), so let’s stop at mobile phones. Apple has pretty consistent design parameters and the classic iPhone has a minimum of 320 px, which is under the range of recent larger models. This is the stopping point on the small end of our constraints scale.
On the large end, we are not considering TVs (at least not for the purpose of this demonstration), so we need an upper bounds for desktop monitors or laptops. Right now, 1400 px is a nice place to put an upper-limit constraint.
Why these numbers? Global stats are a start but the best statistics are a combination of site logs and Google Analytics.
In addition to the extremes, we have a few other number to consider, such as ones for laptops (1024 px) and iPads (786 px). These aren’t necessarily standard, but they are starting points. During the course of building, you will find out the other two parameters – context and content – will affect the constraints. For example, the footer may not look right somewhere between 320 px and 768 px; if this is the case, a new constraint will need to be added. You can really have as many constraints as you want, but the best motto (and the one with less headaches) is the fewer constraints, the better.
Constraints are like conditions, though. They don’t need to be screen size; there are others as well, such as orientations (vertical or horizontal), resolution and pixel density, etc. Other constraints could come from areas beyond your own work (product requirements, project specifications, etc.).
No matter which constraints you are dealing with, they can be influenced by context and content. Let’s look at how this works.
Learn how to adapt to different screen sizes from this informative Intel tutorial:
As you’ve seen, constraints can help define a problem and lead to a solution, but context informs these constraints. Oxford Dictionary defines ‘content’ as:
The circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood and assessed.
For example, taking one device (a tablet), we can drill down in the Analytics data to discover Insights that drive content in learning lessons such as : 1) when users read tablets depends on the time of day at home or work, 2) tablet users are using their device in landscape instead of portrait mode or 3) whether the devices used for certain tasks are Android or Apple, and screen size/viewport.
— Luke Wroblewski (@lukew) May 12, 2015
But more than just statistics, it comes down to research and observation. Taking a device (there are device labs you can check out) and learning about how it handles and comparing with other devices. The experience gained influences how we design/build responsive sites and apps.
Why does this matter? By using context, we can refine our solution and design to better fit a solution to the problem we need to solve. As a consequence, context will define each of our constraints to accommodate user behavior.
Yes, it feels time-consuming, but it’s worth it to create a great user experience. There is still a third element that must be considered, though: content.
At its simplest, content it the stuff that’s on the page. However, with the ever-changing layouts from responsive design, content must become more sophisticated.
In thinking about content, we have to remind ourselves that the core concept of the Web is information.
With the advent of responsive design, we now have a process where we can create websites and apps that can carry the nearly same information without device constraints. However, constraints and context shapes how we view content. It’s not a matter of just hiding or showing words. It becomes a matter of determining what content has the highest priority.
With changes in layout and the concept of the fold largely negated, we needed to rethink how we place content on a screen. Or I should say, we need to reconsider old ideas about placing content on a screen.
For example, the non-responsive NASPGHAN site has complex, deep navigation. Mentally, you would think that the code for this would come at the beginning of the page. However, because the navigation is so large, it would take a vast amount of space before the content the user wants to read. In this case, code for the navigation is written at the bottom with its position displayed via CSS at the top. If you were to use a screen reader/non-visual tool, you could get to the content readily but still get to the navigation via skip/anchor links.
When creating content, keep a mobile-first mantra. Design for the mobile site first and let the constraints of a small environment help select the most important content. Then, as the user gains more real estate or features, give them the extra content. Essentially, just let your constraint and context will be a guide in your content selection.
Prioritizing content creates a flow of information along the screen which aids in how layouts are structured. This, in turn, allows you to adjust content for better solutions to constraints. When creating content for responsive design, the best practices are:
- Prioritization – determining what content gets the highest importance
- Distribution – determining which content is important enough to cause readers to scroll down.
A Collaborative Art
The most important thing that I hope to stress is that responsive design is not a singular effort. As in the jigsaw puzzle at the beginning of this blog post, each project is a combination of the three ‘C’s. A little more content in this project, a little more context in the other. Responsive design is a process that involves many processes and, in some cases, many people to bring it together.
(Originally published on CDG Interactive/Innate blog)
Earlier this year I attended the IxDA Interaction 11 conference in Boulder, Colorado, one of most important in the field of interaction design. At this conference, I’m both an observer of the field and a student, gleaning ideas I can use to improve my own skills.
In my three years of attendance, I’ve learned that interaction design is not just about building products — it’s also about how to visualize information. One of my jobs is taking HTML/CSS code and making the content not only visible but easily accessible to the user. At a time when massive amounts of data are freely available, finding ways to making information not only understandable but also easier to use and manage has become its own field of study.
Making Information Visual
So what does “visualizing information” mean? For example, take a basic weather map we see on the local evening news. Apart from the physical location and geographical borders, information about air pressure and temperature are shown in graphics, instead of a straight list of numbers and statistics. This same information is given some sort of context (work, travel, agriculture) for viewing. From this, we make judgments about what activities we want to do at a certain time period (going to work, growing crops, flying on vacation).
We can use maps to overlay any information we want, depending on what we need or want to do. But one use of a map is something that we have been doing since childhood: using a map with information to find something.
And that’s just what I did at IxDA in Boulder. Each year’s conference has a different twist, depending on the location. Home to The University of Colorado, Celestial Teas and a growing tech/design area, Boulder is nestled near the Rockies and has a reputation as being eco-friendly. Well, when looking at the list of Friday activities, I found one that caught my attention: Geocaching: Treasure Hunt.
The “Treasure Hunt”
Geocaching is a hide-and-seek game where finders use GPS units or GPS-enable mobile phones to find caches. These caches are containers that have various items inside. They can be as large a small Tupperware case. Or they could be micro caches, which can be as small as a 35mm film canister. Either one, these are located in publicly accessible areas and are hidden from view. However, the owner of a cache will leave some clues (text, title name, or images) for the finder to locate it. Of course, having a GPS unit does not mean it will be easy to find. If you have ever used one, you know that there is a certain range of accuracy depending on the signal and location.
Occasionally, these caches will have a travel bug, a type of GPS-enabled tag with a unique ID that the finder/owner can move to any location and place inside another cache. Once the cache has been found, the finder must leave something of equal/higher value in the cache, especially if something is taken from it. The finder marks that she/he found the cache via paper/app/website and replaces the cache in the exact spot for others to find.
Hmmm. Hide and seek with GPS tools. Exercise with actual pay off. Sign me up!
Following lunch on Friday, the group got together. I was matched up with Jill, one of the advisors, due to the fact that we both we the only ones in the group who had Android phones. (BTW…interaction designers luv iPhones. Just an observation… ) I downloaded an app (there are a number of apps for iPhone and Android) beforehand and played around prior to the trip. It also helps if you have the latest upgrade of Google Maps on your phone with navigation abilities.
We traveled to an area in Boulder where we separated into three groups. The group I was in located a micro cache about 0.7 miles north and we walked down some streets to the location. This was located in a parking lot (caches need to be in a public place). The GPS trackers got to about a couple of feet nearby. However, it had snowed a few days prior and the parking lot was covered in snow mounds about a few feet thick. I tried digging with gloves to see if I could find it but to no avail. Everyone searched around the area but no luck. Considering the area was still snowbound and we were finding a small micro cache, we decided to search for another one.
Looking at the geocaching app, we found another micro cache only a few meters away north. Unfortunately, we came up empty again – a snowbound area with little clue to finding it.
We decided to move to another one, this time a regular sized cache. This one was about 0.3mi west from our present location. Crossing streets and more parking lots later, we finally got to the location. Many of us recognized the location because of the clue given in the title. Like I mentioned before, the GPS only gives you a close proximity to the location; you still have to figure out where it actually is. Another clue pointed to its actual location. That’s easy enough.
Well, almost. Now, you have to try to get it out. Remember, these caches were not meant to be easy to find in the first place…
Finding the Prize
The tallest of the group reached in and pulled out the prize – one round metal candy tin. After a few hours of searching and coming up with the third choice, needless to say we were all ecstatic (judging from the group picture afterwards). Then we opened our prize.
Caches contain any sort of object left over from the previous finders or owner. (There are rules to what can or cannot be put there). This one had a simple log book, with list of names and dates, referring when the cache was discovered. One of the more interesting items is a small tale/story in two small pieces of paper, folded in the cache. It also had a squashed penny. This cache had a travel bug, which was taken by our advisor to be placed in another cache. As the custom, we had to put something back into the cache. A few items were put into the cache from other but someone shouted out “Does anyone have a coin?” I had some Canadian coins on me and threw in a “toonie” or a 2-dollar Canadian coin into the cache.
[By mentioning this, everyone here in the Innate office will automatically reply “Of course, he has one!” Needless to say, I take a lot of trips to Canada.]
Well after the celebration and signing of the small log book, everything was sealed up and the cache was place back in the same location before. The adviser marked the find on the site, along with the items that we placed in the cache.
Mission completed. Smiles but tired walking back to the bus and then back to the hotel. For me, the day was complete.
Now, when I work with information and its display, I’ll remember the connections between data and discovery that are made when geocaching.
P.S. I mentioned the travel bug earlier. Beforehand, it was revealed that one of goals, besides finding the caches, was to have at least one of the travel bugs moved bit-by-bit to the location of the next conference – Interaction 12 in Dublin, Ireland in February 2012. If this one makes it, it will no doubt be very well received.
For more information
- Have you ever been geocaching?
- What are your favorite examples of interaction design?
- How about visualization of information?
NYC IxDA Redux
A big belated “Thank You” to IxDA New York for Interaction 10 Redux (3/6). It was nice to meet all the people who attended and to see all of the presentations that I missed at Savannah. Would come back for another event hosted by the group if my schedule allow it.
Of course, that means I have to start paying attention to the home IxDA branch as well.
Ironically enough, after NYC IxDA Redux, I went back to New York for my scheduled vacation for Met’s performance of The Nose. This weekend, went back to The Met for Lulu, the Alban Berg opera composed a few years after The Nose. Same decade, different moods but both are considered some of the most avant-garde works of their time. This was the last performance for me this season. Already planning for attending two performances next season in 2011 — John Adam’s Nixon in China and Alban Berg’s Wozzeck.
If you have not noticed, the font has changed in this site. After the font change last year, I decided to re-evalute my choice and changed to the first choice of Futura. I like Super Grotesk and it was choosen because of its closeness to Futura. However, there were just some things that I felt were not right (weight, letter styles) for me. It was nagging me in the back of my mind for a few months. So I decided to go back to the first choice of Futura.
I am still on the look out for any other Futura-like fonts but the right choice has been made right now.
Recent Blog Entry for CDG
Last week, finally completed a book review of Morville/Callender ‘s Search Pattern for CDG and posted on the blog. Interesting read and really changed my ideas about search engines and how search result can be displayed for easier use.
I mentioned on Twitter (5/4) that this would be my blog for CDG for the next couple of months as I will be spending writing for this blog. A consquenence will be some important announcements about The Wilson Project and Project Charles, as well as some important blog entries.
(Originally published on CDG Interactive/Innate blog)
After a few months’ hiatus, the CDG Book Club is back. In this installment, UI Developer Ivan Wilson discusses Search Patterns: Design for Discovery by Peter Morville and Jeffery Callender.
I first heard about the book Search Patterns during the IxDA Interaction 10 conference in Savannah, Georgia when I attended Peter Moreville’s lecture about The Future of Search. This brief book (less than 200 pages) interested me because it focuses less on technology and more on design. It’s not about Google or Yahoo, but on interaction designers and information architecture.
That said, the main premise of the book can be summed up in the following statement:
The problem of search is designing interfaces and processes that allow people to find things.
Let us step back a moment. Is searching and finding two of the same things? Well, no. And that is a bit of a revelation to anyone, especially me who builds the front-end code for search pages.
The book addresses two main points:
1. Search is a not passive activity.
What do we do when we go to a search page? Input term(s), click button, get results—right? But what happens when the results don’t lead to the information the user is looking for?
The user isn’t some blank slate. Even if you’re just surfing around, you’re affected by a variety of filters–such recommendations from friends, past memories, etc. As users, we’re always judging whether a search result is right for us or just another dead end. If a user isn’t finding what he’s looking for, the problem isn’t necessarily an inadequate use of the search; it may be a user interface problem. In other words, the interface may not be adequate for what/how the user wants to find.
2. Information need to be findable, not just searchable.
Here, the authors approach the problem from the other end: those who create the content that is being searched. Especially on the web, content does not lend itself to being able to be found in an instant. It’s up to content producers and coders to make content searchable by using tools such as keywords or tags or database indexing. If you’re a business, you need to understand how to categorize products in a way that makes it as easy as possible for the user to find them via search (for example, adding information like ISBN numbers for books).
Throughout the book, the authors detail different interfaces currently being used (faceted navigation, widgets, etc) in search. They also give glimpses into the future, with examples of search being tied in with social media like Twitter or Facebook. Also, the authors detail some of the methods the users take in searching for items whether in narrow or expanded focus.
But in the end, designing for search engines will be about more than speed and accuracy; it will be more about having the process of finding easier. And that is what this book is about.