@media 2008

This is the transcript of the Communicating best practices panel discussion from @media 2008, London, 30 May 2008.

Moderated by Paul Boag, with Rachel Andrew, Patrick H. Lauke, and Murray Rowan

See the slides and listen to the audio recording of the panel discussion, mirrored on archive.org.

Communicating best practices

Announcer: The following was recorded at the @Media 2008 Conference, which took place in London on the 29th and 30th of May, 2008.

Paul Boag: OK. So the subject that we have for today is communicating best practices. And that's communicating best practices to clients, managers, and marketers, and people like that. So, put another way, I guess, we're saying marketers are from Mars and developers are from Venus — the basic problem of: we see the world in completely different ways.

Why is it that our clients, our marketing managers, our business-line managers, whoever, just don't get it? They don't get the web. They don't seem to understand what it is we're trying to achieve and what best practice is all about. So the idea of this panel is to investigate some of those issues.

But, in some ways, we seem equally strange and bizarre to managers. We are some strange, alien being to them. If you don't recognize "2000 A.D." then shame on you, frankly.

So we are equally strange. We seem to speak a different language. We're a different kind of beast. And so what we're going to discuss today is three techniques for helping communication and the promotion of best practices within your organization. So those three techniques are: learning to talk the language of management; don't ask permission, just do, and we'll look at the pros and cons of that; and establishing yourself as an expert.

But we're also going to look at the differences between this problem. Whether you're an in-house person working for an in-house organization, or whether you work for an agency of some description, are there different challenges involved in that?

So let's start by looking at the subject of talking to management and how you communicate with management. Now, let's see. My notes are really tiny now, so I need extra-good vision to be able to spot them.

So I think probably the best question to start off with — and if it's all right, Patrick, I'll start with you — which is, from your experience, do the kind of higher echelons of your organization care about things like accessibility, usability, or standards? Is it something that enters into their thought processes?

Patrick H. Lauke: Not necessarily, no. Management, as you mentioned, does speak a completely different language. You really need to start looking at things like cost-benefit analysis and everything else. Particularly for accessibility, the university sector is probably quite good at recognizing that accessibility is something they need to do or they need to worry about. But they don't know the specifics. They might know it as "It's one of those tick-boxes that you need to tick."

You need to make sure that you do something that is accessible, but if you start talking specifics about what you want to do, start talking about HTML or separating content and presentation, that sort of thing, they certainly don't know what you're talking about. And they don't necessarily need to know what you're talking about. They should trust you as the expert to actually know that you're doing the right thing, and just making sure that they know that it's one of their duties and we're fulfilling it, that kind of thing.

Paul: Murray, back in your kind of Yahoo days — Yahoo, a massive, big web company. Surely they're up to speed with latest best practice in web design, and there was no convincing required at all.

Murray Rowan: Well, right now, yes, absolutely. If you were at Nate Koechley's talk today, I'm sure you're convinced that Yahoo takes that sort of thing very seriously. Back when I joined Yahoo, back in 2000, the situation was rather different. I was an accessibility consultant before I joined Yahoo back in 2000, so it was quite some time ago. And when I joined and started harking on about accessibility, I don't think I got paid much attention to.

Paul: [laughs] OK. What about Rachel, with the different clients that you work with? I mean, you work with, obviously, a large number of clients of varying sizes. What kind of awareness is there of not just kind of separation of content from design, but kind of generally about usability, accessibility, other forms of best practice? Is it all foreign to people?

Rachel Andrew: Most of our clients I see are design agencies. And what I tend to find is that they understand the basic ideas behind what we're trying to do. But then, when it comes to a conflict between actually implementing that and perhaps it meaning that some of their design ambitions have to be changed, some of the things they'd like to do, maybe have very small text or low-contrast things, then we're saying, "Well, maybe that's not such a good idea."

Then it becomes a conflict between best practices and the fact that they actually do want to do things right, but they also want it to look the way they want it to look.

Paul: Yeah. Yeah.

Rachel: That tends to be more the issue. Most do come to us because they know that we'll do things well. And they do want it done well, but they also want it to look really pretty. [laughs]

Paul: [laughs]

Rachel: So it's that conflict.

Paul: OK. That's fair enough. So you were talking earlier about having to kind of present things in a slightly different way. How have you adjusted your language when talking to some kind of senior management?

Peter: It's really easy. Particularly from when I mentioned before, I always rant on mailing lists, and we discuss web standards and accessibility. It's very easy to fall into the trap, even when you're talking to management, to just start focusing on very small details, have little arguments about, "Well, this should be an abbreviation rather than an acronym, because an acronym is this and it's not quite right, " or, accessibility-wise, kind of starting to talk about absolute things, in terms of "This must happen, otherwise your site is completely inaccessible, " etcetera.

It's very easy to fall into the trap of actually starting to talk techie. And then, as soon as you do that, management will just switch off. Or even worse, they will from now on treat you as the techie, and then, every time their printer is jammed or whatever, they will give you a call...

[laughter]

Peter: Which still happens to me. It's very interesting. Or they need to do a presentation: "Can you hook up the laptop to the projector?"

So you really need to start kind of learning a little bit of the lingo of the enemy, if you want to treat it as the enemy — or it could be your best ally — management. As long as you start really focusing in on the business case, what are the actual benefits to the end users, and is it going to save them money — that's always a really good argument.

With a lot of things, in terms of web standards, you have to really make the argument of "OK, it might be a bit of an investment now, but in the long run, if we'd want to redesign next year, because we've got like a yearly cycle of redesigns or realigns of the website, this will save us money, this will save us time and effort, " that kind of thing that they understand. Basically, money talk. And talking about best practices is all good and well, as Rachel mentioned, but as soon as it then starts impinging on something else they want to do, they'll start thinking, "Oh, hang on a minute."

So yeah, focusing on the money side of things and how it's going to save time and effort later on is usually a good thing — maintainability, that sort of thing.

Paul: So, how do you go about pushing standards up the priority list? Rachel, you were talking about, as Patrick just said, the fact that if something else comes along that they conceive as being important, then best practice gets pushed out the door kind of thing. How do you prevent that from happening? How do you raise that in their expectations?

Rachel: I think it's important not to actually say no, not to say, "No, you can't have that." It's looking at what they're asking for and saying, "Well, is there another way we can provide that, or is there a way we can provide something very similar to what you're wanting? What's the end result that you're after, and is there a better, best-practice way of doing that?" And that works quite well.

I think if you go in and sort of say, "Well, I'm the technical person, and I say you can't do that, " then it just ends up being there's a standoff there. Whereas, if you can more gently say, "Well, there are other ways to do this, " or "OK, so we've got to have this low-contrast text here. Well, is there a way we can provide something else to do that, maybe do the style sheet or whatever, if that's needed?" Because sometimes that design is very, very important and that rung is very, very important.

And these are the things we can do. So I try not to end up being the person who always turns around and says no. [laughs]

Paul: Yeah. "Yes, but these are the consequences, "or "Yes, but this is an alternative" kind of thing.

Rachel: Yeah. Yeah.

Paul: OK. I mean, the kind of interesting thing that's been raised so far — Patrick raised it — is the idea that you should talk about cost savings; that's a good approach when talking to management. Which is all well and good if you're starting a site from scratch. But in the case of, say, Yahoo, there is a large, existing website there. So, did you find that there was resistance of, "Well, actually, it's not going to save us money in the short term: it's going to be a huge expenditure of moving across to a standards-based approach"? And how did you deal with that?

Murray: Yeah. You can't just walk in one day and say "Right. All of these 20-odd websites are no good: we've got to change them all now." That's never going to work. You really need to be pragmatic in the face of something like that. So the approach that we took at Yahoo! Was "OK. We've came in; we've noticed a problem. We're starting to build a team of people who are professionals at doing things well. We're going to make sure that all sites that get redesigned from this point onwards will adhere to standards and be of much better quality."

If you want to do something with your existing sites that may not be particularly fantastic for one reason for another, you can do a quick run-over, do some things to improve accessibility, that sort of thing, like just putting in proper header tags or something like that; and you can leave it at that until the next redesign comes along. But, yeah, you don't want to just keep banging your drum and say "This is all rubbish; this is all rubbish; this is all rubbish": it won't work.

Paul: I came across an interesting quote from Jared Spool. Obviously, he was talking about usability, because that's his big thing. But it, I think, in many ways, kind of applies to all best practice. He said "I learnt very quickly that business executives don't care about usability testing or information design. Explaining the importance of these areas didn't get us any work. Instead, when we were in front of executives, we quickly learned to only talk about five things: how to increase revenue, how to reduce expenses, how to bring in more customers, how to get more business out of each existing customer, and how to increase stakeholder value." Notice that he didn't, at any stage, mention design or usability or navigation or any of those kinds of things. And he discovered that, from talking in that way, he started getting much bigger projects.

Is that kind of your experience about a kind of good approach? Anybody?

Patrick: Yes.

[laughter]

Paul: Yeah; that was a really rubbish question, wasn't it? It was one of those questions you should never ask, 'cause it's not an open-ended question.

Patrick: It was quite leading, wasn't it? Yeah.

Paul: It was a very leading question.

Patrick: No, Murray already touched on definitely the cost-saving aspect of things. I want to just pick up something, now, that Murray mentioned about the — you know, "Wait for the next redesign." I mean absolutely.

This is something that we — well, I use the royal "we" — I did at Salford: in 2003, basically relaunched the whole core website and started from there using CSS, XHTML, separation, constant presentation, all of those things. But I'd had many talks with managers beforehand, basically suggesting "OK. What we'll do is we'll basically scrap the site that I inherited in 2001, when I first started, which is all table-based. And I'm going to remodel it; I'm going to spend loads of time; and, in the end, you're not going to see the difference, but, under the bonnet, it's all going to be all shiny, new, best-practice, CSS and everything else."

And they looked at those proposals and obviously they just thought "What's in it for us?" There was nothing concrete that they could see. So, definitely, waiting for the next redesign, make it part of the next redesign, and, in the mean time, kind of start cleaning up your pages — as you say, add header tags here and there, where you can. Just doing the small things definitely works. But that is basically the worst proposition you could make — saying "We're just going to redesign it for the hell of it, just because it's not best practice now but it will be best practice later" — because it doesn't mean anything to management.

And, yeah, then you need to factor in all the extra cost. If you switch from completely table-based design, old-school style website, to new ones, there is a lot of time that you invest initially to actually start. If you've got multiple developers, train them up properly, so they know what they're actually doing. Learn it yourself. Start to separate your content. Go back and revisit old pages. There is a lot of costs and time and effort that needs to be done up front. But, then, the savings come later. So it's kind of hedging your bets and waiting for the right project, and then start saying "OK. Well, let's take advantage of this redesign, to actually do the right thing right from the start and then, from then onwards, implementing best practice as a matter of course."

Paul: Another good thing about doing it as part of a redesign is that, in my experience, management hate redesigns, but they kind of accept that they have to happen, but they're kind of fed up with this three-yearly cycle of suddenly their website has become out of date and is a mess and they've got to pay a big chunk of money all over again, a big wodge of cash, to sort the site out. If you can say "Well, this is going to be the last complete redesign you have to do in that sense. From this point onwards, it can be incremental change, and it's going to be so much easier; it means you'll be paying small amounts of money on an ongoing basis, rather than big wodges of cash every three years", then that's better from a cash-flow point of view, but also it gives them the feeling that, every three years, they're not completely throwing away the money that they spent previously and paying a whole lot of new money — because, obviously, with best practice, it's much easier to make incremental changes across the entire site.

Paul: Any other comments about kind of talking to management and the way to do that?

Murray: If I can go back to the point you just previously made actually: I think, over the last number of years, it's difficult to imagine that, if you build a site in 2000, to the best practices at the time, four years later those best practices are going to be the best starting-point for ahead, the new redesign. So you are redesigning it. But can we imagine that, right now, we've actually met that criterion, whereby, in four years' time, the structure and the way we've built the site today will actually be a good foundation for a new site in four years' time? It's interesting; I don't know the answer to that; I hope it is, but —

Paul: Has anybody got an opinion on that? Whether you think that what we're building now is going to last, even if some redesign is happening? Yeah.

Man: Yeah, it isn't.

Paul: It isn't.

Man: I mean think about it: we're in an immensely fast-moving field. The stuff that we're doing now no-one had even heard of two years ago. The room nextdoor was talking about ARIA, which you're all going to need to put into your sites, which no-one is doing at the moment: four years from now, it's all going to be SVG or Microsoft Silverlite.

[laughter]

Paul: Just stop being silly. We all know that won't happen.

Man: But it really is going to — well, my personal opinion is that it's going to change dramatically. The landscape in 2012 is not going to look like it does now, just like the landscape now didn't look like this in 2004.

Paul: Sure. I would agree with that. But I do think that things like separating out content from design, and behavior from design and content — it does enable you to change one part without necessarily changing the others, and that you can get into a situation where you can make — you know, even simple things, three years ago, became a huge undertaking: you know, to change the text size across an entire site. And it's things like that that force a lot of clients to do redesigns. You know, it's silly things. Now, I'm not necessarily talking about massive sites, like Yahoo! And even Salford. But, maybe in smaller sites, I think, those are bigger issues. But, you know, I accept that.

We're going to open it up at this point? Twitter has given out on me. Unsurprisingly, the Twitter's not working, the WiFi connection's not working, and my mobile phone's not working. So, before we move on to the next subject, anybody got anything about talking with management? Any questions about that? We're going to kind of intersperse the questions, instead of having a big lump at the end, where you've forgotten what we've talked about? Yes; a question down far.

Audience: I was going to say "Is it worth using examples to sort of shame people into doing it?" Maybe saying "Look: Yahoo! Would do it that way, so we should do it that way." People like to be associated with sort of —

Paul: Other people. Yeah.

In my experience, I've worked with the HE sector quite a lot; and that's a tactic I quite use a lot. So would you agree with that?

Patrick: Yeah. Well, the amount of times that you hear managers saying — when you ask them "How do you want the site redone? What features do you think are missing?" and they start saying "I want it just like the BBC website." So things like that are a double-edged sword, where you can actually say "Right. The BBC are doing it this way." or "This other big site is doing it that way" — definitely. I mean it still needs to be backed up by all the other things we talked about. They still won't just open up the coffers and give you a blank cheque and say "Right; yeah. Just do it exactly like this other big site does." But, certainly, that can help inform the decision when you start — because, if you just say "Oh, it's best practise" — if you can actually give examples and say "These big sites are doing it for this reason" and give examples of how then later that kind of can help you, your own business goals, then definitely that's one of the tactics that can be used.

Paul: There's a question up there.

Audience: Hiya. You talk about talking to management. And I, probably being the evil one in here — I'm actually a business manager in a web team.

Paul: Good for you.

Audience: yeah.

[laughter]

Audience: Well, I think, last year, I didn't understand a word anybody was saying, but, this year, I've learned a little bit. I work in academic publishing. And, just like somebody mentioned yesterday in the newspaper industry, people work there because they love books. And it's not just talking to management you have to do: we have to think of it as a whole industry, that web is a way forward, that you need to use it.

Do you have any advice on communicating to whole companies, and editors who are scared of providing content, and marketeers who don't know what they're doing, anything like that?

Paul: Marketeers that don't know what they're doing?

Patrick: Unheard of.

[laughter]

Patrick: I work in marketing, myself, so I don't know what you're talking about.

Paul: Patrick?

Patrick: Oh.

Paul: It keeps coming back to you.

Patrick: Thanks. Do I get more money for this?

Paul: No. You don't get any money.

Patrick: Exactly.

Paul: Or are you getting paid and I'm not? Oh.

Patrick: What we do, at Salford, is definitely we try to do whatever we're doing in marketing coms we're now trying to push to get actual research done, so we get big, syndicated research across various universities and by a large company called Heist. So they get like questionnaires about how like the youth sector uses, I don't know, Web 2.0 technologies — they actually have that title; lovely — so things like how they use Twitter, etc., compared to, say, traditional printing, like prospectus — just to inform our view of, for the university sector, do we actually still need to do printed prospectuses, or should we completely ditch that in favor of web? So we try to at least have good data and get information from the actual end-users, themselves, and the stakeholders.

So, if you can do something like user research, that is always really good. Obviously, when it comes to the website, itself, usability tests and so forth: I know management doesn't always see the benefit in those; but, if you can just wangle it in through the back door, or if you can do some guerrilla-style usability testing, etc., that is always really helpful. Yesterday, they talked about mental models. If you can actually show what the end user wants, that's a lot more powerful, and it moves away from a lot of the "Well, I think the web isn't a go" or "I think we should completely focus on the web", that sort of thing. So getting actual answers from the stakeholders, from the end users.

Paul: Let's push on to the next subject, which is my favourite: "Don't ask permission; just go ahead and do it." It's an interesting theory that you hear thrown around a lot at conferences like this; and so I thought it was one worth discussing in a little bit more depth. So I guess the first question is "What are the main obstacles behind just kind of getting on with it, really?" So, Murray, do you want to kick off with that?

Murray: Sure. There are a number of things that can get in your way if you just want to do it. Clearly, just clearing everyone out and starting to type isn't really the best approach.

The first thing, if you're walking into a business that already exists, that's going to get in your way is people that might be existing developers who don't follow a particular approach. It might be editors, product managers, or anyone else in your organisation who just loves getting stuck into that front-end code and they have access to it and, right now, that's the only way they can do their jobs. So, even if you make a really great job of your HTML, once they start going in to change things it will just get really bad over time. Or it may be your management: they don't get it. So these sorts of things can certainly get in your way.

Also, tools. As you previously alluded to, some tools don't have a clear separation of concerns between the various functions of the business. So editors, front-end developers, and back-end developers all could be working in the same sandbox, if you like — or "sandbox" is probably a bad word to use, but — in the same templates files or whatever: that's going to get in your way as well, because the other guys who aren't professionals at a particular discipline aren't going to do quite as good a job at decoding it as perhaps you would.

Another thing that's going to get in your way is capacity. So you walk into the company, you've identified the problem, and you want to change things. I think we've mentioned this before: you can't do it if you're the only person. You can't say "OK, editors. Stop touching HTML. I'm going to do that from now on" when it's just you and there's 100 of them.

Cost as well. Whenever you try to change anything within an organisation, even if it's for the better in the long run, there's going to be a short-term, at least, cost in that. That cost could be training; it could be redeveloping tools in order to fit your goals. And, often, businesses don't want to accept that short-term cost, even if the long-term gain is quite clear.

Paul: So that's depressing then.

Murray: No-one said it was easy, that.

Paul: Hang on a minute. You've just outlined a number of reasons why it can't be done; yet, you achieved it within Yahoo! So how did you overcome some of those obstacles? Magic fairy dust? Hypnosis?

Murray: Some of that. Hire Norm: he's great with that. Which is one thing I did.

[laughter]

OK. So there's a number of things you have to start taking control of if you're going to try to change your company's approach to standards and best practises.

The first thing is to get a hold of hiring: you want to stop anymore people coming into your organization that are going to add to the problem. So plug that one first. And you can do that whether you're a manager or you're a developer. If you're a developer, why not volunteer to write some technical tests for new hires in front-end development? And then that can be the bar that new people coming in to the organization need to meet in order to get in there. And that's going to stop your problem growing whilst you're trying to solve it.

Around the same thing, in hiring: it's good to hire experts in the various important domains that you have. So, for example, an accessibility expert, a JavaScript expert, an HTML and CSS expert. And then the others in your team can then look to them for training in order to raise their game. And, over time, you will improve things there.

Another thing as well: it's really important to start instigating code reviews within your organization. Code reviews are the only real way that people start to raise their game, get better, converge on not just web standards as a whole, but your company's standards and approaches to doing any particular job.

Also, incentivisation is important. You don't want to just incentivise, via bonuses, your developers, just for getting stuff out the door. They should incentivised around the quality of the thing that they get out the door as well.

But, along the lines of incentivisation: if you can do it, it's good to incentivise the product owners as well, the people on the business side, around the quality of the sites. Otherwise, you're kind of setting yourself up for a bit of a fight within the company: if you're incentivising your developers around quality, and your business people around getting it out the door, then they're just going to fight all the time and that's just not going to work; but, if everyone has some form of skin in the game around having a better-quality website, then you're going to be in a much better position.

And another thing that I did at GCap: if you happen to be in a more senior position, then you can bake support for standards and best practises into the organisational structure and processes within your business. What we di d at GCap is we've got two types of team: we've got the multifunctional scrum teams, who work on the various business priorities; and we also have these working groups. And the working-groups are made up of people from the various multifunctional scrum teams; and their job is essentially to identify, set, communicate, and enforce best practises in the various areas in which the working groups exist. So we have working-groups for front-end development, testing, UED, web security — we called it "paranoids", and Yahoo! Quite liked it; and there's a couple of others as well. And the goal of them is to make sure best practises and standards happen: they have a mandate from the organisation so they can go and enforce it within the various teams. And that helped a lot.

Paul: Yeah. No, I can imagine.

I mean, to some degree, that depends on how much influence you've got within the organisation, or how much you can affect the organisation. I mean, Rachel, you're in the same position I am: we're kind of outside of the organisation; and we're kind of implementing a solution on them, in a sense. Do you ask their permission, or do you just get on with it?

Rachel: A lot of the time, we just get on with it. Something Murray was saying about sometimes you have — you know, you've got content editors and they're adding stuff and so you've got these beautiful templates and your CMS is putting out wonderful code and its all fine and then someone comes in and adds font tags.

One of the things we do — Drew was talking yesterday about those developing over in CMS, and one of the things we've done is we don't let people add HTML. We give them tools to add content and to mark up content, without being able to add any HTML, which means that people can, to a degree, style things, they can add things, they can mark things up, but in a way that doesn't damage the accessibility. And we can control that and control what people can put in, which is great not only for best practises but also for the integrity of the design, because if you've got people who can stick in font tags and things, it's going to make things sort of a mess. So everybody's happy about that. So that's one way in which, with tools, you can ensure this all happens.

But, yeah, a lot of the time, we are just doing it. And, when we quote for a project, we're quoting to do it well. If people can't afford to do it well, then — you know, a lot of the time, it doesn't cost anymore anyway. But that's the package; that's what they're getting when they come to us: it is to have it done well; and we don't want to do things badly, so that's not an option really.

Paul: What about you? Do you get into a situation where you kind of implement this standards-based solution, you provide them with the content-management system, which has got a WYSIWYG that, rather than let them set the style, lets them mark up the content, and then do you say "OK. This is the way it's going to be. Now I'm going to educate you as to why it's that way"? Or do you take a different approach?

Patrick: Well, first of all, we haven't actually got a content-management system, I'm very sorry to say. So we're still a little bit in the Dark Ages, in terms of structure. I control the central website, all through Dreamweaver. And then every faculty, school, department, etc., still has its own web authors, who have direct access, basically, to their pages. They've got a few templates that I managed to knock together for them, based on the standards agreed on in 2003.

But, yeah, the majority of it is people who — it's not their primary job function: they just get a copy of Dreamweaver, and they're told "Right. You're not doing anything on Friday afternoon: you're going to look after your department's little website." Not big tasks: we're usually talking a few dozen pages — 20, 30 pages. But the fact that there is no CMs obviously creates a lot of problems for us that, for the last seven, eight years, I've been banging on about: "We do need a CMS."

So, luckily, in the next few months, we're hoping to roll one out. But it's not going to be forced on people. So, at the moment, we're still in a situation where people who might not even know anything about HTML, CSS, accessibility, any sort of stuff like that — they get a copy of Dreamweaver, they treat it like Word, or sometimes they even just copy and paste straight from Word into it, upload it to the web. So, yeah, we mentioned sandbox: I would say "litterbox". So we have a few problems.

In terms of "Don't ask permission." Certainly, when I did the redesign in 2003, I had the green light from my manager, head of marketing at the time, to just go ahead and do it. He was really good in terms of — he trusted me as an expert to just do the best thing. I'd been talking about best practise; he just said "Look. I don't want to know it. As long as basically we're not losing any money and the website's going to look fantastic afterwards, just do it." And that's what I did: I pretty much just sat down, started learning more and more about web standards, read a lot of stuff, started going to conferences like this one; and, basically, yeah, in the course of like three, four months, completely gutted our website and redid it. And, from now on, anything I do is standards-based, and I don't wait for anybody to actually tell me "Oh, by the way, it needs to be accessible." This is all as a matter of course: it's being done.

The problem, of course, is then these distributed web authors around the university. But I'll touch on that probably a bit later.

Paul: One problem at a time.

Patrick: Yeah.

Paul: OK. I'm surprised we've been running behind schedule; that's a real shock. So, before we move on from this subject, is there any questions in the audience? Yes, we've got one down here.

Audience: In my opinion, not asking for permission is just a short-term effort. So, you can build and guerrilla your accessibility into the code; but, by coding accessibility into HTML, you only gain perhaps 50 percent of accessibility. So, to be sustainable in the long term, you have to get somebody from upper management, boardroom-level management, on the track, and then get it downwards from the top of the company. Otherwise, there will be designers, writers, anybody; and they destroy your accessibility. Or, when people leave, there will be no policy for accessibility.

Paul: Yeah. Tidy.

Patrick: Absolutely disagree with that.

Murray: But, also, going back to your point earlier: if you can create a clear separation of concerns within the tools that you're working within, then it's going to be very difficult for a designer or editor to actually go in and change some of the front-end code, for example. So getting that work done in the first place, to adapt existing tools, might require some senior-level support loops; so you're right.

Patrick: Certainly, what we've done at Salford is — I was in quite a lucky situation, that not only did I do the core redesign on my own: I'm also the guy that writes the actual web-publishing guidelines for the rest of the university. And I included all of the stuff about best practises in quite minute detail about how to implement it, what to look out for, almost a completely rewritten version, simplified version, of "These are the topline things to know about accessibility; this is what you should be doing; and, if you don't do it, we're going to completely rip apart your pages and we might even pull your website."

I've written myself powers, which was quite nice at the time, to actually pull any website. I know some universities still have got problems where departments actually run their own web servers and so they're kind of a bit of a law on themselves. We had the lucky situation that 99 percent of all the web content runs off of one single, central web server — which is creaking a bit at the edges now. But it gave me the opportunity to basically say "Right. I've got direct access to your pages. If you're not good enough to follow the guidelines, we will actually pull your pages, or we will force you to get somebody else, within the department, to actually look for these things."

So I've written my legacy; so, even if, tomorrow, I decide to pack it in at Salford, hopefully the guidelines will stay there.

Man: You looking for a job?

Murray: If I could just respond to that one again. Sorry for keeping us all behind. You've got nothing better to do after this, right?

Yeah. So, if you're trying to get support from senior management and you feel that just you going on your own for that support might not be enough, you can look for support from other parts of the organization, from other areas and disciplines that might exist that have similar and overlapping goals. For example: if you go to the SEO department — well, they might not be a department in a smaller organisation, but maybe a person. But there's a lot of overlapping goals between SEO and accessibility, as you probably all know.

Also, the design team will probably prefer that professional front-end developers are developing their designs into web pages, because it's more likely to look like what they wanted, in the end.

And, also, if you work for a large company — for example, if you work for Yahoo Europe, there's a lot to be said for being able to point at a similar initiative in the mothership in the U.S. and say "Look: they're doing this too." I was lucky enough, when I was working at Yahoo!, to have Nick Keckley over the U.S., who was working on similar goals for Yahoo! U.S.; so working with him was very useful as well. And, together, you're more likely to be influential enough to get that senior-management approval.

Paul: OK. I better click "Next" before we go wrong.

OK. So our next subject is that of being an expert. I think that this is something that people who work for external agencies, or freelancers in particular, have to address when they're dealing with clients: they need to come across as experts and they know almost what they're doing, so that they can say that best practises are the way to go.

So, Rachel, I guess that, as somebody that kind of works for lots of clients and needs to persuade them of best standards, you're probably a good person to talk about being an expert. Have you got any general tips about how you set yourself up to be that kind of all-knowing one?

Rachel: Write 13 books? That was kind of where it came from. But that really isn't — in fact, the books came almost after doing other things that probably put me in that position that I was asked.

I think that one of the really important things, actually, is to sort of pick your battles, because, when you go into a client, or even to management or whatever, if you're always sort of picking at every little thing — maybe that thing you don't particularly like very much or you see as a bit of a problem — then you become this person who is just always picking problems. If you sort of save your battles for the biggies, the important stuff, I think, that just sort of underlines that you know what you're talking about and you're not just going around picking for the sake of it.

Another thing is to back up your opinion, because, even if you feel you are a bit of an expert in one field or you know a lot about one particular thing, it looks an awful lot more authoritative if you can sort of say "Well, here's something that's been written about this." I do a lot by email, because I do my clients by email. I never sort of say like "Well, this is a problem, and we're not going to do it." I say "This is a problem, and here's an article written about it and here's some other information." I don't know how much that ever gets read, and I don't know whether people actually do go in and read all of it. But it sort of shows that you're not the only person on this Earth who is saying "That's not a good idea."

I've already mentioned that you should try not to say "No": try to say "Here's another way of doing this."

And also to explain in terms that people understand. If you're trying to put concepts across and you're sounding very technical, it can just be sort of pushed into that "Oh, that's just all technical gubbins, and that's stuff we don't really need to worry about." If you can explain it in terms that people understand, then you sound like you know what you're talking about and you've been able to translate it for people. I think that's really important, and that it something that I've done through the writing I've done is to try and explain technical things in a much easier-to-understand way.

And I think, finally, just be confident that you're right. And that does come from making yourself an expert. You have to read; you have to know that what you're saying is actually correct, it's not just something that you read yesterday on someone's blog, it's something you've researched and you actually understand why you're saying that. If you go in and say "Oh, I don't think you should be doing that", then you're easily going to be trampled over and the other point isn't going to get put across. If you can explain, in solid terms, why, and you understand and you're willing to back it up.

Paul: Yeah. Learning the ability to articulate yourself and explain what it is that you're struggling with.

Patrick, you said that things changed for you when you got your marketing manager on board and that person had the authority to say "Just get on and do it." And you said that that person saw you as an expert. How did you get into that place of seeing you as an expert? I mean, obviously, just looking at you, it's obvious.

Patrick: Absolutely. Absolutely.

Paul: I'm imagining you're...

Patrick: I've got the well toned physique of a web expert.

Paul: That's what it is. And the sharp dressing, power dressing.

Patrick: Absolutely.

I think it's just through exactly what Rachel said: backing up your stuff; not always saying "I don't like this", "I don't think this is the right thing", but actually being far more open. Not saying "No", again. A lot of the stuff you mentioned. And really backing up your arguments with somebody else's opinion, researching your resources quite well.

And, also, as I mentioned before: yes, there are a lot of little battles, in terms of web standards and accessibility, where it really breaks almost down to opinion, in the end. If you can get, say, 90 percent of your website accessible, yes, there might be that extra 10 percent that — "Oh, this really should be marked up this way" or "Really, you should be doing that as well." But, if you start off and focus on that, and all those niggly little things that aren't right, you might not even get the other 90 percent done. So it's kind of a process of picking — as you say, picking your battles, looking at the big things.

And then, maybe after the first iteration, the mythical phase two that was mentioned yesterday about adding the extra 10 percent in, bit by bit — and I think it was just a process, through kind of demonstrating those abilities, that I had got the confidence of management that I actually knew what I was talking about, rather than just being an opinionated guy, the guy in the corner who always says "No, no, no; we can't do Flash", "We can't do this", "We can't do that".

So it's being open about it, actually looking for a good solution.

Murray: I think from a manager's perspective they probably don't really care about the details. But what they do care about is that they have someone there that they can trust and knows what they are talking about at the point of need.

Paul: Yeah. Definitely.

Rachel: It is about trust. I think, it comes back to that being someone who should always have some solutions to problems rather than beina person who just always says, "No".

Paul: Yeah.

Rachel: There is that sort of trust crumbs. And you do get people overtime who then will come back and will ask your opinion rather than just saying, "Right here is a design. We want that." They will actually stop you and say, "We have this idea." and "Can you see any problems with that?" Once you start to get in at that level it makes life much easier because you can then start. Where before you have got something that's cast in stone. This has got to be designed it has been signed off by somebody else. You can start getting your opinion in earlier and that makes everyone's life so much easier.

Paul: No. Good. Go for it.

Murray: You should also look out for opportunities to be the just in time expert, you know, the guy who just turns up going, "ta da" when a serious business problem occurs.

Patrick: You really need ta da.

Murray: It is mandatory.

Rachel: I will have to start.

Murray: Asolutely. And it might happen because you are a bit...your compnay for example is partnering with this other company and it is a big expensive deal and this other company has suddenly dropped the bomb shell that the stuff that you build for them has to be assessable and senior management is running around going "Oh my God. Have we got an accessibility expert." So make sure you're their tap dancing and showing off your stuff.

Patrick: And ta daing.

Paul: So I don't know if I am doing this wrong. It is probably because I never learned to tap dance but I get those occasional situations where a client will turn around and say, "Oh, I know you are right but I want you to do it this way anyway." I mean, how do you deal with that? Rachel you must come across that. Tell me it is not just me.

Rachel: No. That happens all the time.

Paul: That's good.

Rachel: I mean, there's a certain point I think at which at the end of the day they are the client and it is really hard especially if you have done so much right and then there will be something... We had a recent situation where they insist on having loads of texts and graphics and almost every time we go back more text and graphics. You can keep saying it and you can present the argument and at that point there isn't...just do it. We can't not do what they want at the end of the day. They are paying for it.

I think at that point somebody should turn around and say. "Well these are the reasons we think this is a bad idea." It is on record. I think, if your are an organization as well this goes on record that we are not happy with this. We will do it because we are basically employed by you but we don't think it is a good idea.

So then if they come back in three months time wondering why this sites indexed or they've got problems with people complaining about it, you can say, "Well we can change it." But this wasn't something that we did. I think sometimes you do have to wash your hands of the whole bit, of those situations. Sometimes it happens.

Patrick: I have taken that a step further once or twice where I have turned to them and say,"OK, Yeah. I will make these changes but we won't be any longer associated with the project. We don't want it to be known that we produced this work because we can no longer be proud of it." And that often shocks clients into going, "Really? You don't want the advertising of having a link on our site or you don't want in any way be associated with that. That makes them get nervous, so.

Perhaps I am devious.

Rachel: No. We have implied that as well that is to say that this is now getting further then what we really want to be associated with because of what we stand for as a company. Yeah that does surprise people very much that we are willing to put what we feel about it on the line that much..

Murray: I think, if you're in an organisation where the customer and the development team are perhaps the same company, then that's a completely different situation and you've got to approach it differently. If, for example, there's a 2-million sales deal on the line if you don't develop something within two weeks, and, to do it well, it's going take four, you've got to be pragmatic about that and not say "No way! It takes four weeks. Stuff you."

But what you do have to do is that you have to, first of all, let the business know what the trade-offs mean. For example: if you're going to have to cut out progressive enhancement, for example, they need to understand what that means. And you can tell them that it's not going to affect search-engine optimization; and they usually care about that, if not accessibility.

And also, secondly, you have to extract a promise from the business that, once you've released this, you're going to go back and build quality in afterwards. And you need to hold them to that promise, 'cause they'll try and wriggle out of it and say they need this next thing. But the problem is that — OK, they want it now, but you're going have to live with it, going forward, and, if you keep building in technical data into your code base, then that's going to just completely destroy your productivity and motivation and everyday happiness. So you have to be quite strict with the business around that — 'cause, remember, you don't really want your job if you're not allowed to do a good job, do you? I mean, you can't be happy there, right? So stand firm when it matters, but be pragmatic when the business needs you. And that's the only thing you can do.

Paul: OK. Any questions about becoming an expert and being seen as an expert?

No? Ooh. That either means we were totally incoherent or we answered everybody's questions, one or the other.

Murray: Or they've had enough.

Paul: Or they've just had enough and want it — oh, there's one over there.

Sorry. I couldn't see.

Audience: Sorry; I just got in here, unfortunately, so you've probably answered the question previously. But, in terms of just the credibility, I guess, to project managers, if you actually work with people in creating environments and [inaudible] ability to like stand up for friends and say "While we're doing this, how is it going to save time, and how is it going to be something good, and in what way?", because a lot of them are not going to be interested in how good you look — for example, like the technical and programming communities and accessibility. They're more interested in how we look good as a brand or creativeness.

Paul: Yeah, we've kind of touched on those issues, haven't we? Anybody got an answer for that question? Does someone want to answer that question?

Patrick: User-generated content, I see.

Paul: We're a 2.0 panel now. Obviously not. Anything we want to add beyond what we heard earlier?

Rachel: I think, in terms of your own personal credibility, I guess there's a little bit of that. There's loads of ways, particularly now, that you can sort of raise your own profile, which does help. People do Google you. That's going to happen. And I think podcasts like — you know, you've had great success with the podcast, writing and not just books. In fact, probably not books: in fact, articles. And there's loads of outlets: even your own personal blog, if you're writing good stuff and people are talking about it. All of that kind of raises your profile a bit. And people do — and nontechnical people do — Google you and want to know what you've done. And, if there's that in the back of their mind — that "Oh, yeah; other people say that their work's good" — I think that does. And particularly then when you do go on to saying "Look. We don't really want to be associated with this project", they're like "Well, hang on. These people are good; everybody says they're good; and they don't want to be associated with our project: there's a problem here."

Paul: Yeah. That's actually a whole other panel, about how you increase your profile and stuff like that. But the other great advantage of doing that, if you're a freelancer or an agency, is that those kinds of profile-raising stuff wins you work: work comes in because of it. And the people that come to you respect you already, because they've heard about you elsewhere. And they also understand your way of working and are kind of half convinced of where you're going anyway.

So I've found that the work that we've won because of the podcast - they're kind of already there, lined up with the way we work; and they're ready to go and behind us.

Rachel: It's a bit of a filter. Andy Clarke was saying yesterday, in the Hot Topics panel, that the work he puts out there is something that people are looking at: it's a sort of filter for the sort of people that come to him. And I think that's what we find, as well, as a company: people are coming to us because they know that we actually care about this stuff. And so it does make our job an awful lot easier, I think.

Paul: Let's just finish off by touching on the idea of outsourcing and in-house, and really the fact that there are differences between the two. Notice that the outsource is the evil — 'cause that's how I feel most of the time, going into organisations: like I'm the evil outsider that's going to suck the life out of them. But there are differences: how you portray yourself, how you communicate, when you're internal to an organization, is different to when you're external to an organization.

So let's kick off with you, Patrick, on this one. Do you do everything in-house, or do you use outsourcing?

Patrick: The majority of our stuff is done in-house. As I mentioned before, I sit in central marketing, at the centre, so I look after, directly, the core website, www.salford, our main kind of gateway into our site, or the department school websites, managed separately by web authors within the different parts. And, for the most part, because the university traditionally has focused more on the print side of things, rather than the web side of things, it's only in the last two years that they've realized "Oh; this web thing isn't just a fad. So we better start putting some money into it." The majority of stuff has been done traditionally internally.

And, as I said before, it's difficult when you've got web authors that might not be completely technically trained. There's a whole range of web authors we've got, as I said, from the secretary or lecturer who's got a bit of time and been given a copy of Dreamweaver, down to the other side of the spectrum, where it's somebody who's really, really, really heavy techy. Usually they are the department's technical guy as well; so they do the filling paper in the printer and stuff like that as well. You've got a whole range of skills, different skill sets, different understanding of how the web works, etc.

And what we've tried to do at Salford, really, is trying to foster a community of practise around these people. They might come from different departments, might have different knowledge of things.

But we try to get them together at least once or twice a year; do like a mini-conference internally; show off a little bit of best practise, like "This department has done this" or "This is the upcoming redesign of this section for the main website"; and really not just foist it on them, like "Oh, this is central marketing, again, telling us what to do", but actually really going through why things are happening, why standards are important, so that they're not just told "Look. It needs to validate XHTML 1.0, strict", but actually explain why that matters, that, yes, it's a quality-assurance issue, just to make sure that we all work to the same base level of standard, but also what the problems are if you don't code to that particular thing. And being quite honest: not just selling it and saying "Right. If you are using tables, your site is going to be inaccessible."

So not using the shortcuts, but actually explaining "Yes, table-based layouts work with, say, screen readers; but this is why it's better doing it without tables, because it can reflow, it can be repurposed, etc."

So we're trying, really. The in-house side is a lot easier from that point of view, because I've actually got direct control over who these web authors are, in those cases.

You mentioned hiring before, Murray. I tried, even though it's not embedded just yet — but I've tried to sit on as many interview panels as possible when jobs that have a web aspect within the university are being — well, when they're interview these people, just to add a few things about not necessarily the technical side but just to feel if they've got an understanding - these people that are coming in, into the post — of what the web is, and if I get a feeling that they will be receptive to actually learning the way that we do things, based on the guidelines, etc. Sometimes, you do get people that'll say "Oh, I know everything about the web" and then, as you tease it out, it comes out that they just dabble with Frontpage every now and again.

So the in-house side is definitely a lot easier; but we do a little bit of outsourcing.

Paul: I'm getting violent thrashing, slashing motions being made at me from down there, which makes me think that we've gone horribly over time, as always.

Murray: I thought that was me.

Patrick: Or they just don't like me.

Paul: It was unnecessarily violent, was it? I thought it was.

So, with that, we're going to finish. We will sit around here, and we'll happily talk to you about any of the issues in more depth afterwards; but we've got to run. Thank you so much.

Initial transcript provided by CastingWords, with subsequent editing by Patrick H. Lauke. Released under Creative Commons Attribution-NonCommercial-ShareAlike 3.0.