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.

Education Management in O365

Continuing On…

The design and approach for the EMS have been approved, a skeleton solution is checked-in to TFS in Visual Studio Online, and the solution is successfully deploying several core branding and business logic artifacts to on-premises and O365 SharePoint.

The next things to focus on are: cleaning up the basic branding implementation and getting more site content types developed and deployed.


There’s a lot to manage with branding for this solution. Before I start implementing the menus, logo placement, font/color restyling, etc…there are a few housecleaning tasks to address. In this solution, we’re using Bootstrap to provide our responsive framework as well as to build many UI components such as modals, icons, and custom fonts. And, we’ll be branding both custom pages as well as system pages. When tying Bootstrap into system pages, you’ll find a few places where the SharePoint UI is negatively impacted. I address those low-hanging fruit immediately before doing any other UI work.

System Pages Before

Here are a couple of UI components that need to be fixed up when Bootstrap is tied into the system page design.

  • Various dialogs – note the red markup: crowded text/check-box, truncated [X], shrunken file/browse controls, font is bolded, etc.

Upload Document

  • The ribbon – various icons and drop-downs are altered as seen under “Current View”. The bottom third of the drop-down menu is cut-off.

SharePoint Ribbon

  • And, with older SharePoint installations such as SharePoint 2013 on-premises, you’ll see other core navigation components altered. For example, the “+” symbol for “new document” in doc-libs intersects with its bordering circle. O365 suffers from various regressions to system list view pages as well – see the image below where the search icon intersects with the box border:

SharePoint Search

System Pages After

With a few lines of CSS, these issues are resolved. After evaluating Bootstrap’s impact, look into implementing minor updates to the SharePoint UI that are required such as hiding the left-navigation and updating base colors. There’s more to follow of course, but take small steps so changes can be evaluated thoroughly. This image shows a combination of desired changes and fixes:

  1. It’s hard to see because of the modal fading, but a grey theme has been applied.
  2. The ribbon is fixed.
  3. Left hand navigation is removed.
  4. Search and other system UI are fixed up.
  5. Dialogs are in much better shape.

Multiple Bootstrap Fixups

Another serious consideration around the system page branding approach is Microsoft’s right to seriously modify the default experience. As of now, the branding changes Microsoft is making in O365 are detrimental to existing system page customizations using the System Master Page and CSS at the core of this methodology. Expect that it’s going to make more and more sense to use SharePoint as a service available to Provider Hosted Apps and similar implementations wherein you (the developer) have full control of the UI and leverage REST and the CSOM for rich custom experiences. For now, if you want to force classic mode, which can be expected for awhile with larger enterprise customizations, you can specify the setting in the SharePoint Admin center:

Classic Experience

Custom Layouts and Navigation

Note above that I removed the local (i.e. left hand) navigation completely. Later on, we’ll add-and-remove more system and custom components…as both the default and based on users’ roles. Broadly speaking, navigation components and IA implementation will be designed to allow people to quickly and intuitively move between key modules in the EMS.

Some navigation-centric decisions may be purely UI and graphics design driven too, but the philosophy I emphasize is to focus navigation around concerns with user experience. We want users focused on their primary tasks and not with the broader SharePoint ecosystem nor lower priority (or irrelevant) EMS functionality. As we train for and expand the functionality of the portal in a controlled/governed way, we’ll also make sure to re-evaluate which parts of SharePoint and the EMS should be bubbled up to higher class UI and entry points.

So, to reiterate, our starting navigation menus, page navigation “widgets”, site layout and overall IA will be driven to:

  • Get students to the knowledge base apps and their personal document libraries.
  • Get teachers to student management apps and students’ document libraries.
  • Provide intuitive search/discovery.
  • Get admins into the back-end configuration pages.
  • Adapt for mobile and desktop as appropriate.

Several wireframes are used to represent pages in various states and to zoom in on shared and custom components. Previous posts show similar examples, but now behavior is being defined, iterated-upon, and moved through the approval cycle.

Home Page Wireframe

Keeping focused on time and budget, we can implement the approved items now while we wait for additional approval on the more robust and complex page layouts, IA, and design patterns.

Initial navigation is integrated throughout the custom and system page framework. The responsive behavior is seen through the dynamic menu layouts and 2×3 versus 3×2 grids. Images in the grids below are samples, but these components are connected through CSS; things are configured so that images can be swapped in-and-out easily through SharePoint lists.

Framework and Design

This initial wire-up already has us deploying site columns, content types, and page layouts. We’ll now build on this supporting framework to continue developing the rest of our EMS.


Next Posts: continuing to build out the branding framework as well as logic oriented components and backend IA.



Education Management in O365

Continuing On…

Continuing from the previous post: prototypes, wireframes, and rich discussion around our core scenarios led to a variety of agreements around UX, UI, security, testing, maintenance, governance, development/deployment models, systems integration, project timeline, stakeholders and other key decisions needed to move forward with design and initial implementation.

Solution Design

The long list of topics above, and many others, directly impact how to design the solution. Over the series we will touch on solution design often, but to start I’m thinking about:

  • SDLC with very intentional thought around management and long-tail maintenance
  • Configurability throughout the deployment lifecycle
  • Reducing overhead and complexity around deployment
  • Ensuring integrity and proper management of any solution artifacts
  • Ensuring success when implementing system security and governance
  • Hand-off to the business users
  • Aligning with SharePoint and general development best practices
  • Appropriate error/exception checking and handling
  • Third party library integration
  • Debugging and troubleshooting
  • …continuing perpetually it seems

When all is said and done, I’m going with:

  • A pro-developer solution in Visual Studio with source control managed through TFS in Visual Studio Online.
  • The solution will be a combination of SharePoint Add-Ins and a fully-declarative WSP for core framework deployment.
  • When/if appropriate I will go to SPD to create workflows.
    • The initial plan is such that workflows are the only time SPD will come into play within any stage of the SDLC.
    • Any future reasons to use SPD will need to be evaluated; consequences of managing various activities in SPD are often detrimental to continued success with pro-developer solutions. Of course, it may prove useful in certain BCS or other advanced scenarios.
    • Remote event receivers in Azure are another option for WF to be evaluated.
  • Solution will leverage JavaScript CSOM (a.k.a. JSOM) heavily. This is within custom pages and SharePoint Hosted Add-Ins.
  • Using Bootstrap and jQuery. Potentially jQuery-UI. Undetermined third-party JS libraries/plug-ins.
  • Provider-hosted apps with managed CSOM may be introduced.
  • PowerShell scripts may be introduced.
  • Azure services and components may be introduced.
  • EMS will be contained in an isolated site collection, starting with Team Site and activating Publishing Infrastructure.

Let’s address one immediate concern with this decision: that is all of the activity around deprecation of sandbox solutions in O365. The list of pros, cons, and risks around the choice to continue using a fully declarative WSP is extensive and circular. For now:

  • Microsoft is not planning on deprecating fully-declarative sandbox solutions.
  • Add-Ins will be used. Not everything will live-and-die with the WSP.
  • Couple that with a pros/cons/risks-and-mitigations analysis around this and alternatives (e.g. Add-In only, remote provisioning, Design Manager, SPD, OOTB, etc.), and I feel secure in the decision for this solution specifically.

I’ve started off with the core solution built out close to what I’ll expand on for a production release. I’ve also added a couple of prototyping projects to help me test new ideas and features (without muddying up my deliverable projects).

At this point, the solution deploys Bootstrap, a few key JavaScript and jQuery libraries, custom master pages, and custom page layouts. We’re just getting started.


A few quick sanity checks show that deployment and “wiring-up” have been successful…mostly:

  • Check for new Master Pages
  • Check for new Page Layouts
  • Check for new Content Types
  • Update Master Pages
  • Create new page with custom page layout…fails

I encountered a new hurdle when developing this solution. Custom pages in an on-premises environment were returning an error reading, “Unknown server tag ‘SharePoint:ScriptLink'”, while everything in O365 was functioning as expected.

Sometime recently, a namespace change (or similar) within the SharePoint assemblies seems to have been introduced. For years I’ve been adding an assembly and Tagprefix reference for “SharePointWebControls” to the declarations of page layouts so that I can use the ScriptLink tag. For example:

<SharePoint:ScriptLink ID=”ScriptLink7″ name=”sp.runtime.js” runat=”server” LoadAfterUI=”true” Localizable=”false” />

Note though, that I was using “SharePoint” and not “SharePointWebControls” as the actual tag prefix in my ASPX markup. And, admittedly, that’s my mistake…one I’ve been getting away with for years now. Well, that mistake continues to work in O365 as of today (10/30/2016) but not in my on-premises system. I must have installed a SharePoint update recently that introduced this change but is not (yet) part of an O365 update…not really sure. In the end, I just corrected my mistake and updated all tags to use “SharePointWebControls” and the issue is resolved. The page layouts are working on-premises and in O365 SharePoint. This one was so obvious that it took me awhile to see it 😉

At this point, custom and system master pages are being deployed, Bootstrap is integrated into the solution, jQuery and other helper libraries are integrated, page layouts and content types are deployed, and this (i.e. the deployment) is all happening with a few clicks through the Solution Gallery and Site Features pages in the front-end UI. Not a single line of code has been written for deployment and implementation yet – it’s only been XML, skeleton files, and file imports in Visual Studio. Compare that to the SDLC headache of writing CSOM code, PowerShell scripts, remote provisioning scripts, cross-domain SharePoint hosted app JSOM scripts, etc., etc. to manage deployment. I really hope Microsoft continues to support fully-declarative solutions in the Solution Gallery.

Now that we have the basic structure in place we can move on to implementing site columns, content types, additional page layouts, list templates, and other core architecture. All of that will be bubbled up into the UI so we can start to build a tailored experience focused on targeted and intuitive Search, the knowledge base, QRG apps, communication, and document management.


Next Posts: Continuing with branding framework to support UX and UI. Expansion of Content Types and List Templates.

Education Management in O365

Continuing On…

Continuing from the previous post: a simple SharePoint document library was put together to demonstrate how version history, filtering, sorting, sharing, online editing, security, and many other features are available OOTB with a few clicks or taps. The demo facilitates additional discussion and ideas around building an Education Management System (EMS) that will later be coupled with another system focused on professional subject matter and processes.

Discussion now is around academics and generates questions focused on:

  • Who is using and managing the environment
  • What kinds of things people are doing in document libraries and other apps
  • How people are interacting with each other and their content
  • SharePoint’s capabilities, other platforms’ capabilities and integration
  • How content is classified
  • Security
  • Defining content types (i.e. subject matter, properties, ownership…)
  • How people view “their data” and responsibilities around it
  • Scheduling, due dates, milestones, and management/tracking thereof
  • Projects
  • Professional Development
  • Etc.

Information Architecture and User Experience

Early and persistent focus on Information Architecture (IA) and User Experience (UX) are essential competencies and components to focus on when delivering a management system (lifecycle management, process management, customer/relationship management, and so on). On one end, you may expect thousands of users, heavy security and compliance requirements, complex data management, and automation. On the other hand, your system may focus on basic collaboration, task tracking, and document management. Or, of course, somewhere in between. The points I’m setting up are :

  • Pick the right amount of effort for your requirements and don’t over-engineer
  • Try to create a targeted interface that keeps everybody focused on their primary tasks. If possible/appropriate, tailor this to different roles and responsibilities
  • Plan for expansion later but (see first bullet) avoid paralysis through analysis
  • Even a small IA and UX design effort yields large results – this is especially true for SharePoint

Within a few minutes, the discussion yields dozens of thoughts on the who(s) and what(s). Again, “Professional” is not the focus right now:


Within 15 minutes, the mind map was 4-5 times larger than the above image and we’re left with plenty on which to focus our IA efforts.

UX is a huge discussion. If you really drill into how people are thinking about their tasks, individually and as teams and as companies, you can build an intuitive system that truly makes people and groups more efficient, effective, accountable, and successful. Continuing on, you can evaluate the best metaphors, idioms, and layouts to deploy to reduce cognitive friction and quickly move people from novices into experts of the system.

For this project, there isn’t a lot of resource time to allocate towards a heavy UX investigation. We should, and will, address some of the basics though:

  • Implement best practices for an effective mobile experience – a huge subject with many underlying discussions
  • Organize information based on iteration/revision/approval of an expanded IA diagram
  • Focus on using the best platform for the solution (e.g. local SharePoint, Provider Hosted Apps, 3rd party services, etc.)
  • Introduce proven design patterns and strategies for improving productivity overall

With the stage set we can continue refining, designing, and prototyping.


Next Posts: SharePoint IA Design, Wireframes, and Prototypes

Education Management in O365


This is the first post in a series focused on building an education management system in O365. More specifically, this series will cover information architecture, site branding, app development, and simple governance implemented in O365 to establish a basic interface for teacher-and-student interaction and task management.

What will be covered?

There will be a heavy focus on SharePoint in O365 as well as some coverage in broader aspects of the O365, Azure, and Office client platforms. After reading, my hope is that you discover some straightforward steps you can take to help you succeed with implementing and managing a program using Microsoft O365 and Azure technologies as well as how to set the stage for growth and extensibility in the future.

With that written, the starting point will be basic, and as complexity is introduced we’ll see new technology, design updates, and additional functionality added to meet demand. The approach will be ad-hoc as so many SharePoint (and MS Office overall) projects tend to be, but I’m hoping to highlight some critical points at which to pull in the reins and take a moment to set yourself up for success. Posts’ content will focus on building and deploying components, but subject matter will also cover planning an effective approach as just mentioned.

Content covered will be tied to the subject matter of Machine Technology (MT). Our personas and perspectives will reflect those of students and teachers in a Machine Technology student/teacher body as well as those of an architect, administrator, and developer building this system. There are going to be accompanying posts on MasterCam, Shop Math, CNC Programming, and more.

What won’t be covered?

There are many choices to be made around project management, governance, program management, marketing, budgeting, scheduling, SDLC, adoption, and more in the projects we tackle today. These series of posts are intended to showcase O365, SharePoint, Azure, and Machine Technologies and to offer a glimpse into several of those aforementioned topics (some in depth and others on the surface) but not to provide comprehensive coverage off all activities associated with executing an enterprise LMS system implementation.  Also, this is not an overview of the Office 365 EDU tenant and CALs.

Let’s get started.

Starting Out

A machine technology student spends his/her day in the classroom learning shop math, Mastercam, CNC program development, safety procedures, industry standards, and a variety of other subjects. This is coupled with shop time cutting parts and mastering machining techniques. The teacher is hands-on in all activities, both in the shop and classroom and there may be more than one teacher.


The curriculum is intense for the student: completing CNC programs and learning Discriminator, successfully implementing those programs on Mills and Lathes, taking classes at Immerse2Learn, taking classes at ToolingU, and learning Mastercam. Also, some really great requirements are mandated for keeping reference material organized well and readily available, and we’ll be improving on that in SharePoint. All of this is going on simultaneously (a few hours of shop, followed by a couple hours of Mastercam, followed by Immerse2Learn in the evening), and the student is tasked with managing deliverables for assignments on these subjects, his/her notes, CNC programs, and documentation. And, the teacher(s) are working side-by-side with students on all of this and also need to manage their administrative overhead and course planning.

SharePoint is perfect for managing tasks and associated artifacts (of many content types). There is version history, browser read, browser write with exceptional fidelity to the client apps, co-authoring, security and permissions, metadata, filtering/sorting, custom views, search…the document and task management capabilities of SharePoint are extensive and majorly extensible. Extended to the broader Office 365 environment, Students and Teachers find direct access to additional content management through OneDrive, the familiar and powerful set of Microsoft Office client applications, and extensions to all of this through the Office Store.

So, our first requirement is to provide a “sales-pitch demo” showing how students can manage all of the documents associated with various assignments, learning courses, notes, programs, etc. in Office 365. This will give us something tangible to present and demonstrate with in order to receive buy-off and expand functional design.

For this, there will be a simple hierarchy we follow for students’ documents. And, for the demo, we’ll just take the Documents folder that comes with the Team Site template. We’ll use this very basic structure:


We’ll also put together some quick Site Columns to represent/implement the IA above. For now, these provide a great mechanism for filtering, sorting, and basic prioritization in Search.



Mill Program Library
Mill Program Library

Moving forward, we’ll focus on expanding the IA and business process analysis. These will fallout into site design, workflows, views, content types, etc. But, right from the start, we have a basic hierarchy and structure to demonstrate how students and teachers can quickly filter documents, co-author, implement version history, share content, and more with a simple document library.


Next posts: design and IA, security, and associated MasterCam and Discriminator content.