Open Thinkering

Menu

Tag: learning

Digital myths, digital pedagogy, and complexity

Posted on by Doug Belshaw

I’m currently doing some research with Sarah Horrocks from London CLC for their parent organisation, the Education Development Trust. As part of this work, I’m looking at all kinds of things related to technology-enhanced teacher professional development.

Happily, it’s given me an excuse to go through some of the work that Prof. Steve Higgins, my former thesis supervisor at Durham University, has published since I graduated from my Ed.D. in 2012. There’s some of his work in particular that really resonated with me and I wanted to share in a way that I could easily reference in future.

In a presentation to the British Council in 2013 entitled Technology trends for language teaching: looking back and to the future, Higgins presents six ‘myths’ relating to digital technologies and educational institutions:

  1. The ‘Future Facing’ Fallacy – “New technologies are being developed all the time, the past history of the impact of technology is irrelevant to what we have now or will be available tomorrow.
  2. The ‘Different Learners’ Myth – “Today’s children are digital natives and the ‘net generation –they learn differently from older people”.
  3. A Confusion of ‘Information’and ‘Knowledge’ – “Learning has changed now we have access to knowledge through the internet, today’s children don’t need to know stuff, they just need to know where to find it.”
  4. The ‘Motivation Mistake’ – “Students are motivated by technology so they must learn better when they use it.”
  5. The ‘Mount Everest’ Fallacy – “We must use technology because it is there!”
  6. The ‘More is Better’ Mythology – “If some technology is a good thing, then more must be better.

The insightful part, is I think, when Higgins applies Rogers’ (1995) work around the diffusion of innovations:

  • Innovators & early adopters choose digital technology to do something differently – as a solution to a problem.
  • When adopted by the majority, focus is on the technology, but not as a solution.
  • The laggards use the technology to replicate what they were already doing without ICT

In a 2014 presentation to The Future of Learning, Knowledge and Skills (TULOS) entitled Technology and learning: from the past to the future, Higgins expands on this:

It is rare for further studies to be conducted once a technology has become fully embedded in educational settings as interest tends to focus on the new and emerging, so the question of overall impact remains elusive.

If this is the situation, there may, of course, be different explanations. We know, for example, that it is difficult to scale-up innovation without a dilution of effect with expansion (Cronbach et al. 1980; Raudenbush, 2008). It may also be that early adopters (Rogers, 2003; Chan et al. 2006) tend to be tackling particular pedagogical issues in the early stages, but then the focus shifts to the adoption of the particular technology, without it being chosen as a solution to a specific teaching and learning issue (Rogers’‘early’ and ‘late majority’). At this point the technology may be the same, but the pedagogical aims and intentions are different, and this may explain a reduction in effectiveness.

The focus should be on pedagogy, not technology:

Overall, I think designing for effective use of digital technologies is complex. It is not just a case of trying a new piece of technology out and seeing what happens. We need to build on what is already know about effective teaching and learning… We also need to think about what the technology can do better than what already happens in schools. It is not as though there is a wealth of spare time for teachers and learners at any stage of education. In practice the introduction of technology will replace something that is already there for all kinds of reasons, the technology supported activity will squeeze some thing out of the existing ecology, so we should have good grounds for thinking that a new approach will be educationally better than what has gone before or we should design activities for situations where teachers and learners believe improvement is needed. Tackling such challenges will mean that technology will provide a solution to a problem and not just appear as an answer to a question that perhaps no-one has asked.

My gloss on this is that everything is ambiguous, and that attempts to completely remove this ambiguity and/or abstract away from a particular context are doomed to failure.

One approach that Higgins introduces in a presentation (no date), entitled SynergyNet: Exploring the potential of a multi-touch classroom for teaching and learning, is CSCL. I don’t think I’d heard of this before:

Computer-supported collaborative learning (CSCL) is a pedagogical approach where in learning takes place via social interaction using a computer or through the Internet. This kind of learning is characterized by the sharing and construction of knowledge among participants using technology as their primary means of communication or as a common resource. CSCL can be implemented in online and classroom learning environments and can take place synchronously or asynchronously. (Wikipedia)

The particular image that grabbed me from Higgins’ presentation was this one:

CSCL

This reminds me of the TPACK approach, but more focused on the kind of work that I do from home most weeks:

One of the most common approaches to CSCL is collaborative writing. Though the final product can be anything from a research paper, a Wikipedia entry, or a short story, the process of planning and writing together encourages students to express their ideas and develop a group understanding of the subject matter. Tools like blogs, interactive whiteboards, and custom spaces that combine free writing with communication tools can be used to share work, form ideas, and write synchronously. (Wikipedia)

CSCL activities seem like exactly the kind of things we should be encouraging to prepare both teachers and young people for the future:

Technology-mediated discourse refers to debates, discussions, and other social learning techniques involving the examination of a theme using technology. For example, wikis are a way to encourage discussion among learners, but other common tools include mind maps, survey systems, and simple message boards. Like collaborative writing, technology-mediated discourse allows participants that may be separated by time and distance to engage in conversations and build knowledge together. (Wikipedia)

Going through Higgins’ work reminds me how much I miss doing this kind of research!

Note: I wrote an academic paper with Steve Higgins that was peer-reviewed via my social network rather than in a journal. It’s published on my website and Digital literacy, digital natives, and the continuum of ambiguity. I’ve also got a (very) occasional blog where I discuss this kind of stuff at ambiguiti.es.

Photo by Daniel von Appen

3 things I learned during my time at Mozilla

Posted on by Doug Belshaw

Introduction

On my to-do list for the last year has been ‘write up what I learned at Mozilla’. I didn’t want this anniversary week to go by without writing something, so despite this being nowhere near as comprehensive as what I’d like to write, it at least shifts that item from my to-do list!

The following are three (plus one bonus) personal learning points that I felt were some of my main takeaways from the three years I spent working for the Mozilla Foundation. After being a volunteer from 2011, I became a member of staff from 2012-15, working first as Badges & Skills Lead, and then transitioning to Web Literacy Lead.

1. Working openly by default is awesome

Mozilla is radically open. Most meetings are available via public URLs, notes and projects are open for public scrutiny, and work is shared by default on the open web.

There are many unexpected benefits through doing this, including it being a lot easier to find out what your colleagues are working on. It’s therefore easy to co-ordinate efforts between teams, and to bring people into projects.

In fact, I think that working openly is such an advantage, that I’ve been advocating it to every client I’ve worked with since setting up Dynamic Skillset. Thankfully, there’s now a fantastic book to help with that evangelism entitled The Open Organization by the CEO of Red Hat, a $2bn Open Source tech firm.

2. The mission is more important than individuals

This feels like an odd point to include and could, in fact, be seen as somewhat negative. However, for me, it was a positive, and one of the main reasons I decided to spend my time volunteering for Mozilla in the first place. When the mission and manifesto of an organisation are explicit and publicly-available, it’s immediately obvious whether what you’re working on is worthwhile in the eyes of your colleagues.

No organisation is without its politics, but working for Mozilla was the first time I’d experienced the peculiar politics of Open Source. Instead of the institutional politics of educational institutions, these were politics about the best way to further the mission of the organisation. Sometimes this led to people leaving the organisation. Sometimes it led to heated debates. But the great thing was that these discussions were all ultimately focused on achieving the same end goals.

3. Working remotely is hard

I do like working remotely, but it’s difficult — and for reasons you might not immediately expect. The upsides of remote working are pretty obvious: no commute, live wherever you like, and structure your day more flexibly than you could do if you were based in an office.

What I learned pretty quickly is that there can be a fairly large downside to every interaction with colleagues being somewhat transactional. What I mean by that is there’s no corridor conversations, no wandering over to someone else’s desk to see how they are, no watercooler conversations.

There are huge efficiency gains to be had by having remote workers all around the globe — the sun never sets on your workforce — but it’s imperative that they come together from time to time. Thankfully, Mozilla were pretty good at flying us out to San Francisco, Toronto, and other places (like Portland, Oregon) to work together and have high-bandwidth conversations.

Perhaps the hardest thing about working remotely is that lack of bandwidth. Yes, I had frequent video conversations with colleagues, but a lot of interaction was text-based. When there’s no way to read the intention of a potentially-ambiguous sentence, dwelling on these interactions in the solitude of remote working can be anxiety-inducing.

Since leaving Mozilla I’ve read some studies that suggest that successful long-term remote working is best done based in teams. I can see the logic in that. The blend I’ve got now with some work being done face-to-face with clients, and some from home, seems to suit me better.

(4. Technical skills are underrated)

This is a bonus point, but one that I thought I should include. As you’d expect, Mozilla was an environment with the most technology-savvy people I’ve ever had the pleasure to work with. There were some drawbacks to this, including an element of what Evgeny Morozov would call ‘technological solutionism’, but on the whole it was extremely positive.

There were three specific ways in which having tech-savvy colleagues was helpful. First, it meant that you could assume a baseline. Mozilla can use tools with its staff and volunteers that may be uncomfortable or confusing for the average office worker. There is a high cognitive load, for example, when participating in a meeting via etherpad, chat, and voice call simultaneously. But being able to use exactly the right tool for the job rather than just a generic tool catering to the lowest common denominator has its advantages.

Second, tech-savvy colleagues means that things you discuss in meetings and at work weeks get prototyped quickly. I can still remember how shocked I was when Atul Varma created a version of the WebLitMapper a few days after I’d mentioned that such a thing would be useful!

The third point is somewhat related to the first. When you have a majority of people with a high level of technical skills, the default is towards upskilling, rather than dumbing down. There were numerous spontaneous ways in which this type of skillsharing occurred, especially when Mozilla started using GitHub for everything — including planning!

Conclusion

Although I’m genuinely happier than I’ve ever been in my current position as a self-employed, independent consultant, I wouldn’t trade my experience working for Mozilla for anything. It was a privilege to work alongside such talented colleagues and do work that was truly making the web a better place.

One of the reasons for writing this post was that I’ve found that I tend to introduce myself as someone who “used to work for Mozilla”. This week, one year on, marks a time at which I reflect happily on the time I had there, but ensure that my eyes are on the future.

Like so many former members of staff, I’ve found it difficult to disentangle my own identity from that of Mozilla. I purposely took this past year as time completely away from any Mozilla projects so I could gain some critical distance — and so that people realised I’d actually moved on!

So who am I? I’m Dr. Doug Belshaw, an independent consultant focusing on the intersection of education, technology, and productivity. But I remain a Mozillian. You can find me at mozillans.org here.

Image CC BY Paul Clarke (bonus points if you can spot me!)

Radical participation: a smörgåsbord

Posted on by Doug Belshaw

Today and tomorrow I’m at Durham University’s eLearning conference. I’m talking on Radical Participation – inspired, in part, by Mark Surman’s presentation at the Mozilla coincidental workweek last month.

My slides should appear below. If not, click here!

I was very impressed by Abbi Flint’s keynote going into the detail of her co-authored Higher Education Academy report entitled Engagement Through Partnership: students as partners in learning and teaching in higher education. In fact, I had to alter what I was going to say as she covered my critique! Marvellous.

After Abbi’s keynote I was involved in a panel session. I didn’t stick too closely to my notes, instead giving more of a preview to what I’m talking about in my keynote tomorrow. As ever, I’m genuinely looking forward to some hard questions!

css.php