2006-05-02 Agenda and Notes

Weekly Meeting Agenda for May 2, 2006

Agenda

Review "Create New Course Site" context scenario mockups
Review design/development iteration roadmap
Decide on "agile" process and practices
CM Browser Update

Notes

May 2, 2006
Present:
Berkeley - Ray, Josh, Oliver, Daphne
Arizona - Duffy
Stanford - Marc, Daisy, Lydia

Mock-up Review for Creating a Course Site (see mock-ups on confluence site, http://bugs.sakaiproject.org/confluence/display/CM/Home)

General Comments
¿ Going to other sites directly from a site and or between tools from within the tools will be difficult in Sakai. Will require Glenn
o 1st iteration to end at site created but can start conversations with Glenn and whoever else.

Create New Course Site / "Available Course Sites"
¿ Course level and section level shown don't match up to how things are really named. These are meant to be place holders. May end up being configurable. The basic premise is that it look like the schedule of classes.
¿ How do the terms get chosen to display here? Duffy curious about the GetCurrentTerm. Suggestion to put the "Create New Course Site" in front of integrators.
¿ How is the "instructor of record" chosen? The idea is that only the "instructor of record" can assign a roster to a site for FERPA reasons. Josh suggests changing "Get Grader" to "Get Instructor of Record".
¿ Need another call in CM to facilitate the display shown on "Create a New Course Site". Duffy suggests we need something like "GetCurrentCourseThings" (gets the user in their role). Josh will look into this.
¿ Concerned about all the different permeatations if we allow configuration of site structure/mapping (Future iterations will likely allow dept. admins to do some customization of site structures by department). We won't allow every possible option. Users will be dept. admins so we'll want to keep it simple and just ask them a few questions in order to make decisions for them about site structures.

"Find a Course" (page 5)
¿ Decided to leave "auto-fill" functionality out of this iteration because of complexity in design
¿ Lot's of states we'll have to do checking on here.
¿ This doesn't allow for including several courses in one site like the "Available Course Sites" page does. Josh suggests rather than 'create site' we could say 'select" and then take the user back to the "Available Course Site" page.
¿ Don't really have the notion of departments. We don't currently have enough common understanding across schools to know how this should be displayed. Ray suggests: Department definition could be configurable and then we could ask the department type. Are options are:
o Replace flat view with hierarchical view
o Department = type
o Flat view for department and course

"Congratulations! Your course site is ready..." (page 6)
¿ Sakai cannot currently switch to another site. We'll need a helper tool.
¿ What about the title? Which course do you use to name it if they've included several in one site. We'll give them a default and then allow them to customize the title. Need to define these rules still.
o Duffy's use case, for "special topics" known by registrars office. This will need to be customized to the fit the "user-defined" name of the class.

"Home" (page 7)
¿ "Recent Activity" portlet is a placeholder. It will replace the current synopsis tools but be more of a "snapshot" on
¿ Professor is cinglular which may not be the case.
¿ We don't expect this page to be created as part of this iteration. It's meant to be more of a placeholder and a "what's coming".

Biggest hurdles of Agile Dev
¿ Depending on people outside of our team and big framework kinds of things. (Linking between tools within a site from the tool content area & switching between sites from links on the page). This will make it difficult to meet our 3 week iteration schedule.

Phone calls
¿ Stanford and Berkeley will take turns hosting the weekly calls. Berkeley will take the rest of May. Then back to Stanford for a month. Duffy will also check on Arizona's

Iterations
¿ Marc walked through the current iterations on http://bugs.sakaiproject.org/confluence/display/CM/Iterations
¿ Meeting for each context scenario to discuss where we are, new issues, reevaluate the order of the iterations, etc. This should happen ahead of the iteration....by a week?
¿ Design should be ahead of development at least one iteration.
¿ Test driven development is preferred by most on the team. There is some concern about whether there's time to do testing. Ray reminds we want this to be as light weight as possible and talks a little about frequent smaller chunks of work, tests, check-ins.
¿ Discussion of usability testing needs. Can we have a working click-through app to do user testing on? Depends what data or how much data we need.
o This is a different way of working by building out the UI first and not worrying about data. Historically, at Berkeley the back end gets built out and then the UI gets dropped on top of it.
o Need more discussion around the cost trade-offs between implementing a user-testable app (more development costs) and doing paper prototype testing (more design costs).

Status for Course Manager Browser
¿ Daisy will IM Josh to let him see how to access.
¿ Still work to be done but one case is complete that can be looked at.

TO DO's:
¿ Marc & Daphne to talk through what (and how) we'd like to do usability testing
¿ Need to talk about what agile principles / activities this team wants to embrace - Josh, Daphne (lead designer), Duffy (PM), Marc (PM). MARC TO SCHEDULE?
¿ Josh to create the missing method