Lots of freelancers hate having to call up people on the phone and asking if they’ve got any work for them. If only there was a...
10 most common mistakes in a portal projectJelle Van der Linden
1. I’ll do it my way…
Don’t overlook the fact that you will be building a portal for a specific group of people (or several), not just for you. What you might find interesting content and an easy way to work, may well be completely different for your targeted users. If you want your portal to be used and successful and you want a good ROI, find out what your users need, which information they use and also which information they can provide.
Our advise: Start with an Information analysis. The key users of your target audience will be flattered they can contribute to an important project and the chance your portal will be a success increases significantly.
2. You can do everything in a portal
First of all, this is true… A portal can be used as a development platform. So with good development skills, any use case could be developed in a portal. The big question is, shouldthe use case be developed in a portal ?
The use of a portal platform, gives your project a first boost with all the out of the box features, single-sign-on integration, user management, …
But will these features give you the added value you require, or will you still need so much custom development the use of a portal platform will restrain you.
Our advise: Start your project with a requirements analysis matching the features of your portal platform. Some use cases are more suitable for a custom web application than a portal platform.
3. We’ll do the user management later …
The way your user management is set up will determine the flow and use of your portal. Don’t postpone this until the end of the project or a next version. Roles, groups and organizations are very effective tools to bring structure to your portal. When these user management features are used as from the beginning of the project, the risk of some users having access to content they shouldn’t is reduced to a minimum.
Our advise: Work out roles, user groups and organizations at the beginning of the project and implement them as soon as possible to guarantee the security of your content.
4. The free version is OK, we won’t run into any trouble
Often open source platforms offer an enterprise version next to a free community version. The enterprise version is most likely a stable and tested version on which support is given. If you don’t drive a car without insurance, why would you consider building an enterprise application witch holds important content of your company without insurance…
If a major problem occurs and you can’t count on support from the creators of the portal, your only option is to write your own patch. If you should succeed in doing this, the patch will probably need to be rewritten if you want to upgrade to a later version.
Our advise: Don’t underestimate the value of enterprise editions. It will cost you more in custom development and research than buying expert support in the form of a license.
5. This is the perfect portal product for us, because he told me so…
Every use case is different. Most of us are smartphone users, but still there are over a hundred different phones available. All perfect phones for one type of user. The same goes for portal products.
Do your own research. The different portals will have different features out of the box. Use the dynamics of the portal by using as much as possible out of the box. To build your own portlets is always possible, but is much more intensive and requires expert knowledge of the specific portal.
Match your requirements with several products, instead of relying on the advise of others. Your portal will be different than all the others and thus will have different requirements.
Our advise: Do your research thoroughly, once you have chosen a platform and start building your solution, the exit cost will be eminent.
6. All changes have to done by a helpdesk engineer
Who is in a better position to make changes to the portal than IT… they build the application in the first place.
Well that’s where you are wrong. They might know everything there is to know about the platform and how it is configured, but content is something that has to be provided by content editors. And what would be the use of your portal if it is filled with content that nobody needs or that is published to the wrong target group.
So how can you make sure the right content is published ? By appointing at least one editor / publisher for different kinds of information. E.g. the department of external communication covers the public news, internal communication covers the group content and by appointing at least one editor/publisher per department and making them responsible for the content of their department you will create the opportunity to start gathering and publishing expert knowledge that will only be visible to that specific department.
Our advise: Work out a content strategy and divide responsibilities over several employees.
7. Why rebuild our existing application if we can just show it all in an i-frame
A portal is a wonderful medium as start page or portal platform to other applications. But showing all your applications in an i-frame won’t create added value for the users. Instead it will even create frustration, because the viewport will be smaller and scrolling will be less user friendly.
There are other ways to create a possibility to use certain functionality of your applications in a portal, such as web services, REST services and web proxies. If on the other hand the user needs the complete application, it can be configured that by one simple click it opens in a new window and the portal will take care of the authentication.
Our advise: Try to avoid i-frames to create a user friendly and flexible portal
8. My layout does not have to be future proof
Based upon wireframes or a graphical design you start building your portal thinking that you will never have to change this. But what if you do ? What if in a newer version of your portal product, the layout can be even cooler and flashier than it is right now …
If you plan to develop your own portlets, there are some things to consider. First of all a portal should be modular and flexible, so design your portlet so that its position doesn’t have to be fixed in the portal container. Maybe you want the portlet on the left on the home page, but in the middle on another page. Secondly colors and fonts should not be defined within the portlet, but should rather be defined on the portal level. This way all your style changes are inflicted immediately on all pages and portlets. Moreover keep in mind that devices are evolving. Maybe your company will decide in the near future to provide applications fit for mobile devices. By using a responsive design, this will be covered from the start.
Our advise: Design your portal so you can benefit from its flexibility and modularity. Don’t create a monolitic beast!
9. Personal pages? That’s an urban myth…
Why should I let my employees clutter the portal with personal information and content that cannot be moderated? Who actually benefits from this?
Actually 99% of the most successful portal implementations allow personalization. This creates a sense of involvement to the user. Personalization can be implemented on several levels, e.g. by allowing the users to create a personal page, on which they could give information about themselves to their co-workers, but also by allowing users to create favorites and subscribe to news feeds or maybe even by letting them install their own portlets to a dashboard so they can configure them to show the content they need to do their job.
Our advise: If you really want buy-in from your users, allow a certain level of personalization in your portal.
10.Metadata, labeling and categorization is something we’ll start doing when it’s necessary
Label your content right away and use the information analysis to guide you in how to label your information. What’s worse than a portal filled with useful information, but employees that can’t find any of it.
Most portals support various search engines. An advanced search engine can already solve some of the problems, but the main responsibility lies with the content editor / publisher.
Our advise: Make sure the field “label” (or “category” or “metadata” depending on the portal product) is mandatory and that your content editors are well informed about the possibilities and consequences.
Want to know more about our portal solutions? Get in touch!