Web video meeting interoperability

Interoperability challenges get bigger when crossing security boundaries or organizational boundaries. Working from home on a non-secure PC/Mac by definition cross a security boundary before reaching anyone, and places high requirements when attempting peer to peer communication. Communicating with a central server is less complicated, as the number of boundaries crossed is limited.

In the context of web conferencing solutions that may support remote teaching, there are challenges related to interoperability both within the application area and with the rest of the infrastructure:

• federated login: more and more products claim to be SAML2.0, or at least Shibboleth-capable
• supporting pre-defined groups, for example by integrating from a learning management system and reusing the predefined course groupings
• calendar integration, or integration with other collaboration tools
• chat integration, supporting the tools familiar to the end user
• user interface familiarity: standard place for toolbars and icons, familiar icons, comprehensible vocabulary
• integration with the phone infrastructure: could be by SIP or through MCUs, should speak well with plain old telephony

Vendor lock-in is a danger when choosing products, and such lock-in may manifest in different ways for desktop conferencing:

• software installation: requiring everyone participating in a meeting to download and install specific software on their PC/Mac
• lock-out of other solutions: being unable to participate in other meeting solutions as the PC/Mac is pre-configured for a specific solution and the other solutions may have conflicting requirements that are difficult for the end user to sort out
• data rot: stored content/data, developed for a specific whiteboard or document format, get inaccessible as the contract expires
• no sharing of information: impossible to extract content/data to other systems

Software installation is mostly solved by using a central server for multi-person meetings, where the participants download flash or java capable software to their computers.  Any researcher participating in international projects has come across at least one non interoperable web/video conferencing solution provided by the lead partner in the project, and being required to download software to be fiddled with, often leading to non-functional sound, video or chat which then again leads to non-productive meetings.

Some interoperability challenges may be solved on the organizational level for applications residing inside the organizational security boundary. Traditional video conferencing, with pre-configured meeting rooms, is an example where dedicated staff and pre-punched holes in firewalls make it possible to use not-really-interoperable products across organizational borders.

Open standards, and consistent implementation of these, play a key role in interoperable collaborative solutions. The current technology situation makes it necessary to test products for compliance with open standards.  And the current audio/video driver software wars make Linux a hardship with regards to open interoperable video conferencing solutions that will work from home.

I wish there was a silver bullet allowing several of us to speak to each other and listen to others and look at slides and drawings, even in a multi-vendor environment.  I had the same wish 15 years ago.  At least the user interfaces have improved, and USB has added a layer of indirection that solves some of the hardware issues.  I wish that reality would shatter my video conferencing cynicism.

yr.no hits a billion weather forecasts

This summer’s most popular web site at our place is yr.no with the weather forecast.  Yr just hit a billion weather forecasts since the start in 2007 (given that the site is in mainly in Norwegian, and there are only 4.8 million Norwegians, this is amazing).

One of the main factors in the success of yr.no is their open access to data sources.  yr.no hands out XML streams (and GRIB for the oceanic) for 7 million sites world wide, and they provide access to all data from all Norwegian weather stations.  Scripts for including yr.no as a gadget on your own web site are available, with good user instructions. In addition to a good end user interface this helps build a reliable site for weather information.

My advice to other public agencies: provide data that may be presented, reused and reconstructed – and build a simple interface to your own information.

Google Wave federation friendly web2.0

A draft of federation protocols for Wave, the hot-of-hottest new collaboration tool from Google is presented in the draft General Verifiable Federation by Lea Kissner and Ben Laurie.  More white-papers are available from the Google Wave innards site.  Google Wave is announced as open source, and is  based on the principle of federation.

Wave itself is an example of what happens if the user experience is put in the driving site, and looks exciting!  The proof of the email system (and the instant message system, and document sharing, and photo sharing, and collaborative work, and sharing information) is the eating of the pudding, and I am looking forward to tasting the pudding.

Quote from the Wave presentation

Federation that was hard. So we are building this thing with live concurrent editing and chatting and instant messaging and pictures and all that stuff.  And then we throw federation into the mix, which vastly complicates things.  It would be so much easier, frankly, from an engineering point of view if we could just keep this proprietary and we control all the servers and we control all the update schedules and so on.  But we think it is worth the effort. We hope you can help us with this.  We think the world is better place if everyone can build wave systems with it.

The share abilities of federation technology is in focus.  As it should be.

The innards of wave technology remains to be auguried by resident high technologists.  But it looks cool.

Log out from federated login (SLO)

Logging in is simple.  Getting out is simple, you just close your browser.  Unless you wanted to explicitly log out, or you needed to log out from just one application and keep the other applications working. Another issues is related to closing all browser windows, this sounds easy to do, but can be too difficult for some users.

Andreas implemented a nice user interface for single log out in SimpleSAMLphp, as shown on the right.

A surprising high number of users (8-10%) started using the SLO functionality when this was enabled in March 2009. If this number continues to stay high as we move from pilot in a selected user group to the broader audience in education remains to be seen.

Our main motivation behind the SLO interface was to offer a way to log out from one specific application where the licensing scheme was based on payment per  user logged in at the same time.  This motivated us to find a way to log out from that system, while keeping the other sessions with service providers alive.  If we demanded a global log-out, the end users would loose their work flows in all applications within the single sign on domain.  Not using federated log-out would simply give the user a SSO session in to the application for example at a browser refresh, and this without the user knowing and being able to control the situation.

User testing provided useful feedback, and we ended up with a page as displayed above.  If log-out fails from any application (as it sometimes does with HTTP redirect when a server goes down), this is indicated with a warning sign next to the service.  All successful log-outs are marked with green.  The user is advised to explicitly close all browser windows if log-out fails.

Making the end user aware of what applications he is logged in to, is part of the awareness raising for greater security. On the other hand, we do not want to drown the user in information, because than we end up in the Click-OK-to-continue syndrome.  The minimum information required is the names of the services and some graphic indicators of login/log-out situation.

More information about the technical implementation is available in My thoughts about SLO by Andreas Åkre Solberg, and in the SimpelSAMLphp documentation.

Language discovery

What language should a user be presented with in a login service?  The preferred language, of course.  The exercise remaining is to define the two terms language and preferred, and then to determine who preferres the language for the specific user.

A login service may use the following steps to determine what language to present, and terminate the search for information at the first positive answer

1. Check if the user has chosen a language for the login page. End user choice is recorded in a cookie.
2. Check if the referring service provider is requesting a preferred language
3. Check if the browser has set an Accept-Language header
4. Use a globally defined language as the default setting

A web service (service provider) may run through a similar checklist

1. Check if the user has chosen a language for the site. End user choice is recorded in a cookie.
2. Check if the preferredLanguage attribute has a value supported by your site
3. Check if the browser has set an Accept-Language header
4. Use a globally defined language as the default setting

Preferred language is usually preferred by the end user, but in Feide and other federations the home organization of the end user may also choose to enforce a specific language.  For elementary schools this could be a good choice, as children may add choices not supporting the educational goals.  In a situation with heated language discussions, this policy option could lead to further discussion and great opportunities for hands-on learning about political processes.

The Accept-Language header reflects configuration of the browser or operating system.  Such configuration is not necessarily reflecting the needs for web services, but could be optimized for instance for keyboard layout (Danish English being a popular choice, and this is weird even if English is an Anglo-Saxon language and the Angles and Saxons hailed from Denmark). Using the Accept-Language header from the browser without the other choices is not considered good practice, as commented in advice from W3C

The HTTP Accept-Language header was originally only intended to specify the user’s language. However, since many applications need to know the locale of the user, common practice has used Accept-Language to determine this information. It is not a good idea to use the HTTP Accept-Language header alone to determine the locale of the user. If you use Accept-Language exclusively, you may handcuff the user into a set of choices not to his liking.

The vocabulary for language codes is defined in several standards, among these are ISO 639-1 (two-letter language codes) and ISO 639-2 (three-letter language codes.  Feide is changing the encoding from two-letter language codes to three-letter language codes to add support for the two Sami languages that do not have two-letter codes: Southern Sami and Lule Sami.  Support exists for English, Norwegian, Norwegian bokmål, Norwegian Nynorsk and Northern Sami.  If you ask me why a small group of people like the Norwegians (4,8 million) have two kinds of Norwegians (two really similar forms of the same language), you should prepare yourself for a long discussion on urban/rural, political power, nationalism and the construction of a national state.  Or you could just accept the way it is, and move on to why the Sami (30000-70000) have multiple distinct language.

More practical advice on how to handle language processing in simpleSAMLphp is available.

Summing up: Language choices are complex.  Good luck!