DO YOU UNDERSTAND?

In software there are a lot of definitions. As a customer it can be that you have never heard of these definitions, which makes it difficult to understand when we ask for certain information or if we tell about new features in the system. For example customized content; if there is something from a system at your organization that you want to show on screen (numbers, birthdays, etc.), then an API is needed which we implement in a HTML5 widget… Sorry, what? For this reason we made a glossary below which explains most used definitions to make it easier for you.

1. SaaS

You hear it often in the software world: SaaS. But what does it mean? SaaS stands for Software as a Service. This means that the software can be reached through internet. Clients get a subscription for software and pay for usage instead of doing a one-off purchase of the software. The client doesn’t need to install anything and all data is saved online in the cloud on servers. The advantage of this is that the software and all data is reachable from every computer with an internet connection. Next to that maintenance, service and support are delivered with the subscription by the party where it is purchased from. This opposite from local software: here you pay a one-off fee for the software which then has to be installed and maintained by the purchaser itself. With local software the data is only available locally, so on the respective computer.

The client uses the software by logging in onto the website of the company. This happens through the browser, like Google Chrome or Safari from Apple.

2. Sprints

Sprints are part of the so called Agile software development method. A sprint is a period, usually 2 till 4 weeks in which specific tasks are being completed and are set up for appreciation. Think of new features, improvements and bugfixes that are planned for different sprints. Every sprint has a number that increases (sprint 1, sprint 2, etc.), so we can keep track how many sprints it takes to finish certain tasks. 

Every sprint starts with a meeting to make a planning. Through different departments within a company requests for features and notifications of bugs are ending up at the software department. They are being discussed every two weeks by the software department and then are being planned into different sprints. By dividing the tasks in the sprints, it is immediately clear when what features, improvements and bugfixes are becoming available. After completing a task, it is tested by a tester. When everything has been tested and there are no issues, a regression test follows. During a regression test it is checked if the changed parts of an application or software are still working correctly. After this has been completed successfully, all changes are merged to the live server (releasing).

So the route of a sprint is as follows: a request comes in, the request is being put in a sprint, the developer works on the request in the respective sprint, the solution is being tested and then it is being released.

3. Releases

The narrowcasting portal is constantly developing. Bugfixes, improvements and new features are being done. Developers work on these in sprints. A release, also called a stable version, is a version of the software on the test server on which developments are done and the programmers are not sure yet if it is free of bugs. For this reason on the test server it is tested if everything is in order. When a sprint is completed including the testing, the release is put live, so clients can use the new version. Clients don’t need to do anything for this, pushing the release is done by us. After the release, release notes are shared. In these notes the changes and new features are described that have been released. 

4. CMS

A CMS (content management system) is a software application, usually a webapplication. Through the CMS of the narrowcasting portal the client manages his or her content, schedule and media players. A CMS makes it possible for clients to publish documents and data on internet in a simple way without needing a lot of technical knowledge.

The CMS is the bridge between the users and the underlying techniques, like the backend. The client adds content or schedules a playlist through the CMS. The CMS makes sure this is saved in the background in databases and is being ‘translated’ so the media players can play the content and playlists.

Through a webbrowser the client logs in into the narrowcasting portal. After loggin in the client accesses the CMS. Through a menu on the left side of the CMS the client can reach all the functionalities.

5. Animations (relative to static)

An animation is a serie of quickly upfollowing images that form a moving image. An animation adds movement to a clip so it is more dynamic and track attention. We develop as well widgets as templates with animations. The Creation team makes attractive animations and the technical team makes sure that these animation are being processed well by the media players.

6. HTML5

HTML (HyperText Markup Language) is a layout language for web pages. HTML5 is the latest version of this standard. Widgets are written in this language. In the CMS a lot of HTML5-widgets are offered. The development team creates these widgets and makes sure they are available in the CMS. When a client requests a customized widget, this widget is written by us in HTML5.

The client chooses a widget through the CMS and can schedule it. We can create customized widgets for clients. Think of existing widgets in company branding or a completely new widget with a connection to a clients’ system.

 

The following programmer languages are being used in the widget:

1. HTML5 = Layout
2. CSS = Styling
3. jQuery = JQuery is a free JavaScript-framework for dynamic and interactive websites, among others for editing the DOM and CSS and interaction with the web server. Next to that we also use jQuery plugins.

Hoe it will go in the system for creating and programming widgets:

1. The client creates widgets
2. The widget read the feed/input and this is being visualized by CSS en jQuery
3. The client schedules the widget on the media player
4. The media player plays the package of HTML5 (a HTML5 widget is a package of different programmer languages)

7. Connections

Connections are being developed and maintained by us, which means the client doesn’t have to look after this. Clients only choose the widget with the wished connection in the CMS. An example of a connection is a RSS feed, for example from BBC. The widget connects the RSS feed from BBC in which the news items are held. If a client adds this widget to their schedule, the news items are automatically gained by the widget and shown on screen. This way you always show the latest news on screen. Because of the connection a diverse number of information can be displayed on screen. We offer some standard connections, but also client specific connections are possible to be made.

8. API

An API (application programming interface) makes sure an application can communicate with another application.

An API is a set of definitions with which software programs can communicate mutually. It serves as an interface between different software applications for which used code automatically gives access to information and/or functionalities without having the developers to know how the other program exactly works. API’s exist for (web) applications, software libraries and operating systems and can be used for different purposes.

 

The information is being retreived with the programmer language JQuery. This can be JSON, RSS or XML. Here some examples:

RSS: https://www.nu.nl/rss/games

XML: https://widgets01.cms-ds.com/transcode/handler/getOpenweather?lang=nl&city=Leiden

9. Screen region

A screen region is a screen which is divided in multiple zones. At the bottom you can find a footer, also called tickertape, in which you can show news items. On the sides, the side bar, you can show extra information. Think of a queueing management system, waiting times of traffic news. The largest part of the screen contains clips from the playlist you scheduled.

The sidebar and tickertape are being scheduled on player level. This will be shown at all times. At this moment it is necessary that some settings are being done with activating a screen region, so the content that you schedule is shown in the right framework and is not particially hidden behind the footer or sidebar. We are working on an improvement with which this is automatically set when activating a screen region.

10. (Adobe) After Effects clips

An After Effects clip is a video that is being generated by the narrowcasting portal after the client filled in data, like text or images. Next to widgets you also have After Effects clips and these together are the all you can create from your account.

After a client has filled in the data for the template, the clip is being rendered on the server. After rendering the player can play the clip. After Effects clips are different in this than widgets; when a widget is being played, this is being rendered by the player. The player makes the calculations where which pixel must be shown and how animations must be processed. For After Effects clips this has already been done on the server and these clips ask for less calculation power from th e player and will play on every type of player the exact same thing. Across from that the After Effects clips need to be rendered by the server and with that they charge the server (the more After Effects clips are being made, the longer it takes before they are rendered because they are queueing).

11. SMIL

SMIL (Synchronized Multimedia Integration Language) is, shorty said, the playlist of a player.

In the CMS a client creates a program. When they are satisfied with this, they synchronize it with the media player. This is where SMIL comes in. When a player is being synchronized, a SMIL is generated. A SMIL contains everything a player does; which clips must play and when, what time the player must be turned on and off and how the screen region is defined. So everything a client has set in the CMS.

After a client has put up a program, the SMIL is put ready on the server. The player will download the SMIL and will read this, so it knows exactly what it should play.

A client is not involved in the SMIL process. In the CMS the client puts together a schedule and generated by the SMIL in the background and sent automatically to the player.

12. Synchronization

With the synchronization the schedule and settings that a client has set in the CMS are copied to a player. The player will exactly play what is scheduled on the moment of synchronization.

During the synchronization a SMIL is generated by the narrowcasting portal for the respective player(s). After synchronization the SMIL is downloaded automatically within 5 minutes by a player, if this player is online. The synchronization happens automatically one time per day, but players can easily be manually synchronized from the CMS with the synchronization button.

In short: with the synchronization the actual schedule and settings from the CMS are taken over by the media player.