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.
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.
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:
CHECKPOINT: Typical results or potential contract deliverables at the end of this stage could include:
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 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: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.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: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:
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.