Effective Web Instruction, Chapters 5 and 6

SUMMARY

Chapter 5, Building a web prototype

In Chapter 5, Frick and Boling have us moving the prototype from paper to the computer for usability testing to see if the design and format make sense and to see if the course will work.  The authors remind us that if we are going to find that a web-based solution is not the right answer, we would like to find that out as soon as possible.  This chapter is mostly devoted to software requirements for getting a course up and going on a web server so that clients can get the course materials.  They start by discussing the fact that the web runs on the internet, and that the net is made up of computers (web servers) talking to other computers (client computers with web browsers).  Web servers and client browsers must be able to deliver and display files that contasin HTML and images in JPG, GIF and PNG formats as well as a wide assortment of other programs such as PDF, RTF, MP3, RAM, etc. 

An important fact is that “A Web server just fetches a page, delivers it to the client (Web browser running on another computer hooked to the Internet), and then forgets about that client - sort of like a computer with amnesia.”  Because of this the designer must design and build (program) transactional capability into the programming.  They offer several options:

• Create your own plug-in or player that does the interaction – or purchase one; eg., NETg (Skillsoft, ColdFusion, and MS .NET.)
• Include scripts in the HTML files – Scripts can be provided Server side or client side.  Client-side scripts are normally included in an HTML file or downloaded with the HTML (similar to image files), and then the user's Web browser interprets and runs the scripts. Server-side scripts are executed by the external computer host and the results are sent via the Web server as standard Web pages to the user.  Java Script, JAVA, Perl, and PYP are the most commn scripting languages used and all require some programming skills

Another major limitation to the web is that at present none of the scripting languages will support natural language dialogue – you can’t talk to the computer and it can’t talk to you.  As a result other methods of communication have to be used, all of which have their own limitations.  Samples include

• Web tools such as e-mail, electronic discussion boards, and instant messaging systems
• Web-based teleconferencing
• Web-based videoconferencing

A good quote from the authors:  “The old-fashioned classroom, where students and a teacher meet face-to-face is actually pretty efficient for natural language dialogue. Instructors don't need to repeat themselves as often, and most of us can talk faster than we can type.”

Other Types of Web Solutions

The following can be used as stand-alone solutions, or intermixed.

  Electronic Documents shared with the students that contain No Internal Hyperlinks

• E-mails with attachments
• Course Delivery tools – created or purchased
• Home-brewed delivery Systems

  Electronic Documents shared with the students that contain Internal Hyperlinks

• Create hypertext so that documents have internal links to other documents
• Requires a Web editor such as Dreamweaver.

   Transaction with Students with Teacher and other Students as Source of Feedback

• Requires discussion boards, chat, instant message systems
• News Groups
• The course delivery systems mentioned above have built-in discussion boards, and you can rely on stability, privacy for discussions, and support
• Chats, Chat Rooms and Instant Messages (IMs)  (Chat is synchronous, meaning that you need to be working together at the same time. This can be a disadvantage, particularly as students are in different time zones in other parts of the world.)

   Transaction with Students with Computer as Source of Feedback

• Multiple-choice responses via hyperlinks
• Web forms
• CourseBuilder
• Web Froms and PHP or Perl
• Games, simulations, adaptive instruction, and virtual worlds

Templates

Commercial Web development tools such as Macromedia Dreamweaver allow you to build templates – a template includes parts that are don’t change from page to page, and place holders for the content that does change.  The main advantage of a template is that it can greatly speed up the development process for prototyping, and once developed allows you to focus more on content.  Templates also make global changes to be accomplished easier and faster. 

Programmers can also develop custom templates which provide even more flexibility.

Creating the Prototype Rapidly

The first time around, the goal is to develop the prototype as quickly as reasonably possible.  The rapid prototype does not have to be final or smooth, but should provide a good representative sample of the final product for review and approval.  The process for the web prototype is the same basic process as used for the paper, except now we are using computers.  If problems are encountered, additional prototyping may be necessary.   

Chapter 6, Assessing and maintaining the site

This chapter deals with accomplishing Bug Testing (Technical Testing) before delivering the final product to the customer/end user.  Bug testing is a 3 phase process that is linear, with each stage being completed before beginning the next phase.  It is also iterative, in that it should be repeated until the product is complete and ready for delivery.  Very important to Bug Testing is that everybody needs to understand that the design should be locked and that now the testers and fixers are looking to find and fix quality and technical issues, and not to change design elements.

Phase I Testing – It is recommended that the Phase 1 Testing be done using checklists that identify the features to be tested and the locations (pages) where the features can be found.  Problems are documented on a Bug Report that is then used for Phase 2, Fixing. 

Phase II Fixing – When doing Phase 2 Fixing, it is very important that all Phase 1 Testing stops or document configuration control problems can occur which normally means unnecessary rework.  (I can attest to this, as can most developers.)  The bug report should classify each problem as to its seriousness and impact on the final product, something like the following:

     Priority 1 – Critical: must be fixed

     Priority 2 – Important: should be fixed

     Priority 3 – Good to fix: would make the overall product look and feel better

     Priority 4 – Nice to fix: only fix if schedule and budget allow. 

Often, priority 4, and maybe even priority 3, items may be rescheduled as a result of schedule or budget concerns.  A priority 1 problem would NEVER be rescheduled or put off until later.

Phase III Regression – During Phase III, the testers repeat Phase I Testing; all of Phase I should be repeated, do not test only the problems or bugs fixed as a result of the original test.  Only when no new Priority 1 or Priority 2 problems are found should the product be considered for delivering.  And, while we would really like to keep repeating the cycle until all problems are fixed and the product is 100%, this is often not practical by time or schedule. 

DISCUSSION

Chapter 5 was a particularly interesting chapter for me because I am not a programmer or media person, and anything I learn in this arena is good info for me for making good decisions.  For instance, what is the difference between a Course Delivery Tool (OnCourse and BlackBoard) and a Learning Management System (LMS) (ThinQ, SABA, Atlas Pro ROCCE, etc)?  Also, when discussing creating templates using commercial software tools (DreamWeaver), is this the same thing as a Learning Content Management System (LCMS)?  I know what an LMS and a LCMS are; I am trying to place them into the discussion here.  I view Dreamweaver as a type of LCMS.  Would you agree?

There was no discussion of Sharable Content Object Reference Model (SCORM) standards here (or in any other class I have had at IU).  Is anybody else working with SCORM and the ADL Co-labs?  I think IU had or has several faculty members active with the ADL Co-labs (e.g., Curtis Bonk.)  Do you think SCORM could become the future standard for e-learning content, or is it pie in the sky wishful thinking?  What about Section 508 of the American with Disabilities Act (ADA)?

I also enjoyed Chapter 6, but because it is what I do and I am familiar with the process.  A couple observations from my experiences:

1. Save time and resources for fixing things that the client finds.  No matter how much Bug Testing you do, your customer is likely to find things they want fixed and you need to have the budget and time left to make the fixes.  Even if you think a bug is preferential, the customer may see it as technical, and the customer is always right.  (NOTE:  In addition to the priority codes listed above we also classify all bugs as either Technical (T), Editorial (E), or Preferential (P).  We strive to fix all technical and editorial comments/bugs.
2. Once bug testing commences, everybody has to understand that the design is locked.  It’s inevitable that somebody is going to find a better way to do something.  Too late; save it for the next change or revision as long as it does not create a technical or editorial problem with the course. 
3. Configuration Control is always a problem.  I would recommend you ensure you have a good way to maintain document/file configuration control and file naming conventions.  I normally assign one person as the cyber librarian,  This person is responsible who is the sole person responsible for configuration control and ensuring file naming conventions are followed.  This person also starts and stops all Testing and Fixing activities. 
4. One last question:  Bug Testing – formative or summative evaluation?  The last formative evaluation or the first summative evaluation?  I personally think it is the last formative evaluation.