Always Up-to-Date: Live Dialogues for Dispatchers in Public Transport

"Sorry, someone was faster." This is a sentence that everyone who books trips online or buys through portals has probably seen, to their great annoyance. That is completely understandable. Today, GUI toolkits make it possible to design user-centric dialogues. However, a continuous connection to the process that provides or modifies data is rare – which can have serious consequences.

These days it’s not uncommon to see that kind of sentence after spending what felt like an eternity clicking through a complex dialogue, entering a great deal of data and information – without any sign that the offer is no longer valid and that the information is a waste of time. This is simply because almost all dialogues are completed offline, i.e. without a live link between the opened data record and the underlying processes. These are continually updated in the background – with possible consequences for the open data record.

A dialogue – also called a dialogue window, dialogue field or dialogue box – is a component of the graphical user interface that is opened whenever information must be collected from the user. However, as a rule, entries can only be made offline, meaning that a comparison of the information entered and the current situation can only be made after the entry has been completed and submitted. Sometimes the data which was entered has become invalid, or desired actions can no longer be performed.

Stumbling blocks in planning and control systems

Offline processing is also the norm for industrial planning software and for local and long-distance transport applications. Even worse, planning and control systems today generally either provide many compact individual dialogues that fail to take complex dependencies into account, or they combine necessary individual actions into complex dialogues. If it is not possible to make certain changes after the dialogue has been completed, more than simple frustration can result. Most importantly, the desired goals cannot be achieved effectively and efficiently – and the user will certainly not be satisfied. This is in no way fit for purpose or user-friendly.

An application’s usability has long since evolved into an essential measure of its quality and a determinant of user satisfaction, and it contributes significantly to the successful utilisation of applications.

Especially when it comes to unplanned events or deviations dispatchers are required to quickly take the correct steps – in a way that reflects the current situation. Dispatching systems can support this task – for example by

• visualising complex relationships,
• providing checklists and suggestions for action or
• providing acoustic and visual signals.

However, problems always arise when the situation has already changed by the time the dialogue has been completed and individual actions can no longer be performed or have become irrelevant.

Offline and live dialogue in comparison

Figure 1 shows an offline dialogue in which the itinerary of a train is to be shortened using a dispatching measure. Relevant live information such as the current position of the train cannot be displayed and taken into account. The dispatcher can open the dialogue and edit the measure but only when the dialogue is closed the actual implementation of the measure does take place. If the train has already left the station at which the train formation change is to be carried out, the dispatcher only sees this after closing the dialogue.

The solution for an optimal live dialogue

PSI Transcom has successfully addressed this problem and now offers clear advantages for the user. With its adapted PSItraffic platform, both the dialog and the database as well as the actual process are now merged with each other.

As depicted in figure 2, the open live dialogue shows the current status of the underlying process (here train journey) and is also linked to the passenger information. The train handling is carried out as usual in the middle. In the lower part of the dialogue, a preview of the planned passenger information is displayed. This also enables the dispatcher to adjust the passenger information as necessary.

There is now a constant connection between the dialogues and the database. Through this connection, open dialogues always display real-time information or options for action – throughout the entire dialogue process. Data that is no longer up-to-date is greyed out. In the example described, the selected train journey is continuously updated in the upper part of the dialogue. There, the dispatcher can see which stations have not yet been reached.

The days of offline dialogues and frustrating multiple entries in complex planning and control systems are numbered. The continuous connection between dialogues and database helps dispatchers to take measures more efficiently and provides passengers with more reliable information.

With this development, manufacturers like PSI Transcom are not only fulfilling the expectation of a positive user experience for their solutions, they are also increasing the effectiveness of their applications in practice.

More information on efficiency and reliability in rail transport