My Blog: Building a Data Model

19 October 2016

It's time to get started on creating Global Datatypes and Page Datafolders. But how do we identify what we need, and which type do you use for what? This post explains my thinking process for deciding.

Identify the Core Product

All websites do one of three things: sell, promote or educate. They all have a core product around which others revolve. Identifying your core product may seem easy, but do your customers think and feel the same way as you? Maybe, but it's worth asking them beforehand... you might be surprised. Good research is key to a good website. Don't assume that the product you want to push is the one they want to buy / consume.

I've been in the Higher Education sector long enough, and have conducted / commissioned enough research to know that the main products of Higher Educational (HE) institutions are their courses and their research output.

Beginning with courses, we need to find a way to sell them based on the things that customers identified as being their most important aspects. We need to create an emotional / psychological / tangible need for the customer to sign up for a course. Providing raw information isn't enough to reel in a potential applicant... in fact it would make the website pretty boring. We have to tell a story about why they want to take the course. If possible, work with a creative copywriter to design your story.

With great prose in hand, we need to look at how the course links in with the rest of the website. This is where we begin to map connections with other information and start to build a plan for storing and displaying data. From this we get the datatypes.

If we created each course as a normal page, we wouldn't be able to manipulate the data contained within that page and display it in different formats according to the needs of the user. By storing course information as data, we can also expose that data in an API and request it with JavaScript AJAX functions for our course search engine.

Likewise for subjects and modules. Having these in datatypes allows for interesting functions that can combine information from multiple datatypes and display them on pages.

In general, courses are made of either one (single / specialised) or two subjects (major / minor or joint). The subjects themselves are usually made up of multiple modules (your own institution may have different names for these items, but the structure should be similar). This gives us a data model like this:

  • Top-level course information (Page Datafolder)
    • Main subject (Page Datafolder)
      • Multiple modules that make up a subject (Page Datafolder)
    • Optional second subject (Page Datafolder)
      • Multiple modules that make up a subject (Page Datafolder)

All three items here (programmes of study) will be represented by pages in the website, so we use Page Datafolders to define the datatype.

When discussing the costs associated with courses and modules, an abstraction layer using fee banding will allow us to separate fee data from the programmes themselves. You don't want to be typing in the same monetary value in each course datatype over and over again, repeating the process each year as inflation necessitates a monetary increase:

  • Course information (Page Datafolder)
    • Course fee bands (Global Datatype)
      • Course fee band costs (Global Datatype)
  • Module information (Page Datafolder)
    • Module fee bands (Global Datatype)
      • Module fee band costs (Global Datatype)

Here, the fee bands and the cost values aren't represented by pages (although the data may be displayed on a page built from a Page Datafolder) and so are Global Datatypes. Values that would be chosen from a drop-down within a Page Datafolder will almost certainly be from a Global Datatype.

Programmes also have a list of entry requirements, many of which are standardised and common to multiple courses. Therefore, we can create a datatype for these entry profiles:

  • Entry profiles (Page Datafolder)
    • Language requirements (Global Datatype)
    • List of profile qualifications (Global Datatype)
      • Qualification types (Global Datatype)

Because some entry profiles may be common across courses and modules, we don't need to have separate datatypes for them as with fee bands and costs.

For research output, we need to talk about the research project itself, the people conducting it, the outcomes, and related case studies that help to promote the research outcome.

  • Project information (Page Datafolder)
    • People involved in the project (Page Datafolder)
    • Case-studies related to the project (Page Datafolder)
    • Publications (Page Datafolder)

Beyond the Core

Moving away from courses and research output, we need to determine what the other products of the organisation are. Here, researching other HE provider websites can guide us.

The University of Bath's own Digital Marketing & Communications department has done a lot of excellent work in this area. Using with lessons learnt from GOV.UK, the Content Team have grouped pages according to their category types:

  • Announcements - The latest news and updates from the University.
  • Campaigns - Campaigns to encourage engagement with the University or to raise awareness about our activities and causes.
  • Case Studies - Stories about our research and our students' experience at the University.
  • Collections - All the information on important topics, collected in one place.
  • Corporate Information - Data about the University, our policies, strategies and governance information.
  • Events - Upcoming activities at the University from conferences and public lectures to sport and cultural events.
  • Groups - Centres, services and administrative bodies within departments and faculties.
  • Guides - Guidance for using and delivering services at the University.
  • Locations - Information about our campus venues and buildings.
  • Profiles - Contact information and role details for University employees.
  • Projects - Ongoing activities at the University from research projects to campus improvements.
  • Publications - University documents to download.
  • Research Publications on Opus - Search and browse publications by our researchers, including journal papers, conference materials and books.
  • Services - Access to online tools for interacting with the University.
  • Teams - All departmental teams, boards and committees at the University.

With their website, and the custom CMS that they built to host it, these have become their equivalent of datatypes. While this list obviously works well for the University of Bath, it may not work well for your organisation. Indeed, when designing the University Package, I decided to adapt this list, and still give editors the flexibility to create pages outside of these categories.

The Page Datafolders I decided to add to the core product datatypes (listed above) were:

  • Locations and Buildings - Information about the campuses and the lecture theatres / venues.
  • Collections and Campaigns - Gather information together to promote topics and actions.
  • News and Events - What's going on at the institution.
  • Groups and Teams - Describing the way the institution is organised.
  • Partners - Demonstrate links with business, government, charities, colleges, schools and the community.
  • Main navigation - A way to manage the website's navigation structure.

You can view the complete list of all Page Datatypes in the documentation page.

Naming Conventions

Before we begin creating anything in the CMS, we need to decide upon a solid, sustainable naming convention.

When adding a name to a datatype, begin with the namespace of the package you are creating. This will allow you to distinguish your datatypes from those created by Orckestra and others when adding Data Reference field types to your own new datatypes.

My namespaces will all begin with "BaileyWeb.University". From there, I will save functions into folders with the same name as the primary datatype they reference. For example, If I have a Page Datafolder called "Courses", it'll be stored at "BaileyWeb.University.Courses", and all functions that access its data will use the namespace "BaileyWeb.University.Courses".

Following Orckestra's lead, functions that pull, join or manipulate data and output as XML (or some other data type, such as dictionary objects) should begin with "Get", and those that output data as XHTML will begin with "Show". Using the above example, we may have functions called "BaileyWeb.University.Courses.GetCouseTitlesFromSubjects" and "BaileyWeb.University.Courses.ShowAllCoursesList".

With this in place, we can start to create the datatypes for the products and services we want the website to promote.

Drop-downs and Multiple Choices

When creating our Page Datafolder datatypes, we begin to find places where we require drop-down lists or multiple choice selectors. For these we need to add in Global Datatypes (types that aren't generally exposed at the page level, but store data to select from). Most of the time there are just simple lists with one / maybe two columns, but occasionally they need to be more complex. Rather than list them all here, It's probably simpler to refer to the Global Datatypes documentation page in order to illustrate what they store.

Document As You Go!

While adding these datatypes to the CMS, I've found it incredibly useful to document them as I build. Documenting has allowed me to spot gaps in my data model, implementation, and the way pages will eventually display the data. It's better to find these issues before you begin creating pages and functions, as it'll save you a lot of work and hassle amending the datatypes afterwards.


comments powered by Disqus