Client-Side Content Restrictions for Archives and Content Providers

Two times since the launch of the new website colleagues of mine have contacted me about the new requirement on to log-in before downloading content from the SIL Language and Culture Archive. Both know that I relate to the website implementation team. I feel as if they expect me to be able to speak into this situation (as if I even have this sort of power) - I only work with the team in a loose affiliation (from a different sub-group within SIL), I don't make design decisions, social impact decisions, or negotiate the politics of content distribution.

However, I think there are some real concerns by web-users users about being required to log-in prior to downloading, and some real considerations which are not being realized by web-users.

I want to reply to these concernes.

Logging-in may seem like a great inconvenience to those who had previously simply clicked and downloaded SIL's content from, but today's norms are not what they were in a Web 1.0 world. There are several issues which need to be fully considered and digested, prior to users coming to judgment on these issues. These issues are multi-faceted and intertwined with SIL's complex corporate structure and Intelectual Property Management (or absence of management) history.

So, from these perspectives, I want to defend the need for users, to log-in and download content from SIL's Language and Culture Archive.

  • Reason #1. Objects do not have embedded rights management.
  • Reason #2. Objects do not have embedded licenses (or any SIL archive metadata for that matter). This can cause problems when content is downloaded by users and users then do not know under what license they have obtained the content.
  • Reason #3. There is no other way to force compliance awareness and consent with the license agreement, and keep track of who has consented.
  • Reason #4. This is the standard de facto way (and in a way the industry standard) for Language Archives to grant access to archived Objects. Look at: Archive of Indigenous Languages of Latin America (AILLA), MPI's The Language Archive of which DoBeS is a part, SOAS's ELAR, and PARADISEC. It is also the de facto way for online publishers and content providers to grant access to content consider Elsevier, JSTOR, or Wiley.
  • Reason #5 Some sort of client access control is to be required if language communities are to be able to access content and trust the SIL archive to be able to adequately restrict content.
  • Reason #6. Requiring log-in or access control cuts down or prevents unnecessary load on servers from BOT downloads.
  • Reason #7. SIL is a service organization. That means that there are multiple services offered by SIL. When interactants engage with SIL in one service it may be in their interest to become aware of other services which SIL can provide them (either by SIL offering or by pre-calculated suggestion). At this time, SIL does not have a Grassroots or Global perspective on who they are serving or what services are of primary interest to various interactants. Linking service beneficiaries to a log-in ID is important to establishing successful online relationships which can (and hopefully do) become face-to-face relationships.

These 7 reasons are not without objections:

  • If SIL is going to offer its content via Creative Commons licenses, then why track, or require users to log-in so they can download objects? Look at the Alaska Native Language Archive. (Example of Archived Map made available via CC license.) Well, it is pretty simple, Creative Commons is only part of the total services picture, and in the future, not all content may fall under the Creative Commons license.
  • Not all items need to be restricted by virtue of their nature to protect the interests of indigenous speakers. Look at MPI's The Language Archive model.
    MPI Access diagram

    MPI Access diagram, from their website about their archive.

    This is true, but also does not address the services issues.

In closing this short reply, I would like to address some of my own observations about the implementation of requirements for registration prior to downloading:

First, I loath the log-in process (see the screenshot below for what I see). I think it is ugly. It is disruptive. It is really long. It does not help the user to process the information on the log-in page in a logical manner (relative to the user). The sum of the experience is that it sets the attitude of the visitor against the process of logging-in prior to them even accessing the content they desire. This is a two part fault.

  1. It is a User Interface (UI) design issue because the data the user is asked to fill out visually overwhelms the screen.
  2. It is a User Experience (UX) design failure because the relationship with the user and connecting that user to SIL services and then presenting that user the appropriate information at the appropriate time has not been considered. - Fortunately I do work as a UX Consultant, fortunately for me and unfortunately for and it's interactants, I was not part of those screens, or experiences' design process.

(In my estimation) What we have here is a failure to communicate case of poor social engineering, which did not take into account crucial User Experience considerations. Unfortunately for SIL this has repercussions both internally and externally to the organization. My suggestion is that log-in be moved for archive related items to a light-box style login on the page where the user is trying to download items. And then, wait to ask all of the non-relevant questions - to the user in that moment - until the users' second or third download. Add even then, ask them with some social relevance to when the question is asked - ask the questions one at a time, not all at once. Or allow the user to fill out the questions on their user profile page. In as much as SIL likes to celebrate indigenous cultures it needs to learn and understand how to operate in internet cultural contexts to continue to reach the audiences on which it wants to have an impact.

Second, there is no Single-Sign-On ability which works with other SIL offered web services like,, or, or a host of other SIL offered web-based services.

Third, the current log-in user agreement does not address user data handeling or privacy issues. The user agreement is insufficient in a legel sense, considering that FaceBook's End User Agreement License (EULA) is longer than the US Constitution. SIL's EULA should have a legalese version, but should also have a human readable version - Short, Clear and Sweet much like the approach that Creative Commons has taken with presenting their licenses. SIL's End User Agreement License should be translated into the official languages of the countries in which SIL operates (and minimally at least the languages which are used in the browsers accessing the user login user login on 23 April 2013. The page is so long that I can not get it all on one screen shot.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.