Knowledgebase : 8) Product Compatibility
   

Browser

Safari isn’t yet fully supported - it works well with the majority of the bricks and widgets so compatibility depends on what you have used to construct the page you want to view, minor problems associated are broken links and windows not resizing - Firefox and IE are supported and available on Macs but as the iPad is a closed platform, you can’t install either of these until Apple yield to public pressure.

The Toolkit used to manage users, edit templates and build new areas etc is built using IE proprietary Javascript so your VLE administrator will need to use a PC or boot the Mac into Windows for this type of function (IE for MAC is not quite the same so still won’t work for this part of Frog) however this doesn’t apply to students as they won’t use the Toolkit.

The If Device brick has been introduced to Frog to allow users to partition their websites for mobile and tablet users. This makes it easier for users to construct mobile friendly sites.

Touch Pad

In addition to the above browser issues, you have the normal tablet and iPads problems due to the fact you are using a Touch device, (this is a problem for many web-based applications, not just Frog).

Many of the more complicated Frog functions rely on complex Javascript behaviours that are not supported by Touch devices.  Webfiles relies on 'click' events to execute certain behaviours, touch devices do not register this type of event so it doesn’t work.
 
Having said that there are potential work-arounds, “Shared Resources” in a Workspace allows you access to files directly (touch a file to select | Action | View on an iPAD or iPhone) but you can’t drill down into a folder structure - if you know this and plan construction of areas that Pupils will access so they don’t use folders there’s no problem.

Frog have also introduced single click network file functions which allow the Network Files brick to work with touch devices.


What are Frog doing about it?

Frog is investigating mobile templates using the current Frog page building system that will allow content to be displayed correctly on mobile devices. We hope to have a way to detect the type of device you have come from when you hit a web page, then the system can re-direct you to a page which is designed specifically for that device.

The hope is that using nested pages we can achieve different views of the same content on multiple devices.  Even if we can’t automatically redirect, you could place an iPad button on the home page and users take themselves to the relevant ‘alternative’ areas built in Frog 3.

FrogLearn has a wider scope of compatibility with mobile devices so it may be worth investigating FrogLearn activation for your school if you wish to use mobile devices intensively.

We have two official states for browser support - 'tested' and 'supported':


Tested - FrogLearn has been specifically tested in this environment. The Service Desk will log any incidents and report problems (bugs) to the development team for investigation.


Supported - FrogLearn is expected to function in this environment but FrogLearn does not necessarily receive a full test pack to cover all scenarios. The Service Desk will log any incidents and report problems (bugs) to the development team for investigation.

Environments that fall out of this are unsupported and whilst we will attempt to help with a work around where possible, problems are not reported to the developers and a such as not likely to be resolved by a formal build.

At present, FrogLearn is fully tested under:

  • Internet Explorer 10 (Windows 7)
  • Internet Explorer 11 (Windows 8)
  • Chrome (Latest two versions)
  • Safari under iOS (Latest two versions)


Although the above browsers are the only ones that receive a full test as part of rollout, due to its use of HTML5 and CSS3 FrogLearn should perform well in any modern browser - including Safari (OS X) and Firefox.

Whilst Frog is developed to work on all modern browsers, as with other applications of its type, you may notice differences from browser to browser.

 

 

 

 

 

Due to a recent change in Google Chrome, the prompt for 'insecure content' (i.e. content coming from HTTP and not HTTPS) is fairly well hidden. We are working with our developers to investigate this issue but should you discover embedded websites are not working, a number of workarounds exist:


Option 1 – Use a different browser. We have tested using IE9 and IE10

Option 2 - Use the following workaround:
When you load up a site that has HTTP content trying to be passed in Chrome you will see a shield icon appear in the top right-hand corner of the browser address bar. Click on this shield and then click on the text "Load unsafe script". The page will refresh and when you go back to the site/dashboard the site entered into the "Website" widget will now load successfully.

Option 3 - Manually apply the appropriate windows or Mac workaround solution provided below -
- On Windows
1). Right click on your "Chrome" icon
2). Choose properties
3). At the end of your target line add the command line flag. For example - "--allow-running-insecure-content"
4). With that example flag, it should look like – chrome.exe --allow-running-insecure-content

- On an Apple Mac
1). Open up terminal
2). Run the command /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-running-insecure-content
This will automatically open up Google Chrome with mixed mode essentially enabled for this one single browser session.