Continuing On…
Everything is in full swing, and now we’re really beginning on the core EMS functionality. There are a lot of subject choices and content available for the next several blogs in this realm. I’ll focus on workflows around assignments, and grading functionality to start in this blog. Then we’ll likely move on to scheduling of projects, managing a variety of documents with SharePoint and OneDrive for Business, and security over the next following posts.
Let’s start with Assignments and Grading which allow us to cover an increasing path of complexity from document libraries to Provider Hosted Apps delivered through Azure as we implement upcoming modules.
Student Document Structure and IA
Imagine the following example document IA:
What I’m describing above is:
- There are two Document Libraries with Document Sets enabled: Student Assignments and Submitted Assignments.
- Each Document Library has its own document specific Content Types to go along with OOTB Document Set and Document. For example:
- The Student Assignments Library will hold Student Assignments Document Sets which contain Student Assignments documents.
- The Submitted Assignments Library will hold Submitted Assignments Document Sets which contain Submitted Assignments documents.
- Etc.
Thus, within each Document Library, you will find individual Document Sets for each student. The Document Libraries and Document Sets are configured so that students can only add one logical document type, “WMC EMS Student Assignment” (a.k.a. Student Assignment).
The action of adding a new assignment is the beginning of its lifecycle in the grading process. Let’s see how this document continues to move along – eventually receiving a grade.
Assignments and Grades
As covered in previous posts, Assignment documents are part of the broader set of documents that teachers and students need to manage. Assignment documents in this SharePoint EMS are definitely the most interesting though in that they:
- Are shared between teacher and student.
- Are governed by a moderate-to-high level set of security requirements.
- Are date driven and have a repeatable/predictable lifecycle.
Assignment documents also crack the door for us to start covering student grading and how that’s managed.
The lifecycle for these assignment documents in the basic/classic sense is straightforward, and I imagine we’ve all lived through this:
- A student starts a document (math problems, thesis, essay, etc.) knowing it’s due at some date in the future.
- When s/he completes the document, s/he turns it into the teacher sometime before that due date (or otherwise faces late penalties).
- After it’s submitted, the teacher assigns a grade which is fed into the overall average of grades.
Let’s cover this basic grading scenario process flow for Assignment documents in SharePoint.
- Students will be working on their Assignment within the appropriate document set of the Assignments document library. You just saw that above – John adding a document to an OOTB SharePoint Document Set.
- When they finish the Assignment, students will take a significant but simple step to submit the Assignment document to the Teacher.
- At that time, a copy will be written to a “Submitted Assignments” document library to which only Teachers have permissions.
- Teachers then specify the grade of the Assignment document.
- Students can’t change the grade but need to be able to read it.
- Students can’t modify the submitted version of their homework but should be able to continuously update their copy.
- Normally, students can’t resubmit an assignment, but there does need to be a simple way to handle this edge-case when the Teacher approves.
- Teachers can view and write all grades but Students have no access to other Students’ grades.
- Etc., this is that moderate-to-high level of security I mentioned…
- The Assignment document’s final grade is figured into an overall average of grades which come from many sources.
There’s a lot more than what we might see superficially here, such as:
- Variable field level security
- Auto-and-manual workflows
- Version history management
- Custom UI
- Elevated permissions
- Integration requirements
- …
These factors, and many others, have a huge influence on how we choose to implement this “app”. The G-Code app, for example, is not really an official “SharePoint Add-In”. It’s implemented directly in a SharePoint page layout. I did this because the app deals with data that is only relevant in SharePoint, is narrowly scoped, doesn’t integrate with the larger grading process, doesn’t need to apply TRUE field level security, doesn’t need to elevate privileges, and so on. Sometimes, simple page layouts are a fine choice.
With everything we’ve got going on in terms of Assignment document management, field-and-view security, long running workflows, elevated privileges, and integrating into the bigger grading process/lifecycle of the college…we’re going to build a Provider Hosted App.
Student Assignments
Students are managing their Assignment documents in an assigned Document Set as shown in the image above “WMC EMS Student Assignments > John Doe”.
When they are ready to submit their Assignment, students launch the Assignments and Grades Add-In. Students are presented with a list of documents and properties that are filtered to Assignments which haven’t been submitted yet. One part of detecting whether or not a document has been submitted is by checking to see if it exists in the Teacher’s set.
There are some other flags in the final business logic, and we’re checking “existence” based on a couple of properties but you see where this is going: if the student hasn’t submitted the document for a score, let him or her do so. Here we see an image showing John Doe’s Student Assignments – those that are “In Progress” and meet the other checks are shown in the “Submit Assignment” UI:
And, as each assignment is submitted by the document, we see the UI and backend updated.
Just want to call out quickly – notice how the header labels are changing, text is converted to contain ellipsis, and tooltips appear. This is all very much by design. Mobile is a 1st class citizen in this environment. The Teachers’ environment is even more responsive to mobile form-factors as we’ll see below.
Before that however, let’s quickly review the backend updates tracking students’ activity.
Pardon the somewhat confusing version history, I need to do some Bootstrap clean-ups on the dialog layout, and also, I’ve run this file through the workflow a few times. Regardless, there’s something very interesting about this metadata we see in the version history: the ‘Modified By’ field is set to “SharePoint App”. That’s the result of using elevated permissions (and a side-effect that server side developers should be very familiar with).
Enabling functionality wherein a Student writes to a Document Set that s/he doesn’t have privileges for is one of the key factors behind the choice to implement this component as a Provider Hosted Add-In. The elevation is accomplished through the CreateAppOnlyClientContextForSPHost method, and as a side-effect, updates show up under “SharePoint App”. We can combat that with a variety of dimension fields such as “Submitted By” and “Graded By” which I may highlight later. And, I will acknowledge again that TMTOWTDI. Elevation of privileges is one factor in many behind the PHA choice…
Technical details aside: students have used a Provider Hosted App that is 100% mobile to submit documents into a secure document set that stages everything for the Teacher to come in and use a matching interface to submit an assignment document score.
Teacher Grades
Students are submitting assignments, and teachers need to grade them….makes sense. Of course, what appears simple at first is often very complex. These assignment documents only make up part of an overall “Main Assignment” score. So, the assignment documents have their own score…as do all other sub-components of the grade. It’s a rabbit-hole discussion, and for now, the important things to note are:
- The assignment submitted by our student above was copied into private instance of his or her document set in Submitted Assignments.
- Students can do whatever they want to the original document with no impact to their submitted version, and that was a requirement.
- The Submitted Assignment lives as the “source of truth” for the students’ grades.
- Student and teacher can easily reconcile to give the student opportunities to resubmit and/or teacher to re-grade.
- Otherwise, students can take notes, update, and improve their own versions of the assignment.
- The submitted assignment carries an arbitrary (i.e. at teacher’s configuration) weight of X scored points against Y possible points.
After the student submits his/her document, the backend is updated as shown above, but we also see the new version of the assignment in a private Submitted Assignments document set specific to each student:
See above:
- This is “John Doe’s” document set (didn’t outline…sorry) – “WMC EMS Submitted Assignments – John Doe”.
- There is a unique document set for every student just as we (or they) have in Student Assignments.
- I’ll take some time to write about the benefit of Document Sets in the future, but this architecture is intentional .
- Assignment Submitted By was captured to counter the fact that Created/Modified would be assigned to “SharePoint App”.
- Several fields are blank…these fields are used to help determine overall document status and drive what we show on the UI {Document Score, Document Points Possible, “Date Graded”,…}
Obviously then (toungue in cheek), Teachers’ views will often default to show them all assignments that are submitted by a given student, yet do not have a score, and are also in status “Submitted”.
And, after submitting:
Let me explain:
- Teacher is submitting a 90/100 by phone.
- We see the Teacher’s UI updated in our Provider Hosted Add-In where “Graded Documents” now contains the 90/100 score for John Doe on this document.
- John Doe sees this 90/100 in his student UI in the PHA.
Also, you’re looking at an alpha build and some prototypes, so colors for “Remove” will probably not be green next time around. Need to get this post out sometime though :).
Next
I know – that was a poor segue into the conclusion, but we need to stop before this post grows into a small novel. Fact is, there are dozens of directions to go from here. We could cover SQL BI, the “Grades” tab UI, other Add-Ins, testing and deployment, continued IA development, endless!
I think we’ll cover some basic reports next, and then get into SQL BI and working with SharePoint data. I imagine I’ll cover updates to the UI/UX soon as well.
