We’ve laid the framework for our Education Solution in Office 365 and SharePoint with the production of prototypes, wireframes, and through rich discussion around our core scenarios. This led to a variety of agreements around User Experience (UX), User Interface (UI) design, 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. Now it’s time to move into Solution Design and review the use of the SharePoint JavaScript Object Model (JSOM), WSPs, Twitter’s Bootstrap, and jQuery.

Office 365 SharePoint – 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 SharePoint Designer (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 Business Connectivity Services (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 Office 365. 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.

Validating the Office 365 SharePoint Education Solution

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 Office 365 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 Office 365 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 Add-In 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

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

Categories: Education Solutions, Machine Technology, SharePoint, Software Development

Tags: Education, EMS, Machine Technology, SharePoint