Boxes and Arrows: Comments by Chris Collingridge

Chris Collingridge — Fri, 26 Jan 2007 14:53:01 GMT

For information stored in the EU, you’ll also need to consider data protection regulations. While your legal department should know about this, it seems to be a little bit of a black hole in some US companies, as there really is no equivalent binding legislation in the USA.

If it’s all in the cookie, I’d imagine there’s no problem (as you’re not controlling any data), but if information in cookies links to personal information on your servers then an issue may arise.

Exactly what the situation is for information collected from people in the EU and stored in the US, I don’t know. A useful (if sometimes pretty complicated) resource for this is www.ico.gov.uk.

Chris Collingridge — Fri, 26 Jan 2007 14:53:29 GMT

Andrea,

I think all you’d need to do to repair the link is remove the full stop (period) after .pdf

Chris.

Chris Collingridge — Fri, 13 Apr 2007 08:39:07 GMT

This is a really good article. I think sometimes technical ‘communicators’ don’t sell themselves well (this is often within the typical persona), and sometime they overstep their bounds in the organisation, and never get another chance. The key is making the most important stakeholders realise that technical communicators have value, and actually demonstrating that value when technical communications get the opportunity – exactly as you say.

There is lots of overlap between technical communications and IA, and between technical communications and interaction design. It doesn’t mean everyone wants to, or can, make that switch, but there are a lot of transferable skills for those that do.

Chris Collingridge — Wed, 27 Jun 2007 18:31:30 GMT

Excellent article, and good advice. My mantra has been “add value”. Think about what you can do that adds value to developers, marketing folk, technical support, and so on. By asking yourself (honestly) whether you can really make an almost inarguable improvement, don’t do it. By only acting where you know you add value, you build positive memories in people that are a basis for further cooperation in the future.

Basically, this is the “low fruit” you talk about. In a more mature situation it’s harder to make obvious improvements, but in the early stages (and in many companies these “early” stages could be many months, if not years) you can really benefit from being perceived as a problem solver rather than a hassle. Someone who makes less work, not more.

And good luck to everyone taking this on!

Chris Collingridge — Fri, 10 Aug 2007 08:49:17 GMT

Both this article and the article on PDF are excellent for those of us who need to create simple prototypes that are easily distributable, and don’t always have a development resource to assist. The roll-over is a good tip, but a horrible solution! Thanks also to Tamlyn for the heads-up on OpenOffice…

Chris Collingridge — Thu, 27 Mar 2008 17:25:03 GMT

Firstly, the length of this article is great – short and snappy. Much appreciated!

There’s a sliding scale of user involvement, in my opinion. At one end we have an idealised process with unlimited time and resources, in which we conduct ethnographic research across truly representative samples of users or potential users, and continue this engagement throughout product development. At the other end is grabbing someone in a corridor and showing them a screen. This method definitely falls towards the latter end on the spectrum, but utilising information within the organisation is an important area to highlight.

Most organisations that have spent some time developing products for a specific domain do actually contain a lot of good domain information. Using all the information from people who contact customers is a really valuable way to increase the degree of proxy-user input, possibly enabling you to focus your limited time and resources on the areas where real users truly are key.