Camille Dickson-Deane

Structuring and Resourcing Your eLearning Unit

This chapter will help you make decisions on the types of resources you will need and the qualifications of personnel that should be considered in order to create an eLearning Unit. These suggestions include considerations of an organization’s mission and vision as it relates to course design, delivery, and implementation. Some course delivery processes require different needs based on where the development is occurring within the organization. If the course development is viewed as an academic process, then the skills and/or abilities of the resources will differ than those associated with course development occurring as part of a technology process. Deciding on which model benefits your organization is pertinent to the mission of the entire need for the eLearning Unit. The models described include considerations for responding to market needs as the new education models now include business needs as key goals. These do not exclude further considerations for the pedagogical nature of the unit but simply allow for an overall awareness of the field and its requirements.

Ben Shneiderman: making a difference 2001

[A]: My background was in traditional computer science, technically oriented but I always had a very eclectic outlook on life. My parents were journalists and my sister an English professor, so the human condition was very much part of my outlook; it was natural in the early days of programming to take a look at the designs of programs to see that they would become readable and comprehensible. The use of meaningful variable names, good layout, modular design, clear comments were all issues that intrigued me. When I was an early graduate student I worked with my dear friend Charles Kreitzberg to write a book called The Elements of Fortran Style which tried to capture these recommendations for making comprehensible and therefore debuggable and maintainable programs. That work naturally led me down the path to say, “Were the recommendations that we were making legitimate?”, so the idea of running controlled experiments naturally ensued. Of course, we had to refine and transform traditional experimental psychology methods to fit this emerging new domain and that became an early challenge. I got guidance from an excellent psychologist named Richard Mayer who remains a professor at UC at Santa Barbara. So that early work focused on programmers as users, but by the 1980’s when interactive personal computers became available, it was natural to focus on that topic. The book I wrote in 1980 called Software Psychology was seen as a very strange idea by many people, but the publisher took it hoping to sell a few books. It became the selected book from the two Computer Science book-of-the-month clubs and suddenly there was an increased interest in this topic. By 1982, several of us organized a conference near Washington, DC on Human Factors in Computing Systems, hoping to draw 200 or 300 people. We were delighted that 906 people turned up, which signaled that there was a great interest in psychologically-oriented studies of programmers and computer users. By the following year the SIGCHI group was formed and so the idea of research topics on user interfaces, humancomputer interaction and human factors, became institutionalized in a wonderful way. The conference that we started continues as an annual event, drawing up to 3000 attendees. It’s a great satisfaction to see the growth of a strong academic discipline, but it’s still a struggle every day to promote these ideas in technical communities. Catherine Plaisant and I just published the 5th edition of Designing the User Interface; which tries to tell the story about this growing field with strong academic and professional interest.

Eugene Spafford: making a difference 2004

[A]: I really do not remember. I think it was when I was working on a project related to my PhD, and someone mentioned to me that I should be careful about what I claimed for my work (on fault-tolerance and security) because someone else might be building something on top of it that could be life-sustaining. I got to thinking about the responsibility incumbent on me, as a software designer, to do the right things in design and testing, and in being really accurate in what I presented. Then, as I looked around at what others were doing, I realized that too few people really understood the downstream consequences of what they did with computers. It became an important part of my worldview thereafter.