Continuing from the previous post: we brainstorm and use techniques such as mind mapping and white-board exercises to refine our IA and understanding of the types of activities people want to facilitate in our EMS. We then filter our content from those meeting into design, development, and implementation of IA, UX, and other core concentrations of our system.
There will likely be several posts in this series that focus on Information Architecture. IA is essential to the systems’ usability, extensibility, scalability, discoverability; you get the idea. And, that’s generally regardless of platform when you’re building even the most basic “management system”. As a SharePoint designer, developer, and architect…I know that IA can impact UX, UI, Search (intuitive and system), topology and server infrastructure, workflow design, and overall adoption of the system. IA also happens to impact pro-developer solution design and implementation (e.g. modules, site columns XML, list templates/instances, content types, and deployment dependencies). It’s not just SharePoint of course – IA also impacts database and class design, security, extensibility, compliance, integration with other enterprise systems, and endlessly on-and-on.
The impact of Information Architecture in software engineering is why it’s of such importance (and personal interest). However, these are targeted blog posts so I’ll spare you the book. Let’s just cover a quick-win we get as a result of taking a moment to focus on IA.
Sample Information Architecture
A small sample of our IA for the EMS looks as follows:
And, what you’ll see mature from this is content type and site column design, list and library view design, app development, workflow development, and of this post’s next subject…Search design.
The time we take to develop our IA and implement it as content types, site columns, managed metadata, etc. pays off quickly with search. Search is an essential component of this EMS. There are a lot of moving parts, new vocabulary, and dynamic subject matter; students and teachers both need to quickly discover and filter content.
Search can be complex though often it’s just really tedious to manage. But straight from the SharePoint Admin Center UI, you’ll read, “Search automatically extracts crawled properties from crawled content. You add the content of a crawled property to the search index by mapping the crawled property to a managed property. You can use the settings of the managed property to restrict search results. Search automatically creates managed properties for site columns that contain values“. So the point is – spend some time adding content types and site columns and get instant ROI for your time.
When we look at our Crawled and/or Managed Properties listing, we see our site columns mapped to managed properties as expected with no extra administrative overhead, and the same goes for using these fields directly in Search.
We could now, for example, set-up a search container which focuses on returning programs written with specific software (e.g. Mastercam or Discriminator in this portal).
And, in real-time, people can search for documentation on Immerse2Learn lessons, but only when it relates to Mastercam:
It’s worth noting that the promotion of fields to managed properties is also necessary for certain Search API methods so we’ll see an equivalent payoff when we build some search driven components programmatically later.
The demo of document libraries leads to a much broader discussion, and the opportunity to gather essential feedback on how people will interact with their data, save it, manage it, and share it. We discuss:
- When and where students and teachers are likely to access the system (e.g. on the shop floor, classroom, at home…) and on what devices of course?
- What’s the highest priority…for both the students and teachers?
- How can we tie into other systems and what can we foreshadow will cross over into a production facility software system?
- What kinds of roles (and security/permissions) are we expecting, and what about different views and organization of content.?
- What’s going to be configurable, automatically deployed, and who is going to own management of that?
There’s some richness in this line of questioning and it brings to light that, for the initial roll-out, the site is equally-or-more mobile focused as it is document management centric. This was unexpected but taking 1-2 meetings for UX helps us prevent a big mistake like focusing on lower priority activities. If that happens, you know the story: low adoption rate, low adherence, poor organization, and overall poor ROI. We find that:
- Students are as interested in quick apps and dashboards for checking due dates, viewing grades, and finding quick links as they are with editing content (and getting all of the valuable document management).
- Teachers have an interest in some of the apps, including how to automate their associated content management/maintenance. They are, however, more concerned about content organization, opportunities for workflow around assignments, schedules, and e-mails. Overall, they want to manage their broad set of tasks, processes, and activities needed to lead their classes.
This mixed demand is a common requirement for LOB and process management systems: follow the latest design patterns focused on agile and meaningful consumption of data while still allowing for business logic, content management, security, configuration, and so on. Specifically to our EMS, we also need to focus on keeping students out of the system pages and library views generally speaking, but we do want them (i.e. those site pages and list views) available when appropriate. There isn’t any security concern. Instead, we simply don’t want the students distracted and we don’t want them spending time drinking from the fire-hose of SharePoint features. A major point and responsibility of this EMS is to provide those powerful views and configurations at the entry point of the system. So, as just noted: students and teachers will end-up in the backend both by accident and by design. But, we’re not going to re-skin the core document management features of SharePoint nor do much around removing/branding system pages. There’s too much for all users to gain by leaving these features intact. We’ll allocate a few hours for a bootcamp on SharePoint basics with the message to avoid features for which training has not been provided.
We are definitely going to spend time on custom pages though. Nothing overboard…just a few dedicated page layouts that surface core apps, transition across form factors fluidly, and provide insight into the subject matter that teachers and students are most interested in.
The wireframes, prototypes around Search, and continuous collaboration around our product subject matter lead us into setting up the initial design and architecture of our solution. We’ll start constructing artifacts around deployment and also begin working within some constraints of a basic implementation of the EMS. Having something tangible like this will also help elicit rich feedback with stakeholders around complex topics such as security and the myriad options we have for implementation.
Next Posts: UI, Apps, and Security