User experience design agency Nomensa recently celebrated 10 years in the industry by releasing the source code of its accessible media player to the public. The organisation says its player is "extremely versatile, supporting standard multimedia content (MP3/MP4/FLV), as well as content hosted on YouTube or Vimeo", and we spoke to Lonie Watson (LW), Nomensa director of accessibility, to gain some insight into how the player came to be and why designers should consider using it.
.net: What's the background behind the player?
LW: It began as a project to solve a problem. Talking to our clients, we knew there was a need for a customisable and accessible web-based media player. We realised website owners wanted to pull in content from multiple sources and also give site visitors a consistent experience. When we began working on our player, we weren't aware of any players that could pull in content from different sources and offer good accessibility at the same time.
We also wanted a customisable solution. We develop a lot of websites ourselves, so we know how important individuality is. This is why we wanted an HTML/CSS/JavaScript wrapper that could easily be adapted without the need for a Flash re-skin.
.net: Why did you make your efforts open-source?
LW: Because we're into humanising technology. We wanted to try and remove one of the barriers that prevent disabled people from consuming multimedia content, and to do it in a way that could be enjoyed by everyone. We also want to make the player as good as it can be. We figured the best way to do that would be to open it up for scrutiny, and welcome new features, bug fixes and extensions from other people as well as our own.
.net: Why should designers consider using the player over any others they already work with? What advantages does it bring?
LW: It's capable of pulling in locally stored content, as well as content from YouTube or Vimeo. It's less hassle for developers if they only need to handle one solution, rather than many. It also solves the Firefox Flash 'keyboard trap'. There's an outstanding bug with Firefox that causes keyboard-only users to get stuck on Flash objects with no means of escape. When using the Flash version of the player, keyboard-only users won't find themselves trapped within the UI. The HTML/CSS/JavaScript wrapper means the UI is also really flexible. It automatically reconfigures itself at smaller screen sizes, but it can also be made larger. It means the UI can be adapted to suit someone's personal requirements, without compromising on the way it looks.
The YouTube and Vimeo APIs restrict the way captions can be pulled through into third-party players. When captions can't be pulled through from source, the player can synchronise a locally stored XML caption file with the video content being pulled in via either platform. And the player can also use HTML5 video for locally stored media. Like other players, this means content can be made available on platforms without Flash support. Unfortunately, the JavaScript APIs prevent HTML5 video support for content pulled from YouTube or Vimeo, but we hope this will change soon.
.net: How future-proof is the player in terms of coding and format support?
LW: It's never possible to really future-proof something, but the player has an extensible architecture. If other online media providers have JavaScript APIs, it should be straightforward to expand the player's capability. We hope this will happen over time, through collaboration and contributions from developers using the player.
And making it open source is another way we hope the player will be future-proof. If people find it useful and decide it's worth contributing to, then we hope it will continue to evolve to meet the future.
