One of the fundamental issues in the adoption of e-learning is that the failure to adopt (which is common) is attributed to the weakness or "lack of usability" of tools. "If only the tools were better, then adoption rates would be improved," we tend to say. This is a very tricky and, I believe, slippery argument.
In the light of this critique, a methodology of elimination might be proposed which goes like this:
Logically, therefore, the method is flawed. But it gets worse. Because, if it not accepted that the method is flawed and its stages are followed, the process of 'improving' tools throws yet more murk into the picture. This process ostensibly does nothing to address the purpose or the context within which the tools are used, whilst expending lots of coding effort in improving them. But in fact because causes of failure of adoption are entwined, what is set in motion is a sort of Zeno's Paradox, where the goal of adoption moves away as new developments in the tools are deployed because they do affect the purpose (things have to be re-explained to users) and change the context of adoption (new functionality addresses different sorts of problems). We get into an infinite loop of groundless innovation.
I think a more constructive way to deal with this is to accept that in e-learning what we do is not create technology, but attempt to communicate ideas which we believe to be valuable in education. The value of ideas lies in our ability to demonstrate their causal power which we attempt to do through building technologies. In this way, technological acts are rhetorical in the same way that discourse is. Given this understanding, we have to accept that sometimes we simply have bad ideas. How can we tell a bad idea from a good idea? Because the causal power of a bad idea can either be demonstrated to be bad (it makes people confused/angry/depressed) or no evidence of social benefit can be demonstrated from the idea. As part of communicating a bad idea, technologies might be created. Whilst lack of adoption of such technology is not conclusive evidence of a bad idea, it should nevertheless be taken as a strong hint that indeed the idea might not be a good one. In such cases, effort should go into thinking of a better idea, rather than trying to 'fix' technology! Indeed, if there was some hope for the idea, but poor engagement with the technology, then a different pattern of communications would emerge where perhaps users who were excited by the idea might recommend refinements to the technology (this is often the case with agile development of Beta web2.0 tools).
Because we make technology, and making technology is hard and time-consuming, we forget that what we really are doing is communicating ideas and values. Remembering that it is 'just an idea' can help us to reject the bad ones more quickly and move on to different ideas. Technology confuses us because it puts a 'thing' in the place of an idea or a value. The problems start when we confuse the 'thing' for the 'idea'.
In the light of this critique, a methodology of elimination might be proposed which goes like this:
1. assume that the failure to adopt a technology has a number of distinct possible causes including the usability of tools, the purpose of tools, and context within which they are used.At first glance, this seems reasonable. After all, failure to adopt must have multiple causes, and a methodical approach to eliminating each possible cause as a way of identifying what's wrong seems defensible. At least it would be if the individual causes were separable: i.e. the issue of usability was separable from the issue of the purpose that a tool serves, or the context within which it is used. Without separability between the usability of a tool, the purpose that it serves and the context within which it is used, there is no hope of effectively being able to investigate each causal factor in turn, because every causal factor affects every other one.
2. invest effort in trying to improve the tools as an attempt to rule-out tools from the failure-to-adopt equation
3. having ruled-out tools, pursue other possible causes sequentially in a similarly methodical manner.
Logically, therefore, the method is flawed. But it gets worse. Because, if it not accepted that the method is flawed and its stages are followed, the process of 'improving' tools throws yet more murk into the picture. This process ostensibly does nothing to address the purpose or the context within which the tools are used, whilst expending lots of coding effort in improving them. But in fact because causes of failure of adoption are entwined, what is set in motion is a sort of Zeno's Paradox, where the goal of adoption moves away as new developments in the tools are deployed because they do affect the purpose (things have to be re-explained to users) and change the context of adoption (new functionality addresses different sorts of problems). We get into an infinite loop of groundless innovation.
I think a more constructive way to deal with this is to accept that in e-learning what we do is not create technology, but attempt to communicate ideas which we believe to be valuable in education. The value of ideas lies in our ability to demonstrate their causal power which we attempt to do through building technologies. In this way, technological acts are rhetorical in the same way that discourse is. Given this understanding, we have to accept that sometimes we simply have bad ideas. How can we tell a bad idea from a good idea? Because the causal power of a bad idea can either be demonstrated to be bad (it makes people confused/angry/depressed) or no evidence of social benefit can be demonstrated from the idea. As part of communicating a bad idea, technologies might be created. Whilst lack of adoption of such technology is not conclusive evidence of a bad idea, it should nevertheless be taken as a strong hint that indeed the idea might not be a good one. In such cases, effort should go into thinking of a better idea, rather than trying to 'fix' technology! Indeed, if there was some hope for the idea, but poor engagement with the technology, then a different pattern of communications would emerge where perhaps users who were excited by the idea might recommend refinements to the technology (this is often the case with agile development of Beta web2.0 tools).
Because we make technology, and making technology is hard and time-consuming, we forget that what we really are doing is communicating ideas and values. Remembering that it is 'just an idea' can help us to reject the bad ones more quickly and move on to different ideas. Technology confuses us because it puts a 'thing' in the place of an idea or a value. The problems start when we confuse the 'thing' for the 'idea'.
No comments:
Post a Comment