Category Archives: Research

Synote mobile phone testing

Synote mobile meeting

Testing with the mobile phone  version of Synote is proving exasperating!  The different devices, operating systems and browsers all produce different results despite the fact that the pages have been designed in HTML 5 with media element js player and jQuery mobile.  The transcript, synmarks and the PowerPoint slides all appear to display in the same way on the various browsers and devices.

 BUT …

Issues arising with videos and the media element js player have caused several headaches.  The way YouTube videos are presented  on iOS 5 (iPhone) where the controls work but the video is launched in the iOS player  and Android where there are variations in the software used on different phones e.g. some HTC and Sony phones.   On the latter the video is seen but cannot be played using an Opera browser but will play in the built in Android webkit browser – on the former an error message appears within the Chrome browser as it cannot load the player.  There is no mobile Firefox for HTC Wildfire.

The HTC OneXL with a 4 inch will run  Synote Mobile  in the same way as the tablet and desktop version.

Audio is not a problem as the transcript can appear below the player in this case.  Synmarks can also be seen with a separate tab.

Planning ahead

whiteboard designThe view of the video page will have titles, tags and description – the options page will allow the user to go to the video or audio page, transcript, slides or synmarks.  The transcript has the thumbnail picture from  the video and the start and end times for each transcript block.   The slides can be displayed in a row or line with start times and actual slides, the synmarks are listed with title, description and tags plus start and end time and a thumbnail of the YouTube video for that time.

At present there is also a huge variation between the way mobile phones show the captions as taken from the transcript (as seen in the tablet version) because the players (whether built or in the browser) react differently to the selection of the caption button.   This is a testing phase and we are trying to see if there is anyway to overcome this issue.   If you use a Flash player on the HTC Wildfire it will display the captions  but this does not help us with HTML5! At least we know there is a fall back player that will cope with closed captioning on Android

Testing with the iPhone – it did not matter whether we used Chrome, Opera or Safari the player once launched just would not play the YouTube closed captions despite having closed caption settings on.  This appears to be a known problem as mentioned in the blog “YouTube – Apple’s Lack of Caption Support

Discussions around embedding media players

There has been much discussion over the last few weeks about embedding media players  within web pages that will automatically adapt to the user’s chosen device.  The responsive design needs to be more than just responsive to one or two issues as we have discovered – there needs to be fall forward and fall back options!  As Yunjia has said

The challenge for HTML5 video/audio in Synote is we need to embed different players not only based on the media type, but also the platform. Obviously, Flash is not well supported on mobile platform. So we must consider the html5 native player and control it through javascript.


MediaElement.js is a “fallforward” html player, which means it is based on HTML5 native player. However, if the browser doesn’t support HTML5, mediaelement.js will embed the self-developed flash and silverlight player.  Hopefully this option is going to provide us with a solution to the issue!

The website MediaElement.js has provided a  comparison of codecing and applicable browsers, including mobile devices.

Browser and device support for HTML5

There is also a large table providing a useful comparison of the HTML5 video player with available features.




Beautiful mobile applications, beautiful user experiences Part 3

Whilst exploring issues around the look and feel of Synote Mobile Mike sent me this blog, which is one of three from The Computer Weekly Application Developer Network

“In part three of this guest blog for the Computer Weekly Developer Network, Sybase technical evangelist and mobile evangelist Ian Thain discusses the new mobile application landscape characterised by new and more beautiful user interfaces.

Links to part one and part two of this series.

There are a few mobile design guidelines that should never be far from your thoughts.

To take a few as examples :-

  • The initial screen should be kept as clear as possible to act as a launch point, because first impressions count – Synote has always gone for the minimalist approach! 
  • Keep the main/primary controls in the thumb ‘hot zones’ at the edge of the screen and keep the most important content at the top, with controls at the bottom – this is particularly important for screen reader users who often track their fingers around the edges of phone screen to catch menu items.ITSmallPR.jpg
  • Be generous with the space on the screen, do not crowd and avoid scrolling where you can. Reducing clutter helps everyone but in particular disabled users as does the following point. 
  • Stick to proven navigation models, which can be used in combination, use flat pages for simple applications, and if possible make use of a tab bar that switches between the app’s main functions, and/or a tree structure for drilling down through a hierarchy of content.”

Please read the rest of the actual blog if you are interested.

Research – Streaming videos onto mobile phones

Since the OER meeting we have been exploring the issues around streaming video on mobile phones and tablets. It appears the latter is easier than the former! We have also been exploring all the web pages of those we met up with at the meeting to see how we can collaborate to stream data from these sites into Synote Mobile but more on that later!

The state of HTML 5 and video is well explained by LongTail Video and it looks as if this is the way to go when one wants to deliver a cross platform service. However, there are issues around fullscreen viewing with iPhones as the video is not presented within the webpage so is no longer browser based as can be seen from the BBC news screen grabs taken on an iPhone 4S.

BBC News iPhone screen captureBBC video iPhone screen capture

This fullscreen issue makes it impossible to add captions unless they are included when the video is made.  Closed captioning is explained by Longtail with the support provided by JWPlayer and it is clear that external files will be unable to be read with the method presently used by iPhones for rendering videos.

There are several pros and cons when researching the different HTML 5 players and the methods they use to support captioning.  A recent blog on Salt Websites offers several options, but the author has come to the same conclusion that we have reached namely:

“Now after all this effort to get your videos working on iOS I have to give you the bad news – the iPhone does not show subtitles! They put the video into full-screen mode and ignore the subtitles. ”


The gauntlet has been thrown down …

gauntlet thrown down

Research – Planning for an easy to use and accessible mobile app.

iPhone accessibility

Link to Apple accessibility web pages

Mobile apps have huge potential to help and liberate people, including disabled people and the elderly, who face challenges with other methods of communication. But as with other new technologies, there is also the potential to further exclude people who are already at a disadvantage by providing small, hard-to-use, inflexible interfaces to devices and apps that create more problems than they solve. (One Voice – Moving Together)

One of the main problems this project will need to overcome when considering ease of use and accessibility is the multitude of portable devices and operating systems. The use of a common code such as HTML 5 may overcome some of the difficulties rather than choosing to program a device dependent native app.

Jakob Nielsen’s Alertbox, September 26, 2011 provides some research into usability with an update on the subject pointing out the need to be aware of ‘fat finger syndrome’ and limit the number of features available. 

When it comes to usability testing, User Centric provide some key pointers that link to co-design and testing prototypes to ensure ease of use. There are answers to the following questions:

  • Does a fully functional prototype have to be built before user testing?
  • Should the user’s device be tested or is it better to provide a device?
  • What devices and user groups should be tested?
  • Are there differences between iPhone and Android users?
  • Do both need to be included in a study?
  • When is lab testing versus remote testing appropriate?

W3C have produced some Mobile Web Best Practices (MWBP) guidelines for developers that are relevant to HTML 5.  There are also the British Standard 8878 guidelines as presented by Jonathan Hassell – BS 8878 in 88 seconds – a lightning summary of the Standard (video with captions and transcript) provides a gallop through of the process!

Perhaps the easiest check list comes from the One Voice for Accessible ICT Coalition

The suggested seven steps are:

  1. Learn about accessibility.
    Learn how a user with a disability may use your app.
  2. Quick accessibility check.
    Get an estimate of how accessible you app is now.
  3. Publish an Accessibility Statement.
    Express your intent to be accessible.
  4. Provide a Contact Us function.
    Enable users to tell you easily about accessibility issues.
  5. Ensure reading sequence is logical and comprehensible.
    Ensure page navigation is simple.
  6. Create a user interface that is easy to understand and operate.
    General usability is an underpinning of accessibility.
  7. Ensure text formatting can be altered.
    Allow users to read text using a size and theme that meets their requirements.
Andoid Accessibility Features

Link to IDEAL Group's Android Accessibility Project


There is no such thing as full accessibility for everyone, but that should not stop app developers from attempting to maximise accessibility. (One Voice: Moving Together)