On the Why Grow Coders from inside of Libraries question

You have to take a look at this great Library Hat blog post on "Why Not Grow Coders from the Inside of Libraries?" Author Bohyun Kim's opening paragraph makes a compelling argument about the benefits of having in-house developers at libraries:

How fantastic would it be if every small library has an in-house developer? We will be all using open-source software with custom feature modules that would perfectly fit our vision and the needs of the community we serve. Libraries will then truly be the smart consumers of technology not at the mercy of clunky systems. Furthermore, it would re-position libraries as “contributors” to the technology that enables the public to access information and knowledge resources. I am sure no librarian will object to this vision. But at this time of ever-shrinking library budget, affording enough librarians itself is a challenge let alone hiring a developer.

Bohyun Kim (@bohyunkim) mentioned the difficulty of luring an IT professional into libraries. But at DrupalCon, I met several people who'd migrated into libraries from the world of "commercial web development". I know that this just anecdotal, but it reinforced other times recently when I've watched IT pros go into either libraries or state government from the commercial world. They were often pained by the pay cut, but in the current jobs environment (not to mention with the rising cost of healthcare and the outsourcing of IT), it may not be so hard to hire those IT folks after all.

On the flip side, I totally agree that those librarians who are so inclined, with enough of a technical background, could and should become developers. It would help libraries... a lot! Moreover, I think that the libraries should commit to providing resources and support for these staff. But we do, as a profession, derive a benefit from getting people from outside the library world to work with us. They give us new perspectives on the best way to do things. And there's a part of me that thinks that it may be easy for developers to come into libraries with the right skillset already in place and adapt their mindset, principles, and concepts to the library environment. Developers are used to working for all sorts of different agencies and organizations - everything from nonprofits and government to for-profit. If they're user-centered, they'll learn the library environment & be good additions to it, regardless of their background.

But what I wanted to point out most was what I feel the real issue is - a lack of vision and leadership in regards to the library's role and how technology plays into this vision. If you think that the library is nothing more than "books" (which is what most of the non-library-using world thinks it is - that's our "brand", if you will), then you wouldn't put resources into information technology. Instead, you'd expend time and create jobs (and whole departments) for aspects of handling those books.

And that's just what happened.

What we really need is to cement the vision of libraries as providing support for the community's information needs. And given that so much information is online (and, in fact, that we're putting it online) this commitment means that we need expertise in information technology. There are some library leaders who are committed to this. In some cases, they were committed enough to - like Darien Library - change the organizational structure to reflect their values. They've done away with the cataloging department and instead created a technologically-inclined user experience department. I don't mean to kill the sacred cow (and there are places where catalogers are still needed, but for most public libraries, honestly, they need to build better systems more than they need original cataloging).

But what do you think? I know it's a bit of the same old argument we've been making since (at least) the 1990s, but I think it's worth getting to the root of the issue and then establishing a way forward that will resolve that issue. To me, it means that all library directors have to buy into the need for (and complexity of) better technological support. Solutions include library directors supporting staff who want to code, integrating IT with all of the library, and hiring from the non-library world. There are a number of methods to deal with this problem. It's just that the people with the hiring power and the budget have to agree that it's a problem.

The Unintuitive Nature of Creating Intuitive Designs - Jared Spool Keynote Day 3 - DrupalCon Chicago

Jared Spool was funny and right on, a great final keynote speaker for DrupalCon, reminding Drupal developers about how hard it is to create “intuitive” designs, but exhorting us to use several techniques that will help us achieve such designs. This long-time human factors engineer is truly a usability guru - he knows his stuff. When Spool speaks, all web developers/designers must listen... (content developers must listen, as well...)

Jason Samuels, who I met at DrupalCon & who was a fellow tweeter at the conference, has done a great writeup on this session at: http://goingtodrupalcon.wordpress.com/2011/03/10/jared-spool-keynote-speech-notes/

Also, take a look at the DrupalCon Chicago site to view the video of the keynote (not sure if it will remain at this url, but it is currently visible at http://chicago2011.drupal.org/live. It’s definitely worth it!

I’ll just give you my raw notes, because I don’t have a lot of time to post about everything I saw and learned here at DrupalCon Chicago. Hopefully, they’ll be helpful to someone.

Avis went against understood design patterns - * next to optional (v. required) fields... to avoid a senseless waste of asterisks!
learned unintuitiveness - the asterisk (now means required)

What is an intuitive design?

AIGA website in the 90s (Am Inst. of Graphic Artists) - “they built the damn thing in Flash” - created scrollbars in Flash, to keep visual integrity in place, but scrolling didn’t work well only went up 1 line of pixels at a time

the problem was that they didn’t understand how to build a scrollbar (which is actually really complicated, as simple as it sounds, it’s hard to do. Only like 7 people are left who know how to do this, but we don’t need to build new ones - it’s a done project, take it off the list... it’s perfectly functional, as is.) But AIGA built scrollbars from scratch, nonetheless and, of course, didn’t know how to build them so they created tremendous usability issues. This took focus off of the content and instead focused the user on the site’s unintuitiveness.

Intuitive design keeps user focused on their objective

It’s not noticeable. It’s invisible.

it’s not the novelty that makes something unintuitive... could you have an unintuitive design in a simple page?

YES...
found 1 a while back at the U.S. Dept. of Agriculture - Hay Net - how can you screw this up - very simple, you either need hay or have hay... but end-users didn’t know if you the link labelled “Need Hay” would give them list of people who needed hay or was for people who needed hay.

Intuitiveness has nothing to do with complexity vs. simplicity

it has to do with being invisible; if I have to take focus off what I’m trying to accomplish, I’ve lost intuitiveness

hard to put up pictures of good design - you don’t notice it

like air conditioning, only notice it if too hot or too cold

An intuitive design is personal, though, so we have to know about our users

ATM may be most intuitive thing we’ve designed; but there are confusing ones - 1 in India - 3 similar options: “Cash withdrawal”, “Fast cash”, “Ultra fast cash”
What does that mean?
could invent an unusable ATM - put everything on it, but in another language - but this is similar to this is often what we do with design

just look at anything Microsoft has ever designed - unintuitive (I think he played this one just for laughs - it worked... it was a good example from the Access 97 days, I think).

You would think after years of selling subway tickets, it would be simple to do, but as the photo of the fare card purchasing machines (& their instructions) shows, it’s not!

current knowledge is what they come to the design with

target knowledge is what they need to know to use design

so the difference between the two is called the “knowledge gap” -

only design for this gap... nothing above, nothing below

current knowledge should be = target knowledge for design to be intuitive

2 ways to fix gap:

1. train user (bring them up to target knowledge)

2. simplify design (bring design to them)

- ongoing cost option = training

options: training v. simplifying

Wang word processing machines in the late 70s - so much training required - paid $14K for A week-long course simply to load file, save file, and print file... The advanced course included italics and bold...

original Wordperfect - the little cardboard/keyboard templates to put around the function keys to show all of the features - so many features!
we go from raw technology to something with lots & lots of features (too many for most users) to simplicity... The one designed to be simple takes the prize (Microsoft Word v. Wordperfect in the early days of pcs / word processing programs)!
... then shift back to wanting more features
the same thing happens in hardware world

raw technology-->more & more features-->simplified experience

you can make the shift from features to experience

Problem with extra features is that they create a gap between current knowledge and target knowledge
users bring their own current knowledge to the table... they’re all over the map, though

multiple domains of knowledge, too... that’s what makes creating something intuitive REALLY HARD

What techniques can we use to make it easier?

used these techniques for years, very effective:

1. field visits - have the makers meet the customers (“Jane Goodall” experience)

1a. helps identify who the users are and their current knowledge

2. usability testing (not user testing, because not testing user, testing design)

3. quick tests:

- paper prototyping

- five-second tests

Handbook of Usability Testing is recommended book

paper prototyping - using their finger as a mouse (the original pointing device - "mouse classic")

shows us about flow

and if the labels that you’re thinking of are working

also recommends book Paper Prototyping, Carolyn Snyder

five-second tests (which you can do in 10 minutes) (5-seconds to memorize screen then write down all you remember about it & rate it)

just username/pwd, live chat boxes -

support cases - 8

challenge: watch users interacting with your design: at least 2 hours every 6 weeks

this is not rocket science

when upgrading to a more usable version - don’t bring the whole system down!

"Facebook has mastered the art of screwing with its users"

like your kitchen cabinets got all rearranged when you were sleeping - the usability fairies change everything - you didn’t ask for it, but they’ve decided to do it - the goal wasn’t to have a more efficient system, but to get kids off to school, which the new changes don't help with (beware of turning into the usability fairies)

destroying the users’ current knowledge

so how do we deal with this?
mitigate pain of change with bubbles, overlays to show what the new functionality is

but have to think about the process of designing for the change
design the process of change for the user base

we have to give them some control over this

- an intuitive design is invisible, personal, when the user is focused on their objective
- when current = target knowledge
- when design is focused on experience
- different users have different current knowledge
- you need to collect feedback about your users and their knowledge
- design for embraceable knowledge

spend at least 2 hours in the next 6 weeks to watch users interact with your design

Clay Shirky's Keynote Presentation

I loved Clay Shirky's keynote (see: http://chicago2011.drupal.org/live)
He reminded all of the web developers in the room that "the most valuable thing attached to a computer is the user" and covered the new "C's" in CMS (not just Content, but) Community, Convening, Culture. He believes that we're moving into Community Management Systems (vs. Content Management Systems) and, further, that these are evolving into cultural management systems. People who work in libraries, museum, and governmental agencies should be participating in movements like the open-source Drupal community, if for no other reason than that [my aside].
I know that there were those tweeting during the keynote about how this was just a rehash of the old Web2.0 paradigm that we've been hearing about for nearly a decade, but I think Shirky added some new pieces to the discussion and refocused the Drupalists on how we build our systems.
1. he challenged web developers' conception of the user
Shirky pointed out that we often develop for personas, as though people behave consistently - always good or bad, for example. He mentioned what psychologists term "the fundamental attribution error", wherein we see others' actions as though they are a distillation of everything about those people (so when they behave in destructive ways on some occasions, we imagine that they are always destructive) vs. seeing them, as we see ourselves, that is to say, behaving due to context and circumstances. (e.g., when I cut off that person in traffic, I was rushing to the hospital, but when someone else did, they were showing how selfish and narcissistic they were).
This does remind us that the use of "personas" - and our design for personas can actually have a negative flip side, in having us design systems for "people" who we imagine behave in certain ways all the time. The scenarios we put those personas in are more important. The context is crucial in figuring out how to build systems to work best for people. Which brought us to his second challenge:
2. he spoke about targeting behavior as a 1st-class object
As we build community systems, we have to build them to accommodate behaviors, not single-dimensional personas. We have to build systems that reinforce the behaviors we want and reduce the effects of behaviors we don't want. He used the example of del.icio.us and how, as the social bookmarking service was designed, there were debates over how it might be mis-used. Sure enough, many of the designers were concerned about the possibility of spammers bookmarking spam sites & gaming the system until those bookmarks were highlighted, reducing the value of the community tagging of sites. But they decided that as long as they built the system to not allow those spammy bookmarks to rise to the top, it didn't matter if spammers were using the service. If there's spam on the system, but none of the real community is affected by it, does it matter?
Through the social aspect of the bookmarking system, they actually leveraged the greater number of community members - who wanted to use the system legitimately - and used their collective input to highlight which tagged sites were valuable. In choosing this approach, they stopped themselves from designing onerous barriers to legitimate community members which they would've had to include if they were designing more heavily around the "spammers". Instead, they concentrated their efforts on a system that would enhance/highlight the legitimate behaviors of the many and reduce the effects of the illegitimate behavior of the few.
3. he talked about including users in redesigning the system as we go
This one isn't so revolutionary - you've heard it a million times nowadays. There's two parts of this statement: (1) that you include the community in building the system and (2) that you build iteratively. The bit that he added in that I personally hadn't thought of (in this way) before was about how you can't pre-design the system for the user. It's real-time use that shapes how you build. You'll never be able to fully anticipate how people are going to use what you provide, so instead of pre-designing for all of the edge cases, you need to design the system with community input and more importantly, design a system that easily enhanced/changed/redesigned in response to community demands.
Along the way, Shirky also pointed out some interesting things about organizations & organizational culture - that, for example, successful open-source movements are led by people who might be described as "benevolent dictators". In other words, they neither micromanage, nor are they simply charismatic visionaries, the leadership options we so often see in the corporate world. Instead, they are "roadblock clearers" whose commitment to the continuation of the community trumps the disputes that inevitably arise when there are so many impassioned developers involved.
He spoke about Linux's creator Linus Torvalds, who, at one point did source control by having community members send their work zipped via email to him and he redistributed it via email. He did so until he could find a technical solution that "fit" the linux community's culture. So he cleared the roadblock, kept things going until he ultimately resolved the dispute with a technology that fit into their community practices.
He also said that in such impassioned communities, what worked best was for the communities to have a space to "take it to a room" for debates, without affecting the development of the project overall. So online spaces for such communications are crucial infrastructure for open-source movements.
He pointed out the difference between what's been called "single-loop organizations" and "double-loop organizations". The former, he said, fix problems; double-loop organizations, however, fix problems and the situations that cause the problem.
He didn't say that the open source movement was definitely going to survive and persist and that it would all work out. Instead, he said that the people at DrupalCon (and active in other open source communities) represent "the experimental wing of political science".
I think that the endless feedback loop of the community with its resulting "continuous, iterative improvement", the participation of believers who are most impassioned about the project (along with the space for other folks, who may be less involved, but whose contributions may nonetheless be helpful) will ensure the continued success of the amazingly powerful, open-source Drupal project. I think Dries, and so many others who've gotten involved, are correct to emphasize the community aspect of their work.
Being here, right now, with the Drupal community, gives me a lot of hope about the future.

Organization of Intention

So awhile back, I posed the question about centralization vs. decentralization when it comes to systems - which is better?

I’ve just been in a great keynote by Clay Shirky given here at DrupalCon Chicago. In it, he spoke about how those great old concepts of Web2.0 are playing themselves out and what our challenges we face as website developers moving forward. I’ll summarize it in a separate post - it’s worth a whole post. But bottom line, we have to stop considering the audience the audience, but rather as collaborators. We have to cede control of our web presence to the community of users.

So you’d think I’d be all about having everyone just do everything. But what I’ve been watching - both in the larger world and more close to home - is the political power of organizing intention. The less empowered, the less resourced you or your organization is, the more important it is for you to rely on community and to bring the community together. So, when it comes to the question of centralized, high-control systems vs. lots of little grassroots projects that don’t even know about one another, neither is ideal (in most cases). Instead, depending on context (which is key in an analysis of needs), most systems work best when they facilitate collaboration. That’s the key. It’s not whether or not the system itself is centralized or decentralized. It’s whether or not the system helps people to work together, leverages and harnesses their strengths, empowers them at an appropriate level. Importantly, those who are empowered have to work together, within certain parameters. That's the only way it all works. That's why there are legal systems and governance in complex societies.

A lot of times with library systems we make a huge mistake. We have databases, “digital collections”/archives/repository systems, a catalog, a website, some web2.0 tools. And these don’t work together. They’re under the control of different people. Each of those people is an advocate of their little world and in control of their little world. But they aren’t sharing with others. Often times, they’ll create a little blog on the side because they’re nervous about the high control folks saying no. All of those constructions can only be fractionally successful, at best. They are unsustainable without the one or two people who are behind them. They are really constructions of ego. They are built of fear. Fear of loss of control. I empathize, I really do, but I also see the negative results of diffusing our efforts. I see it in poor user experiences. If you want the end user to support your larger organization, you have to harness your efforts with the efforts of the larger organization. And if you're not supporting the larger organization, then who are you working for? On the flip side, the technology should be supporting us as staff to be empowered to innovate. And empowerment of staff can lead to great innovation. It's just that we need to harness all of this - we need to have collaboration, communication, and agreement about our overall mission.

With the many little independent projects, neither harnessed nor collaborative, there is no overall sense that we are creating what either the user or the organization needs to fulfill their goals. The scaffolding of all of these endeavors must be collaboration. The construction must be worked on together. We have too few resources - too few people and too few funds for little fiefdoms.

And yes, Drupal is a technology designed to help us harness and empower the collective staff intentions in service of users’ needs.

Wrapup of Webform module session

This session was a great introduction to the Webform (contributed) module for Drupal. It also showed those of us who've looked at Webform the awesomeness of Webform 3 and how well it plays with not only Drupal 6, but Drupal 7. (btw, link to the Webform project page is http://drupal.org/project/webform)

Personally, I find a few things particularly great about Webform for my library's use (not specific to Webform 3, also true of earlier versions):

• webform will allow my colleagues to easily make forms and polls/surveys (of whatever complexity they want, with many possible methods for data collection) without them ever having to come close to code
• webforms created using this system will be more secure than we might come up with from scratch - keeping our form creation activities from opening up new security holes on the server... also, can apply form spam blocking techniques (such as the use of CAPTCHA or Mollom modules)
• that it actually offers at least as much functionality and ease-of-authoring and data collection as SurveyMonkey, but gives us a lot more flexibility

My notes are found below (BTW, some rockin' new aspects of Webform 3 are highlighted - take note!):

Webform 3
Nathan Haug
“quicksketch” on d.o. - Lullabot Consulting, Development, training

Webform
- the tool for making surveys on Drupal
- easier to use than CCK
-- no it’s not based on CCK
-- no it’s doesn’t use Entities in D7
- designed for end-users, not administrators (people who just want to make a survey)
- many-to-few method of collecting data - many fill out form, just a few receive the results/submissions
- not a data creation tool, but users can see their own submissions, if you’ve granted them that permission

New Features in Webform 3
- ability to have conditional logic - can show fields / multi-pages based on what the answer to previous questions were submitted (so many people who aren't in development have no idea how difficult this functionality can be to add in... but now anyone can do it!)
- user can now save drafts & resume later
- you can webform-enable for any content type
- basic Views module support (a good start, not fantastic/fully implemented yet)
- much better data integrity - info is stored in the db more efficiently & makes it usable by Views
- Form Builder Integration* (http://drupal.org/project/form_builder) - which will blow your mind! ;)

Holy APIs!
- module-provided components - additional fields (E.g., a grid field full of text fields in web form, similar to cck)
- more hooks (for save/insert/update/delete submission)
- hooks for pre-built select lists (heading toward Views integration for select lists)
- renderables used in forms, e-mails, and viewing submissions, even in D6

Webform 3 v. 2
- shorter node form - just title, body, all settings elsewhere - 1st save node, only then there will be a webform tab on top of node - then you can click on the Webform tab to do settings like email
-- save node 1st! then make web form in Webform 3
-- in webform tab, there’s a form components tab, an emails tab, a form settings tab
-- can send out templated email response / confirmation upon submission of webform - tokenized

Excellent tools for getting data out of Webform 3 - including basic analysis capabilities built in
- Basic analysis tools built in

- Table view of form submission data

- Downloadable form submission data
This is AWESOME! Bye bye Survey Monkey!!!

Date module & jquery ui on your D6

You can use date popup calendar ui in form

showed Webform 3 off in Drupal7 environment - still has popup calendar, doesn’t need Date module and jquery ui native to D7

Can skip page if none of the components show up in a given page - conditional logic coolness

Payment systems - combo of Pay module & Webform 3 module
can map fields to payment component - payment gateway
(of course with all cautions about implementing using HTTPS)


Form Builder
system to make it really easy for users to build and construct forms
creates kind of a wysiwyg looking interface for building webforms
drag and drop fields, then add the fields’ attributes
ability to add check boxes - by adding the Options Element module - ability to easily define lists of things

webform has basic token capabilities, so can take advantage of logged in username info, for example - e.g., %username - can do this with any core profile fields the user has...
you can hook into the webform_components from other modules webform_webform_components

how to handle form spam - CAPTCHA or Mollom modules - make sure you’re using latest versions of webform and mollom - Mollom now allows you to natively add Mollom protection to any form
NEVER expose a webform to the public if without this type of form spam protection

other cool things you can potentially do / combine with Webform:
- check out Webform integrations listed on project page
- mime mail module - to send html emails to users (so they look like my website/can embed images, for example)

can you populate select list from db table?
- can load prebuilt select list coming from some php - only way to handle this currently is to create a module that hooks into webform webform_options - but pretty simple-looking to do

is webform3 generating html5-compatible code for things like email? not currently
Elements module makes sure you have html5-compatible elements

is the arrange fields module compatible with form builder? two different interfaces, so prob should work together, but doesn’t know, hasn’t tried it

Exhausted - Day 1 of DrupalCon Chicago

So I’m totally toasted. Today was the first full day of DrupalCon Chicago, beginning with Dries Buytaert’s (the creator of Drupal) keynote, explaining his vision, doing a recap of what went wrong and what went right in the creation of Drupal 7 which went into full production in January (he said that Drupal 8 development begins today and set out some goals for this project in the address also). Dries reminded those who’ve been on this journey for any part of the last decade what they should be proud of the work that they've done and he welcomed those of us who are newer to the journey, and - throughout his address - he reaffirmed our choice to be involved with a project that’s not just a technological platform, but a community!

Approximately 3,000 attendees are here for DrupalCon Chicago. There are other, even more impressive numbers that were given in the keynote highlighting Drupal’s exponentially expanding influence on the web today. It looks like over a million sites - almost 2% of the entire web are now Drupal-based. The largest enterprises and governments down to the most humble not-for-profit or individual websites are built on Drupal, a testament to its flexibility and scalability. And not only has Drupal grown so much, but that growth appears to be ever-accelerating. In fact, that may be the one danger, per Dries, that the Drupal community has to grapple with most in the coming years - the growth of the community.

http://goingtodrupalcon.wordpress.com/2011/03/08/drupal-opening-keynote/. Also, a video of Dries’ keynote appears at http://chicago2011.drupal.org/live

It’s Dries' message of empowerment that so appeals to me. I want to similarly empower my colleagues. I’m trying to migrate us to a Drupal system that will allow them - brilliant as they are in their areas of subject matter expertise - to really shine. I’m building a stage, a backdrop, a sound system, and lighting. It should be a showcase for them, not a distraction. But at the same time, I know that my process hasn’t been as open and communicative as it needs to be. I need to be sitting down with my colleagues weekly to discuss the project, get input, and make sure that what I’m building is what will work for them and the people that they will be building the content for - I want to provide them with scaffolding that supports the construction of a better user experience.

In today’s library BOF (Birds of a Feather) session, I was impressed with the quality and breadth of some of the development happening in the library world. In many cases, professional developers are being hired and in some cases libraries seem to actually be fleshing out digital experience departments (including graphic designers, developers, information architects, and multimedia producers). We're so far beyond the concept of a "webmaster" in this day and age that teams are definitely a must for libraries that want to have true "digital branches". (Sadly, even at MPOW, which has more advantages and staff than the average small public library in our state, they have only one person whose time is dedicated to web work,... and I never started out as a web developer, either, so it's not like MPOW can claim to have even 1 true "developer".)

But hearing about the work happening at these other libraries gives me hope.
All libraries should be at least as far along as the people in that DrupalCon Library BOF were. Seriously. We need to identify, and - more importantly - to FIX the problems that we have with our library systems. Stop dividing up the systems - online, to the user, all of the aspects of the librarys’ digital presence are seen as “the library’s website”. That’s how we have to treat them.

If we need further help to achieve this - in the form of consultants, Drupal firms, what-have-you, we have to try and get pony up the funds to make it happen.

Just a thought from a very tired person in Chicago, whose feels extraordinarily grateful to be in on this whole Drupal thing!

Notes From "Designing for Content-Rich Websites" DrupalCon Chicago preconference

Designing for Content-Rich Websites

Jared Spool, User Interface Engineering

Lots of folks in-house who have large, content-rich sites that have grown organically through time (drupal.org, e.g.) & are hearing from users that things aren’t as easy to find as they should be.

There’s 8 types of pages you can find on a website today. Users behave very specifically on certain types of pages vs. others, but most people don’t realize this:

1. Content
2. Gallery
3. Department
4. Store
5. Home
6. Search page
7. Search results page
8. Categories (search) page.

Finally, will talk about search & role it plays on your site.

The Best Content draws itself to the user - “it must suck” - (by which we mean the content sucks itself to the user)
* designing for “scent” is more successful than designing for navigation (theory was successfully tested that people’s behavior in searching for info is like an animal hunting for food...”scent”)
the more experience you have with a given technology the more successful you are with the technology - so assumed that anyone with a lot of web experience would have an easier time than people who were new to web, UIE tested these more experienced web people, but found that it had nothing to do with amount of experience - only with sites - some sites all people, regardless of experience, were successful; on some sites no one was successful - it had to do with scent
the scent is MOST important - the design is most important (designing for scent)
* every link gives off scent that users follow
“trigger words” were important to allowing user to find what they wanted (user didn’t even mention word “drivers”, but this was a trigger word for them for finding drivers)
* NO EVIDENCE THAT THE 3-CLICK RULE IS RIGHT!!!! In fact, many, many (30 even) clicks are fine, as long as the “scent” is good

Search Engines are scent-less
* users click on them when they don’t see a link with good scent
* they type in the words they wanted in the link
* we call them trigger words
* users are trying to make their own scent
* except they don’t know if the designers have anything that matches the trigger words
Search boxes should be labelled “BYOL” - Bring Your Own Link.
User hopes that search engine will figure out what designers missed
* Poor scent - iceberg problem - people don’t bother to scroll when they are assuming that what’s above the fold is the same as what’s below the fold

Banner ad problem - “banner blindness” - because of so many ads, people don’t even look at that top area of page where ads were so often displayed

When people search, they really search:
* >24K results - with “relevancy” which was terrible because people blocked out “lower relevancy” links

Users know how the scent is working - represented by confidence
We can’t measure “scent” directly - no good way to measure it
- have to wait until we hear someone ask about something (E.g., popcorn example)
- we can’t look at a link & say it has good scent - but we can watch users & see if they’re confident - if they have great confidence in link, shows good scent

Users do “information masking” - learn which parts of page to look at and ignore
Often the things that prevent our design = policies (vs. users’ needs)

Navigation panels are often scentless
- Scent is specific, navigation panels are not
- Amazon forces you into search (author, title search works fine for just those things, but not for many needs, such as, for a specific character’s name (within a book or series, for example) or other aspects, such as is the story scary, not so good)
- the categories, e.g., in Dr. Koop’s site - so vague, hard to choose which one to use - category “resources” completely vague/meaningless & because it was third-party bought glossary, put under “resources” because not their own stuff, but user wouldn’t know that
- (FAQ might be: what’s the deal with ejournals, “research databases”, “library catalog”, “finding aids”, “digital collections”... “what’s where? how do I find it? how do I get it?”
- Fidelity website - “Research”, “Retirement”, “Planning” - meaningless to regular people, but in financial services industry, those terms have standard understood meanings, but it’s jargon for others
- it's jargon if a small group of people have very specific meanings for usage of terminology but terms are used more broadly or differently in the general population (librarians, here’s our “database” problem... well, one of them)

Short links don’t emit scent
- average link success = 42% (so anything above 45% = excellent scent)
- best links are 7-12 words... short links don't emit scent...w/link text & associated text included - most successful links are 7-12 words in length
- trigger word not in shorter links (it’s a probability game, fewer words in link, less likely to see trigger word in it) (let’s not even talk about the “click here” link wording which is utterly meaningless -- poor usability and accessibility)
- but too many words in link text = trigger word buried
Other issues with scent
- too many similar links in Kraft Foods site navigation example, so didn’t know which to choose “recipe search” v. “recipe connection”
- CNN site - is a story “U.S.” vs. “World”? but at least putting links underneath each category - provides example / trigger words in those links, so it wasn’t the broad category, it was the examples that made the navigation work in those cases
- put links under categories to strengthen scent = good technique, works well
- interesting example of very old Pfizer site - tons of links to “financial” and to “FunZone”, hard to tell what site’s really for - not what you expect - there was a great subsite, called “Dealing with Depression”, but no easy links from Pfizer main site to get to the “Dealing with Depression” - originally, there was a link from that home page, but it was only on that page for two weeks - every two weeks, had to change homepage - corporate site policy must keep home page “links fresh” because we know most people must go to Pfizer site daily and might get bored if they don’t...

Short pages reduce scent
- users have no trouble scrolling! long pages are not necessarily a problem
- the problem with users not scrolling only relates to the design of the page - if it looks like it stops at a certain point, they won’t continue scrolling. For example:
- large margins at bottom of page = stop scrolling
- if horizontal line = stop scrolling
- you need one long column v. others, means people will keep scrolling, but if it looks like they all end at the same point, won’t scroll past that point
- copyright statement = stop scrolling

if scent gets more general, instead of more specific, user gets lost - so links should be specific, example of old etrade site link where it implied that the link would take the user directly to information about their qualifications for program, but it just took them from more specific promo page to the etrade home page, - this led to user frustration

The site map is what people click on when they’ve given up hope. “Site Map” has no scent.

Scent depends on context
* example, misinterpreted context - from Boston.com’s “The Boston Red Sox” page, link to “Sports Calendars” didn’t bring them to calendar with Red Sox games, but rather to calendars for other things.
Users don’t think in terms of sections!!! Designers think in terms of sections (re: who’s in charge of building sections)

Traditional approach to website design has been to think of home page first, then link out to individual pages, but that’s only the way you design for navigation, which is low on scent.
Instead, to design for scent, start with a target content page.
- figure out from where users will likely want to get to that page
- put links in all the places people would most likely want to find your content

DON’T START DESIGNING YOUR WEBSITE WITH HOME PAGE - IT’S THE LEAST IMPORTANT PAGE ON YOUR SITE! THE MOST IMPORTANT PAGE IS THE ONE THAT HAS THE THING THE USER’S LOOKING FOR! START DESIGNING FROM SPECIFIC CONTENT!!!

Min = 2 hours every week that you should be watching people use your design. Interview users for most important content.

Good Design = Users Have High Confidence
- every design element that makes scent stronger contributors to the user’s confidence
-- before they click, these things make them feel confident:
--- link quality, navigational graphics, information organization
-- after they click, they will have confidence if they are:
--- seeing desired info
--- or more, stronger scent

Summary:
Your Content Must Suck
- your content must give off scent
- scent is about pulling the user to the content
To make Your Content “Suck”, you need to know:
-- why users are coming to the site
-- what their trigger words are
-- where are they likely to look
- avoid search as answer
- keep links and pages long
- you can’t design great sites without testing
- spend time with users
* users need strong scent to find their content
* as users work their way through the site, they encounter different types of pages
-- each type helps them in a different way
* key user behaviors predict navigation failure
-- designers can use these behaviors to learn how to improve the site

Going Over the Different Types of Pages (and associated patterns of user behavior):

1. “Target Content” Pages
Users Seek Content
* the target content page is the most important page on the site - nothing else matters to that user at that time but that content
* all other pages are dedicated to delivering the user to the target
(v. old myth of “surfing” a site - which was just that, a myth - they don’t care about the rest of your site)
* navigation pushes users
* scent pulls users
There’s always a task.
There’s always a page that fulfills that task - it’s what we call “the target content page”
Has the info the user’s looking for. Most important page on website, dictates failure or success of user.
Getting user from home page to content page = scent issue

2. “Gallery” Pages
List of links to content pages - enough scent has to come through those links to get us to the correct gallery page.
Ecommerce sites are simple. Users want to buy something, website builders want to sell something - they both meet their goals at the same instance. So used as the “laboratory rat” of testing how to design things.
That’s why we call them “gallery pages” - because of ecommerce - display of all of the shirts, for example, at clothing store site.
But there are non-ecommerce, content-rich sites. Still, they have gallery pages.
Content Galleries
* behave same as ecommerce galleries
* content pulls users towards it

Predictors of failures of scent:
1. Forcing the Back Button (designers said, you have to go back if you’re seeing this page) - a sign of failure = back button usage
when they used back button, only succeeded 18% of time (v. 42% w/o use of back button), if user had to use the back button 2 x, their success rate drops down to 2%
The back button is the button of doom!!!
2. Pogosticking - when user bounces between levels of the info hierarchy
* pogosticking PREVENTS success - when you do that only succeed 11% of time (vs. 55% of the time w/o “pogosticking”)
3. Search
* search also prevents success - if search is used, they are only successful 30% of the time (vs. w/o using search, which = success 53% of time)
So...
a successful gallery page doesn’t force the user to use back button, to pogostick, or to search

when users tell you something is “cluttered”, it’s code for - you’ve got a lot of stuff, but none of it’s what I’m looking for...
been in many projects where adding info reduced users’ perception of clutter.

Link order is important
* random order & alphabetical order are essentially the same from the users’ perspective on almost all things:
only in specific names (e.g., of cars, states, people), is alphabetical order sensible

The length of a gallery page doesn’t matter!
Longer pages work better
(See all on one page in Lands’ End allowed more sales of items that would’ve been in the 4th, 5th, 6th pages when they didn’t have the “see all” option)
Get into trouble when there’s too many concepts/”ideas” in a gallery... it’s not that there’s too many items, it’s just that it’s hard to figure out which type of item I want

3. Department pages
Departments divide things up - reduce set of choices
have to clearly know what you want and also which categories you definitely don’t want
often put departments into navigation - but now, if have like “account management” and “bill and payment informaton”, which one of these links do you use?
Global navigation turns out to be really useless for people - we’ve trained users that global navigation is useless
People think in terms of local navigation
Very few people do second things on a website. They get the task done & leave the page.

division by audience issue - cancer site - the public read the doctors’ side & the doctors’ read the general publics’ side.
should’ve been clearer about what was meant - not “for patients” vs. “for doctors”, instead should’ve said “written in plain-language” vs. “written in doctor-speak” (or something like that) - that was the real difference between the links

For Department pages to be successful
- reduce the number of choices in galleries
-- to allow galleries to provide more detail per item
- gallery links are descriptive
-- trigger words are present
- categories need to be logical
-- users need to quickly eliminate uninteresting categories
-- users don’t mind if there’s 20 ways to get to the page they want, as long as it’s the target content that they want

Links Must be Meaningful
- marketing terminology/jargon can block scent
- context helps a lot
- also use of specific links as an example of the category

4. Store pages (400,000 pages or more - VERY LARGE websites)
- completely eliminate some aspect of site from users (like MEGA-departments)
- it’s ok to include the path to “men’s” OR the path to “shoes” to get to men’s shoes
- stores must be familiar (JCPenney, Petsmart, CNN) - and competitors all use very same words/terminology

5. Home page (is special)
- the landing page of the site
-- whether type in url or get there from Google search
- aggregates either stores or departments
- home page may simply be a gallery page, or department page
- 1 purpose & 1 purpose only, to get users to the content they want - best of all, to have that target content on the home page itself
-- primarily the category page
-- divide real estate accordingly
- home page is the LEAST important page on your website
- home page plays the smallest role

no language to describe design for everyone, terminology “information scent” is best terminology we have come up with

[Note to self: try out Instapaper - takes large sections off website & view offline / on cell phone]

Faceted search isn’t really search - categories create scent - if it works, has great scent...
Search is actually the only way to deal with the long tail of least used content
But the content used by the majority of users is where you design architecture for
Getty images doesn’t consider every picture to be equal
There is such thing as most important content - it’s contextual though, e.g., with Getty images, by season, by current events issue

User study:
Pauline - senior citizen, fell, hurt hip, recovering - needs meals delivered. Niece living in another city trying to go online to find help
Went to New York City municipal website to find out about meal delivery, but nothing to help (16 links, but none helpful) - link labelled “Online services” then “All”, then “page 6” - at very bottom of very long page - “Senior Programs Locator” (would get her 1/2way there).
Department of Aging
search results “in wonderful alphabetical order, exactly the order she needs...”
why did they build out a database like that - “to reduce number of calls” but didn’t really work out, since the records in the database didn’t answer important questions & just dead-ended the user - so they would have to call to get what they needed. Waste of resources to put a database like that online.

- search engine logs - keywords - is a list of links you should have on your website

- division of screen real estate on a page should reflect the most important / heavily sought content

on avg site home page, users:
go to search 6.8% of the time
use category links 86.8% of the time,
“featured content” links 1.3% of the time
home page link on home page 2.6% of the time
so why give so much space to “featured content” (e.g,. “hero boxes” - the giant slideshow boxes displaying what marketing/company wants to show off) vs. category links?
instead, should give 86.8% of space to category links...

Galleries: The Hardest Working Pages on Your Site
demo of cell phones gallery pages - which info is shown there
- which design works best?
Lesson #1: Provide meat - information to help people decide whether or not to pursue link further
scent of information - content ages emit scent through links
users scan pages for trigger words
Lesson #2: What makes each link different?
How will someone tell the difference between each link - this is especially a problem with fully automated gallery generation pages
don’t confuse the value of the content with the presentation of the content
Lesson #3: Support Selection
3 stages for decision making:
1. winnowing - reduce candidates to a smaller set (dept. page level)
2. selecting - (gallery level)
3. validating - (content page level)
Gallery pages are for selecting, so make pages clear
Lesson #4: Will Users Understand Individual Elements?
Lesson #5: Provide Necessary Distinguishers
Lesson #6: What do the users already know? (keep in mind that you live & breathe this content every day, so what seems like normal language to you may be jargon)
Lesson #7: Provide for Individual Needs
- e.g., sorting capabilities by various features
- gallery doesn’t have to be a list, could be presented on a map, if information is most usefully presented that way
Lesson #8: Take Advantage of Available Real Estate
Visual Design & Copy
Lesson #9: Take Advantage of Progressive Disclosure
- take advantage of available real estate
-- progressive disclosure can help for dense information
Lesson #10: Think Beyond the List-O-Links Approach
- tables are not a requirement
-- can use embedded links in paragraphs when appropriate
- good copy is essential
- design for the user’s objective
- good to show what an item does NOT have
- we want to think that we can just create the shell and hand off the content to someone else to populate it
- good design is often a team activity. You need to be able to sit in the same room and have a conversation (content folks & website admins)
Lesson #11: Will People Understand Your Terminology?
Lesson #12: Avoid Meaningless Noise Words
Lesson #13: Good Copy is Essential
Lesson #14: Design for the Specific Use
Lesson #15: Take advantage of associated text
- turn a gallery page into a content page by adding more info into the gallery page - e.g., staff directories - make users happy
- supportive info about the listing that you’ll be linking to
- NY Times has editors create summary statements, instead of computer-generated associated text - makes for better listing
Lesson #16: Humans Trump Programs
Lesson #17: Realize the Impact of Changes
Lesson #18: Order links from most likely to least likely to be wanted/related
Lesson #19: Group related links together
Lesson #20: Avoid chronological order (again, in most pages)
Lesson #21: Know when alphabetical order makes sense (usually only for specific names)

Designing Galleries for Selecting:
- ensure you understand what’s important to the users
- how will you differentiate one link from another
- how will you prevent pogosticking?
- take advantage of good copy, thoughful ordering, and matching the design to the user’s objective
Lateral Links on Content Pages:
- like “customers who bought this item also bought” on Amazon
Lesson #22: Lateral Links allow users to continue the adventure
- choice is value-added - you can get similar item with fewer or more features - give users more choices
Lesson #23: sometimes 1 choice is all you need
Lesson #24: “more” “previous” and “next” are noise
next & back or previous & next aren’t very strong info-scented, doesn’t give you a great idea of what you might get
Lesson #25: look for opportunities to provide more scent
a “curated section” - overview pages with lateral links
Lesson #26: Find Ways to Eliminate Poor Candidates
Lesson #27: Faceted Winnowing Eliminates “No Results”
Lesson #28: Look at Interactive Controls for Filtering
letting people dynamically filter (with sliders for example)
Lesson #29: A Good Demo Doesn’t Imply Usable
but you’ve got to test with users & see if it actually works with them
Don’t let Flashy Overtake Useful
Lesson #30: Don’t Forget the Basics: Selection is Key
Good Design is Delightful and Useful
It’s only a “target content” page if they find what they’re looking for... if they’re moving through multiple pages, that “content page” is really a “gallery page”

every so often, take last 4 weeks of content & do a group sort
how would NY Times have done it & talk through it?
everybody gets to play the game...
interesting discussions
another fun game - if we wanted to make this really suck what would we do?
we don’t yet have a language about what makes “good design” vs. “bad design”, so need to have these conversations
to create a language of design amongst team members
the notion of critique is missing in a lot of shops - you should do critiques like they do in art school...
2 pieces to critique:
1. sense of where you’re trying to go - what do you want page to do? what’s the call to action?
2. what did you do to do that?

Search, Scent and the happiness of pursuit
this AM, talked about how search fails users frequently
we don’t realize how bad it is because we use Amazon

Browsers vs. Searchers
we expected “natural searchers” would automatically use search across all sites - studied this. There were natural browsers, but no natural searchers across all sites. The site’s design forces users to Search.
aha moment = this is why library users were so unhappy with library catalogs.
We fronted all catalogs with web pages to talk about various books, collections, etc. or else we didn’t. And no one wanted to use straight search with no context.

Getting from Home to Content
6.8% of people prefer to use search off top to get from home page to content pages - it’s just a design phenomenon
but worse, only 7.5% of searches occur from home page
23% of search = from search results page
so people only use search when they get lost

Users search from the page where they lose the scent - already in problem recovery mode
people actually search completely different ON a site than they do AT Google - because AT the site, they expect level of specificity and context that they don’t get at Google level

Items easy to find with search:
- books by Tom Clancy
- a Canon SD1100
Items HARD to find with search:
- the 1st Tom Clancy book featuring Jack Ryan
- an inexpensive, but high quality SLR camera
success of search depends on what they’re searching for

users don’t want to search, but not all content searches equally well
User Expectations of Home Link placement (study from Wichita University) - most people expected home links at top left-hand corner (& bottom left, to much lesser degree)
expected search box somewhere in top right-hand side
none of these positions make it harder to use the search box - if it looks like a search box, they search in it (not about where it’s placed, but what the box looks like)

Type of Results
- match relevant type = has the user’s target cotnent = best
- relevant = strong scent to user’s target content = good
- irrelevant (Wacko) - unrelated to the user’s target content
-- relevance is perceived by the user
-- completely unrelated from the user’s perception
- no results - target content does not exist on the site (but it really does)
-- mistakenly given when search can’t find target content
-- faceting prevents the “no results” search outcome - hence its utility

Great search results
- avoid pogosticking
-- it’s not about choices, it’s about the right content
- make sure match relevant results are at top
- eliminate wacko results
- make sure no results are handled carefully
-- e.g., what price of Wii would be & descriptor, but immediate indicator that it’s out of stock, so they don’t get misled

Tested search engines (77) & created an agility course for them
- test searches that should be findable - copied & pasted text directly from record of inventory record into search engine & it worked for specific model of Palm
- “implementation services” phrase searched on, ok
- intentionally mistyped things - “19 LCD Montinors”, ok
- this site did great on agility course
- but new search engine - so retested, but it tested worse - the misspelling & the implementation services tests & even the model of Palm all came back badly
- they had broken search by improving it
- we don’t have good metrics on search engine performance
- so putting together benchmark tests for search engines
- officemax.com did best in their agility course
- was able to handle “shipping tape”
- worst site performance = “your search did not produce results”, try “redoing your search with other search terms”
Build your own search obstacle course
- research the commonly used search terms
-- look for variants, such as synonyms, misspellings, or types
- go to target pages on the site & pick out trigger words
-- look at the heading and important descriptive phrases

Search problems to look for
- is search returning too many results without categorization or facets
- are the top links not match relevant
- are there duplicate links? (ppl will stop if they see duplicate terms)
- do users need to click to determine the relevancy of the result
- are categories weighted equally?
-- even though there’s an obvious first choice?

Correctable Input Errors vs. Search Indexing Errors
- 43% = search indexing
- 57% = correctable input (user input)
- spelling errors
- typos
- plurals
- parsing errors (tshirt (no hyphen), 19” LCD monitors (extra quote))
- multiple words: winter slippers, maternaty clothes
YOU MUST REGULARLY LOOK THROUGH YOUR SEARCH LOGS
(the reality of the situation = we can find the problems, but we librarians can rarely resolve them because we aren’t programmers & our vendors are not responsive)
Jared Spool talks about the Endeca search engine at Eddie Bauer site. Calls someone high up at Endeca & he fixes it while Jared is on hold. A missing ; was the difference between relevant and irrelevant search results.
Each technology that was at top of list, it was also at the bottom of the list...
it was the installation and implementation of the technology!!!!!!
Google search appliance sux on the intranet, because no 1 links back to the travel expense report, so doesn’t rank highly
- site design has more effect on the user’s success than user skill
- users always scan the page for trigger words before they search
- the site’s design forces the user to search
- users search from the page where they lose the scent
- not all content searches well (most doesn’t)
- users find a search box by its visual presentation
- focus on match relevant resutls
- implementation trumps vendor choice

Breadcrumbs
“they suck”
3 types of breadcrumbs =
1. path breadcrumbs - user actually clicked to get where they’re going
2. location breadcrumbs - best path / actual hierarchy in site, best way to get there
3. facet breadcrumbs - can click on any of them and get any combo
most users think breadcrumbs = path breadcrumbs - so confusing,
but mostly users don’t pay attention to breadcrumbs
because if they got to target content, they won’t look at it.
it’s a last ditch effort like the back button, without requiring them to hit back button
it’s an attempt to treat the symptom, rather than the problem
they can never use breadcrumbs to get unlost
they don’t care about the structure of your site
the problem = when people are spending a lot of time on breadcrumbs = a waste of resources

winnowing v. selecting
what you definitely don’t want v. picking what you do want

Supporting Winnowing
- winnowing supports reducing choices in galleries
- we’re seeing new interaction techniques to support winnowing - eliminating lousy candidates

Random notes in answer to audience questions:
users tend to move their mouse only AFTER they’ve decided that they want to go somewhere else (this is the problem with drop-down menus, they require users to move their mouse to decide where to go)
what about the giant footer - most people never use it - is just used for SEO
big pictures of the administrator are terrible on government sites (no good for the user)
“subject areas” is a too-generic term (on bureau of labor statistics)
“hero box” that huge slideshow you see on the home page - not usually helpful to users