Education Management in O365

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:

Example Content Types

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


Adding Documents


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:

  1. A student starts a document (math problems, thesis, essay, etc.) knowing it’s due at some date in the future.
  2. When s/he completes the document, s/he turns it into the teacher sometime before that due date (or otherwise faces late penalties).
  3. 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.

  1. 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.
  2. When they finish the Assignment, students will take a significant but simple step to submit the Assignment document to the Teacher.
  3. At that time, a copy will be written to a “Submitted Assignments” document library to which only Teachers have permissions.
  4. 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…
  5. 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.

Available Assignment Titles


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:

Submit for Grade

And, as each assignment is submitted by the document, we see the UI and backend updated.

Submitted Assignments


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.


Version History


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:

Teacher Backend View

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

Teacher Submitting Grade


And, after submitting:

Apply Grade Flow

Let me explain:

  1. Teacher is submitting a 90/100 by phone.
  2. 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.
  3. 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 :).


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.


Education Management in O365

Continuing On…

Design and prototyping are consuming a majority of project time and budget.

  • Creation/Maturation of artifacts (solution components, functional and technical specifications, IA, icons and design elements, etc.).
  • Iteration on the above and more.
  • Approval/Reject cycle.

We’re keeping a constant churn of dev-test-fix with QA and eliciting stakeholder feedback as new milestones are reached. Some minimal-for-critical-success criteria are in place to help manage a project under a rapid-churn like this:

  • BDMs/TDMs are truly empowered to make decisions.
  • Daily stand-ups are enforced.
  • A task board or something like the SharePoint Project Task Tracker is in place for triage.
  • Communication and visibility are embraced, hence “Daily stand-ups” above, but I’m more so referring to team support and successful execution here.

Let’s review progress on the UI, IA, and our first app.

UI Update

The distribution of mobile and desktop focus is being refined and implemented. Shop-floor/mobile-ready app entry points are in the core UI (G-Code Lookup and Time Clock), and so are classroom oriented entry points for viewing assignments, grades, and linking to other sites for online learning.

SharePoint Mobile and Desktop

These graphics are also closing on final sign-off, and they’re wired up to actual endpoints such as custom apps, document libraries, and external sites.


IA design and implementation are in a mixed state. Content types, site columns, and list definitions that are locked down (or are very close) have been implemented in Visual Studio and are deploying via WSP. Other definitions are being built on the front-end and will be migrated into our solution after approval. We see below, for example, our G-Code content-type and associated list defined in Visual Studio and implemented/deployed in SharePoint.

Content Types and Lists


Apps: G-Code Lookup

When CNC Machinists program mills and lathes, they define their part programs using a series of codes that are prefixed with a representative character related to the codes’ function (e.g. G71 for canned cycle, M3 for spindle-on clockwise, T0202 for tool selection on a lathe, I-.125 to specify a radius, etc.). The broader part program specifies highly precise control over different materials as they collide at high speeds to produce parts ranging from a spring in a keyboard to airplane wings. A broad-stroke reference of “G Codes” is used during casual conversation when talking about the entire set of codes.

In an educational environment, and in a professional shop, the question of which G-Code means exactly what comes up often. It happens enough such that each machine has a chart of all the primary G/M codes permanently mounted to its structure. On a shop floor, the mounted reference chart is perfect, especially if you know exactly which code you’re looking for. There’s no need to pull out your phone or go to a kiosk when a perfectly structured chart that is specific to that machine is within a hand’s reach. However, in the lab or in a classroom, one is not standing in front of the machine. And, it’s not so easy to find a code on those mounted charts by keyword or description. For example, one may ask, “What code is coolant on”? With the mounted chart (which is in very fine print), you need to manually scan dozens of codes which may have that word present. So, we have a real-world problem that exists in both our environments (education and professional) and we have a solution that will work for both: the G-Code Lookup App.

  • Must be as easy to use as the manual reference chart.
  • Should scale well on a desktop and mobile.
  • Enables machinists to search by exact-or-partial code, keywords, and description.

Here’s where we’ve landed so far…

G-Code SharePoint App

Fidelity across Android, Internet Explorer, Firefox (not shown), and Chrome are 100%, and the app is connected to SharePoint via the JSOM.

In the near term we’ll clean-up the G-Code App to get it pushed for review and iteration, move on to the next app (Time Clock), keep building out the IA components, and start putting some structure around security and document management. There’s a lot more to do.


Next Posts: activity around submitting assignments and the start of managing grades.

SharePoint Project Task Tracker Update

This is a brief post regarding a new update to the SharePoint Project Task Tracker app.

The update was deployed to fix a bug wherein all content on the Reports tab was collapsed when clicking the “Project Views” section header. The intended behavior was that it should only collapse the “Project Views” section and not the “Task Views”.


This issue is now resolved.

When loading the app, you may not see any UI for upgrading. If that’s the case, you can manually check for updates by using the “Details” option in the fly-out menu available in Site Contents:


This will forward you to the app details page where you can click the “GET IT” button to start the update.


Thanks for using the SharePoint Project Task Tracker app.

SharePoint 2013 Installed App Properties

This is a quick SharePoint 2013 developer post which highlights how to get properties of your installed apps on a given web.

The first step is to obtain the App Instance Id. You can do this by navigating to the site on which the app of interest is installed, hovering over its link in the Current Navigation area or Site Contents area, and observing the URL.


With the ‘instance_id’ value in hand, you can now execute the PowerShell commands:

$web = Get-SPWeb http://sharepoint/full/path/to/installed/site

This will now render the App details:

AppPrincipalId  : <Claims String>
InError         : <True|False>
App             : <App Class>
SiteId          : <Site GUID>
WebId           : <Web GUID>
Title           : <App Title>
Id              : <Instance_ID>
LaunchUrl       : <Relative Url>
Status          : <Installed|Other>
RemoteAppUrl    : <Remote Web Url>
AppWebFullUrl   : <Full Launch Url For App>
SettingsPageUrl : <App Settings Page Url>

In development what I find most useful are the RemoteAppUrl and the AppWebFullUrl properties. These can be used to setup DNS and browser favorites on the various machines in your test environment to enable you to test non-public URLs in a small lab environment (e.g. one without a proper DNS server).

Monetizing SharePoint and Office Apps

Monetizing an app involves specifying the billing model, how to go from user to site pricing, as well as other options around trials and so forth. These are common things one expects to consider when looking at selling apps in a market place.

When it comes to SharePoint and Office apps, I found some clear documentation explaining their market’s options around these kinds of monetization settings. Take 5 minutes to read the following article and you’ll likely have a majority of your questions answered on setting a pricing model and monetizing your apps in the SharePoint and Office app market place: