Project Builder Wizard

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

2. Statement of Problem • How can the project builder be supplemented to better allow it to interact with a student researcher and embody knowledge of his/her teacher-mentor to assist the student in framing a research problem and potential solution spaces. • What avenues of investigation might be plausible alternatives for a student researcher given interests? • Are previous experiences available as suggestions of possible ways to approach the problem or solution space?

3. Linkage between EUD Tools & DLC • Design: • Importance of EUD design tools as bridges to learning • DLC is a showcase for such tools and their application to real world challenges • Could be available as an ongoing project for students • Learning: • Visual processes foster understanding of domain logic • A wizard facilitates 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 “givens”

4. How Can Value Be Added • Designer has some domain knowledge – but needs a guide through the problem space to find one suited to personal interests • Designer will have motivation issues learning the tool …………. too complex; too technical • Mentor has process knowledge but might not be able to generalize it into a coherent process • Mentor may have limited availability .…… can a surrogate stand in on occasion

5. Why a Wizard Issue Current Situation With a Wizard

6. Design Philosophy • Visually promote understanding of the logic defining a particular problem domain • Make changes in the wizard simple to reflect new understanding or to correct misunderstandings • Allow new ideas/paths to be added …….. problem spaces of interest that can be explored/added • Stay open; invite collaboration, knowledge sharing, and creativity

7. Design Challenges • What should be in the wizard and outside • What is in wizard as opposed to PB • What is 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

8. Design Challenges (2) • How best to reflect a mentor’s philosophy without compromising the creativity he fosters in his students • Comparisons can be quick and long lasting • How do you promote concepts in a wizard tool like descriptive or evaluative thinking without diluting their full meaning?

9. Design Choices • Decision tree structure to appeal to visual cues and easy understanding of logic • Keep tool distinct from, yet integrated with, project builder • Provide thoughtful messages on screens at key junctures • Query to PB repository for past relevant approaches • Focus on guidance and provoking aspects …. to resources and not to “the answer” …….. maintain creativity • Progress indicator to track steps taken, current step, and future steps • Visual Design Language features

10. 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

11. 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)

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

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

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

15. 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

16. 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

17. EUD Reflections • Complexity vs. Flexibility • 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 • Fosters Social Capital • Allowance of Creativity

18. A Phased Approach to Wizard Development • Access to Process Knowledge • Simple Scenario for Proof of Concept • Testers – Maybe Mentors, Not Students • Generalization/Customization • Value of More Data ??? • Leverage the Experiences of Others

19. Future Wizard Features Will the wizard learn (about the pattern of the researchers, about the problem domain) Can it effectively mediate the inter-action with the researcher ongoing Can it sift the database for recom-mendations to a new researcher’s needs