Skip to end of metadata
Go to start of metadata

A few points to keep in mind:

  • The screens are meant to be viewed in sequence (more or less).
  • Screens 4-4b show different states.
  • Screen 6 is the same as screen 3, but used to show the proper sequence. In other words, when a user updated his/her search settings, the system returns to the search result screen.
  • The cross-listing feature was omitted at this time. I have another screen where I include it, but am not thrilled with it so I didn't post it.
  • Going through this exercise has made me realize that the lightbox method for this flow is too restrictive. I think we need to open up the UI without the small window constraint. I'll probably be working on a version like that in the next round, but want to get some feedback on these screens first.

Enjoy!

11 Comments

  1. Two things:

    1) the notion of academic term selection is missing from P2 and P3, but showed in P4 and P4a.

    2) the columns in the list view in P3 and P6 should be adjustable for different institutional needs of course hierarchy/id.

    Otherwise, I like the new design looks.

    • Zhen
  2. Also, what's on the "Add a new class" tab? How would the "manually requesting site" fit into this?

    Thanks,

    • Zhen
  3. On 2. Am assuming that the "Classes" section (in grey) is conditional based on having selected a Course radio in the same screen? Also - site title will not be editable in some circumstances when a course is selected, now at least, but it may be editable in other cases.

    On 4. The "Search in" control is a filter, but it is a different type - might be good to distinguish it from the rest of the cascade.

    Since there is a bit of branching I find myself needing some sort of more abstract visualization of the flow to accompany the screens.

  4. An elegant refinement of the existing interface. A much better experience. But I wonder if it cuts through to the user's aims clearly enough in how it associates the tasks.

    It seems to me that what you're really doing when you "add a class" is to grant access to an enrolled set of people. But the language used doesn't make this clear, and the information presented doesn't support that interpretation (e.g. there's no way to quickly check that list of people along the way, to reassure yourself, say, that this is really the section you think it is).

    Speaking more generally, this process of mapping the registrar's enrollment units to sites seems fundamentally a "membership" issue, and not a site creation issue, so that linking sites with users inextricably (as it seems they are here - you're forced to do this as a necessary part of course creation) might not be the most helpful way to structure the tasks. For example, teaching assistants/tutors are often not reliably identified or recognized by SIS data, so that the creation process laid out above would also require you to go back after creation and add more people. Would it not be better to join all the "add people to this site" tasks together, as a unified user experience of connecting people to your site?

    Then, once you've done so, it's worth asking whether the unified "add people" stuff is a necessary part of initial site creation (it seems to be enforced that way here), or whether it's optional, and something that can be sorted out later.

    I think it is optional at the outset, and the one thing in this set of screens that militates against it is the automatic title. But I don't think an automatic title works in many cases (e.g. cross-listed courses, or if the instructor wants to lump all "lab sections" together and explicitly put "lab" in the title, etc.).

    I think you've got two basic halves to site setup: one is setting up the structure of the shared space itself (along with any initial content), and one is joining people to it in appropriate roles. I think we'll be better off if we treat that second region as its own area, optional for initial site creation. The way it's broken out now seems to assume the legacy UIs that the CM API was forced to work within, and I don't think we need to be limited to them.

    1. Let me attach a use case:

      "An adjunct faculty member is hired to teach some of the Introductory Physics sections a month before the term opens. But the course coordinator told her she's not sure how many sections will be assigned to her yet, let alone when they will be - only the text has been established. Still, the section instructor wants to get started on setting up her course site, since she knows that whatever she puts together will be appropriate for all of her sections of this course.

      The SIS used by her campus uses full course designations, and it's called "Introduction to Classical Dynamics I." This is pretty unwieldy in the interface, and no one calls it that anyway, so she just wants to set up a site called "Dynamics I," and set about fleshing it out. When she gets her specific assignment the week before term opens, she plans to connect those particular sections to it then. To start with, though, she just wants to add the course coordinator who is going to provide some initial materials. Two weeks later she finds and adds a teaching assistant.

      In the first week of classes another a lab instructor has to leave for family reasons, and she's scheduled to take on one of the lab classes in addition to her lecture sections. The lab materials, assignments, and grading are all rather different than the lecture material, even if the latter lays out some of the grounding concepts, but it seems to make the most sense to just create a new space for the lab-specific content, since she's not sure if she may end up having to teach more lab sections. So she creates a new site called "Dynamics I: Lab," and adds the one lab section to it."

    2. Another:

      A professor is going on sabbatical for a semester, but knows that he's scheduled to co-teach a seminar course starting in January with a colleague. Since he knows he'll be moving back in December, and preoccupied with both that and the holidays, he suggests that they get the site set up now and start working on it gradually while he's away. It's a new course, and it doesn't have a registration code or official title yet - that paperwork is going through the department and it will get settled at some future point. But those are details that can wait: right now he just wants to set up his course site so that over the next few months he and his colleague can collaboratively winnow through the material which will end up comprising the course.

    3. I agree w/Clay. An interesting case we did for the state of Ohio is adding the ability to associate sites with groups defined externally (hooking up AuthzGroups from an LDAP based provider). Right now the "UI" is the Sites tool, and plugging in group names to a site attribute, but ideally I think a parallel to the UI for attaching rosters would be part of both site creation & editing.

      Perhaps tied into site types - e.g. part of the site type definition being "support attaching external groups from XXX" where XXX is a registered provider or source. I could see a number of scenarios for institutions want to allow only officially attached groups to be created for say Course sites, or maybe University Committees, or other sites.

      I can also see where overloading the term "class" to represent both the site (content?) and the members might be confusing – is "class" a physical object in Sakai? "Roster" was the term we used at Rutgers for classes, and that seems to be in fairly common usage. Maybe "Member List" as a generic term? or "Groups"?

  5. I like it. However, I agree with Nathan's assessment that the lightbox may be a bit too constricted for this sort of operation. Also, for localisation purposes it would be useful if UI code for the "new" Worksite Setup is segmented in a way that allows for localised versions of the "add courses" part of the wizard. In Sakai 2.5 we today have an entirely different UI from the OOTB one for selecting courses/sections as courses at our institution do not fit the course-section paradigm very well. C f screen shot.

    1. In the notes page, John added this comment to the Design Reqs Summary:

      "Finally, Cambridge would prefer the 3 part course identifier be handled more as optional metadata than as a central data concept as we do not use this system (although Peoplesoft is introducing the concept to the campus)."

      I think this refers to the same UI, which is not currently configurable for different ID structures.


      1. Currently you can configure that by implementing some Java code – at Rutgers, and for some projects I've done for other groups for instance we collapsed the entry to a single text-field. I think it's a useful concept to have in terms of quickly getting a handle to a specific group – though a cleaner way to configure what that input looks like would be nice.

        e.g. printing out ID numbers in a list, or in an email and being able to paste them into a box or on a list of rosters is a nice benefit.

  6. Thank for all the feedback guys. I'm sending out an email shortly that summarizes my thoughts and migrates this discussion to two other confluence pages. Think of it as taking one step back and two forward.

    Please look for the email. Also, in case you miss it, here are the links:

    http://confluence.sakaiproject.org/confluence/x/fQDJAg

    http://confluence.sakaiproject.org/confluence/x/ggDJAg