Project Builder Wizard End User Design Tools By: Cortney Germain, Matthew Hung & Mark Lewis Prazen

Statement of Problem  Designing a project builder aid that interacts with a student researcher and embodies knowledge of his/her teacher-mentor to assist the student in framing the problem and solution spaces. What avenues of investigation are plausible alternatives for a student researcher given the general problem space of interest? Are previous experiences in the repository of any potential value as suggestions of possible ways to approach the problem or solution space?

Why a Wizard? Project Builder is powerful; but a complex tool for the domain expert to master Use requires technical scribe Investment deemed to have long payback Inhibits interaction with tool Interaction indirectly with PB thru wizard Investment decision becomes less crucial Tool is learned on demand Knowledge and KN processes (domain and system) are not widely understood or disseminated Domain process logic is a black box Little reflection on things not known Not matched to short time horizons- incre- mental imprvmt slowed Domain process logic is malleable Reflection is an active process Atmosphere more conducive to PB use and learning IssueCurrent SituationSituation w/ Wizard

Beyond Couch Potatoes (Fischer)  Designer - a person desiring an active role in a project of interest with the opportunity to contribute in some personally meaningful way.  How to make learning & knowledge public & able to be shared - moving beyond the black box  “……future of how we live, think, create, work, learn, and collaborate is not out there to be ‘discovered’ – it has to be invented and designed.” - wizard opens possibilities; promotes understanding

Linkage between DLC & EUD Tools  Design: Importance of EUD design tools as bridges to awareness DLC is a showcase for such tools and their application to real world challenges - even internal ones Intermediate stable components  Learning: Exposed visual processes foster understanding Learning on demand  Collaboration Tools that can be “opened up” invite discussion Open tools encourage creativity and are more susceptible to tinkering by students; Closed tools viewed as “given”

Design Philosophy  Visually promotes understanding of the logic defining a particular problem domain  Simple to make changes in the wizard to reflect new understanding or correct misunderstandings  Students build on each other’s ideas on a common topic guided by the mentor’s leadership  Not closed; invites collaboration, knowledge sharing, and creativity

Design Challenges  What should be in the wizard and what is not What is in wizard as opposed to PB What is in wizard and left to other processes/interactions  Decision tree framework Easily understood by wide audience & programmable Less applicable to fuzzy problem space  Frame problems so that creativity is not stifled  Tone of the wizard given wide audience  How to prep researcher for data input to simulation

Design Choices  Decision tree structure to appeal to visual cues and easy understanding of logic  Keep tool distinct from yet integrated with project builder  Tool should be able to query PB repository  Tool will focus on guidance to resources and not “the answer” …….. maintains creativity  Progress indicator shows steps taken, current step, and future steps  Visual Design Language

Scenario Walkthrough  Wizard guides the student researcher to find the research topic  Wizard guides the student to build a simulation  Tool provided for mentor to tailor the logic of the Wizard

Refine Research Topic  Wizard gives the appropriate prompt and thoughtful questions and recommendations to help the student researcher to articulate his research topic  Wizard suggests the possible resource related to his topic  Iterative process (move backwards in logic)

Design Simulation  Design by Example Build above the previous project simulation related to researcher’s topic  Visual Design Environment: AgentSheet based design language Drag and Drop Define the behavior of object and interaction between objects What you see is what you get

Wizard Tool  Give control to the researcher/mentor  Design by templates  Integrity check mechanism Localize the Error Explain the Error Learn from the Error

Wizards as Design Tools: Some Do’s and Don’ts  Minimize download time  Provide additional help  Inform users of progress  Indicate required fields  Limit navigation options  Summarize wizard data  Unclear purpose  Too many screens  Long wizard screens  No alternatives  Technical jargon  External tasks

Wizard Limitations  Can describe or possibly help user describe: Problem density Descriptive issues or characteristics (provide resource lists)  Will have difficulty in areas such as: Problem intensity measurement Concurrence Fuzzy thinking …….. Decisions that can’t be framed in a discrete set of choices

Possible Issues to Consider 1: Tool becomes too mechanical of an experience 2: Loss or absence of variety 3: Design boundaries are bridged ………… either performance degradation ensues or creativity is compromised 4: Tool tries to replace the expert 5: Tool isn’t deemed useful; doesn’t provide a process for driving focus to a narrower problem space 6: Experts can’t be persuaded to participate or the process by which they mentor cannot be captured in our framework …… it is too fuzzy or indeterminate

EUD Reflections  Complexity to leverage to generalized environment vs. Flexibility to appeal to masses Graphical features Standard design features Some aspects remain domain specific  Freedom to Design vs. Need to Control Open Environment Amenable to change Version control a community decision?  Motivation to Learn Learning on Demand Provide contextual knowledge Allowance of Creativity

A Phased Approach to Wizard Development  Active Design  Access to Process and Shared Understanding  Simple Scenario for Proof of Concept  Generalization/Customization  Community of Learners - Need for Data  Leverage the Experiences of Others

Future Wizard Features  Will the wizard learn (about the pattern of the researchers, about the problem domain)  Will it learn enough to mediate the interaction with the researcher  Can it sift the database for recom- mendations to a new researcher’s needs