Cyberdegrees.org recently finished a new website for students on the topic of cyber security. With many high-profile hacks grabbing national headlines there has been an increased interest in the field from both the government and students. Despite this growing interest, cyberdegrees.org found there weren’t many online resources discussing cyber security degree programs, so we developed our own - CyberDegrees.org.
Here are a few features:
- A full directory of cyber security degrees, from associate’s degrees all the way to Ph.D programs
- Detailed looks into 20 careers related to cyber security, including job responsibilities, requirements, and growth opportunities
- Tons of in-depth resources, including our complete guide to government security clearances (what they are, why they’re given, and how to earn them)
We’re listed as a resource by the Department of Homeland Security’s National Initiative for Cybersecurity Careers and Studies and the Society of American Military Engineers, as well as universities including Boston University and the University of Pittsburgh, among others.
Morgan Kaufmann / Elsevier
Sign in to save 30% and get free shipping when ordering Morgan Kaufmann / Elsevier titles.
WebVisions Portland will be held from May 18-20 at PNCA and Revolution Hall. Learn more and register here today! Remember CHIFOO members get 15% off on tickets- sign-in and get your member discount.
O’Reilly Ebook & Print Discount
Sign in to use CHIFOO’s discount code for O’Reilly print and ebook orders.
SEMpdx presents 10th Annual SearchFest Conference
SEMpdx is excited to announce that Michael King of iPullRank and Dr. Pete Meyers of Moz will be the keynotes of SearchFest 2016!
SearchFest is a one-day digital marketing conference, presenting multiple informative learning tracks and panel sessions designed to provide expert insight into the latest strategies and technological advancements in online marketing, whether that is SEO, advertising, content, or social media. Our devout attendees and speakers will tell you that SearchFest is “one of the most important regional thought leadership events in the world” and that each year’s agenda is “forward-thinking and relevant”. In addition to the world class programming, we place an emphasis on creating opportunities for speakers and attendees to meet, ask questions, and make important connections. We do all this for a just a fraction of what you would spend elsewhere. Plus, every ticket includes a Video Bundle of all of the speaker sessions and keynote presentations.
Sign in for your CHIFOO member discount code.
The website is a comprehensive search engine designed for students who are interested in learning more about CS and CIS programs around the country..
It’s a resource for people who are just getting into the field which gives breakdowns of cost, demographic makeup, student-to-faculty ratios, and retention rates for hundreds of CS programs across the US.
You can see the site here: http://computersciencedegrees.org/
Data Visualization With Circles, Spirals, and Other Round Things
In this post, I’ll be writing about using circles and spirals in data visualization. There are some interesting things you can do when you arrange your data circularly – benefits you don’t get from more traditional layouts. Of course, I’ll also discuss the drawbacks, too. None of these techniques are categorically superior to the alternatives.
This is certainly not an exhaustive review of the topic. There are many kinds of visualizations I won’t be able to explore in a blog post. The common thread here is simply “things I’ve found while researching another project I’m working on for my information visualization class.”
One of the earliest examples is Nightengale’s Coxcomb. This graph was created by Florence Nightengale during the Crimean War to advocate for better sanitation. It shows that the number of deaths due to preventable causes (blue wedges) exceeds the number of deaths due to wounds (red) and other causes (gray). It also shows the success of sanitation efforts – the decrease in preventable deaths in April 1855 corresponds to sanitation cleanup efforts in Turkey.
Figure 1: Nightengale’s Coxcomb
The major advantage of the circular layout of the coxcomb is the way months have a consistent placement around the axis. This makes it easier to do year-on-year comparisons. (This will be a recurring theme.)
Nightengale was careful to map data values to the area of wedges, not the radius. This solved one problem, but introduced another. Nightengale was avoiding the problem where area increases as the square of radius. Had she mapped her data values to the radius, this would have exaggerated the values, since a doubling of the radius would show a quadrupling of the area (Rehmeyr, 2009). But by avoiding that lie factor, Nightengale made it somewhat harder to compare months. You can somewhat easily tell that the radius for January 1855 is about twice as long as the radius of November 1854. But what of the area? People aren’t that good at estimating area, especially of odd shapes like wedges (or even rectangles with differing aspect ratios).
Teoria Generale Della Statistica
Figure 2 avoids the area/radius confusion of Nightengale’s coxcomb, by plotting the data as spokes on a wheel. It is also much less visually striking than the coxcomb. It’s okay, sometimes, to sacrifice some utility (but not honesty) to increase impact.
Figure 2: An early circular plot (Gabaglio, 1888)
The graph comes from Teoria Generale Della Statistica, an 1888 statistics book by Antonio Gabaglio. Although the book is cited often by visualization papers, I haven’t found out much about it. And since it’s in Italian, I can’t even tell you what this is a chart of.
One final note about this chart: It doesn’t scale to showing large numbers of years in one plot. You could represent a few years by having several colored lines along each spoke, but you’d quickly run out of colors.
By plotting data on a spiral, we can show several years worth of data. Figure 3 shows quantities of a certain food eaten by chimpanzees in the Gombe preserve in Tanzania between 1980 and 1988. Each revolution of the spiral represents a year, and the months are aligned on the spokes. This supports both month-to-month and year-to-year comparisons. And notice that there are no breaks in the data: other, non-spiral, layouts would have breaks, such as between December and January. With the spiral, every data point is adjacent to the the previous and next month, and the previous and next year (Carlis & Konstan, 1998). The downside, compared to a table, is that it becomes more difficult to compare months of the same year that are located on opposite sides of the spiral.
Figure 3: A spiral plot (Carlis & Konstan, 1998)
To compare two or more data sets, Carlis and Konstan placed bars onto the spiral. Figure 4 compares chimpanzee consumption of two food types. The visualization seems fundamentally sound, although it could certainly be improved. At first, I was concerned about perspective effects. Since the spiral is shown in perspective, would the brain perceive bars in the back as larger objects whose sizes have diminished in the distance? The answer seems to be no. I checked, and bars in the front and back that appear to have the same height actually do. (Comparing heights is something the brain is pretty good at.) The display of the graph could certainly be improved to have less occlusion of the blue bars.
Figure 4: Comparing multiple values on a spiral plot (Carlis & Konstan, 1998)
An Aside About Scales and Legends
You probably noticed that there aren’t any labels on the spiral plots I’ve shown. That practice will continue. I don’t have a good explanation as to why that is, but I do have a guess. The visualizations are generally created by interactive programs where the user can specify lots of parameters. I’m assuming the scales and legends (months, years, etc.) are shown in those controls.
However, the nature of the spiral doesn’t leave a lot of room for annotations. The spokes can easily be labeled, but the revolutions of the spiral are harder to annotate, especially if the spiral is tightly wound. Weber et. al. (authors of a paper on the subject, from 2001) suggest making an interactive visualization, where the user gets gets information about the data underneath the mouse pointer.
This is also a good time to mention that Gabaglio, the Italian statistician, did an early spiral chart. I think it’s hard to read (you have to compare sizes of rotated rectangles), but it at least manages to label both axises. You can see this reproduced in The Visual Display of Quantitative Information (Tufte, pg. 72).
Spirals and Periodic Data
The spiral layout can make periodic trends in the data easily apparent, as long as the correct period is chosen. Figure 5 shows the importance of choosing the correct period. The chart on the left has a 27-day cycle (that is, 27 days per revolution), the correct period, 28 days, is shown on the right. There are some data analysis techniques that the computer could use to suggest a time scale to the user (Müller & Schumann, 2008).
Figure 5: The importance of having the correct period for your spiral chart (Müller & Schumann, 2008)
Glass Patterns, Pattern Recognition, and the Kaliedomap
Another interesting feature of circular data layouts is that it can make it easier to recognize patterns. To understand why, we’ll begin by discussing Glass patterns.
If a field of random dots is copied, rotated slightly, and superimposed on the original, people will notice a circular pattern in the dots (Glass, 1969). Simply shifting the dot pattern along one axis (not rotating it) produces a dot field in which it is much harder to notice a pattern (Wilson & Wilkinson, 1998). This leads to the observation that perhaps it will be easier to notice trends in data if they’re arranged circularly instead of rectangularly.
Figure 6: A Glass pattern (Glass, 1969)
Kim Bale tried this in a design she and her colleagues called a kalliedomap (so named because the result resembles a kaleidoscope). Each segment of the kaleidomap plots one value, with time increasing by hours as the angle increases, and time increasing by days as the radius increases (see fig. 7). Bale et. al. compared this with a more traditional cascade plot, where time increases by hours on the x axis and days on the y axis.
Figure 7: Reading a kaleidomap
Figures 8 and 9 show air quality data from London in 2002 and 2004. Traffic calming measures were introduced in 2003, and the graphs are investigating changes that may have resulted. There are some stripes in the data, which are particularly evident in NO as NO2 segment. The stripes are weekends, where there is less traffic and hence less pollution.
Figure 8: “Two Kaleidomaps showing the air quality data from around Westminster during March 2002 (left) and March 2004 (right).” (Bale, 2007)
Figure 9: “Air quality data from around Westminster during March 2002 (top) and March 2004 (bottom) displayed as a series of 2D cascade plots.” (Bale, 2007)
Bale et. al. contend that the striping effects are easier to see in the kaleidomaps than in the cascade plots (and they did some research to support that claim). In my experience, the striping is more striking in the kaleidomap than in the cascade plot. However, the kaleidomap has the drawback that it’s difficult to find the same point in time in different segments – you have to mentally flip a segment upside down to compare it to a segment across the circle.
There’s Much More
There are many more possibilities that I don’t have time to cover here. The papers I’ve cited go into more detail about the solutions they propose. If you’re interested in this subject, they make good reading. And there are many uses of circular visualizations I haven’t covered – clustering and identifying relationships is one such topic.
Evan Dickinson is a former Portlander currently pursuing an MA in interaction design at Simon Fraser University in Vancouver, BC. He blogs about his studies for CHIFOO. Write him at evan_dickinson at sfu dot ca.
Bale, Kim et al. “Kaleidomaps: a new technique for the visualization of multivariate time-series data.” Information Visualization 6.2 (2007): 155-167.
Carlis, John V., and Joseph A. Konstan. “Interactive visualization of
serial periodic data.” Proceedings of the 11th annual ACM symposium on
User interface software and technology. San Francisco, California,
United States: ACM, 1998. 29-38. 3 Nov 2009
Gabaglio, A. Teoria generale della statistica. U. Hoepli, 1888.
Glass, Leon. “Moiré Effect from Random Dots.” Nature 223 (1969). 7
Glass, L., and R. Pérez. “Perception of random dot interference patterns.” Nature 246.5432 (1973): 360–362.
Muller, W., and H. Schumann. “Visualization methods for time-dependent data - an overview.” Simulation Conference, 2003. Proceedings of the 2003 Winter. 2003. 737-745 Vol.1.
Tufte, Edward. The Visual Display of Quantitative Information. 2nd ed. Cheshire, Conneticut: Graphics Press, 2002.
Rehmeyer, Julie. “Florence Nightingale: The Passionate Statistician.”
Science News 26 Oct 2008. 8 Nov 2009
Weber, M., M. Alexa, and W. Muller. “Visualizing time-series on spirals.” Information Visualization, 2001. INFOVIS 2001. IEEE Symposium on. 2001. 7-13.
InfoCamp 2009 Notes
A few weeks ago, I went to the InfoCamp 2009 unconference in Seattle. InfoCamp describes itself as “unconference about user experience, information architecture, user-centered design, librarianship, information management & related fields.” For those of you not familiar with an unconference, it’s a kind of conference where sessions are put on by the attendees, instead of pre-screened presenters. I had a great time at InfoCamp, and I recommend attending next year.
These are my notes, from some of the sessions I went to.
- Death to Static Wireframes
- Jing Screencasting and Information Literacy Instruction
- Designers and Business People: Best Friends Forever
Death to Static Wireframes
In this panel discussion, design practitioners discussed the future of wireframes. The panel was:
Matt Turpin: Interaction designer at Ascentium in Bellevue.
Kris Bell: User experience designer
Mark: From Blast Radius. (Sorry, Mark, I didn’t catch your last name or job title.)
Andrew Otwell: User experience architect + interaction designer
Kevin Wick: Designer at Ascentium
Aaron Louie: Associate Director of User Experience, ZAAZ
The panel started by discussing what constitutes a static wireframe. A picture you can’t interact with at all, such as a PDF file, is definitely static. Some panelists considered a basic click-through (static except for clickable links) to be static, too. There’s some gray area.
Each panelist made an opening statement. (And, unfortunately, I didn’t capture Andrew’s statement in my notes.)
Aaron’s Opening Statement
Are static wireframes dead? It depends. They’re not all that problematic for small sites with little interaction. Anything with animation, motion graphics, video, complex interactive controls needs a better representation.
Kevin’s Opening Statement
In his experience, when walking through a static wireframe with a stakeholder, sometimes the stakeholder just doesn’t get the experience will be. Kevin has to do a lot of explaining about what the static pictures mean. The best way of showing the experience is to actually interact with the experience. This gets everybody closer to what the end product will be like.
Mark’s Opening Statement
There’s a danger in letting the tool drive your design solutions. For example, if you’re sketching in Visio, you’re tempted to just use whatever the stencils give you. Maybe that’s appropriate, maybe it’s not. Start with big ideas drawn on paper or a whiteboard. Think of static wireframes as a higher-fidelity sketch.
Chris’ Opening Statement
Wireframes will continue to exist for executives who want to cruise through a design. Think about who will consume your wireframe. Developers need rich & high fidelity, others don’t need that much.
At this point, I mostly lost track of who said what. Statements are the (unidentified) speaker’s point of view, not necessarily the consensus of the panel.
Question: It’s easy to control a discussion with stakeholders, when using static wireframes. It’s harder to herd cats as the mock-up gets more elaborate. How do you manage the conversation with stakeholders with dynamic wireframes?
That is, interactivity increases fidelity, therefore stakeholders worry about fit and finish.
Expression blend has a module called sketch flow. Things look sketchy. But it is interactive. Expression also has some presentation tools. Aaron was using a beta version, and saw lots of potential. They succeeded in framing the discussion they wanted to have.
Q: What tool do you prefer at the moment?
(Each paragraph is a different panelist’s answer.)
Axure. That panelist has used it solo and with a team. Axure uses subversion for revision control & collaboration. Axure also has the pencil-looking widgets.
HTML + JQuery + CSS. They’re good for low-fidelity prototyping, and they’re the panelist’s final product anyways. JQuery + FireBug + other plugs-ins help for dynamic web sites.
Visio. Pen + paper. Excel (to plug in which content goes where).
Axure. Dreamweaver. HTML + CSS.
Q: Do you prep the clients, before showing them wireframes?
At the start of a client (or stakeholder) meeting, discuss the scope & purpose of wireframe. Remind them that we’re not talking about visual design, copy, creative elements, etc.
80% of the job is managing stakeholder’s expectations. This is more politics than drawing. It helps if you have the same clients over & over again, because then you train them.
Q: Different stakeholders need different documents with different content and different levels of fidelity. How do you automate creating all those documents from one master?
Wow, that’s hard. That’s something of the ultimate goal, but the panel doesn’t think we have the technology to get there yet.
Q: Wireframes are, to some extent, the core deliverable of interaction designers. The other teams (developers, product managers etc.) are used to getting static wireframes. How is switching to interactive wireframes a cultural change in the organization?
Kevin was pleasantly surprised at how well Axure was received. PMs, clients, and developers “get it.”
As for how much time a manager should schedule for creating wireframes, Kevin hasn’t seen an increase in time needed for making the wireframes. The time spent making an interactive wireframe is slightly longer, but the wireframe doesn’t need heavy annotation like a static wireframe does. The time for dynamic wireframes could be about the same, or a little less – Kevin hasn’t done a formal study.
A follow-up question asked how you ensure that developers find all the required behaviors without annotations. You can’t hand them a prototype and expect them to find everything, can you? In response, it was pointed out that Axure has some annotations built in. You can print static, Visio-looking wireframes from Axure.
Comment from QA
A software test person commented that he feels separated from designers by too many levels of bureaucracy. He asked designers to please engage QA earlier in the process. Dynamic wireframes will help QA get a better understanding of how the product is intended to behave. Additionally, the QA person feels like he often doesn’t know rationale behind the design, and this hampers his ability to test.
Q: An audience member tried to use Axure a year ago, and found it limiting for making high-fidelity wireframes
This comes back to not letting tools limit your thinking. Do more sketching outside of a technical tool. Be prepared to murder the ideas you like.
Build your own prototypes (as opposed to having developers make them for you). That gives you more freedom to try 5 ideas and discard 4.
(Note: I don’t think I captured this fully. In my notes, the answer seems disconnected from the question. That wasn’t the case in the presentation.)
Q: Is there a clear distinction between when wireframe is done & when you start the site?
This is a common situation: The wireframes are locked down. Then you get to copyrighting, and copy writers argue about the space needed for text. Then more changes happen. The wireframe isn’t as locked down anymore.
An agile design model could help here (analogous to agile development). Keeping UX involved longer in the process could also help, to remind people why page elements are there.
It helps to work with copy writers during design. Use high-fidelity wireframes for this. You should also design contingently: What if I get 20 words of copy here? What if I get 200? Know that your copy will change over time. Your design will outlast the initial copy.
Content is not just words – content is everything & anything (videos, etc.).
Jing Screencasting and Information Literacy Instruction
Jing is a tool for making quick and simple screencasts. The presenters, librarians at the University of Washington, discussed how they use Jing to support their patrons.
Screencasts are video recordings of an application’s window, demonstrating how to use an application. The librarians started using Jing because it easily lets them do video tutorials – for example, how to search using the library’s web site. Because Jing is a light-weight tool, there’s little cost to re-doing the tutorials after a site change. Also, many of the ideal librarians to create the tutorials have limited technology skills; they don’t want to learn a complicated video-editing package.
The librarians found Jing so easy to use, they started using it for one-off support situations. When supporting a patron via online chat, it’s easier to record a quick screencast showing the patron what to do than to describe it textually.
The presenters put their notes up on the web, so I’ll link to them rather than repeating the information here: http://docs.google.com/View?id=dd8gk9tj_18s84x2mf6
Designers and Business People: Best Friends Forever
This was my session. Sometimes marketing and management can be a valuable ally for designers. Sometimes they’re an obstacle to overcome. I led a group discussion about why that is, and how to improve relations between designers and business people.
Most of the questions and advice came from the group. This was great for getting breadth of perspectives. However, like the wireframes panel, I don’t have names to go with the comments. I’ve generally put one speaker per paragraph, but not always. If a paragraph has contradictory viewpoints, it’s probably the opinions of two different speakers.
Video of the talk is at http://www.ustream.tv/recorded/2336539
Question: Who are business people?
That is, who are the people we’re talking about how to get along with. Marketers and project managers are very different people.
One agency worker’s perspective: Who you work with varies. In some accounts, work with the CMO & COO. Other accounts: work with people who are more of a product manager type role. Try not to work with only the product manager. The product manager answers to a room of other stakeholders. The other stakeholders probably need to be involved, but it can be unclear who to get.
Another agency worker offered this advice: Have managers of your group & managers of the other group get together for a conversation of what’s guiding decisions. When you deal with someone, you deal with their whole org chart. The more you can find out about the pressures on them, you’ll be able to help them, and they’ll feel that you’re helping them.
Frame your pitch in terms of what your business partner cares about. In my job, worked with product planners who were concerned about creating a launch message. When I’d talk to them about design and usability issues in terms of how it affects the launch message – talk to them in their language – I got better results.
We’re all service workers – internal or external. Think of providing customer service to your clients & business partners. Understand what someone needs, and appeal to their sense of importance. Business folks, we think, learn this in business school; designers don’t formally learn this.
Stakeholder management would be a great college class. Some UW students and graduates report that their MSIM (masters in information management) program covers this (not in a class that’s actually called stakeholder management – they picked it up over several classes). They learned how to pull out concerns from their stakeholders: . Asking why stakeholders asked for features, to get at stakeholders’ rationale.
In an agency, it’s important to have a strategy of how you’ll deal with clients. Especially troublesome or difficult clients. Know some of the red flags, have an agreement of how you’ll go through it.
Q: How to deal with last-minute changes?
One participant has a challenge where some influential business stakeholders will not engage with the rest of the stakeholders or the design team. They wait until the last possible moment – everything has been signed off, nothing is supposed to change, a few days until site launch – then they muster all the power they have to completely change everything. No time left for anyone to provide feedback or pushback or discussion.
One suggestion: Put everything in writing. The contract can say “we have 4 design iterations, anything over that, you’ll pay more money.” But being legalistic about the contract isn’t always the best approach. Come from a customer service approach, and negotiate how to meet in the middle. This helps maintain a relationship – you need this for internal or external clients. Make it clear what the effect of the changes will be; give a clear timeline. If you do this right, your stakeholders will be happy that they’re listened to. One participant gave an example where he buttered up the client, starting the conversation with how the client’s ideas would improve the project, and then moved on to discussing the ramifications of the change. This changed the client’s tone, because designers validated her.
The participant with the stakeholders who delay clarified his problem: He thinks his stakeholders are trying to avoid design by committee. They don’t want their message and goals to be distorted or watered down, or to have to go to 24 meetings to advocate for what the stakeholder wants for the site. The lesson learned is to have the stakeholder who did the delay tactic engaged early. Don’t let him skip meetings. Appeal to his sense of importance to engage him.
Q: Business people in peer relationships
The questioner deals with stakeholders every six weeks or so, but has business peers he deals with every day. How to help those day to day relationships?
Acknowledge that good ideas can come from anywhere. Don’t rule out ideas from the rest of your team, just because they didn’t come from the designer.
There’s the stereotype of the opinionated designer. When the designer’s work is criticized, it can come across like a personal criticism. Designers need to foster an environment where they can be criticized effectively.
Q: How to extract knowledge from product planners?
When working with product planners, the questioner needs to find out what a product is going to do. It’s hard for her to get the product planners to reveal this information. How to get that information from the product planner, and hold the planner accountable?
Building a personal rapport with the product planner makes the rest of the process easier.
A planner will often say something like “What we want it to do is be successful.” The value you bring as a designer is to bring concrete representations. Sketch, with many iterations. Ask “Is it this? How about this? This?”
What’s missing is for people to understand the role of design in the business. If you can base your recommendations on data, not opinion, you get more respected. Talk about design decisions from a business point of view. Also, program managers think in terms of features. The designer’s job is to make those features work together.
The product manager is probably doing some early research to define the product. It would be great if the designer was invited, but often times you’re not. Even if you don’t come along, you can ask lots of questions about the research. Examine the findings. Ask deep questions.
“As designers, our jobs are so cool that everyone wants to do them for us.” So give people paper & pencils, and let stakeholders do some design work. (Especially early in the process.) If you have some pre-seeded ideas, you can direct the conversation a little bit.
Another needs analysis tactic: Come with some post-its, and have everyone write down the most ideal thing that could come out of this project. Put them on the wall, affinitize them, and discuss.
Ask what the value of the design is. By what criteria will the design be considered successful? Use that as a starting point to derive what the product planner wants.
Stakeholders will propose a solution. You need to understand the problem they’re trying to solve with the solution. Propose alternatives.
What approaches do people take for evangelism? How do you educate clients and managers.
For usability testing, let stakeholders watch. Or have video clips / highlight reels. Let stakeholders see the “aha” moments.
Let a third party do the evangelizing. Give them something to read (e.g, The Inmates are Running the Asylum). Or maybe just photocopy a chapter, if they’re reluctant to read a whole book. Sometimes, your point is in the title or summary of an article – even if they don’t read it, they get some of the message. A third party gives the message more credibility than just you.
If you know what brands your stakeholders respect, you can talk about what that brand does. But make sure you’re accurate – they’ll know what their competitors do.
For external clients, let your sales team educate clients on your process. It’s challenging to take an approach to a project that the sales person hasn’t sold to the client. Sales is where the approach with the client is defined. Then by the time you do the work, you’re contractually locked in to do the approach you want.
For internal clients, try to get involved early in the planning process. “We can make your planning documents look way cooler. We can get in screen shots. Would that be helpful?” Tell the planners: “If you want this 6 months from now, here’s a process we can use to get here.”
Speaking of sales, it helped to have the designer go on a pitch. It’s a good time to educate the designers about what stakeholders are concerned about. There’s also a time to be the guy in the black turtleneck, as a sales technique. Especially now, since the concept of design thinking is big & hot in the business community.
Q: Design thinking and business strategy
Where do design thinking and business strategy intersect? Where can designers help, and where do we have no business giving advice? Sometimes we can do our jobs so well that business people listen to our design suggestions and start listening to our business suggestions.
Identifying an unmet need, and bringing it to the attention of management, is a legitimate role of designers. But that’s different than saying “put all your eggs in this basket,” and advising how the business allocates its funds – that’s dangerous.
Follow-up: What is design thinking? What does the buzzword mean?
Design thinking is taking a design process and applying it beyond designing an object/web site. A natural extension of contextual design – understand how an object fits in its context of use. IDEO started going into the medial field, and found that the problems that need solving are larger than just the devices – the design process uncovered systemic problems. Apply design methodologies to business problems: Sketching, prototyping, systemic thinking. Use these to improve a business. This is related to service design – how do we improve a business process?
Because it’s a buzzword, business people, and even engineers, are more receptive to talking to designers. You can use this to your advantage.
Evan Dickinson is a former Portlander currently pursuing an MA in interaction design at Simon Fraser University in Vancouver, BC. He blogs about his studies for CHIFOO. Write him at evan_dickinson at sfu dot ca.
Interaction Design at Simon Fraser University
This is the first in a series of posts I’ll be writing for CHIFOO. I’m Evan Dickinson, a Portlander and CHIFOO member who recently moved to Vancouver BC to study interaction design at Simon Fraser University (SFU) in the School of Interactive Arts and Technology (SIAT). Before I left Portland, David Stubbs asked if I’d be willing to write about my time at SFU.
In this post, I’m going to to talk about the SIAT program at SFU – what’s in the program, why I chose it, and where I hope it will take me.
The biggest draw of SIAT for me is the interdisciplinary program. Many universities with programs addressing interaction design approach IxD by expanding on an existing discipline: Growing a design program or information school to include interactive technology. SIAT feels more inclusive – there is a home for people from various disciplines, and the program doesn’t feel like it’s geared towards just one discipline.
There are many fields of research at SIAT, and I’m still learning about them all. They fall into the general categories of knowledge computation, social and human experience, media and culture, scientific methods, and media art. My interests fall mostly in the social and human experience area: Interaction design, design ethnography, computer-supported cooperative work. And knowledge computation has some interesting aspects, such as visual analytics and visualization.
SIAT is a research-based program. (From what I hear, Canadian grad schools tend to place more emphasis on research than American grad schools.) The idea is that I’ll take coursework during my first year, then spend the bulk of my time in my second year doing a research project. I like the emphasis on putting my skills to use, and actually making something.
So that’s the long-term plan & possibilities, but what am I doing right now? I’m in two classes, information visualization and new media. I’m also the teaching assistant for an undergrad senior design studio, where the students apply their skills on a year-long project.
In the information visualization class, we are starting out by exploring human perception and using that as a foundation to explain why some visualizations do and don’t work. For example, when learning about color perception, we learned that people tend not to be able to separate the dimensions of color. It is difficult to splice a color apart and perceive red separately from green and blue. It is somewhat less difficult to separate hue, lightness, and saturation, but still not optimal. The graphic below indicates population density with hue, and change in population with saturation and lightness. You can sort it out, with some effort. The textbook author recommends using color for one variable and another attribute, such as texture or shading, for the other variable. (Ware, 135-137.)
(Map: U.S. Census Bureau.)
The new media class is about analyzing the design principles that go into new media works; things like narrative, representation of space and time, analyzing strengths and weaknesses of a particular medium, and the ways in which a work is immersive. This is is the most culture-centric class I’ll take – designed to give me some breadth. It’s been a healthy change for me. I’m used to analyzing designs only in terms of how well they support the user’s effectiveness in the workplace, and now I’m learning to use criteria that are less narrowly focused.
I’m the teaching assistant for a capstone project for the undergrads in SIAT. The students form interdisciplinary teams and work on a project of their choosing. They go through the whole project life cycle: inquiry, design, development, testing, and launching. Right now, their projects are still in the early stages. Even so, they are already planning cool things. We have teams who want to build rich media experiences, tangible devices, games, projects to encourage sustainability, and much more. I’m excited to see what the students come up with as the year goes on.
So that’s how my graduate program is starting out. I’ll have more to say as my education continues. I welcome questions – the point of these articles is to share what’s interesting, and your questions will guide what I write about.
Brewer, Cynthia A., and Trudy A. Suchan, U.S. Census Bureau, Census Special Reports, Series CENSR/01-1, Mapping Census 2000: The Geography of U.S. Diversity, U.S. Government Printing Office, Washington, DC, 2001.
Ware, Colin. Information Visualization: Perception for Design. San Francisco: Morgan Kauffman, 2004.
Architecture and User Experience (Part 10: Pieces of the Puzzle)
Finally, after 10 months of wide ranging discussion, I’ll touch on the parts and pieces of a User Experience Architecture. In addition to describing the Puzzle Piece Meta-model as a framework, I will go into detail about each of the pieces themselves.
The puzzle comprises four main areas:
- Quality Attributes - the branding experience - the emotive qualities of the experience - the impact of the experience
- Models and Use Patterns - the user behaviors, work models, contexts, mental models and patterns of use the experience must address
- Design Language - style guides, visual representations, interaction standards, widget libraries, content architectures - how the experience is represented to the user
- Design Principles - the underlying, fundamental principles to guide decisions about the experience - perhaps the one thing to distinguish this “architecture” from any other
The Puzzle Piece Meta-model
Hugh Dubberly’s May/June Interaction’s article provides a great survey of models and frameworks - a sort of meta-model of meta-models. It’s wonderful and I highly recommend it. (ACM Digital Library subscribers can see the full article online - here is the bibliographic reference with links to the online version for subscribers). I’ve spent most of my design career self-consciously considering the model I use even as I design the object itself. Our tools craft our models; our models craft our perceptions, and hence our designs are affected by the modeling frameworks we employ.
I prefer cyclical diagrams - I am a strong believer in spiral progression: we continue to revisit the same problems and situations, but never the same way twice. Linear models are too definite - most real world experiences are a continuum with no definite starts and stops. Even birth and death are stages in a continuum, depending on your point of view.
The Puzzle Piece Meta-model is a closed cyclical diagram with five parts. The outer four “puzzle pieces” interlock, each invading the territory of its neighbor. If I were more clever, I would have found a way of representing the pieces so that all four interlock with each other - perhaps as a star pattern, or maybe a 3D globe - because in fact, all parts of the framework touch all other parts. A decision made in one area depends on and affects decisions made in the other three areas. The fifth part - the center - is the experience itself. It comprises the objects, artifacts, built environments, phone scripts and any other user facing elements actually delivering the experience. It is intentionally left blank as the experience morphs considerably over time and from project to project.
The puzzle pieces do not morph considerably over time. They change when the user population changes, the technology infrastructure changes, or the business model shifts. None of those move rapidly or dramatically compared to the myriad possible experiences an organization could deliver.
The diagram has several faults in addition to the aforementioned lack of total integration of all four pieces. It is too “slick” - its clean edges and corners suggest a finality and completeness that I’m quite certain is hubris. It’s not nearly architectonic enough for my aesthetic - it’s crude. But it’s sufficient to communicate to business and engineering stakeholders without my having to explain the meaning of each piece (even if I do have to explain the content of each piece).
Contrast my Puzzle Piece Meta-model with Morville and Callendar’s Treasure Map of User Experience Deliverables. Although their stated goal was not to develop a meta-model for user experience design, many of their deliverables map well into my puzzle-piece meta-model. As I describe each piece I’ll also reference example deliverables from the Treasure Map.
I don’t know from where I lifted the term, but I like it. It is used in lots of contexts. I like its multiple ambiguous meanings.
Quality - as in “peculiar and essential” characteristics, not as in “degree of excellence.” I use it to emphasize the non-quantitative aspects of the experience. So much of our training and guidance in user experience stems from gathering data. I included this adjective to reinforce the importance of emotive aspects of the experience.
Attributes - a way of purposely blurring the edges of the experience - the experience isn’t a set of things, rather it is a set of attributes that surround the thing. The phenomenological debate surrounding experience design (can we really design experiences, or design for experiences, or design contexts in which people have experiences, etc.) is not terribly interesting to me. I leave those distinctions to the philosophers. I do know designers and architects have been intentionally creating opportunities for others to enjoy and experience their creations for millennia. It is this self-conscious intentional act of creation I’m referring to with respect to designing experiences. This quadrant of the meta-model describes attributes of the experience I hope people will discover, encounter and desire.
Put together, these two words describe the aspects of the experience that are emotive, non-quantifiable and create a long-lasting impression. The Quality Attribute piece of the puzzle covers key characteristics of the experience users expect, demand or desire.
To illustrate my point, consider two completely different design problems: a game and a rodent trap. For the game we are likely interested in creating an immersive experience with lots of “flow.” We’ll likely want to seduce the user and tease them as a way of enhancing their engagement. For the rodent trap, we will likely avoid seduction (for the human user, perhaps seduction of a different kind for the rodent), enhancing safety and security (again for the human, but also possibly for the rodent) and depending on the design, the humaneness of the device. In the first design problem we may wish to create an engaging experience for children; in the second we’d likely want to push children away.
Quality Attributes deliver the brand promise - the two are reflections of the other.
Nothing in the Treasure Map deliverables directly correspond to this aspect of the Meta-model although a few of Morville/Callendar’s deliverables include these qualitative aspects.
Most user research, usability and user-centered design activities and deliverables are part of this puzzle piece. Mental models, work models, contextual inquiries, most of the pre-design deliverables discussed in my last article all fall under this puzzle piece. This piece is where we determine and describe the users’ context, behaviors, work breakdowns and other artifacts to which our designed experience must respond.
Some would claim the models and patterns are the UX Architecture, but as I argued in my last article, while a crucial pillar in the structure they are not sufficient to comprise an architecture. If only the contents of this puzzle piece were the architecture, then Software Architecture would be an appropriate framework for a UX Architecture (since Software Architecture comprises many of the same kinds of deliverables contained in this section). But as the most recent article pointed out, Software Architecture is not a sufficient framework to support a UX Architecture.
Note how Quality Attributes integrate with Models / Patterns: if we believe a key Quality Attribute of our designed experience is to attract the user, we must have data, contextual models or other formalisms to support that position. The obverse is also true: an observation of our users’ habits must inform us as to what is attractive to our user base and hence inform our design direction accordingly.
Almost all of the Treasure Map components correspond to this portion of the Meta-model, including: Stories, Proverbs, Personas, Scenarios, Analytics, User Surveys, Concept Maps, System Maps, Process Flows, Story Boards, Wireframes and Narrative Reports.
The Design Language we choose is crucial to expressing the experience itself. Our choice of colors and geometries, even our use of language itself are the direct interfaces people have with our designs. Whether we are designing an artifact, and environment or a new service, there is always a “surface” with which our users interact. This piece of the puzzle addresses the thousands of micro-design decisions necessary to communicate the Quality Attributes and embrace the discovered use patterns.
Typically an Architecture has a “style guide”, specifications, standardized controls and prototypes that define the boundaries of the solution space so that multiple designs over time reflect a coherence with an underlying structure. This puzzle piece covers all of the vocabularies (visual, interactive, architectural, content) we will use in our design.
Consider the rodent trap example. The aesthetic choices for the trap itself, the material, its packaging and the supporting marketing communication are all specified in this puzzle piece in support of the use models and Quality Attributes defined in the other pieces.
Most of the remaining deliverables in the Treasure Map fall into this area: in addition to Design Patterns, Style Guides and Specifications, I would include Concept Designs and Prototypes.
A design is part of an Architecture by virtue of its conformance with the underlying (or overarching) design principles laid out in the Architecture. Through a self-conscious, intentional choice of principles, the architect establishes a framework tying the other pieces together.
Design Principles are perhaps the most important ingredient to an Architecture; without them we would still have a design, or an engineering solution, but we wouldn’t know whether our design was part of a larger constellation of designs belonging to a common architecture.
According to Bill Buxton, one process distinguishing design from engineering is the formal nature of “critique.” Architects critique another’s work by reflecting on the Design Principles inherent in the solution. Either the work is criticized because of the (poor or inappropriate) choice of principles, or it is critiqued because it fails to conform to the explicitly chosen principles. In any event, designs can only be evaluated in the context of their Design Principles.
There are literally hundreds, if not thousands, of design principles. It is up to the Architect to decide which principles are key and which can be ignored. The choice of principles depends on several factors perhaps most critically, the subjective aesthetic of the Architect. When you decide to hire an architect, choose carefully - her design “aesthetic” (which principles she holds dear) may conflict with yours.
In the Puzzle Piece framework, Design Principles must be consistent with the Design Language, Use Patterns and the Quality Attributes. That is, the Design Principles must inform these other puzzle pieces as well as be informed by them.
A few articles back I made passing reference to three Vitruvian principles: firmitatis utilitatis venustatis, translated roughly as strength, utility, and beauty in the context of “elegant” design. Vitruvius, a Roman Architect, engineer authored his famous “10 Books of Architecture” over 2000 years ago, and briefly mentions these three characteristics as inherent to any design. I put these design characteristics together into a single “Vitruvian Principle.” For me, the Vitruvian Principle is a key metric I use to evaluate a design proposal: Is it robust? Is it useful? Is it appealing?
Which principles the Architect chooses and their relevance to the targeted audience is one meta-decision to be made. A second is how many principles to abide by.
Mies van de Rohe, a mid-20th century pillar of German and American Modernism, is famous for his design principle “Less is More.” The absurd conclusion of this principle leads to it being the only principle. Minimalist designs, Google’s home page for example, are driven by this principle.
Sticking to a single design principle (assuming for the moment it’s even possible) drives a purity in the solution. Assuming the design team is successful in driving an expression of this principles, users will feel its impact.
A single principle for most non-trivial design problems is likely impossible. At best it leads to tedious results, at worst, broken. If one principle is not enough, what is the upper limit? Theoretically there is no upper limit - one of the joys of Architecture is juggling the number of design principles. For some Architects, dozens of principles come into play as justifications for specific design decisions. It comes down to an individual’s capacity for keeping multiple balls in the air.
I top out at about a dozen principles for the most complex problem spaces; beyond 12 my design solutions become diluted by too many competing influences. For less complex problems, a handful of principles is usually more than sufficient. But again, this is a subjective decision, completely integrated with the Architect’s aesthetic and competency.
Finally, to be an Architecture, the Design Principles must be chosen intentionally and before the design is complete. Some may be picked a priori because they are part of the Architect’s aesthetic; others may be brought into play as new information about the problem is revealed. But as a new principle is brought into the Architecture, all of the prior decisions must be reviewed in light of the newcomer. The coherence of an Architecture depends on the interplay between the meta-decisions (Design Principles) and all of the design decisions. We don’t get to pick and choose which principle applies to which aspect of the design and still call the solution an Architecture.
This last piece of the puzzle is extraordinarily self-conscious. It is the constant reflective activity of design, in this case not on the experience design, but rather on the design of the Architecture itself.
So that’s about it. I’ll finish up next month with some reflections on how to get started in crafting an architecture and how you know you’re done.