Archive for August, 2009
One of the things about being the only IA/UX/ID type in the building is I tend to work on a lot more things at once than I did at the BBC. As well as the e-commerce project and trying to get the new website live, I’m also working on (to varying extents)
- shared drive folder structure
- replacing various ‘company’ directories
- investigating care management systems
- a new library system
- thinking about the next phase of intranet/teamsite development
- supposedly a reference data management strategy, although I keep having to postpone this
So good friends in the UX community have expressed concerns about some of my slightly less than impressed references to “user experience”. There was the whole penguin thing. And the using your clients language one. And the getting a bit snippy in an innocuous post about content management resources. It is, admittedly, a bit of a bee in my bonnet (and no, I don’t own any bees before any of you ask).
But I can’t say “I’m an user experience designer”. In much the same way that I couldn’t say “I’m a neo-conceptual artist” with a straight face. I wasn’t raised that way.
I’m a bit embarassed to say “I’m an information architect”. And as I said before I tend to avoid that at work.
(I’ve got a biological taxonomy metaphor I can use here but the whole Lakoff’s penguin thing went down so well…I think I better save that for the pub)
It would be a bit like me telling you my husband is a “craftsman”. It is completely accurate. It has grandeur and a philosophical sweep. It gives his career a wide scope and avoids him being boxed in by his job title. But it doesn’t help anyone of you realise that he could make you a rather nice spoon, a lovely rustic fence or even some really good charcoal. And that he might not be the best person to ask for an earthenware pot or an Aran sweater.
What’s the IA equivalent of “makes beautiful, useful things with wood”?
In the old days job titles were created by grabbing a bit of Latin/Greek and adding ‘er’ or ‘or’ to it. The suffix just means “one who does”.
Something of the bits of Latin /Greek are obvious, some not:
Carpenter=wagons, Cooper=vats, Plumber=lead, Lawyer=law, Miner=digging, Baker=roasting, Butcher=slaughtering goats, Doctor=teaching, Teacher=also teaching, Farmer=collecting tax/rent, Soldier=being paid, Tinker=jingles, Tailor=cuts, Dyer= dark/secrets
Vicar interestingly just means substitute or deputy.
And who slaughtered anything that wasn’t a goat? (I’m putting the etymological dictionary away now).
It seems for a modern job title that a single word is not enough. You need a combination of object and activity.
Possible objects in my professional sphere:
Some people seem to feel hemmed in by the activities bit and choose something vaguer. This usually implies they will only produce opinions not things e.g.
In the public and non-profit sector you also get ‘officer’ as in police officer but also projects officer or knowledge officer. This usually just means one who holds an office and seems to be a way of avoiding saying ‘man’. “Head of” is similar but usually at the opposite end of the hierarchy.
All combinations of object and activity are plausible and many are common. Although so far I only know one Usability and experience design oompa-loompa.
Working for a charity is rather different from any of my previous jobs. In spite of having mostly worked for the Queen my current job is the first one that is funded by people voluntarily handing over their cash because they wanted us to help someone else who is in need.
That has a subtle impact on your attitude to spending the organisation’s money. I’ve become more interested in alternatives to conferences, historically one of my more extravagant uses of my employers cash. And on projects it makes me far more focused on value for money…which also helps with maintaining a “more is less” attitude to interface design.
I’m also conscious that I’m a big expenditure for the organisation, so I’m getting better at saying “I’m paid to make this decision, so you really need to take advantage of my expertise here”.
Being the IA in an organisation that is fundamentally and very practically committed to accessibility is for the most part an IA dream.
Imagine it. A top-down drive towards machine readable content. An emphasis on the content rather than the style. A management team that understands that whizzy and award-winning is no b****y use if your users can’t use it (unless you count getting management their next job as a use).
But occasionally IA and accessibility, if not conflict, at least exchange a couple of slightly sniffy words.
Let’s take machine readable for a start. Which machine is doing the reading? And what language does it speak? Google and Jaws at the very least speak different dialects. I’ve been struggling for while to get to the bottom of the punctuation in URLs issue. SEO suggests a slight preferences for hyphens in URLs, screenreaders (well JAWs) seem to work better with CamelCase than with either hyphens or underscores (if the screenreader is set to read out the punctuation then imagine listening to all those underscores). It isn’t clear cut with either technology.
(as an aside, I was impressed to discover that JAWs seems to get Latin and had no trouble trotting through the Lorum Ipsum in lots of my documents)
In an effort to get a local navigation that shows the user where they are on the site, regardless of whether they are using a screenreader, we’ve ended up with a rather unfamiliar pattern of navigation on our new site. And as a general rule I don’t like novel patterns for common stuff like navigation. No-one wants to think about navigating.
But mostly my IA instincts and the needs of screenreader users are happily in tune, or at the very least don’t interfer with each other (courtesy of the magic of CSS).
Where it really gets interesting is when you consider screen magnification users. Screen magnification users are using the same interface as everyone else, just a whole lot bigger. I actually find screen mag much harder to use than a screenreader. I can mostly touch type and I tend to use the keyboard rather than the mouse so I don’t find a screenreader too much of a leap (when the site is accessible, of course!). But a significantly magnified screen is just baffling. It is the world as you knew it but nothing quite works the same. And moving around the screen just makes me feel a bit sick.
So some design constraints are: You can only see a very small amount of the screen at any one time. You don’t know where the next bit of information is, unless part of it is already on screen. And you don’t want to have to go back and forth on the page.
In many ways this helps the IA. It reinforces the need to follow accepted patterns. If the mag user is expecting the search box to be top left then don’t stick it in the middle of the left column or they’ll never find it.
Magnification creates a slight preference for linear, left aligned layout. You have to be careful with white space, otherwise the mag users is left with nowhere to go. I’m noticing a tendancy for my layouts to end up with empty space towards the right and bottom of the page.
A similar issue that isn’t really about magnification but about designing for low vision comes up when you design for significant font resizing. You can find that you are not making full use of the screen when the font is smaller.
Now none of this can’t be sorted out with some clever information design and a CSS whizz. Except maybe the URL punctuation but I should probably just get over that and worry about something a little more important.
Debora emailed asking for resources about content management from an IA perspective.
I had a rummage around and created a quick list of content management books, presentations, and websites. Plus a short flurry of content strategy links as quite a few of the interesting structured content debates seem to have moved that way (is that a sympton of all IAs being UX designers these days?)
I often refer back to SEOMoz ranking factors article when I think teams are getting hung up on minor SEO issues.
Will from Distilled just ran a free webinar about the SEOMoz tools so it seemed a good opportunity to learn more about what more is available from SEOMoz.
Will says that SEO tools (some free) give you three things:
- Quick research (basic understanding)
- Deep dive research (actionable insights)
- Making things pretty for boss/client (ever important)
The Pro tools aren’t particularly cheap, so it was useful to have someone talk you through what the return on that investment would actually be. In places the data looks a lot like the stuff you get from your web analytics tool e.g. Google Analytics. But remember this is data on your competitors as well as your own site.
Using AutoTrader as an example, Will talked about
- SEOToolbox: Free tools. Will likes and uses Firefox plugins instead of some of these. Still likes and uses Domain Age tool
- Term Target: free, aggregates data on a given page, identifies keyphrases
- Term Extractor tool: free, uses for competitor and keyword research. 3 word phrases might give you something new.
- Geotarget. Get Listed is an alternative.
- Popular searches. Particularly likes the Amazon content.
- Trifecta. Useful aggregator. But has the comparison of your site to the rest of the web as whole (possibly unique data).
- CrawlTest: pro-tool. Xenu is an alternative.
- JuicyLinkfinder: finds linking opportunities
- Keyword Difficulty: how hard a keyword is going to be to rank for, regardless of domain.
- Rank Tracker: Will keen to stress that individual keyword ranking isn’t the important thing. Often your boss will demand it. Makes little graphs and will export to CSV. Can combine with analytics data e.g. using Google Analytics API
- Firefox toolbar Will loves this. Uses it more than any other SEO tool. Pro version better. Shows some pagerank-esque data for page and domain. Going up 1 MozRank point is equivalent to 8x stronger. So decimal points are important.MozTrust is similar but restricted to links from trusted sites. Page Analysis also part of the toolbar? Alternative is Bronco tools.
- Linkscape: the tool SEOMoz are heavily investing in. Web graph of which pages link to each other on the web. Will doesn’t see an alternative to this. Free version does basic stuff. Pro version produces more data and prettier data. Will recommends the Adv Link Intelligence Report. You can get data on who links with “nofollow” which Will thinks is unique data.
- Labs: Online Non-Linear Regression is scary. Visualizing Link Data is more mortal friendly. Link Acquisition Assistant helps you construct queries for search engines to find link opportunities.Other tools include Social Media Monitoring and Blogscape.
(As a side point, Will recommends learning Excel functions MATCH and LOOKUP. And pivot tables.)
Distilled are going to do more conference calls, including one on keyword research tactics. Could be useful. Free webinars are another useful alternative to conferences when budgets are tight but you need to keep learning.
There are lots of tools that help you choose terms to purchase in PPC campaigns and to target for SEO.
They can also be useful in helping you design navigation, choose your site name and even your company name.
Google provides all sorts of resources, some which seem to do very similar things.
There are analytics specifically for your own site:
And some that anyone can use:
Of the ‘public’ tools I mostly use the Adwords Keyword Tool, inspite of not using Adwords.
Try searching for ‘phones’. From the results you can see whether ‘cell phone’, ‘wireless phone’ or ‘mobile phone’ is the dominant language in your area. When there are labels that my team is arguing about, Ill sometimes see if the Keyword Tool can add evidence to the argument.
But beware, they can get addictive.
Recession-Proof Graduate is getting attention mostly for Charlie’s advocacy of working for free but there’s lots of good stuff about how to approach your career. None of it is rocket science but it is the sort of stuff we lose sight of when job hunting.
Some quotes, mostly from the stories contributed by others interesingly enough:
“Postpone getting paid now, for amazing opportunities later”
“I quickly figured out that the most important thing to do in college was to not focus on getting great grades, but to get out of the classroom and start working for people to build a solid portfolio.”
“I learned more from my Google Reader than I ever did in graduate school.”
“There are absolutely no rules to what you can put on your blog.”
“Very few job seekers take the time to actually put themselves in the shoes of the people they want to work for.”
Also a must-read in this domain is Avinash Kaushik on Web Analytics Career Advice: Play In The Real World!. Gold dust if you want a career in analytics but still applicable to everyone else too.
So you’ve tested your site search. You’ve submitted some bugs. You’ve probably got lots of responses to those bugs along the lines of “oh, that’s just a config setting” , “you don’t understand – that’s a feature of how this product works” and “the search is fine, you just need to get the authors to do their metadata properly”.
Now the config statement is fine. So long as changing the configurations actually sorts the problem. Don’t sit back at this point. Either make the recommended changes yourself or insist the supplier does. Don’t close the bug until they’ve proved the point.
Changes you can usually make to the configuration
- change the crawled pages
- change the indexed fields
- default query syntax
- change stop/noise words, stemming and the thesaurus
- ranking parameters
Be very, very careful if you are changing the ranking parameters. If fact, I’d suggest this is a mini-project in it’s own right. You’ll need to be able to make one change at a time and compare the new results with the old, across a large set of queries. You probably want to do this with someone who has experience with the specific search engine.
The other two scenarios/excuses are more problematic. If the search has a feature that you thing make the results bad you’ll need to see if you can get it switched off/removed. If you can’t you may have chosen the wrong product.
If your supplier thinks that teaching authors to do metadata properly is a simple goal then you may need a new supplier. This is hardly the attitude that made Google the search masters.
(I’m not contradicting my Best Bets post here: I think there are scenarios where properly motivated and focused editorial staff can do a better job than natural search results. But I’m not thinking of your average author, I mean your central web or search team. I mean people paid to care about search.)
You change the guidelines/training for authors. You can probably get the current batch of authors to listen to some simple tips and pointers. They might remember. They might pass them on. But be realistic, how much control do you have over the authors? Metadata education is often a thankless and futile task. The best solutions are those that don’t require the authors to think about search, whether that is technology or intervention by search specialists.
Where the natural results just aren’t good enough and the authors can’t help there are things you can do on the search results page to help the user out.
Not really about testing but still coming soonish: Changing the interface