Apprix Builder training tool is used simul­ta­ne­ously by dozens of clients, in hundreds of training courses and by thousands of users. It is obvious that dif­ferent parties have quite dif­ferent needs and expecta­tions, relating to the deve­lopment of the Builder tool, which are dif­ferent from those of others. The aim of this blog post is to disclose and talk a little about the ways how Apprix handles product deve­lopment in a manner that wishes of eve­ryone involved could be satisfied in the best pos­sible way.

Builder has been set up such that it allows to perform a wide range of eLe­arning courses, while making all its fun­c­tions avai­lable via a web browser. The­refore, the same software needs to have a really large number of dif­ferent fun­c­tions used by dif­ferent users.

The core prin­ciple of deve­loping of the Builder system is that:

  • We are basi­cally ready to implement the system such as to include anything that the customer wishes.
  • Our aim is to realise all the most com­monly used items on the wish list such that they could be offered to any other Builder users as well.

The above-men­tioned prin­ciples are not self-evident, and not all com­panies pro­viding SaaS (Software as a Service) ser­vices are ope­rating in this manner. For instance, it would be much easier to have no client-spe­cific custo­mi­za­tions ever made to the software, and instead provide just one and only software version which is the same for all (in fact, it is a quite common practice: or have you ever heard about Microsoft pro­viding someone their requested custo­mi­sa­tions to word pro­cessing, spre­ads­heets, etc. software con­tained in Office 365).

Our top-level objectives relating to the custo­mi­sation options for Builder are, among others:

  • Making Builder easy to use for both those involved in planning training courses as well as for par­ti­ci­pants in these courses. 
    • We remain faithful to the prin­ciple of user-fri­end­liness, even though Builder offers many dif­ferent functions.
  • Our aim is to use such content and exer­cises in the training courses that serve the learning process in the best pos­sible way.
    • For example, it might be necessary to use slightly dif­ferent training tasks in dif­ferent learning situations.
  • In terms of grap­hical repre­sen­ta­tions, the training courses are made to match the custo­mer’s wishes. 
    • Custo­mi­sation of the grap­hical repre­sen­tation means that colours and fonts, as well as images used in the training mate­rials are con­si­stent with the cli­ent’s own visual branding.

While we are pre­pared to widely modify our training system in accor­dance with our customers’ wishes, we get a large number of requests relating to the deve­lopment of the software, which some­times even cont­radict each other. In order for us to be able to control the flow of wishes, our product deve­lopment is divided into three dif­ferent stages in terms of responsibilities:

1: By requi­rement mana­gement we mean that we collect all ideas ori­gi­nating from dif­ferent sources into the same “barrel of wishes” (Feature back log). Deve­lopment ideas could come from the customer, as well as from our­selves, and they might apply to new requi­re­ments relating to the software or, as some­times happens, to bugs / inco­he­rencies that need modi­fi­cation / repairing. We go through these deve­lopment ideas, pri­o­ritise them and plan their imple­men­tation rhythm. The most urgent requests are attri­buted the highest pri­ority, while in many cases it is fea­sible to implement several requests relating to the same topic at the same time. The objective and the end result of the requi­rement mana­gement process is to make sure that our deve­lopers have a clear understanding of what is going to be add­ressed next.

2: At Apprix, imple­men­tation of indi­vidual deve­lopment ideas is handled by a team of highly qua­lified software deve­lopment experts. For each imple­men­tation, a sui­table team of experts in tech­nical archi­tecture, user expe­rience / user inter­faces, grap­hical repre­sen­tation, pedagogy as well as tech­nical imple­men­tation and testing is assembled on a case-by-case basis. The team will make sure that the imple­mented product satisfies the fun­c­tional needs, is easy to use and, on the other hand, can be integ­rated natu­rally into other fun­c­tions of the system.

3: When the new fun­c­tio­nality has been rea­lised, the pub­li­cation mana­gement will make sure that the fun­ction becomes a part of the Builder system in a con­trolled manner. In this context, it is further ensured that any code made for the Builder is imple­mented such as to integrate into and become a part of the rest of the code. The code, for example, is checked to make sure that it com­plies with the com­monly defined security practices and that e.g., highly similar needs are not add­ressed dif­fe­rently in dif­ferent parts of the software.


Finally, the goals we set, the wishes of our customers and the clear product deve­lopment process have led us suc­cess­fully to the point where Builder is, on the one hand, a spe­cific system tai­lored to the needs of each indi­vidual customer, while on the other hand, offering all our customers a pos­si­bility to benefit of our con­tinued product deve­lopment efforts. 

Our objective is to work at any point of time on a number of major deve­lopment pro­jects, where certain totally new fun­c­tio­na­lities are being imple­mented into the software. In addition to major deve­lopment pro­jects, we are typi­cally working on some dozens of minor indi­vidual requests / ideas. Thanks to our skilled and effi­cient deve­lopers as well as the clear product deve­lopment process, in prin­ciple, something new is published in Builder every week: whether minor repairs or larger new fun­c­tions. And these fruits of our deve­lopment efforts are there to be enjoyed by our entire clientele.

Welcome aboard to use this eLe­arning tool that is tai­lored to your needs and wishes.

-

Author

Antti Rasi

As a member of the Apprix team, the author is involved, inter alia, in the impro­vement of the product deve­lopment process, as well as designing of the archi­tecture and new functionalities.