arkitrave :: log

Design and Social Responsibility

This was a good panel, though a little dry in the presentation. I tend to prefer more conversational, interactive panels to those in which each panelist presents their little 10-15 minute package with separate powerpoint files. But, the information was good. The portion on accessible Flash was thought-provoking; I’ve been thinking a lot lately about alternate content as a replacement, and this is just another extension of that idea.

What are our responsibilities?
Basically, the web is about people, not technology. We can’t accept the way things are. We exercise humane principles in other areas of life; why not the web?

Examples of technological difficulties: Microsoft Word predicting what you want, Flickr (try sharing photos with Mom…), things I don’t actually want from Amazon, despite their algorithms, difficult checkout processes, and forms with “clear” buttons. Nobody needs clear buttons; they just typed in the information!

The good news is that we can do grassroots activism and effect change gradually and incrementally. More usable technologies are always more accessible, but not necessarily vice versa (accesskeys screw up the browser controls).

Think like your users. Step away from the visuals. Start with the usability/content/text, then move into graphics afterward.

Remember, Google is deaf and blind.

What should technology look like?
Technology should serve people and improve their lives. It should adapt to people. 1) Tech is a utility, like electricity. 2) Tech should be simple. Feature lists should shrink, not bulge. MS Word has too many features. 3) Tech should be ubiquitous. 4) Tech should be contextual. 5) Tech should integrate into our lives. Solve needs first.

Technology is not the solution; it’s the utility that supports the solution.

Accessible Flash
96% of the 6.2 million US disabled students are in the mainstream after 1997 legislation. Thea showed an example of an accessible Flash game. The experience for a blind user is different, but they can still play the game. They complete sentences that are read to them instead of positioning the tiles on the screen. This doesn’t take too much extra effort if it’s planned from the beginning of a project. Her firm has done many accessible Flash games for kids.

Clients say “The web and Flash are visual tools.” These accessible Flash games work for non-sighted people. The web isn’t just visual. For disabled kids, tech is everything. They have and depend on many gadgets. Tech levels their playing field.

Cleints say “We’ll have to sacrifice interactivity and fun.” The truth is that accessibility in Flash often means more usability (exposed states, control over sound, etc). These are things that improve the user experience for everyone, not just the disabled.

Clients say “It’s too time-consuming and expensive.” But, it’s a lot easier to incorporate from the start. You show social maturity, do the right thing, and set the example for everyone to follow, instead of closing the door on part of your constituents.

Conclusions
We need to learn how to sell this stuff to Marketing. There are benefits outside of just disabled people. Don’t focus on the technique. Everything is expensive if you don’t plan for it.

Tagging 2.0

Not a bad overview. This was more well-done than yesterday’s panel on Tag Clouds for Grandma. It highlighted issues and problems with tags as well as the reasons why tags are around to stay. Still, there was duplicate information presented, and much of the thoughts were things we already know (who has used delicious and not run into the problem of delimiters…?)

Uses for tags: re-finding information, personal metadata, new command line, tags as verbs? (buy/sell/print). Helps with focusing on the user’s view, not the system itself, links users by interest, helps people learn about things they don’t have the jargon/vocabulary to research in other ways. Issues: Tag Spamming. Implicit tagging is good and bad…our interests change and we get smarter over time. A huge issue with tagging is the interface; how do we make it interesting and fun to tag, as well as really easy?

Tagging looks messy to others - tag clouds aren’t understood by the masses.

Six dirty secrets of tagging: 1) It’s the content, stupid. 2) Ordinary people don’t get tags. 3) It’s the UX, stupid. If tags work, it’s because lots of attention has been paid to the UX. 4) Tags don’t play well with others. Delimiters are a problem. Character sets are a problem. Singular/plural. Shades of meaning. 5) Rich functionality requires rich metadata. We don’t want to hunt terrorists with tags. 6) Nobody wants REAL tags. We want “tagginess.” People are experimenting with hierarchical tagging, which flies in the face of the whole idea of tags by creating folder structures.

Reasons for tagging - mainly, categorization is hard. Trying to put things into category boxes doesn’t work all that well, and tagging gets around that problem by allowing many words to be used. She talked a little about the wisdom of crowds; groups can be wise under the right circumstances, and she feels tagging is one of those. Tags are good because they support cognative diversity, decentralization, independence, and easy aggreagation.

Tips for use: 1) Serve individual’s motives. 2) Does the individual understand and support the goal? 3) Social vs. personal. 4) Too easy to mimic the tags of others - try to keep autonomy of the tagger. 5) ? 6) Enable discovery. 7) Let users do what comes naturally. 8 ) Ensure good findability.

Lunch

Twelve of us went to lunch at a mediocre Thai restaurant with glacial service. It took so long to get out of there that we missed the Mobile Web panel completely. Here’s me at lunch.

Web 2.1: Making Web 2.0 Accessible

This was an excellent panel. Derek Featherstone kind of stole the show, and the moderation kind of made me feel like I was in gradeschool, but there was lots of content.

Components of web accessibility include author tools, evaluation tools (validators etc), developers, users, user agents (browsers), assistive technology, and content.

A good amount of time was spent discussing the new WCAG guidelines. Basically, this new version is technology independent, rather than just focusing on HTML. The guidelines are also testable, rather than nonspecific (5:1 lumosity ratio, rather than “sufficient color contrast”). She recommends that you read Understanding WCAG 2.0 instead, as the actual guidelines are pretty technical.

We have a myth that things need to work with JavaScript on and off. What about a screenreader running on top of IE6 with JavaScript turned on?

Derek talked about issues: we need lots of testing. Tabbing through documents needs to work (CSS image map example was used). JavaScript libraries should build in accessibility. Go Test With Users.

It’s not just about people who are blind, either. There are many different types of disabilities.

Matt works for Bank of America. When he started, the web group was controlled by Marketing, and couldn’t do accessibility. Now, the group is called the “User Experience Group” or something like that, and it has veto power over Marketing.

How to fix things today: Keep it simple. Go back to basics. Do JavaScript, but degrade, and keep your HTML pristine and semantic. Flash does remote scripting better than Ajax in many cases; it’s had a lot more practice.

We need to make accessibility cool.

Holistic Web Design

The idea was 5 people. 5 cities. 5 skillsets. Create a website redesign working together as a team. Jason Santa Maria (graphics), Carl Sieber (HTML and CSS), Garrett Dimon (usability and project management), Eris Stassi (information architecture), and Shaun Inman (JavaScript).

The site was plazes.com, a social map-mash site to find your friends around town. The site, as you can see, has some problems. But this posse fixed all of them.

We have a myth of separation in design - really, all our parts integrate with each other. Involve everyone in the group. Share. Communicate. Educate. Respect Everyone. Compromise. Remember the Big Picture.

Interaction Design: Eris used two forms. First, a page which asked the Intention, Goal, and Question of each main page on the site. This helps to get rid of things users don’t need or won’t use, and leaves things open for the graphic designer to create, rather than force-feeding him wireframes. It’s goal-oriented rather than layout-prescriptive. Second, she used page description diagrams to lay out priorities for each page. No layout or design yet.

Graphic Design: Stan used his sketchbook, started with the logo. He passed around the sketches to everyone on the team, not just finished comps. This brought everyone into the project and allowed them to give feedback. He works from sketches to gray boxes (no color, just layout) to finished comps with color.

Markup: Nothing revolutionary here, and the snippet of code he showed wasn’t so hot; it should have been a definition list instead of a name/value pair separated by a <br> tag. He made validity and no hacks a priority. Putting in hooks for Shaun to script with was easy. He used sIFR for type, sliding doors for a couple page controls, and faux columns to keep columns looking equal height. Remember, the <form> element is a block container; you don’t need a div around it. Use comments to close div tags to keep track of your code better. [note: comments after closing div tags when boxes are floated can lead to ugly IE problems]

Scripting: The site used Google Maps and it’s API. He used modular code so that there would never be conflicts with any other script. He tried to minimize touch points with the HTML and maximize flexibility of the code. He built a better buddy list - you don’t need everyone in the world showing up; just the people in your area.

Accessibility: This actually seemed to be more of an afterthought than it should have been. Derek was consulted, but they didn’t implement many accessibility features.

Some notes from the demo of the site, in no order: “Everything on a page should beg to be there.” Hierarchy of the page is important - everything can’t be the most important thing on the page. Whitespace should be there, but not trapped in the middle of the page. Pay attention to templates with multiple states; some of these states may have whitespace problems.

This was a great example-based panel, after a day of theoretical academic exercise. Their parting thought was especially vital for working with multi-disciplinary teams: Everyone should know and be able to talk about everyone else’s part in the project. People work so much better with each other when they respect and understand each other’s roles. Take a developer out to lunch. Educate each other. This makes for effective teams.

This was an amazingly talented group, and they all have a mutual respect for each other. But, these ideas are portable. I’ve found in my own work for Fisher-Price that I have a couple developers I’ve spent a lot of time talking to and demonstrating things. These developers work with me, not against me, when I hand something off to them. We end up with a really good product, because we each know what the other’s job is, and we respect each other. It sounds basic, but it’s vital to an effective working relationship. Front-end people who despise developers and developers who think front-end people aren’t real coders can’t get anything done in teams. Get educated about what the other people in your workflow do.

A Dinner Panel

There were nine at Chang’s for dinner. A much more pleasant experience than lunch, and great conversation. I met the guys from Godbit and CSS Beauty, and Nathan Smith and Dave Seah got into it over the legitimacy of being part of a network of sites (not that I’m going to name which network they may have been talking about…)

This turned into a couple-hour conversation that was as good as some of the panels I’ve been to. Too bad nobody was recording it, so there will be no podcast.

It’s late again. Tomorrow looks to be a great series of panels; I’m having a hard time deciding what to attend, and there’s one time slot that I really want to be in four places at once.