It's All Geek to Me at dev8D
•
0 gostou•372 visualizações
How can developers in the JISC community communicate with a broad, non-technical audience? Lightning talk given at dev8D 2010 by Steve Boneham
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (18)
Destaque
Semelhante a It's All Geek to Me at dev8D
Semelhante a It's All Geek to Me at dev8D (20)
Mais de JISC Netskills
Mais de JISC Netskills (20)
Último
Último (20)
It's All Geek to Me at dev8D
- 1. It’s all <geek> to me dev8D Image: http://informationarchitects.jp/ia-trendmap-2007v2 Steve Boneham, JISC Netskills photo: mogrify via flickr
- 4. With great power comes great responsibility http://www.thesuperheroquiz.com/ photo: missrogue via flickr
- 5. Know your audience photo: GlowPlug via flickr
- 6. JISC Netskills Help mortals use the stuff geeks make mortal geek photo: Wikimedia Commons
- 7. I have a few lab coats in my closet photo: plutor via flickr
- 8. Know their RSSfrom their elbow? photo: istockphoto
- 9. Know their RSSfrom their elbow? photo: istockphoto
- 10. Disorientated? photo: (c) iA. Used with permission.
- 11. Inertia: resistant to change
- 12. ?/10 8D Photo: dietpoison via Flickr
- 13. Manual labour RTFM isn’t working photo: www.sxc.hu/photo/883122
- 14. Offer lots of Carrots photo: emospada via stock.xchng
- 15. Evangelism & pragmatism photo: coba via Flickr
- 16. Instructional design 101 Taxonomy, autonomy & experiential learning...
- 17. Quick pitch… photo: Netream via Flickr
- 18. Mind your #!%£ language! Clear, creative design inspires clear, creative language Cathy Moore, Dump the Drone photo: istockphoto
- 19. Use your audience photo: .:Calaveracafè:. via Flickr
- 20. Variations on a theme photo: Flowery *L*u*z*a* via Flickr
- 21. Anyone can play guitar? Photo: istockphoto
- 22. Shameless big plug… Photo: Adam Mulligan via Flickr
- 23. Image credits Creative commons/royalty-free images used with thanks... http://www.flickr.com/photos/36673768@N00/575142440/ http://www.flickr.com/photos/missrogue/344736934/ http://www.flickr.com/photos/11831132@N00/157578783/ http://www.flickr.com/photos/92331968@N00/1509548968/ http://www.flickr.com/photos/dietpoison/133957015 http://www.sxc.hu/photo/883122 http://www.sxc.hu/photo/731122 http://www.flickr.com/photos/coba/1825369 http://www.sxc.hu/photo/972396 http://www.flickr.com/photos/74073406@N00/2779096394 http://www.flickr.com/photos/11599314@N00/459219845/ http://www.flickr.com/photos/calavera/65098350/ http://www.flickr.com/photos/amulligan/370214398/ Used with permission from iA: http://informationarchitects.jp/ia-trendmap-2007v2 iStockphoto images used under license to JISC Netskills.
Notas do Editor
- These are the slides from a ‘lightning talk’ at JISC dev8D on how developers in the JISC community can communicate with a broad, non-technical audience. Given the time constraints of this session in a packed and very interesting event, my presentation was always going to be a little light. Most of this is just common sense, but the fact that I was asked to talk about it at dev8D implies that there is still something of a communication problem between the developers of a system and it’s end-users.I’m a little wary of sterotypes such as digital natives or the google generation and of extrapolating from these. So while preparing for this talk I scanned for some evidence that the geek sterotypes are still in common usage. Just to be clear, I consider the term geek to be a compliment. Developers do some amazing stuff that the rest of us benefit from, but only if we can understand it and use it.
- The first ‘evidence’ I saw was a tweet on the launch of data.gov.uk. This is a resource with amazing potential to give public access to public data. However, that’s only true if the data can be made available in meaningful ways. Luckily, as hubmum put’s it, the geeks came to the rescue.
- The next was from psychemedia, talking about the responsibilities of developers to make data available to the masses - or as he put it in his tweet - the mortals.
- That idea of responsibility is why I think this is an important issue. No offense to developers, but no matter how good your new system is, it’s only as good as the uses that people put it to. So, if there is a communication problem, how can we make it better?
- The first responsibility is to know your audience(s). As this is where the sterotyping starts, let me defend my position by explaining a little about what I do.
- I’m a trainer at JISC Netskills. We provide end-user training in web technologies for 1000s of staff from the education sector each year, as well as producing training materials for institutions to do their own. As such, we work with a fair few of (what I assume to also be) your audience. So although I’m presenting anecdotal evidence, it is at least based on a relatively large sample size (even if one that may be biased by being an audience seeking training). We work at the interface between geeks & mortals, taking the systems and ideas of developers and translating them into something users can put into practice. That often requires us to speek both geek and mortal.
- I should also declare that I’m part of the mortal audience. Before working in tech, I spent 10 years as a researcher working on HIV vaccines. As such I worked with some extremely intelligent and capable people. Similar sterotypes applied here regard to the problems of scientists communicating about their research with the general public. The key for both scientists and developers is to recognise the nature of their audience and adpat accordingly. So what can we say about a typical audience for systems developed for use in academia?
- Firstly, don’t underestimate how little awareness there is of technologies that you might consider to be mainstream and well-established. Your users aren’t stupid, but tech is just a tool that they pick up to use when they need to, then put away again.They don’t see the world through the lens of technology as many developers do. RSS is a good example of this. For something so fundamental to the modern web that offers real and immediate benefits to users, surprisingly few people in the audience we work with know what it is or make use of it. They’re typically familiar with web browsers and facebook, but much less so with things like RSS, AJAX or XMPP. As for emerging services like google wave, buzz or pubsubhubbub…
- A recent example of this was when ReadWriteWeb (RWW) introduced FB connect as a way to allow login to their commenting system. They made a post to announce this and it soon found it’s way to the top of the google SERPs for ‘facebook’. As a result, a not insignificant number of people found their way to RWW and logged in believing they were logging in to a new version of facebook.
- That highlights that many users are disorientated by the ever-increasing rate of change in technology. When a geek looks at this ever-changing landscape they see possibilities and opportunities to do new things. When a mortal looks at it, they can often see change and increased choice as confusing. Many people prefer to take the well-trodden, familiar paths with technology, even if new systems are better. So developers need to be careful when adding new system to this already crowded space.
- Change is never easy for people and is often met with resistance and inertia. Academia (and academics) is traditionally thought of as being slow to change and the rate of change of technology outside this world can sometimes appear to be inversely proportional to the rate of change inside it.
- So, how ‘happy’ are your users likely to be when you present them with your new system? Well, that largely depends on how it is presented to them.
- All too often, it’s as an uninspiring product manual or piece of documentation that tells people how to use a system, but not why. I’d argue that this approach might be necessary, but is not sufficient for people to truly understand something new.
- What we need instead are some carrots – reasons why a system will help people, their life easier or make them more productive.
- So, how does all that translate into communication? Well, this is a simplified version of the model we use for our training. It’s based on elements of Blooms’ taxonomy, Kolb’s experiential learning, Honey & Mumford learning styles, Ecclestone’s autonomy to name a few of the giants of educational research whose shoulders we stand on. The key point is that instruction in new technologies should focus first and foremost on the ‘why’. Without this hook, it’s unlikely that people will be motivated to find out how. So we start with some evangelism, then move onto guided practice to hopefully sow the seeds towards the transformation and pragmatism needed for true independent practice.
- Consider starting with something akin to a quick elevator pitch. What would you tell someone about your service in 2 mins? What are the key points to communicate? How would you get them across effectively?
- Make sure your language is appropriate to your audience and remember the principles of writing for the web, such as using plain English, an inverted pyramid structure and front-loading.
- One of your best assets are the people ‘formerly known as the audience’. They’re the one’s use systems in anger. They will find problems you’d never thought would be problems and solutions that you’d probably never come up with. So encourage them to help each other and help you. If you listen, they’ll give you vital feedback. If you let them, they’ll help write the manual, not just read it – as well as make videos, write reviews, make suggestions…
- Mix your media. Without veering off too much into learning styles territory, different people prefer to learn in different ways and through different media that suit those ways of learning. Consider what media would work best for your evangelism or for facilitating some guided practice. For example, many new services launch with a short video overview about the why, more than the how. Back these up with more in-depth guides, FAQs as well as forums to encourage discussion.
- Problem is that not everyone is happy (or good at) presenting, recording podcasts, making videos, writing manuals or facilitating training.
- Creative commons/royalty-free images used with thanks: http://www.flickr.com/photos/36673768@N00/575142440/http://www.flickr.com/photos/missrogue/344736934/http://www.flickr.com/photos/11831132@N00/157578783/http://www.flickr.com/photos/92331968@N00/1509548968/http://www.flickr.com/photos/dietpoison/133957015http://informationarchitects.jp/ia-trendmap-2007v2http://www.sxc.hu/photo/883122http://www.sxc.hu/photo/731122http://www.flickr.com/photos/coba/1825369http://www.sxc.hu/photo/972396http://www.flickr.com/photos/74073406@N00/2779096394http://www.flickr.com/photos/11599314@N00/459219845/http://www.flickr.com/photos/calavera/65098350/http://www.flickr.com/photos/amulligan/370214398/Used with permission from iA: http://informationarchitects.jp/ia-trendmap-2007v2Commercial stock images used under license to JISC Netskills.