MOATS Project
Plan
Version 2
April 4,
2004
1.
Project Goals
a.
Audience: Instructors and instructional support staff
b.
Domain:
Encompasses the transformation of instructional design and pedagogical
practice through enhanced engagement with instructional design and learning
science research in pedagogical practice and the effective use of technology to
promote learning.
i. The instrument is envisioned to
provide an instructor or instructional support person, with a means to a
solution based along a continuum of the inputs concerning the instructor’s
goals, preferences, and/or key instructional variables such as learner
characteristics, subject matter content and learning task characteristics, or
other contextual variables such as course level, class size, and teaching
philosophy.
ii. The instructor or instructional
support person should be able to view and select a solution along the array if
the primary solution is not the most desirable.
iii. The selection is based on the
input pattern of variables and should
be stored so that popular selections are immediately available.
c.
The instrument is a design experiment that will suggest
the three dimensions of preferability be attended to when selecting an
instructional strategy. The major methodological concern in Instructional
design theory is preferability rather than validity. The ability to choose
which method is better than another method for achieving a desired outcome is
preferability and is based on the three dimensions: effectiveness, efficiency, and appeal (Reigeluth & Frick,
1999).
2.
Design Team members ( +1/4 FTE each: programmer, DB,
Web-designer, Flash, graphic artist)
a.
Jean Kreis
b.
Wayne Brent
3.
VALA Team
a.
Jenny Franklin
b.
Jan Knight
c.
Garry Forger
4.
Core Team Members
a.
Design Team
b.
VALA Team
c.
NLII Staff
5.
Stakeholders –(UA & NLII)
a.
Design team members
b.
Core team members
c.
LTC & CIO
d.
NLII Staff
e.
Bridging Core Team (6 people skilled in T&L and COP’s)
f.
Select UA Faculty
g.
Bridging Community (Advisory Group)
6.
Budget
a.
?
7.
Development plan outline
a.
Development plan to be completed by 4/16/04
i. To
include programming information/adjustments
b.
Design team will use a functional requirements design
approach
c.
Establish specifications for MOATS
d.
Develop a storyboard
e.
Establish the algorithm
f.
Design team will perform acceptance testing using the
personas, a set of scenarios, and the theory-vocabularies, followed by
structured testing by core team, general review by advisory group.
8. Specifications
for MOATS
a.
Refine members, roles
b.
Refine purpose, domain
c.
Define need and activities
i. Related
to array - The array should be displayed along a continuum based on the inputs
concerning the instructor’s goals, preferences, and/or key instructional
variables such as learner characteristics, subject matter content and learning
task characteristics, or other contextual variables such as course level, class
size, and teaching philosophy. (though this will be related to the algorithm)
ii. Related
to ontology
iii. Related
to algorithm – possibilities to examine
1.
Ax + Bx + Cx + Dx = Adjust as necessary
2.
word position comparison between theories
a.
(ex. “Active” & “engaged”)
3.
Series of comparisons (if, then, else)
iv. Related
to interface
v. Related
to project teams and design plans
vi. Related
to instrument management as it continues after development
vii. Needs
for resources, programming notes, explanatory texts
d.
Technology requirements and functionality (requires input
from programmer)
i. Expected
size of database, accounts, user population
ii. Customizable
–
1.
How will we be
able to add to the storage of design theories and instructional strategies
(vocabularies)?
2.
Will they have to go through a vetting process?
3.
Will there be a wizard walking them through the process?
4.
Will the additional strategies only be available to the
user who added them?
iii. Account
management (specify requirements)
iv. Design
requirement open access vs account storage
9.
Evaluation Plan
a.
(TBW)
10.
Recommendations for next steps
a.
Technology choices
b.
Development team creation
c.
Personas & Scenarios created
d.
Algorithm developed
11.
Deliverables and Milestones
a.
Planning phase (1/5/04 – 4/16/04)
i. Development
plan – attached – to be refined with technical input
ii. Design
proposal – attached
iii. *
Evaluation plan
b.
Design / Prototyping / Testing phase (4/19/04 – 6/230/04)
i. Personas
and scenarios - 4/23/04
ii. Functional
specifications - 4/30/04
iii. * Design
documentation – to be revised, refined
iv. Acceptance
test report 4/30/04
v. Recommendations
4/30/04
vi. *
Prototype – 6/15/04
vii. Usability
testing – 6/15/04 – 6/28/04
viii.
Usability test report – 6/30/04
ix. Recommendations
– 6/30/04
c.
Design / Modifications / Revisions ( 7/1/04 – 8/20/04)
i. *
Prototype Revision– 7/1/04
ii. Usability
testing – 8/8/04 – 8/13/04
iii. Usability
test report – 8/20/04
iv. Recommendations
– 8/20/04
d.
Implementation (8/20/04 – 10/30/04)
i. Documentation
ii. Training
materials
iii. Resource
library set up and seeding
iv. Feedback
mechanisms
e.
Formative Evaluation (4/30/04)
i. *
Formative evaluation report
ii. *
Recommendations
f.
Summative Evaluation (10/22/04)
i. Summative
evaluation report
Reigeluth, Charles, & Theodore Frick. “Formative Research: A Methodology for Creating and Improving Design Theories.” Instructional Design Theories and Models: A New Paradigm of Instructional Theory. Ed. Charles M. Reigeluth. Mahwah: Lawrence Erlbaum Assoc. Inc,. 1999, 633-653.