Developing Wbt With The Addie M Isd Model
Posted on 23 Dec 2002
by J Haag (hermithaag)
Rated 3.89 (Ratings: 0)
- More articles in Site Development
Define Goals and ObjectivesWhen working as part of a development team, the first step in planning any web-based application is to define your goals and objectives. Without clearly stated goals and objectives, the project will continue past an appropriate endpoint. Work through the development process outlined here to refine your plans. A statement identifying 2-3 goals should be the foundation of your design. The statement should include specific strategies around which the application will be designed, how long the design, development, and evaluation periods will be, and specific quantitative and qualitative measures of how the success of application will be evaluated. Think about addressing these fundamental questions:
- What is the application supposed to do?
- Are these goals realistic? Are they possible?
- How does it accomplish its goals?
- What data does the application operate on, and with?
- How does the application communicate its action and interaction with the user?
Know Your Audience
The development team should always function as an active advocate for the users and their needs. The knowledge, background, interests, and the needs of users will vary from novices who need a carefully structured introduction to expert power users. Having access to a subject matter expert will be crucial to meeting the needs of the learners.
Design Critiques and Content Inventory
Each member of a development team will bring different knowledge, preferences, and skills to the project. Once an agreement has been made on the goals of the project, an agreement on the overall design approach for the WBT application needs to be established. The goal at this stage is to identify potential successful models in other Web sites and to begin to anticipate design problems from the user's point of view.
A content inventory is a methodical review of all material and content. This should be researched and collected before creating content you may find to unusable later on, and the information you glean from conducting this research is sometimes as important as the deliverable you create at the end.
This stage should detail the content and organization of the application. The team should have an inventory of all existing content, determine what content is required, and define the organizational structure of the site by drawing or sketching visual representations of the flow of the content by linking concepts to one another by creating concept maps. Once a content architecture has been sketched out, small prototyped parts should be built to test what it feels like to move around within the design.
PrototypesPrototypes are the best way to test navigation and develop the user interface. The prototype should incorporate enough pages to assess accurately what it's like to move from menus to content pages. Creating a prototype also allows the graphic designers to develop relations between how the site looks and how the navigation interface supports the information design. The key to good prototyping is flexibility early on: the prototypes should not be so complex or elaborate that the team becomes invested in one design at the expense of exploring better alternatives.
Design Specification or 'Style Guide'
In badly planned projects, 'scope creep' is the gradual but inevitable process by which previously unplanned features are 'added' - not always by request of the client, but after poor planning by the development team.
Content and content features are padded to accommodate each stakeholder group, major changes in content or site structure during application development are made, and more content or interactive functionality than you originally agreed to create is stuffed in. Changes can be a good thing, as long as everyone is realistic about the impact of potential changes on the budget and schedule of a project.The application specification document is the planning team's concise statement of goals, values, and intent, to provide direction for the development stage. It can be easy to lose sight of the original priorities, and to not know whether on any scheduled day whether the detailed decisions you are making actually support those overall goals and objectives. A well-written design specification is a powerful daily tool for judging the effectiveness of a development effort. As such, it quickly becomes a daily reference point to settle disputes, to judge the potential utility of new ideas as they arise, to measure progress, and to keep the development team focused on the ultimate goals. At minimum, a good design specification should define the content scope, schedule, and technical aspects of the project. The best application specifications are very short and to the point, and are often just outlines or bulleted lists of the major design and technical features planned.
Psychologists have known for decades that most people can hold only about four to seven discrete chunks of information in short-term memory. The way people seek and use reference information also suggests that smaller, discrete units of information are more functional and easier to handle than long, undifferentiated tracts. There are five basic steps in organizing your information:
- Divide the content into logical lessons
- Establish a hierarchy of importance among the lessons
- Use the hierarchy to structure relations among lessons
- Build the WBT application that closely follows the information architecture
- Analyze the functional success of your project
File Structure, Naming and StorageDuring the design and development process, the designers, developers, technical writers, programmers, subject matter experts, and quality assurance personnel handle numerous files of varying types. Creating a standard format for all folders and file names will make it faster and easier for all parties to identify and located the files they need.At a minimum, a file should include the name, and/or number of the course for which it was created, the module or lesson number, a description of the item, and a version/revision number. The names should be as intuitive as possible, so that developers and programmers can quickly and easily identify files without having to view the contents of each file to ensure they are using the correct file. In addition to standard file names and conventions, ensure that, during the development process, files are stored in a central location and accessible to the entire production team. Filenames cannot have spaces or special characters and should not be longer than 20 characters.
CHECKPOINT: Typical results or potential contract deliverables at the end of this stage could include:
- Detailed Design Specification
- Detailed description of site content: concept map, thumbnails, outlines, table of contents
- Detailed technical support specification: bandwidth requirements, multimedia plugins,etc.
- Proposals to create programming or technology to support specific features of the course
- An established file naming convention and centralized location for team production
- A schedule for implementing the design and completing development
- One or more prototypes of multiple pages or screens
- Multiple Graphic Design and interface design sketches or roughs
Establish Information Architecture - 'MVC Framework'
Information Architecture is the art and science of organizing information and interfaces to help information seekers solve their information needs efficiently and effectively, primarily within web-based environments. Information Architecture has three interrelated aspects:
- the use of graphic or multimedia design to facilitate communication; and
- the use of intellectual technologies, such as site and content organization, needs analysis, usability studies, metadata application, and
- programming to make an information interface or source easy to locate, comprehend, navigate and use.
The applications you produce can have a clean seperation between document structure, presentation logic, and behaviour -- all of which let teams focus on their strengths, instead of forcing designers to program, or programmers to design.
Upon completion of the information architecture and MVC Framework, team production can be invoked synchronously. If the interface to the rest of the program remains immutable, no one will care where the data originates (except, of course, the person responsible for the Model).This is the stage the project establishes its look and feel, as the page grid, design, and overall graphic design standards are created and approved. Now the illustrations, photography, and other graphic or audiovisual content for the application need to be commissioned and created. Research, writing, organizing, assembling, and editing the web application's text content is also performed at this stage. Any programming, database design and data entry should be under way by now. The goal is to produce all the content components and functional programming and have them ready for the construction stage. CHECKPOINT: Typical products or contract deliverables at the end of this stage could include:
- Content components, detailed organization, and assembly
- Text, edited and proofread
- Graphic design specifications for all page types: interface graphics for page templates, header and footer graphics, logos, buttons, backgrounds
- Detailed page comps or finished examples of key pages
- Graphics style guide or manual
- Interface design and master page grid templates completed
- Finished HTML template pages
- Illustrations and Photography
- Functional and logic components:
- Database tables or XML data sources completed, and programming interaction prototypes
This is the stage of the project where the bulk of the pages are constructed and filled out with content. By waiting until you have a detailed information architecture, mature content components, and a polished application specification you will minimize the content churning, redundant development efforts, and wasted energy that result from rushing to create pages too soon. Be prepared to refine designs as you navigate and discover weak spots and opportunities to improve navigation or content.
One of the defining principles of a web application is that it should provide all people, regardless of physical or technologcial readiness, with access to information. Web application design is intricately tied to accessibility design. For many organizations, providing equal access is institutional policy, if not a federal mandate.It is critical that the team validate designs and page templates and the content of the web-based training throughout the development process to ensure that the web pages are accessible to all users. Web-based designs should be validated at every development milestone to avoid time consuming and potentially costly revamping efforts. Your content can be made more accessible if you use Cascading Style Sheets (CSS) to style your pages.
EthicsAuthors of web content are viewed as having the same rights as those of other materials, and anyone who violates those rights could be subjected to penalty. Copyright is granted to the creator of a work the moment it is fixed in a tangible medium. Though a Web page rendered on a computer screen doesn't appear to be tangible, copyright is granted to Web authors upon creation of any single page. A page doesn't need to have a copyright notice in order to be protected by copyright law. As technology continues to evolve, the need for an appreciation of both information proprietors' rights and user privileges like "fair use" is expected to intensify. "Fair use" is the most well known and most important exception to the copyright owner's rights. The concept of "fair use" was established in the Copyright Law of 1976. It specifies situations in which copyrighted materials may be used without express permission of the copyright holder. The four factors that define "fair use" interpretation include: purpose, nature of work, amount and market effect. The definition and accompanying factors protects the creator by ensuring that the quantity of the work used is negligible, and of little adverse effect to the market for the work, and that, whenever possible, permission of the creator is sought. Unfortunately, the lack of intellectual property rights for the web and distance education has forced developers to produce course applications that hinge upon incorporating a distorted balance between copyright law and "fair use". Until new bills such as TEACH (S.487) are passed and amended to the Digital Millennium Copyright Act, or unless the scope of the "fair use" parameters are broadened to more specifically include the use of copyrighted materials on the web, then web applications and web pages will still be considered as publications and intellectual property rights will be applied as it would in any other publishing medium. Since copyright law is a bit murky when it comes to issues involving teaching, distance education and the like, obtaining permission is the only solution educators are presently given.
Testing should be done primarily by the development team. Only after the application has been thoroughly beta tested should you submit it to the QA (Quality Assurance) team for testing.CHECKPOINT: Typical products or contract deliverables at the end of this stage could include:
- Finished XML & HTML; All database or data source components in place
- Finished navigation link structure
- All programming in place and linked to pages
- Beta Testing conducted by QA
- All graphic design, illustration, photography, and multimedia in place
- Final proofreading of all content
- Detailed QA of database and programming functionality
- Testing and Validation of Accessibility features
- Testing of support procedures, comment forms, answering e-mail,etc.
- Archives of all site components, HTML, programming code, and any other development materials
All professionally designed web applications or web sites should meet at least the minimum standards for accessibility as defined by the World Wide Web Consortium guidelines. The W3C Web site contains extensive information on the details of how to make your web application reasonably accessible to blind, deaf, or other disabled users.Before version releases, 6.2 of Nescape and version 6 of Internet Explorer, web developers faced difficulties in implementing many of the W3C accessibility suggestions because the browsers previously did not implement newer technology standards like Cascading Style Sheets or implemented them inconsistently. Your content can be made more accessible if you use Cascading Style Sheets (CSS) to style your pages. With CSS-styled pages, users can easily apply personalized formatting to web documents. A page design using specific font colors and backgrounds, for example, presents a problem for users with color blindness: the contrast between the text and background may not be enough for the text to be distinguishable. If the colors are set via a style sheet, users can set their browser preferences to override your settings and can apply their own style sheet to the page instead. With CSS-styled pages, the user can transform web content into a format that addresses their requirements for accessibility.
One of the concerns many instructional designers express is about the reusability and context-free aspects of SCORM. As a best practice, one of the easiest ways to ensure the instructional integrity of SCORM content is to ensure that each SCO essentially becomes a stand-alone "lesson" or instructional unit.Since a SCO is intended to be inherently small, an SCO should represent a single instructional objective and all of the related materials and resources required to support that objective. All course learning objects and sharable content objects should be implemented in a test run before its release to its evaluators. This involves creating a content package, such as an ADL SCORM Content Manifest. Both the individual learning objects and the larger framework should be tested against the instructional design and technical criteria they were intended to meet. This requires a rigorous Quality Assurance (QA) period of testing and revision. It is essential to test content under a Learning Management System early in the process to isolate and resolve and communication issues. SCORM provides nine categories of metadata fields called elements. There are several subcategories in each field. This results in over 90 possible metadata fields. Since the metadata filed options are so numerous, a SCO SPECIFICATION might additionally be created to define which of these fields will be required for your projects and which fields should will be optional. All assets, SCOs, and content packages require metadata in order for others to search for and locate your content in a repository. Metadata should only reference one item, so if you have multiple versions or revisions to an item, each iteration should have its own unique metadata. You can accomplish this by using different unique identifiers or the version field in the Life Cycle element. The primary purpose of metadata is as a tool to enable those seeking assets and content relevant to their requirements to locate them efficiently and effectively. When creating metadata, always remember the knowledge base, search habits, and search vocabulary of those seeking your content, and develop metadata with these things in mind. This means including the most specific and descriptive terms possible. Since the developers and programmers will likely compile the metadata elements when they package the content, the application style guide should also provide a standard format, such as a SCO SPECIFICATION or a design form, for completing the metadata. It should also assign responsibility for defining the metadata fields. In most instances, the instructional designer or developer should define the metadata fields for the programmer in advance.
Testing should be done primarily by readers outside of the development team who are willing to supply informed criticism and report programming bugs, typographic errors, and critique the overall design and effectiveness of the application. Only after the application has been thoroughly beta tested should you submit it to QA for testing.
The three cardinal rules of Web-based training:
- Identify the technical limitations of learners' computers early in the process
- Design to accommodate the lowest common denominator
- Test the design early in the project life cycle
Life Cycle Maintenance
Most large organizations will contract with a web development group to create the initial application and to build all the pages in the first version of the application. Then they assume responsibility for the application, doing some or all of the maintenance for updating content as needed.Web development is an evolutionary process. As the development team arrives at the end of one project delivery cycle and embarks on another, it will be faced with a variety of maintenance issues. The first such issue is the need to update content. Wherever possible, the developer should provide access for the subject matter expert or final content manager to make these changes. These can be achieved by keeping content external to the presentation layer during development.