Our baby!!

Academic reserves via ReservesDirect (as implemented at NCSU libraries)

-opensource

-functional requirements list: global, administrative, user, course, item, statistics

-contenders: Equella (not suited), Docutek e-res (no trail of versions over the semesters), Ares (good tools for the staff but not enough for faculty), ReservesDirect

-works through authentication (login); enrollment based for students (pull datafeed from registrar’s office); for profs, can only see own classes, not edit anyone else’s—can add their own documents and URLs; searchable, so faculty can see what is on reserve for other classes

-admin side: the’ve added ability to add a video; can see who has used a particular article over time; way to make links non-breakable as they move across platforms

-needing to educate faculty about metadata so the search function wrks better (or cean it up for them)

-good, useful canned stats with limiters for admin; faculty also get a report as to which items have been opened, how many times, and by how many students (but not which ones)

-pilot test summer 2008 w/ 4 faculty and 1 instructional designer; bug reports led to fixes (if had to do over, wouldn’t use faculty, just more instructional designers, since the one was the only peson who really gave useful feedback)

-full release fall 2008; lots of positive feedback from faculty

-migration: datamap, 17 gigs of data, broken links (all of them!), confused document icons, wayward data, safety net

-ran some instrution session for faculty, but they don’t take them—only the instructional design people. Made office calls in order to do one-on-one training. Also has a video tutorial.

-www.reservesdirect.org/wiki

How to be the Bad Guy Without Being Bad (now with LOLcats!)

-You have to have the right group of people with the right attitude in order to have everything work right; any other group of people makes for an entirely different group of people.

-She’s had 52% turnover in 3 yrs but now has the right mix of people.

-Poor performance eats at an organization, rendering it unproductive, slow-moving

-Basic responsibility: productive and well-disciplined individual (then they’re happy)

-3 types of issues: performance issues; attendance; beahviour/conduct

-punishment failures: uncertainty, inconsistency (favouritism), long-term disaster (looses power); breeds apathy

-performance improvement discussion: know your org’s process; serious and planned; specific goals; structured (one goal: have the person agree to change the behavior)

-prepping for discussion: identify the specific difference between the actual and desired performance (the person has to take responsibility, and that won’t happen without specifics—too easy for them to rationalize); anaylyze the impact of the problem (why to solve); identify consequences (“further disciplinaty action” isn’t enough—be specific); determine appropriate action plan

-actual vs. desired performance: type of problem (if there are multiple, limit to highest priority); be specific and limit to facts

-first conversation is about the behavior and opportunity to change; second is about failure to change (consequences)

-disciplinary: change in workflow, physical location, or whatever might be incentive

-5 questions: Did employee understand the policy that was violated? Did the employee know in advance that such behavior would be subject to disciplinary action? Was the rule violated reasonably related to the safe, efficient, and orderly operation of business? Is there substantial evidence that the employee actually did violate the rule? Is the action planned reasonable related to the seriousness of the offence, the employee’s record of service, and the action taken with other employees who have committed similar offenses?

-Conducting the discussion: Somewhere private; as soon as possible; give enough time for discussion (but don’t want it to be endless, either); Go straight to point—no sense dragging it out since they’re already freaking out or worried; let them talk about it from their POV and be an active listener; gain agreement; end on positive expectation of change (and follow up in writing)

-2 causes of performance probs: 1) lack of knowledge (training issue) and 2) lack of execution (clarify expectations)

-execution problems: clarify expectations; remove obstacles; provide feedbac; arrange appropriate consequences

-attendance problems: cause is irrelevant; only the effect counts. Individual responsibility—coming to work is a condition of employment, as is coming to work on time. Address as you would a performance issue: logical consequences; gain agreement; personal choice; further action.

-attitude probs: (other than psychotherapy, religious conversion, and brain surgery) Handle it same as others. Just don’t *tell* them they have a bad attitude! They’ve heard it before. Just get the expected behavior in writing.

-Discussion difficulties: “yeah but,” “I’ll try,” silence, irrelevancy. You’re going for a concrete answer. Keep the conversation on track.

-Dismissal (aka “No Fault Divorce”) Sometimes the best thing you can do is fire someone. It isn’t a judgement on them as a person—it just means that the fit is bad. Dismissal should not be a surprise to anyone involved. Lots of meetings, feedback, and written documentation. There is no other choice.

-Have a plan. Pre-meeting; meeting; post-meeting. Know org’s requirements.

-Run it by a jury first if you feel at all uncertain. Was employee aware? How do you know that they knew? Do you have documentation? Were they given time to improve? Was training provided?

-Write a script. Short and to point. Listen to response. Repeat as necessary. Anticipate questions and concerns.

-Avoid misdirected compassion. No one enjoys doing this. Don’t let that stop you from carrying out the process. Their actions have had an impact on your org. The time and effort is only worth it if the behaviour is fixed or they leave.

Q&A

-how do you deal w/ unions? Doesn’t have to do so now, but in past union was very supportive as long as there was cause.

-Before the divorce, do you consider moving them elsewhere within the org? Yes. Sometimes it works, but sometimes there are other issues. Act in good faith.

Usability Testing for websites and other applications

-focusing on tutorials and user guides

-started out as making sure web sites cohered to design standards, but has gradually morphed to include how users intact with the site—really have to think about how to include testing in implementation process

-ISO def’n: extent to which a product can be used by specified users…

-don’t forget the consent form! might have to talk w/ IRB, too

-Card sorting: use, perception, demand; have participants sort cards w/ headings, then have them come up w/ own headings, then interview (from soc and psych); can lead to navigation redesign; time consuming to test and analyze results (can take pictures of the cards post-sort to help)

-heuristic: best practice (Jakob Nielsen); need outside experts; evaluate for specific criteria (ie, match beween system and real world [library jargon]); fix now/soon/someday; hard to find experts (and $$); high learning curve; can be hard on the site designer due to negative focus

-Assessment testing: users complete tasks; objective or goal-oriented; review for duplication; arrange from easiest to hardest; best method for feedback on functionality and navigation; can be formal or informal; remember to debrief the participant

-choose right method: demographics of users, purpose of testing; need lots of user groups represented; use incentives to recruit (also, neutral location and timing) [do lib staff and librarians separately, since they use the site differently and staff might be more willing to be open w/out libs in the room—can be good to have outside moderators for some groups]

-testing 2.0 apps: Focus! assessment tests work best for this. specific audience; greater depth of test; user population may have no prior experience with the application, so have to account for that in the questions

-content testing: focus on info; tasks based on learning objectives; interfae independent

-software testing: focus on navigation; tasks based on finding info; interface dependent

-Be sure to be focusing on Content, not software (unless you’re doing OA, you can’t do anything about the software)

-pretest: use to refine questions; small sample user group; screen captures can really help; repeat until results are consistent; methods: interviews after, screen capture, filming

-designing test questions: be specific and task-oriented; pretest for validity and clarity; broad or narrow scope—keep to middle ground; longer is not better—don’t want to tire people out or have them get bored (on side of paper seems to be good; it looks do-able)

-samples:

-find book: Does the lib. own a copy of ____?

-access a db: Does the lib. have access to _________?

-find lib. hours: What time does the lib close on _____?

-find contact info: Where is liaison’s office?

-Use back button: How do you get to previous material?

-Nielsen says doing 5 should be plenty—diminishing returns after that. But they aren’t so sure.

-implications: highlights user interaction relative to design; focus on important content; indicates higher maintenance items; underscores tast complexity; potential redesign

-figured out that students were having different interactions w/ the info depending on the librarian who had created the libguide, so they’re going to write some standards for the guides based on their findings.

Q&A

-What type of 2.0? Tutorials and guides are the only ones they’ve done testing for.

-signifiant diff in user groups? Yes! Esp. btwn patrons and librarians, w/ libs not understanding what patrons want (user testing can debunk lib myths about what students want)

-institutional standards in the website redesign? yes. colors, header, and a few other things dictated by the school (Wartburg College) so they had to work around, but their head guy was ok with a little switcheroos

-how much time? card sorting: one afternoon (used magnetic board and handed out candy bars while at the ref desk);  assessment takes much longer, esp. w/ pretesting, plus fact that application are often new to the user (and sometimes the lib!)