Compatibility Issue with SiteKiosk and IE10 on Windows 7

We are currently investigating a SiteKiosk startup issue that occurs when SiteKiosk is used on a Windows 7 system with Internet Explorer 10. Under the restricted SiteKiosk user the SiteKiosk browser may not be able to start properly because of problems with the new Webcache folder introduced by IE10.

 

It is recommended to not upgrade to Internet Explorer 10 on Windows 7 systems. Microsoft provides a toolkit to prevent systems from automatically receiving the IE10: http://www.microsoft.com/en-us/download/details.aspx?id=36512.

 

We are working on this issue and try to resolve it as soon as possible.

People who are already affected and experience a loop during SiteKiosk startup can use the instructions from this FAQ to reset the system: http://www.provisio.com/en-US/CustomerSupportCenter/ArticleDetails.aspx?ArticleID=364.

 

Please note that Windows 8 with IE10 is not affected.

Changing the User Agent of the SiteKiosk Browser

The user agent string is used to identify the browser with which a client contacts a server. This information can be utilized to decide what kind of content is delivered to the client in return, to make sure the browser receives data that is optimized for exactly that type of browser. 

SiteKiosk uses the public WebBrowser control of the Microsoft Internet Explorer installed on the system. This means that SiteKiosk identifies itself with the same user agent string as the IE. When a standard configuration is used SiteKiosk will add SiteKiosk Version Number at the end of the user agent string, e.g. SiteKiosk 8.6.1251. A full user agent string under SiteKiosk will look like this:

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SiteKiosk 8.6 Build 1251)

Adding SiteKiosk to the user agent can be used for example to let a server deliver SiteKiosk Object Model code to a client. You can deactivate this behaviour in the SiteKiosk configuration and you can also add your own identifiers. You can find more information on this topic here: http://www.provisio.com/helpconsole/SiteKiosk%20Help/en-US/default.htm?advanced_settings.htm#three.

Ideally the above means that your client browser receives the content it is supposed to display in the most suitable form. If a kiosk project is created from scratch, the content can be optimized to fit the kiosk. Even in projects where content has already been created, it will usually run without modifications on the kiosk, because the content has already been designed for usage in a standard browser like IE.

In some cases though, it might come in handy if your browser could pose as something completely different, for example in a kiosk project where touchscreens should be used. The web pages that should be displayed are already existing in a version for normal browsers and in a version for mobile phones. The mobile phone version would fit perfectly but the server dynamically delivers its content based on the user agent. This means on a normal Windows system you would get the version for standard desktop browsers and not the version for mobile phones. The solution is to completely change the user agent string to one of a mobile phone.

Microsoft already provides this option by means of editing the Windows registry using the registry editor (regedit.exe). Note that changing the registry is always done at your own risk. Making the browser pose as another may also cause script errors or corrupted page layouts. You should carefully experiment with the values described next before applying it to live systems.

The registry key we will have a look at is for the Internet Explorer, but as SiteKiosk is based on the Internet Explorer it also uses it. That means changing the key will change the behaviour for IE and SiteKiosk. A detailed article on the topic of the user agent string on Windows systems can be found here: http://msdn.microsoft.com/en-us/library/ms537503%28v=vs.85%29.aspx. The registry key can be found at two different locations in the Windows registry.

One location is under

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Note: on a 64-Bit system the location is slightly different

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Editing that key changes the behaviour for all users on the system.

The other location is under

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Editing that key only changes the behaviour for the current user. This means to edit this key you must be logged in with the user you want to change the behaviour for.

On most systems the above key only contains the default value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Default). For the desired effect we need to add two additional string values (unless they are already there). One is called Platform and the other Version. As an example we will add the following data to Platform (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Platform)

Linux; U; Android 4.0.4;

and the following data to Version (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Version)

AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

These are values an Android smartphone uses. When the changes are done, we can see the effect by opening the SiteKiosk browser (or IE, as both are using that registry key) and going to www.nytimes.com. With the changes we will be directly transferred to the mobile version of the page. The SiteKiosk user string now looks like this:

Mozilla/5.0 (compatible; AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30; Linux; U; Android 4.0.4;; Trident/5.0; SiteKiosk 8.6 Build 1251)

If the above workaround is suitable for your project and you want to spare yourself the hassle of manually editing the registry on all your kiosk systems, you can use the SiteKiosk ProgramPatcher tool to automatically apply the registry changes.

Starting the SiteKiosk File Manager from a Link

The SiteKiosk file manager is usually started from the Start button in the task manager or the programs page. But it can be handy to start the file manager from a link or button link, especially when using the SiteKiosk Portal Startpage.

The file manager is built using HTML, but because of its capabilities it is hosted in a special dialog window. As a consequence just starting the selector.html, which is the base file for the file manager, is not an option. You can of course edit the code of the Portal Startpage, but there is a much simpler approach to it. We will just create a simple html page that will take care of opening the file manager. You can either put the file on the local machine (recommended location: ..\SiteKiosk\html\) or a web server and then create a new link in the settings of the Portal Startpage that uses this page.

Our example page will consist of two methods. The first one is not really required to start the file manager, but it will make the process more complete. It basically checks if SiteKiosk payment options are used and if they apply to starting the file manager. If that should be the case the process of opening the file manager will be aborted and the SiteKiosk payment information dialog shown. More information about this part of the code is available here. Now this is what the first method looks like:

function OpenMediaWindow()
{
	try
	{
		var lk_SiteCash = SiteKiosk.Plugins("SiteCash");
		if (lk_SiteCash == null || lk_SiteCash == undefined || lk_SiteCash.Enabled && !lk_SiteCash.PayApplications || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || lk_SiteCash.Enabled && lk_SiteCash.CurrentBalance > 0.0 || lk_SiteCash.Enabled && lk_SiteCash.ApplicationPrice == 0.0 || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || !lk_SiteCash.Enabled)
		{
			OpenIntWindow();
		}
		else
		{
			SiteKiosk.Plugins("SiteCash").ShowPaymentInfoDialog(0, "", false);
		}
	}
	catch (e)
	{
		OpenIntWindow();
	}
}

As you can see in the above code, it tries to open another method named OpenIntWindow once the prerequisites are met (or in case of an error, when it goes to the catch part). The OpenIntWindow method deals with opening the actual file manager window. It looks like this:

function OpenIntWindow()
{
	var WS_OVERLAPPED = 0x00000000;
	var WS_MAXIMIZEBOX = 0x00010000;
	var WS_MINIMIZEBOX = 0x00020000;
	var WS_THICKFRAME = 0x00040000;
	var WS_SYSMENU = 0x00080000;
	var WS_BORDER = 0x00800000;
	var WS_CAPTION = 0x00C00000;     // WS_BORDER | WS_DLGFRAME
	var WS_MAXIMIZE = 0x01000000;
	var WS_MINIMIZE = 0x20000000;
	var WS_POPUP = 0x80000000;
	var WS_OVERLAPPEDWINDOW = WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX;
	var WS_EX_TOOLWINDOW = 0x00000080;

	var mediabox = SiteKiosk.SiteKioskUI.CreateHTMLDialog();
	mediabox.URL = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Selector.html";
	mediabox.Styles = 13565952;
	mediabox.Icon = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Img\\Icons\\fms_ico.ico";
	mediabox.Width = screen.width > 800 ? 1024 : 800;
	mediabox.Height = screen.height > 600 ? 700 : 550;
	mediabox.ExStyles = 0;
	mediabox.Border = true;
	mediabox.Type = "FileManagerDlg";
	mediabox.TopMostWindow = false;
	mediabox.CloseOnInput = false;
	mediabox.Parent = SiteKiosk.WindowList.MainWindow.SiteKioskWindow.Window;
	mediabox.ShowDialog();

	window.close();
}

The first part of the method sets the different window styles used for the file manager dialog. The second part creates an HTML dialog object (SiteKiosk.SiteKioskUI.CreateHTMLDialog();) and assigns window styles, height, width etc. to it. You can learn more about this part here in the SiteKiosk Object Model help. The last line of the method tries to close the window or html page is using now that it has done its purpose of opening the file manager. This will of course only work if the link opened in a new window, which is the default behaviour for the SiteKiosk Portal Startpage.

Now we just put the two methods together and place it in some simple HTML. This is what we get:

<html>
	<script type='text/JScript'>
		window.external.InitScriptInterface();

		function OpenMediaWindow()
		{
			try
			{
				var lk_SiteCash = SiteKiosk.Plugins("SiteCash");
				if (lk_SiteCash == null || lk_SiteCash == undefined || lk_SiteCash.Enabled && !lk_SiteCash.PayApplications || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || lk_SiteCash.Enabled && lk_SiteCash.CurrentBalance > 0.0 || lk_SiteCash.Enabled && lk_SiteCash.ApplicationPrice == 0.0 || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || !lk_SiteCash.Enabled)
				{
					OpenIntWindow();
				}
				else
				{
					SiteKiosk.Plugins("SiteCash").ShowPaymentInfoDialog(0, "", false);
				}
			}
			catch (e)
			{
				OpenIntWindow();
			}
		}

		function OpenIntWindow()
		{
			var WS_OVERLAPPED = 0x00000000;
			var WS_MAXIMIZEBOX = 0x00010000;
			var WS_MINIMIZEBOX = 0x00020000;
			var WS_THICKFRAME = 0x00040000;
			var WS_SYSMENU = 0x00080000;
			var WS_BORDER = 0x00800000;
			var WS_CAPTION = 0x00C00000;     // WS_BORDER | WS_DLGFRAME
			var WS_MAXIMIZE = 0x01000000;
			var WS_MINIMIZE = 0x20000000;
			var WS_POPUP = 0x80000000;
			var WS_OVERLAPPEDWINDOW = WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX;
			var WS_EX_TOOLWINDOW = 0x00000080;

			var mediabox = SiteKiosk.SiteKioskUI.CreateHTMLDialog();
			mediabox.URL = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Selector.html";
			mediabox.Styles = 13565952;
			mediabox.Icon = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Img\\Icons\\fms_ico.ico";
			mediabox.Width = screen.width > 800 ? 1024 : 800;
			mediabox.Height = screen.height > 600 ? 700 : 550;
			mediabox.ExStyles = 0;
			mediabox.Border = true;
			mediabox.Type = "FileManagerDlg";
			mediabox.TopMostWindow = false;
			mediabox.CloseOnInput = false;
			mediabox.Parent = SiteKiosk.WindowList.MainWindow.SiteKioskWindow.Window;
			mediabox.ShowDialog();

			window.close();
		}
	</script>
	<body onload="OpenMediaWindow();">
	</body>
</html>

Note the extra line at the beginning of the script part (window.external.InitScriptInterface()). It tells SiteKiosk that SiteKiosk Object Model code follows. If you allowed this page to use such code, it will be executed. Once the page is loaded it calls the first method using onload. The script checks whether payment is required and then opens the file manager (or the payment information dialog).

That's it. The above should help in all cases, where you want to start the file manger from a link/button link. This includes the SiteKiosk Portal Startpage but could even used on any html page, including pages located on the Internet.

Please be aware, that you should activate the file manager in the configuration of SiteKiosk to make full use of this code example.

File synchronization on a SiteRemote Server that uses port forwarding

The following advice only applies if you run your own SiteRemote Server (3 and above) and you need to use port forwarding on the server side. This basically means that the address (IP or host name) you are using on the clients to reach the server is not the actual SiteRemote server itself.

Under the above circumstances you might notice that file synchronization (used for the File Manager and Digital Signage features) does not synchronize any content to the client. Should this be the case and the basic client server communication (registering the client on the SiteRemote server, client status updates etc.) is working, you can try to make a change to the SiteRemote server configuration file. The file is located under ..\PROVISIO\SiteRemote\Config and is named SiteRemoteServer.config. Before you edit the file you should stop the SiteRemote Server Windows service in the Service Management Console of Windows (services.msc) and make a backup of the original. Then open the file with Notepad or your preferred editor and look for the line:

<Torrent.config ClientPort="52138" />

This tag already includes the port used for file synchronization. You can add ClientIPAddress to that tag to force the client to contact the server under a specific IP, in this case the IP of the port forwarder in use. So after the change the line will look like this:

<Torrent.config ClientPort="52138" ClientIPAddress="12.12.12.12" />

Save the SiteRemoteServer.config file and start the SiteRemote Server Windows service again. The new information will be distributed to the clients on the next connection. Note that you may need to stop and restart running synchronizations to see the effect.

Manipulating the DOM with the SiteKiosk Object Model

Web pages that are used for a kiosk project are often ones that have been created before the kiosk project started and have not necessarily been created with kiosk usage in mind. In most cases this does not matter. But sometimes the requirements of a kiosk project may ask for special handling if a page is displayed on a kiosk (e.g. change button size). Ideally the web pages are then adapted, but this may not always be possible, e.g. because direct access to edit the pages is not possible.

With the help of the SiteKiosk Object Model pages displayed within the SiteKiosk browser (Internet Explorer engine, for the Chrome variant please have a look here) can be altered by directly editing the DOM of a page. For that you need to look at the source code of a page, e.g. by using the developer tools of IE, Chrome or Firefox, and find the appropriate places that need to be changed.

The following example demonstrates this by changing the Google page to show SiteKiosk as the search term and to use 'Search for SiteKiosk' as the caption of the search button. Copy the code example to Notepad and save it as a .js script file with whatever name you like, e.g. manipulatedom.js. Open the SiteKiosk configuration, go to Start Page & Browser or Browser Design (depending on the SiteKiosk version you are using), click on the Advanced button and add the script as an external script file. Save the configuration, start it with SiteKiosk and go to www.google.com to see the effect.

SiteKiosk.Logfile.OnMessage = OnMessage;
function OnMessage(seq, time, utcoff, awtype, awlevel, facility, text)
{
    if(text.indexOf("Navigation:") !== -1 && text.indexOf("google.") !== -1)
        evtid = SiteKiosk.Scheduler.AddDelayedEvent(1000, ManipulateDOM);
}
 
function ManipulateDOM()
{
    for (var i=1;i<=SiteKiosk.WindowList.Windows.Count;i++)
    {
        try
        {
            if(SiteKiosk.WindowList.Windows(i).SiteKioskWindow.SiteKioskWebBrowser.WebBrowser.LocationURL.indexOf("https://www.google.") !== -1)
            {
                SiteKiosk.WindowList.Windows(i).SiteKioskWindow.SiteKioskWebBrowser.WebBrowser.Document.getElementsByName('q').item(0).value = "SiteKiosk";
                SiteKiosk.WindowList.Windows(i).SiteKioskWindow.SiteKioskWebBrowser.WebBrowser.Document.getElementsByName('btnK').item(1).value = "Search for SiteKiosk";
            }
        }
        catch(e)
        {
            //SiteKiosk.Logfile.Notification("Editing the DOM failed for window: " + SiteKiosk.WindowList.Windows(i).ItemText); //Debug
        }
    }
}

The for part of the above code goes through all open windows to find the one that shows the Google page and apply the code.

Note that when using the above example you should make sure to take care of local laws, ownership rights, copyright etc. Also note that the above example only works as long as Google does not change the code of their page.

Securing the SiteKiosk browser with Microsoft EMET

SiteKiosk uses the browser engine of the installed Internet Explorer to render web pages. To minimize security risks you should therefore keep the Internet Explorer updated by using the automatic Windows Update feature that comes with the operating system.

Unfortunately there is the risk of so called zero day attacks. There was one just recently that affected the Internet Explorer and was covered extensively in the media. Because SiteKiosk uses the Internet Explorer engine it is also affected. While the security features of SiteKiosk do limit the attack options to a certain degree a possible risk remains.

It is also notable that one aspect of zero day attacks is, that even antivirus software does not help as a required signature update takes its time to become available.

This is where Microsoft EMET or Enhanced Mitigation Experience Toolkit comes in. The toolkit can be used to harden an application so that flaws cannot be used as easily and zero day attacks have no or a more limited effect. It is free to use and easy to configure.

When you install EMET make sure to select to install it for all users. After the installation is finished you can just add the SiteKiosk.exe and other applications you want to protect using EMET in the EMET configuration. That's it. You can keep on using SiteKiosk as you did berfore, but now with the extra protection that EMET provides.

How to Build a Script Watchdog for External Applications

The secure SiteKiosk browser offers an easy way to run external applications from within the restricted SiteKiosk context. You can just add the desired applications with the help of the SiteKiosk configuration. SiteKiosk will then provide means to start the applications through the SiteKiosk browser interface, it will also close these applications when the screensaver starts or a user logs out. The configuration of SiteKiosk even allows you to automatically start an application when SiteKiosk starts, the screensaver ends or after a user logout happend.

There can be situations where you may want to have even more control of the external application you want to run with SiteKiosk. For example you don't want to use the browser features of SiteKiosk but just want to use SiteKiosk to protect the operating system from being tampered with and your main goal is to permanently run a specific application.
The culprit is that this may be an existing application that for example allows to user to close it. This is where the SiteKiosk Object Model comes in. It is a proprietary Javascript extension that enables you to control nearly all aspects of SiteKiosk but also comes in very handy to create helpful custom scripts.

Let's summarize what we want to achieve with the script we are about to create. SiteKiosk should run in fullscreen mode in the background and on top of that an external application should always be visible.

The first step would be to create a blank page for SiteKiosk running in the background, alternatively you may of course as well use a page with a nice design. Here is the code for the blank page:

<html>
    <head>
    </head>
    <body>
    </body>
</html>

Save it as background.html (or whatever name you prefer) and make sure to put that file into the ..\SiteKiosk\html\ folder.

Next is the Javascript that we use to control the application. The first step is to start the application. For that we are using the Run method of the ExternalApps collection. Because we do need that code later on again, we will put it in a function:

function StartMyApp(){
    SiteKiosk.ExternalApps.Run("c:\\pathtomyapplication\\myapplication.exe", true);
}

The Run method basically expects the path to the application plus a boolean value that specifies if SiteKiosk is to check first if this application is already running. If it is already running, it will be maximized and focused. For the purposes of this script the boolean value should be true to ensure that no additional instances of the application are started.

SiteKiosk or the SiteKiosk Object Model cannot prevent the user from closing an application that provides the user with options to close it. Therefore we now need the code that monitors the application.

We will use the OnRemove event of the WindowList object. The OnRemove event fires whenever an application window (this means every Window that produces a tab in the Windows task bar) is removed. We assign a function to the OnRemove event, in this case also named OnRemove.

That function receives a parameter that is a WindowInfo object and includes information about the window that has just been closed. We use the ItemText property of that object to check if the window title of the window that has just been closed is from the monitored application. If that is the case our application has just been closed and we need to start it again, for that we call the function we already created that start our application. The code for all this looks as follows:

SiteKiosk.WindowList.OnRemove = OnRemove;

function OnRemove(skwin){
    if(skwin.ItemText === "WindowTitleOfApplicationToWatch"){
        StartMyApp();
    }
}

Depending on the speed of the process to start SiteKiosk and the application at the same time or the time the application needs to fully close, the application may not have the focus or start at all. To prevent this from happening we can add a slight delay to starting the application, you may need to test what the best timing is for your individual application. We add the AddDelayedEvent method of the Scheduler object to our controlapp.js script at all the places we want to start the application:

SiteKiosk.Scheduler.AddDelayedEvent(5000, StartMyApp);

We are done. When we put the parts together the complete code of our script looks like this:

SiteKiosk.WindowList.OnRemove = OnRemove; //fires if a window has been closed
SiteKiosk.Scheduler.AddDelayedEvent(5000, StartMyApp); //starts the desired application the first time after 5000 ms

function StartMyApp(){
    SiteKiosk.ExternalApps.Run("c:\\windows\\notepad.exe", true);
}

function OnRemove(skwin){
    //checks if the application that should run has been closed
    if(skwin.ItemText === "Untitled - Editor"){
        //the application has been closed, restart it again
        SiteKiosk.Scheduler.AddDelayedEvent(500, StartMyApp); //starts the desired application the next time after 500 ms
    }
}

Save the code as controlapp.js (or whatever name you prefer) and make sure to put that file into the ..\SiteKiosk\html\ folder.

Now open the SiteKiosk configuration tool and create a new configuration. Set a password, set the background.html file as your start page and then go to Browser Designs, click on Fullscreen and set SiteKiosk to use the permanent fullscreen mode. Still under Browser Designs click the Advanced button and add the conrolapp.js file as an external script (optional: on the same configuration page tick the option to 'Keep the SiteKiosk main window in the background').

Save the configuraion and test the script.

 

Another possibility is creating an external script that checks if the application EXE process is running in regular intervals.

For this you basically need the following methods:
- AddPeriodicEvent Method: http://www.provisio.com/helpconsole/SiteKiosk%20Object%20Model%20Help/en-US/default.htm?scheduler_addperiodicevent_mth.htm
- IsProcessRunning Method: http://www.provisio.com/helpconsole/SiteKiosk%20Object%20Model%20Help/en-US/default.htm?externalapps_isprocessrunning_mth.htm
- Run Method: http://www.provisio.com/helpconsole/SiteKiosk%20Object%20Model%20Help/en-US/default.htm?externalapps_run_mth.htm

The following example script will check if the “notepad.exe” process is running every 30 seconds (30000 ms).
If it is not running it starts notepad.exe again.

evtid = SiteKiosk.Scheduler.AddPeriodicEvent(30000, checkExecution);

function checkExecution(eventID){
   if (SiteKiosk.ExternalApps.IsProcessRunning("notepad.exe") == false){
    SiteKiosk.ExternalApps.Run("C:/Windows/notepad.exe", true);
    SiteKiosk.Logfile.Notification('Application started');
    }
}

Smooth animations on Android

SiteKiosk for Android offers secured browsing preventing any misuse that could mess up your tablet configuration. But it's not only browsing that you can secure with SiteKiosk, also self service applications like for example menus, info terminals or customer surveys can be (and should be ;) run with SiteKiosk. An additonal advantage: you can use the powerful SiteKiosk Object Model to have even more control as normally possible with HTML pages. As I mentioned in an earlier post you can have access to local files via the sk:// protocol for example. We are adding more and more useful functionality to the Object Model in the future, so watch out for new versions. You can also post a comment here stating what you'd like to have us added to the SK Object Model.

Speaking of self service applications we realized early in our development process that android tablets are capable of many things, but still not comparable to desktop computers. Especially the browser component is a difficult story, since on one hand it supports many HTML5 features already (which is fantastic), but on the other hand still has some problems concerning completeness and performance of these new features. So you have to be a bit careful if you program web applications targeting android devices.

One example would be animations. Ever since JavaScript was introduced to the browser world, it has been used to program animations for web pages. Still it is widely used for that purpose on many pages and doing it quite well at least on desktop computers. Concerning Android, doing animations (like transitions) in JavaScript is not the best thing to do (even for desktop computer, but goes unnoticed most of the time). Say you want to create a sliding animation of a particular div containg some content that need to be exchanged when the user pressed a "next" button. You could use JavaScript's setInterval() and periodically update the div's left parameter. Unfortunately this results in poor results since the animation can be jerky on many Android tablets. A better way to do it is using CSS transforms and transitions. These will be hardware-accelerated even on Android tablets and therefore a lot smoother than JavaScript animations. 

An example would be:

<div style="-webkit-transform: translate(-600px, 0px); width=600px">Your content.</div>

This moves the div 600 pixel to the left relative to its normal position. Nice, but still no animation, right? Here you go:

<div style="-webkit-transition-duration: 500ms; -webkit-transform: translate(-600px, 0px); width=600px">Your content.</div>

Adding the "-webkit-transform-duration" will result in transition animations every time you change the "-webkit-transform" value. Obviously the transition will take 500 ms in this case. So Adding these two style properties results in a sliding animation moving the div from right to left by 600 pixels. There are a bunch of other transforms you can use for transitions like rotation, scaling and skewing. You could also use transitions for normal CSS style properties like "margin-left", but these might not be hardware-accelerated, so be aware.

Manipulation these style properties in JavaScript is not a big deal, but can be a bit cumbersome. My adivce is to use the free Move.js which makes adding these transitions dynamically very easy.

 

SiteKiosk Android: access the local file system via the "sk://" protocol

SiteKiosk Android has been out now for a (short) while and we've already gathered important feedback. We've learned that customers want to go beyond what is possible in a normal browser, which makes perfect sense given the fact that SiteKiosk for Windows already provides such possibilities to a great extend.

Accessing arbitrary local files is not allowed in a normal browser with pages coming from a server. This makes sense because security would otherwise be compromised. But sometimes you need to access large image or video files from a page and downloading these files from a server and relying on the browser to cache for example mega or even giga bytes of data doesn't seem very feasible.

So with the release of SiteKiosk Android 1.1 we proudly present: the "sk" protocol. Using "sk://" as a prefix for your URLs allows you to address files in a particular location on your Android device. When connecting the device as a USB drive, this particular location is a folder named "SiteKiosk" directly inside the root folder of the drive. The HTML pages you load in SiteKiosk don't have direct access to this folder but instead to a subfolder named "data".

So suppose you want to show a local image named "test.jpg" in one of your pages in SiteKiosk. Here is the HTML snippet for the image you could use in order to achieve this:

<img src="sk:///data/test.jpg"></img>

Notice the three (!) slashes after the "sk:", the last one stands for the sk root folder and is mandatory (meaning it doesn't work if you forget to write it). The image "test.jpg" must be located in "SiteKiosk/data" (relative to the root of your Android USB drive). Important: you have to create both folders "SiteKiosk" as well as its subfolder "data", so don't be confused if you don't find them after installing SiteKiosk (we may add the creation of these folders to the installation process in a future version).

You can use these "sk" URLs with the 'src' attribute of image, script and link tags at the moment (further support might be available in one of the next versions). Make sure the "Enable SiteKiosk scripting" option is enabled for your page, if you restrict the surf area.

If you have any problems using this feature or have other suggestions, comments, etc., please write a comment or contact us via our web page.

Using SiteCaster offline

Please note that this article refers to a legacy product. We recommend to use the SiteCaster Kiosk CMS instead.

One may think that everthing is connected to the internet nowadays: PCs, Tablets, Smartphones and even refrigerators. But there are still terminals that have no internet or other network connection. SiteKiosk can be used on these machines without a problem. You can show your users local HTML pages that don't require an internet connection. With SiteCaster things are a bit different. Creating campaigns, scheduling and publishing them normally requires a SiteRemote account and a license for each machine. This is without a question the preferred way to bring your content to your terminals.

But some scenarios are a bit too simple to justify the use of such a content management and distribution system. Here I will describe how you can use SiteCaster to play your content, without requiring SiteRemote. 

I am assuming here that you use SiteKiosk 8.1 and want to show a video in the SiteCaster area (either in split screen or fullscreen mode) . The first thing you have to do is switch SiteCaster to offlline mode so that it doesn't wait for a broadcast to be distributed but instead play a local broadcast. In order to do that you need to locate the SiteCaster configuration file named "SiteCaster.config". In Windows 7 and Windows Vista you can find it here: C:\ProgramData\PROVISIO\SiteCaster\. In Windows XP you have to look in this location: C:\Documents and Settings\<your account name>\Application Data\PROVISIO\SiteCaster. Notice that from now on I will mention every path as it appears under Windows 7 with default settings. The paths could be different, if for example your system drive is not c: or when using Windows XP. 

Open the file in Notepad (or your preferred text editor) and make sure the following line appears inside the section SiteCasterPlayerConfigurationData:

<UseOfflineBroadcasts>true</UseOfflineBroadcasts>

The important thing is that the value inside the tag is "true", after a fresh install of SiteKiosk it is set to "false" .

Save the file and the next time SiteCaster starts, it will look in a special location for offlline broadcast data. This location is "C:\Users\Public\Documents\SiteCaster\OfflineBroadcastData" (again for Windows 7 and Vista). You have to create the folders in this path if they are not already present. After you've done this, create another folder, inside OfflineBroadcastData, named ".SiteCasterBroadcasts". This is a bit tricky in Windows Explorer, because it normally doesn't let you create a folder with a name beginning with a dot. But naming it ".SiteCasterBroadcasts.", with an additional dot at the end (that will be automatically removed), will do the trick. Ask your local Microsoft consultant for an explanation why this is necessary ;)

In this folder you have to save the XML file that is attached to this post. It describes the structure of the broadcast that should be played when in offline mode. After you've saved it in this folder, open the XML file in a text editor. You need to find and change the file path for the video that should play:

<MediaFile>
...
<Path>/nature.wmv</Path>
...
</MediaFile>

Replace "nature.wmv" with the file name of your video. This file should then be placed (or copied) into the folder "C:\Users\Public\Documents\SiteCaster\OfflineBroadcastData". There is more to do, you have to set the duration of the video. Find the first occurence of this section:

<EndCondition>
...
<OffsetInSeconds>0</OffsetInSeconds>
...
</EndCondition>

 

 Change the "0" to the duration of your video in seconds, for example "120", if the duration is 2 minutes.

Two more changes and you should be ready to go. Find these two sections and change in each one the width and height to the dimensions of your video:

 

<Section>
	...
	<Width>800</Width>
	<Height>600</Height>
</Section>

  
<Layout>
	...
	<Width>800</Width>
	<Height>600</Height>
</Layout>

 

Save the XML file and you should be done. In the configuration tool you have to enable SiteCaster, either as a split screen setting or fullscreen. The next time you start SiteKiosk, the video should appear in the SiteCaster area.

You can do more than just play a video over and over again. If you want to show a picture, there is just one thing you have to change in comparison to the video and that is <ItemKind>Video</ItemKind> to <ItemKind>Picture</ItemKind> (just search for it, it should only appear once). You can even play files sequentially and on differents channels, but this requires a deeper understanding of the XML format used here.

In case you want to do something more complex, it might be a better idea to use the  SiteCaster online editor in SiteRemote, publish the broadcast created there to a client machine of your choice and grab all the files from there. All necessary files are normally located in the folder right beneath C:\Users\Public\Documents\SiteRemote\Sync\. The name of this folder is either "{1D3F97EE-F5E6-4E81-ABF8-F7754638833E}", if SiteCaster has already been playing the broadcast, or it is the name of the broadcast plus a short postfix starting with "_", for example "SiteCasterOfflineBroadcast_123". Anyway there should be only one folder there normally, so the decision should be easy ;) You should copy the content of this folder (not the folder itself!) to "C:\Users\Public\Documents\SiteCaster\OfflineBroadcastData". Remember to edit the file SiteCaster.config to set the SiteCaster offline mode as described above.

SiteCasterSingleVideoOfflineBroadcast.xml (5.72 kb)