Grad Tools

1. Grad Tools Richard Ellis University of Michigan rwellis@umich.edu

2. Introduction • “What is required of me?” • A new tool was designed and built to answer this question, • In the context of the Collaboration and Learning Environment. • See “Supporting the Dissertation Process with Grad Tools” distributed at the session.

3. Doctoral Degree Navigator • Merging requirements of • An Academic Group • Rackham Graduate School (Ph. D., Ed. D. (Education), Arch. D. (Architecture), Ph. D. in Music) • Its Academic Programs, e.g., • ASIAN LANGUAGES & CULTURES • 92 others • Their Fields of Study, e.g., • Asian Languages and Cultures: Buddhist Studies • Asian Languages and Cultures: Chinese • Asian Languages and Cultures: Japanese • Individual students and faculty committees

4. Overview • What the tool looks like, for those who haven’t seen it, • How Grad Tools is being used, and • The re-design for Sakai, and what that looks like.

5. Grad Tools in CTools • Grad Tools is a collection of selected tools on three Grad Tools site types. • Student site • Department site • Graduate school site

6. Routine Administrative Tasks • Defining official steps and prerequisites • Customizing by adding • Recommended steps • Official department steps • Links to library services, forms, etc. • Marking steps complete • Viewing students’ progress • Administrative staff • Dean • Faculty

7. Data Management • Official steps may be tagged as “auto-validated”. • A step’s auto-validation id identifies the data and business rules to apply in updating step status. • Sakai’s data is synchronized with institutional data using file upload. • For matriculation, new checklists are created for incoming students by loading their data. This is done using interactive batch submission to Quartz. • Codes that connect a student to an academic program are maintained using an editor in the upload tool. • For graduation, the students who have graduated are removed using the upload tool.

8. Helper Tools • Upload Extracts • Worksite Setup • A graduate student can create a Grad Tools type site in Worksite Setup. • /site/!gtstudent and !gtstudent templates contain the tool and role configurations. • Announcements • Batch job reports are posted as announcements. • Retroactive step changes (when “Apply this change to all current students” is checked), and • Data upload. • Email • Job reports are also sent to site participants. • Resources • A “snapshot” of the checklist is written to the student’s Resources area when a student graduates.

9. Grad Tools in Use • As of October, 2006 • 1121 of 4552 active students are using it. • Users/Active ~25% • 265 have graduated having used it. • Top 12 reasons to use Grad Tools

10. Top Twelve Reasons To Use Grad ToolsMark Clague, musicology • 12. USE CHECKLIST to track your progress to degree and official status at Rackham. Checking off these items can help to keep you motivated and help mark your progress. You can add custom items to the list. • 11. USE GRADTOOLS to manage your dissertation committee and keep them informed and engaged with your work. • 10. USE GRADTOOLS as a master site for your entire graduate career, archiving final versions of all seminar papers, pdfs of influential readings, professional correspondence, grant applications, etc. • 9. USE RESOURCES FOLDERS as a remote archive for dissertation word processing and research files that are safe backups and accessible from any computer via the Web. You can also catalog important research links or upload primary documents. • 8. USE EMAIL ARCHIVE or ANNOUNCEMENTS as a record of official correspondence with your committee. • 7. USE SCHEDULE as a time management tool to track dissertation related deadlines and share these targets with your committee. (Avoid putting personal items in schedule. Use worksite schedule for this and merge GradTools schedule into your master calendar.) This scheduling process also helps you to set goals and priorities. Think beyond the dissertation to the job search by planning to present chapters at conferences or to publish work as journal articles where appropriate. • 6. USE THE HOMEPAGE to keep your contact information current and available for your committee, especially when you are traveling for research. • 5. USE THE DISCUSSIONS feature to create a research diary, dissertation blog, new ideas, big questions, or freewriting area in which you explore your original thoughts and ideas. • 4. USE DISCUSSIONS to invite feedback and comments from committee members of drafts stored in the RESOURCES folders. • 3. USE RESOURCES as a professional tool to store recent résumés and links to your activities, so that your advisors have the ammunition they need immediately at hand when writing recommendations. • 2. USE GRADTOOLS as part of a Dissertation Support Group Project Site that connects you to a group of 3-4 graduate student colleagues for social support and safe intellectual feedback. The project site can be a powerful collaboration tool. • 1. USE GRADTOOLS as a thought structure to consider and challenge your own working methods. Its flexibility demands that you customize it to work best for your own style. To do that, you need to know your working style. • Three Reasons Not To Use Grad Tools • 3. Because it’s there. • 2. To force your committee chair to do things your way… • 1. Because you’d rather goof around with technology than write something.

11. Scope of a Navigator • Doctoral degrees @U-M • But with a relationship to • Other degree programs @U-M • Graduate programs at other institutions • Issues of time to program completion & attrition • Flexible learning paths with assessment of clearly defined outcomes • Competency-based curricula • A “readiness calculator” • Other “What is required of me?” scenarios

12. The Sakai Checklist • Generalizing the model and tools • Easy user configuration of • Merging of steps • Attaching a leaf (recipient) to a branch (checklist) • Flexibility in connecting to institutional data • Data, format, business rules per checklist • Request handler • Registering request handlers

13. The Object Model • Checklist • has ordered Sections • Section has ordered Steps • Step may have ordered Prerequisites • Recipient’s Path • has Steps from Checklist • Step has Status • Step may have auxiliary text • Actors carry out, Approvers mark step complete

14. Merging Steps • Like reporting structures, a tree structure of arbitrary depth. • Create a Blank Checklist. • Share the Checklist. • Create a New Checklist based on that Checklist.

15. 1. Start a Blank Checklist

16. 2. Add Actors

17. 3. Add Sections

18. Grad Tools Sections

19. 4. Add Steps

20. Grad Tools Step

21. Optionally, Add Hyperlinks

22. to Library Services, Forms, etc.

23. Until You’re Done

24. 6. Share the Checklist • Access to checklist regardless of the site on which it was created. • “Sharing” creates a realm for the checklist that contains its permissions. • Permissions are holistic with respect to a checklist and workflows. • This part of security is based on a checklist reference that identifies the webapp and checklist.

25. 7. Start a Checklist Based on a Shared Checklist

26. 8. Title it

27. A Child Checklist is Created

28. Attaching a Leaf to a Branch • The checklist tree has a root checklist and branch checklists. • Creating a Recipient’s Path requires “attaching” a Recipient to a Checklist. • To do this a Recipient needs to be mapped to a type of Checklist. • This is done using the codes editor in the Checklist Data Manager tool.

29. Mapping Field of Study to Academic Program

30. Connecting to Institutional Data • Each checklist potentially requires its own data provider. • Using Controller Pattern IoC approach • Request handler • Registering request handlers

31. Request Handler • Checklist Data Manager tool requests that institutional data be used to update recipients’ progress. • A controller identifies the type of Checklist whose recipients’ status is being updated. • The controller selects a request handler bean that is specific to that checklist. • e.g., RackhamDoctoral bean is specific to the checklist of the Rackham doctoral student.

32. Registering Request Handlers • Components.xml <!-- add checklist data handlers where key = checklist uuid, bean = handler --> <bean id="org.sakaiproject.checklist.api.Controller" class="org.sakaiproject.checklist.impl.DefaultController" init-method="init" destroy-method="destroy" singleton="true"> <property name="requestHandlers"> <map> <entry key="eaba7c65-9ada-41f7-006a-b6ec8be8d1c7"> <ref bean="RackhamDoctoral" /> </entry> </map> </property> </bean> <bean id="RackhamDoctoral" class="org.sakaiproject.checklist.impl.RackhamDoctoral" />

33. Set Up • Insert actors icons in a chk_actors table in the db. • Auto-ddl creates a chk_lock table for Quartz long-running updates. • If you like, use an optional “auxiliary eid” when displaying recipients. • Set up templates and registration files. • /checklist/c authzgroup template for checklist authzgroups. • Site and realm templates, and sakai.properties properties, for Worksite Setup, if specific site types, such as Grad Tools sites, are used. Grad Tools site types are registered in selected tool registration files. • components.xml Hibernate .hbm.xml’s and beans for auto-validation • sakai.checklist.xml • <configuration name="sections" value="5" /> • <configuration name="autoValidationIds" value="12"/>

34. /checklist/c

35. Using tool, customize actors

36. for the type of checklist

37. Status • Active? • Most definitely! (Just me.) • Michigan is migrating to these Sakai tools. • Code will be available shortly (short //TODO list) • Interested? • https://source.sakaiproject.org/contrib/checklist • gradtools@umich.edu • http://gradtools.umich.edu • Questions?