Dedicon is a Dutch foundation who specializes in making (school)books, papers, magazines, sheet music and other information available to people with a reading restriction. Examples of such reading restrictions are a visual impairment, dyslexia, or motor restrictions. The head office is located in Grave, with a studio location in Rijswijk.
The most important clients for Dedicon are the Dutch Ministry of Education, Culture, and Science as well as the Dutch Royal Library.
Dedicon also delivers its audio products to clients through a streaming service. For this service a platform migration was executed in 2016. After this migration clients responded with vague complaints, like: “it was working yesterday”, “it is slow”, or “it is not working”.
Even after some detailed questions users were not able to point out what wasn’t working. Dedicon decided to ask IT visibility for help with a health check on their app and its underlying streaming media platform.
This case study shows our troubleshooting approach and the findings on a health check in a complex application environment like this streaming media service.
How an app can impact user experience with half-duplex connections
There are several ways users can access the streaming media service:
- the “Daisylezer” app is based on the combination “Appcelerator Titanium” and “BASS/2.4”. Appcelerator Titanium is the development platform and BASS/2.4 is the MP3player that Titanium uses. This combination is used for both Android and iOS devices.
- a regular web browser like FireFox, typically used for downloading the MP3 audio files and play them later.
- an appliance called the Webbox, a kind of browser-in-a-box identified as KWR/3.6.704; brought on the market by Solutions Radio.
The different ways users are accessing the streaming media service (sorted by amount of hits)
However, it was unclear which part of the service played a role in the negative user experience.
The Health-check showed that the “Daisylezer” app did a partial end of an existing connection followed with a new half-duplex type of connection. From there on, users where experiencing delays and errors when doing 2 or more actions repeatedly. Due to this half-duplex behavior, the server-side was not able to stay in sync with the client-side.
Users who waited a few seconds between 2 actions didn’t suffer from this half-duplex behavior. The server-side was fast enough to complete the transaction within the user wait time. Hence some users reported issues while others didn’t. Moreover, the ones who reported problems were bnog able to explain clearly when-and-what.
Download this case study as PDF
This case study, which is only available as a PDF, describes the setup, the findings and the solution to these problems.
Please click here to get your copy of this PDF. Be aware that depending on your browser and its settings this request form could open a new window.
