Portals in the real world: How we created the Regio Jobanzeiger Job Portal family

In our previous post, we discussed the advantages and challenges of portal management systems. However, that post was purely theoretical, and we thought it would be a good idea to show you one in action.

The portal we are going to talk about is one we built for Yourfirm.de.

Yourfirm.de

Yourfirm runs a job portal, where job seekers can find and apply for jobs in Germany and Austria. The original jobs portal Yourfirm.de, was doing quite well for its size and business orientation and they decided to grow the business. The goal was to reach more customers in other countries and to provide specialized services for select occupations.

Based on customer feedback and due to SEO considerations, we decided to create several specialized sites for different types of job seekers.

Yourfirm.de, the site, stayed as a general jobs portal but we introduced Regio Jobanzeiger (RJA) for regional jobs and Fachportale (FPO) for specialized jobs.

Each site needed different branding and customization while being managed centrally. So how did we achieve this feat and create a specialized job portal?

Case study - specialized job portals

We had several dimensions to handle, and the potential number of portal instances could range from tens to hundreds. Our dimensions were three different brands spread across three countries, various cities, and even more professions. So, for example, we could have a portal instance for jobs in Munich, Germany, and another for IT jobs in Austria.

With that in mind, we decided to have proper portal management support from the get-go.

Technical Challenges

Firstly we needed a way to manage instance-specific data in the system. This means we needed some extra tables in our database for portal-specific content like default search configuration, and functional data. We needed to model the aforementioned dimensions and decide which combinations were allowed. For example, in every country, we wanted to have regional portal instances and profession-specific instances, but regional profession-specific portal instances would not have enough content to be of any use to users.

The next challenge was to have some kind of preparation logic (in our specific case as middleware) to detect and assign the precise instance based on the information from your user's requests, such as the domain they are accessing the portal on. This detection logic needed to be quite optimized, as it needed to be executed for every single request made to any portal instance.

After detection, the portal type and content information needed to be made accessible to the rest of the application, including the frontend and backend logic, which used it to implement the special handling required.

The frontend needed to handle the different styles for each interface based on the portal type. Instead of coupling the display logic into the frontend we chose to generate several bundles for each instance and only use the appropriate bundle for each brand. This allowed the frontend code to remain fairly simple while allowing each brand to have its own look and feel.

For searching we applied geospatial filters on the search results for regional instances, and profession-based filtering for the profession-specific instances.

Another consideration is how the backend passed information to the frontend. We already mentioned that the frontend used separate bundles for each instance, but it would also need some explicit information about the instance and we passed this information in a configuration object.

The result

Once we implemented the logic for the different kinds of instances and managed the portal-specific data in the portal data management interface, adding new instances could be done with minimal effort and virtually no developer involvement.

The client could also remove and replace instances in case, for example, they decided to redefine the regions or clusters of professions they wanted to use.

Once in place, the portal management system gave them a lot of flexibility in managing portal instances. It only needed extension when they decided to add new features or requested that new data be made instance specific or they introduced a new kind of dimension to differentiate a different portal type that was not supported before.

Branding and Customization

The different brands had their own look and feel which the Portal system handled. Each portal had different color schemes and styling customization, for example, RJA had rounded corner styles while FPO was more squarish.

The customization potential didn’t end there, each portal had its own special features only available to it, for example, FPO portals had a video on their homepage, a feature RJA didn’t have.

This also allowed each portal to set obligatory search parameters by client, so for example, berliner-jobanzeiger.de would have Berlin preselected while muenchner-jobanzeiger.de would have Munich preselected.

This all happened while still allowing all portals to share common data, such as the jobs, and while having a unified search engine that did the matching for all portals.

Finally

Our client is currently managing between 100 and 200 portal interfaces across three different brands in several countries and has seen growing traffic due to targeting the audience in a better way - a success story we’re proud to be part of.

Does the idea of taking your business to the next level with a portal management system appeal to you? Don’t hesitate to contact us, our team of experts builds portal solutions tailored to your needs. We’ll work together to see if a portal management system is the right fit and if so we will gladly develop it for you.