Designing the eLearning platform is a complex activity with multiple stakeholders. eLearning experts, Education experts, Content developers, Technology Architects, Business Analysts and sometimes even end-users participate in determining the overall functionality and features of a portal. However, many times the resulting portal may display some design drawbacks, which may prove difficult to mitigate.
In this blog, I will try to outline top five of such typical pitfalls / traps in platform design and also provide some thumb rules that we can bear in mind to avoid those.
Trap #1: Content or Platform
The whole purpose behind building any eLearning platform is to showcase content. Having said this, many times it happens that the platform is heavily dependent on the content or vice-a-versa. For example, I came across a platform for eBooks that planned on creating landing pages by reading the index (Table of Content) in actual content books! Furthermore, we also see content being designed for a specific platform or player. In both these cases, the resulting portal has very tightly coupled content and any change or upgrade in content or platform becomes a tedious activity with a lot of limitations.
Thumb Rule #1: Platform and content are two separate entities. There should be ‘NO’ dependency amongst them. A Platform is a container that will store, showcase and play the content and this activity should not be dependent on content format, structure or attributes.
Trap #2: Allure of Custom Development
There are multiple frameworks and third party extendible components that can be used in designing portals. They save a lot of time and costs. On the other hand, every designer craves to design something unique. So the next step in design is invariably a frenzy of customizing these third party ready components to suit ‘unique’ requirements for the portal. Such customizations can be in features, user interface or at times even the architecture. I have also seen cases where complete custom code is favored for the control it provides. But the resulting endeavor is very time consuming and non economic and may not be strictly needed.
Please note, custom code and customizations are necessary. However, many times the number of customizations as well as the components customized results into a complex architecture at the loss of scalability and modularity. I think if the goal of a portal is to sell / showcase content, there is no point in reinventing the wheel by building learning or content management platform from scratch.
Thumb Rule #2: Decision about custom code and customization is a balancing act. Customizations should always be minimum and modular and a custom code should be developed only when it is absolutely essential to do so.
Trap #3: The Generic Portal
Quite often there are multiple types of target users selected for a portal. The thinking is that if the portal is generic enough, it can be used to serve a wide range of user base with necessary customizations – which is a fine goal. However, I have seen a portal which is designed for K to12 kids and was also supposed to be generic enough to be used as a corporate platform at a later stage! This is like trying to design a bottle of baby food which can also be used while packing gourmet dinner!
Portal features are usually defined according to the target audience. For example, if the portal is for kindergarten students, COPPA compliance becomes necessary. However, a corporate portal will need integration with conferencing solution and moderated discussion boards. So trying to design a platform which can be generic enough to serve both customers becomes an unnecessarily tedious task.
Thumb Rule #3: If the target audience has a varied range, it is better to design separate portals. There will be around 30% functionality which can be common across any portal. However, such common portal functionality should be duplicated in the separate branches of code.
Trap #4: Feature Rich Portal
Now-a-days, every portal comes with an array of features. All of these features are what makes the overall user experience efficient and attractive. Having said this, you may come across designs that go overboard specially in terms of mobility and offline availability of features. Integrations with third party portals can also take one overboard. As a result, the portal becomes feature heavy instead of feature rich.
Thumb Rule#4: Start small. Design with features necessary for minimum value preposition, making sure that the design is scalable, modular and have a road map in place for all other additional attractive features.
Trap #5: Over-architecture
The intent of developing any portal is its wide and enthusiastic acceptance. However, many times this may result in over architecture. It may not be necessary in most cases to design for high number of concurrent users at the beginning of the portal. I have come across examples of high level of redundancy implemented in portals that take care of the occurrence where any content asset goes viral. Use of NoSQL database can also be done unnecessarily in portal design with the hope that someday the data can be used for data analysis. Technically, such decisions cannot be taken without the awareness of which data we are targeting and the possible analytic information that can be gleaned out of the data.
Thumb Rule #5: Capacity Management, Performance and Redundancy architecture is a valuable part of portal design and deployment. So scalability becomes of paramount importance. Furthermore, the current architecture and deployment should always be such that it is sufficient for the current portal goal.
All these traps are common sense and while reading them I am sure everyone is confident that they will not be people who end up in these traps. Actually, the main danger here is that these traps are as a result of a particular way of thinking and that is what makes the mitigation difficult. So better idea is to always assess the overall design and architecture with these thumb rules to reduce the chances of falling into one such trap!
