Today, we will take you on a journey through some important insights we achieved as builders of educational portals. Portals in which Drupal plays a part and how we managed to create added value to educational portals we built over the years. Of course we like to give some examples in how we succeeded, but it is just as interesting to look at some flaws that actually helped us to do it better the next time.
But first, just what is an educational portal?
An educational portal has a broad understanding. In this blog, we would like to focus at applications that have a clear internal focus for our university as a whole, our students, our teachers and staff. You can think of electronic learning platforms, digital learning (and working) environments and intranet systems for universities.
Recent years: digital workspace
As part of the digital transformation every university is going through, the term “digital workspace” is floating around in this context. A digital workspace brings together all the aforementioned subsystems into one intuitive, platform. We’ll touch on that subject later on.
Role of Drupal
Secondly, how do educational portals / digital workspaces relate to Drupal?
Universities around the world have been using Drupal for some years now, even going back to version 4.x. Drupal is particularly popular because of:
- High modularity
- Flexible API for integrations
- Identity and access management
- Authentication with external providers, OAuth, SSO in place via contribs
- Open source nature / General Public License
- Very flexible but yet fine-grained management of roles & permissions
And that is exactly where we would like to start today.
We could say that the typical challenge of education is the broad collection of target audiences. When developing an educational portal it’s important to know your target audience, not only are you gonna deal with Teachers and Students and cater to their needs, but you’d also have to keep in mind that Parents may be visiting the site, as are Alumni, Heads of Faculties, potential sponsors, researchers, general staf, journalists and the general public.
And we are probably still not complete in our list.
One way to tackle this is making use of personas, a method of visualising your potential users. With this method you create fictional characters that represent one of the user roles. (Afbeelding user roles)
With the personas defined you can make an educated guess of the type of user journey the users of the portal are gonna follow. The next step is wire framing. An efficient way to achieve a shared view on “what we need” is to invite the target audiences to literally DRAW what they have in mind and bring all these views together in user experience sessions.
After this, we can use these views in wire frames. This is quite essential in managing expectations. And there is a hidden advantage in this way of working: it can be a superb way of bringing together groups that are not necessarily ‘best friends’ or at least have opposite goals. Prototyping the application and perform usertests with a select group of users which represent the roles defined earlier.
[dit nog aanvullen en bruggetje naar technische tip hieronder]
From a Drupal perspective we would like to share another important insight we achieved during development of portals. As we concluded that Drupal has a flexible basis for role and access management, we need to make sure it is still manageable. The actual handing out of permissions can of course be carried out in Drupal itself, but large organisations should prevent this multilayered approach. In easier words: we want to make sure all permissions are stored in one central location, like for instance Active Directory. In the end this will prevent flaws like abusing the system while no one notices it.
Politics in Education
Working with large educational institutes brings some special challenges in the form of different fractions in the organisation. There are not only the IT and business side of the organisation, but also lots of different faculties who all think they are the most important faculty of the university. Getting all these different teams on the same page can be a daunting task and sometimes lead to extensive rework on your project. Essential in preventing these issues is understanding what the goal of the various stakeholders is and realising that, sometimes, it just isn’t possible to please everybody and still have a great product, so you have to make compromises now and then. There are however some factors which can either make your life a little better, the most important being a good product owner and a competent analyst to really get a feel of what is essential in your project.
Another crucial part of the process is to make proper wireframes, mockups and have a clear content strategy so all parties involved can get a good feel of the expected functionalities. Make sure everybody is on the same page as early in the process as possible!
Also having proper personas, having people involved and taking a good survey can be of great help in preventing bickering and arguing.
Organisations in Higher Education probably already have a multitude of systems and programs that need to be incorporated in some way in the portal. Examples of types of application you’d have to interface with are: HR applications, Scheduling programs, Learning Management systems, Publications repositories, mailing lists, external websites, Document Repositories, Course management software, and so on, the list seems endless.
Of course you could write an importer for the xml which comes from the HR application, a feed processor for the external websites’ RSS feed and a file fetcher and processor for the archaïc publication repository.
The universities we saw do not have 3 systems.
Abetter way to handle all these streams of data would be to create a standalone piece of software to act as a middleman, a so called Enterprise Service Bus or ESB.
Garbage in, Garbage out!
The ESB is built to adapt multiple intgrations and normalize the data, which is distributed in a uniform way to our portal and any other clients. With an enterprise service bus Drupal only has to take care of a standardized and centralized integration. This heavily reduces complexity in our portal.
Some of the advantages of using an ESB are:
- decoupling the requesting party and the distributing party
- Simplifying and standardising the interfaces between the two parties
- Stimulating the re-use of data (as they are centrally available it promotes the re-use)
- Centralised location of monitoring of services
- Reducing time-to-market
- Sanetising and validating
While the ideal of an ESB is great, reality is unfortunately different and in some cases you will have to manage external connections to the portal within Drupal. This simply means that there will probably exist some point-to-point integrations in your portal.
To handle this not so ideal situation, we should implement some control management inside Drupal. To be more specific: standardize this within your Drupal application.
We need a referee
A Gatekeeper, or, as you wish, some kind of referee
This will require two essential things for each integration:
- Some sort of gatekeeper functionality which will prevent to import garbage.
- Proper logging system which will help keeping track of unwanted side effects of integrations with third party software.
Yes, it is a clock and it is a quarter to nine. True.
It actually represents the starting time of the students who were going to use the new portal first day at school after holiday break. We proudly launched the portal the week before. As teachers were already using it, we had a positive shared view on the use and especially the performance of the system. But, as the students day schedule now was part of the portal, and somehow we could have foreseen that, well, EVERYONE would check their day schedule at the latest moment possible, we ran into some big time performance problems. This is a typical example of peak traffic. We hadn’t taken peak times into account. As a development team we found out that we failed to address the cost of quality on this matter. It would have been better to have some proper stress testing in place. So, we quickly fixed it by shoveling some extra power to our servers and immediately sitting down with IT people of our client.
Although it is quite tempting. Running away will eventually bring more problems. We sat down with IT people and created the solution we wanted.
Different types of tests
Tests which check if your code is working as supposed
Behavior tests (e.g. Behat)
With behavioral test you run scenario’s / user stories
Visual Regression tests (e.g. BackstopJS)
Visual regression tests check visually if anything changed on the page
Performance tests (e.g. JMeter)
Test the performance of the application
Performance testing = Being prepared
Some general steps to running tests on your application.
- Analyse existing data
- Google Analytics / Logs
- What are the top pages
- What pages give errors
- Prepare testscenario
- Use the results of the analysis
- Configure tooling
- Pick your tool (Jmeter?)
- Run the test
- Analyse results
- Profiling & monitoring
APDEX is a standard for measuring user satisfaction based on pageload time. Basically it works like this, you set a baseline that’s acceptable and one that’s frustrating for your application (which for an LMS might be a different baseline then for a webshop). Then when you run your test, firing of a gazzilion requests to your application, you get a set of results mapped to your baselines following a pretty simple formula:
APDEX is not the holy grail
Technical Choices / architecture
So we were talking about the ESB. What would happen if we considered Drupal as actually being one of the distributing systems, a client to the ESB? We would simply consider Drupal as a content management system, out there to serve content to whatever external system we want. This is typically the case when operating in an omnichannel communication strategy.
A user experience is partly determined by the online ‘obstacles’ that a user encounters. Removing frictions within the customer journeys of users makes the experience positive. We also believe that omnichannel communication is becoming increasingly important in the online world. In concrete terms, this means that the publication and distribution of content and information via a website is no longer sufficient. Channels such as (native and mobile) apps and other websites are becoming more and more part of the communication strategy. It is crucial that a CMS has the right interfaces and tools to make this possible. The CMS as a publishing machine, which provides direct communication to all channels and chain partners in combination with a front-end interface for the distribution of function, form and content, will form the basis.
The news here is: Drupal is not necessarily the portal itself.
In fact, we are aiming to serve a unified experience for our users across all channels.
“The digital workspace is a new concept that enables tech-savvy employees to access the systems and tools they need from any device—smartphone, tablet, laptop, or desktop—regardless of location. ”
And that, in our opinion, is a very unpretentious definition. Because the digital workspace is device-independent as well as adaptive. One could image that, for instance, when you work together in a group for a school project, that all these subsystems “know” you and also “know” you are part of that group. When asking questions to tutors that apply to the group, you would expect the whole group to be found in the correspondence. So when the teacher answers to the question, every member of the group receives the feedback.
Future role of Drupal
So, having written down all these insights, we are left with a question. Just what is the role of Drupal when a portal really is a set of collaborating systems?
I am happy to hear your thoughts on this matter below.