Rather than take a traditional page-design approach, we architected the database and interaction to be slim and exchangeable. First, the database was managed by use of two .NET-based Web Services written in C# that ingested via POST marking transaction success with 32-character IDs, output via XML and with multi-purpose edit functions using switches and variable inputs. Next, the authentication was built on a combination Basic and session-based approach using ASP – quick and efficient and easy to modularize should the system need to be moved to another platform. Finally, the front-end was built on a single HTML page with jQuery and jQuery UI to support the large number of Ajax exchanges and interactive features.

The result is a clean, easy to use, transportable DAM-CMS capable of complex transactions (multi-tiered, synchronous updates), hooks to a Silverlight-based rough cut editor from Southworks, and most of all, easy and quick to modify without affecting the production environment. By deploying a single jQuery-based controller separate from the parser and presentation components, new objects could be introduced to the interface based on a modifiable, dynamic XML document at login (or pushed in real-time, even after the user had logged in).

Some of the things we learned seem pretty silly but in fact were critical to the project completing in such a short amount of time.

First, segregate all the processes – by constructing the database, the web services, and the interface separate from each other, different developers could rapidly deploy all of it and mesh together quickly at stop-points each day. Chandler and I (with a big assist from Srini and Mio) were able to work independently and merge as he completed parts of the web service, or make changes as parts of the interface came together. Likewise, during testing, changes to the interface and sequence could be done in real-time and re-tested within minutes instead of having to go back to the drawing board. This was eased by the fact that issues could be easily attributable and divisible to interface or back-end, and handled separately.

Second, it’s the little things that make a difference. Providing small visual cues – update notifications at the top of the page that disappear, Ajax loader starburts, highlighted labels and input boxes – all give the user information, information that helps them get through difficult or tedious and complex processes (for example, in creating a VOD asset, a user had options that might require upwards of 50 different pieces of information – eliminating unnecessary components on the screen made it easier to get through).

Finally, architect it but be flexible. Changes happen, and while developers and project managers all try to keep scope creep from happening, we all know that in the real world, so does feature change. It is unrealistic to assume that projects will get started 6 months before the deadline. It is also unrealistic to assume that, in such a project with a short deadline, that you’ll remember to include everything. Likewise, it’s also unrealistic to assume that during the process you’ll realize that the planned interface will work – prototyping is great but it takes time and testing that you may not always have. Being able to be flexible by following a basic interface design, using modular builders (in jQuery UI or other framework) and XML-based instruction sets, and providing error catching systems in both the front-end as well as the web services makes the project continue to move, even when not all the parts are correct.

In the end, we had a lot of hiccups and it didn’t go as smoothly as we’d hoped but it did get done and delivered on-time. The client goes to training in 9 hours and there will likely be another round of changes, but that we were able to post a full-featured DAM CMS in such a short amount of time gives us new methods and targets for the future.

While is why I am extremely proud of the evolution of the CMS that I designed and built for the Wimbledon Live player (see this post).

To understand the complexity behind designing the UX it’s important to understand the nature of the data and the critical effect of the workflow. First, video was being supplied from six sources, some to us using Saviant direct to our servers, some we pulled via FTP, and then of course the live streams (some HD and some SD). Then there were multiple parties…NBC (as the news reporter) needed editorial control over metadata, while iStream’s Managed Webcasting team needed to control the timeline over when items went to publication. My team, RnCS (Research & Creative Services) needed to insure that everything was tested before going live so we needed to throw the whole thing through a staging server before hitting a production server that then fed a cluster of edge servers on Akamai’s network.

So we structured it in several parts. First we put automated bots to determine when new assets had been dropped, specifically seeking out XML files that held the initial metadata, and dropped that into the CMS DB. Once there, the appropriate parties were notified by email (or in my case as PM, by SMS) – to update metadata, insert images, begin video transcoding, etc. Through the entire process, we designed screens to make it as easy as possible to follow the flow of assets, provide enough ability to each staff person so that overlaps in duties existed but that checkpoints assured data integrity throughout.

The grid above, for example shows the visual layout of the thumbnails that would appear in the cover-flow style playlist inside the player. Deep linking was provided so editorial users could create pointers on the MSNBC/NBCSports sites. Drag and drop allowed us to reorder objects to maximize the visibility of prominent players.

Each level of user had various modal windows to insert data. Even imagery was uploaded first to the staging, processed for size and then sent to production.

Because of the nature of edge servers, we also had to purge the cache after any update, so we provided a three-section grouping that allowed us to send the feed XMLs to production and clear the cache in one shot. And to make THAT process even easier, we built it so that it was accessibly by mobile phone so even if I was in transit, I could still update the CMS in a timely fashion.

Finally, the live streams had the ability to be toggled on and off so that the matrix of available feeds, particularly the Smooth HD stream, was optimized and prioritized. To be sure, there was still much room for improvement but given that the whole CMS was built in 6 days and now, five days into Wimbledon, has eased us into a steady, smooth workflow, speaks volumes for making it easy to use, intuitive (for example, the color designations on the player match the ones in the CMS, big text and extensive micro-transaction Ajax created an interactive environment), and overall a good experience.

Excellent article on a consistently overlooked problem for most web designers – help elements.  A help element is anything that provides the user with assistance in completing a task.  They come in many shapes, sizes and formats but the primary goal is to be unobtrusive but noticeable and, well, helpful.  Most designers/developers look at help elements with trudgery but in many cases it can actually enhance the user experience.

The place we frequently see help elements is in form completion and validation.  Why we somehow can’t provide scripts that reduce error rates in the first place is beyond me, but I suppose in a lot of cases you still have to provide visual cues and alerts to help some users out. 

In HCI we consider that a standard free-form entry is the most volatile of inputs and sure enough, that’s where you’ll encounter the most errors, but don’t neglect the other visual aspects, including external labels, internal (low contrast, like the one shown below) labels, direct manipulation (such as calendar popups). 

The extremes of direct input error handling might be dates and telephone numbers, but here you may need to also consider flow; if within the form you require country, simply provide formats that the user will be more familiar with (such as auto-complete country codes).

From Matt Cronin’s post:

Usability is the Key

With any website design, one strives for usability. Usability is the key factor in the success that a website achieves. Usability is simply about making things easier for your users — and help elements certainly do that. But are your individual help elements themselves usable?

Don’t Confuse the User
Confusing the user contradicts the purpose of the help element, so avoid it. Only put in content that is appropriate to the element. The way you organize content within the help element affects usability. If the element contains a lot of content, use lists and highlight keywords so that the content is easy to scan.

Placement Has a Major Impact
In Web design layout, placement of objects is a top usability consideration. Likewise for help elements, placement affects usability.

Many designers make the mistake of making help elements (i.e. buttons, links, etc.) very small so that they don’t get in the way of the website’s main content. The problem is that they become hard for the user to find. Sure, their small size leaves room for more content, but that won’t help a confused user. Find a balance between subtlety and accessibility.

Also remember that help elements should be optional for the user, not required. Allow the user to choose to get help, instead of immediately showing the element.

Next time you’re designing your site, put some extra consideration into the help elements and see what ideas you can come up with.  Send me some examples of your clever solutions via comment.

Once installed, it adds an additional panel to the FireBug console labelled “Reference”. Check out the screen shot to see the changes and be sure to get all the details on SitePoint’s web site.

Part of designing the dynamic web site involves looking at the application as a whole, determining where interactivity or dynamic interactions can occur (or should occur).  It’s an art of determining what is sufficient to create an engaging experience without being over-bearing.

Interactivity and dynamics can be created on both the client-side as well as the server-side.  More commonly, and for more engaging results, it is a mixture of both.  So for this quarter we begin where you should be at with Javascript programming, sidestep to learn a bit about XML, progress through some basics of PHP, and finally move into using AJAX and some common libraries for composing AJAX applications.

The class will be a combination of slide-based lectures and notes.  I will post digital copies of everything on the class page at http://www.mobimeet.com/class-imd322/

There is a lot of criticism that exists concerning digital rights management and much of it has merit.  However, DRM is a technology that is continuing to grow and prosper as technology moves forward and concerns over copyrights, ownership, usage and consumption also grow. Critics argue that the term “digital rights management” is a misnomer, that the term “digital restrictions management” is more accurate.

Definitions 

Public Key Infrastructure:  In cryptography, a public key infrastructure is an arrangement that provides for third-party vetting of and vouching for user identities. It also allows binding of public keys to users. This is usually carried out by software at a central location together with other coordinated software at distributed locations. The public keys are typically in certificates.

DRM (Digital Rights Management):  A PKI-based system of encrypting media and requiring authentication for delivery, play, copying or any other number of usage schemes.

Rights Set: Also known as rights structure.  A rights set defines the rules of the encrypted media and is built into the unique license.  Rights sets include such information as play count, transferability to other devices, whether the media can be burned to CD or DVD, expiration (date) of the license, etc.  The current term for this is “Media Usage Rights”.

DRM, The Simple Scheme

While DRM is overall a very simple scheme, it is not always so easy to implement.  There are a number of factors to consider when deciding if DRM should be implemented and even more factors once the decision to implement is made.

How DRM Works 

DRM is both simple and complex at the same time.  While the end result and the basic concept is generally similar across all implementations, the steps to implementation differ.

iTunes

Apple uses the AAC file format (a Quicktime variant) with DRM applied through a system known as FairPlay.  FairPlay predicates that:

• The protected track may be copied to any number of iPod player(s)
• The protected track may be played on up to five authorized computers simultaneously
• The protected track may be burned to a CD unlimited times (the resulting CD has no DRM and can be ripped, encoded and played back like any normal CD except there are first sale rights issues so it may not be distributed, and may have lossiness, also known as artifacts of compression)
• A protected track within a specified playlist in iTunes may only be copied to a CD seven times
• FairPlay only manages the decryption of audio content, not the ability of the file itself

The intent of FairPlay is to prevent the use of purchased music on a device other than an iPod.  FairPlay is constrained by incompatibilities with the Creative Commons license.

iTunes uses a regular MP4 container file with an encrypted AAC audio stream using  the Rijndael algorithm and MD5 hashes.  The master key used for decryption is also stored in the MP4 container.  The decryption key, also called a “user key” is provided by the user’s iTunes.  The keys are tied to the GUID of the computer, so when that computer is “de-authorized”, the keys are removed from Apple’s central repository, rendering further use of the file invalid for other computers.  The iPod itself, however, also maintains its own repository, so the file can continue to be played on the device.

iTunes and FairPlay, despite its commercial success, has received widespread criticism, particularly in France and by Real Networks.  The FairPlay system has long been deconstructed (cracked) and is easily removed using any number of publicly available tools.

Napster/PlaysForSure

PlaysForSure is a Windows Media-based system supporting the distribution of WMA files, most notably used in subscription-based approach such as those used by Napster.  The certificate system in PlaysForSure, a variant of the standard Windows Media DRM system, renders files useless if the subscription is expired by doing a continuous certificate check into a central repository every time the file is played.  This is covered more in the next section.

DivX

Introduced in 2006, DivX was once on the hit list for major studios (being a significant distribution container for illegally copied torrents) but is now the darling of the industry because of its ability to maintain high quality video in a relatively compact form factor.  The implementation has gained popularity with firmware manufacturers (such as DVD player makers) but works very similar to FairPlay.

Windows Media DRM

Windows Media DRM, like iTunes, uses a central repository to track the existence of licenses.  When any Windows Media file (note, this is the container, the codec may be any number of acceptable types) is encoded with DRM, an encrypted key is placed inside the header of the file.  The key is half of the PKI match to the certificate server.  The certificate server,  in addition to the remainder of the key, stores the acceptable use characteristics, currently called the “Media Usage Rights” which include any or all of the following:

• Computer Play Count: This field dictates the number of plays a licensed recipient will be able to play the media (on his or her receiving computer only). For example, if you want to restrict a pay-per-view type video to 5 views, change the selection to 5 plays.
• Burn to CD Count: This field indicates the number of times a licensed media may be burned to CD-ROM and still maintain license integrity.
• Portable Transfer Count: This field indicates the number of times a licensed media may be transferred to an SDMI-compatible portable device and still maintain license integrity.
• Grace Period: The number of hours that a device that has lost secure clock time may operate using its “best guess” time.
• Collaborative Play:This field indicates whether the license permits consumers to play protected content in a collaborative peer-to-peer session (messaging session).
• License Backup and Restore: This field indicates whether or not the applicable license can be backed up and restored at a future date. If Not Allowed is selected and the user inadvertently deletes the license certificates from his or her computer, the license for the media file will be automatically expired.
• License Begin Date: In mm/dd/yyyy format, this field set indicates when the media file license can begin. By default, this is set to the current date. If this field set is modified, the license usage date can be modified to a future date.
• License Duration: This field indicates how many days the license will remain applicable in the recipient’s computer once it is generated and stored.
• License Acquisition URL: The License Acquisition URL field requires a fully validated URL. In the case of non-silent delivery, this can provide an error page telling the user that he or she is attempting to play a media file without a valid license

Any individual usage right can override the others.  For example, if the license duration is 30 days and the expiry date has passed, the unlimited computer play count is no longer valid.  Windows DRM requires plug-ins and hence it is not operable on non-Windows platforms.  These plug-ins are ActiveX controls that are resident in all Windows systems.

Here are 3 examples of Windows Media Files.  Download them (right click and ‘Save As’) to your local computer and attempt to play them.  If you are prompted to install the security upgrade, go ahead and do so.  If you would like more information on upgrading or installing the security upgrade to use Windows DRM, go here.

• File 1 – No DRM
• File 2 – DRM Applied with Silent License Delivery
• File 3 – DRM Applied with Challenge

If you attempt to play File 2 (and have already done the security upgrade), you will notice the status bar indicating “Acquiring License” and then begin to play.  In the duration of time between loading the file and when it begins to play, the file itself send a command to a license certificate server and delivered a license silently (in the background) to your computer.  The  file has media usage rights set for only 10 plays and expires in 7 days.

If you attempt to play File 3 (and have already done the security upgrade), you will get a prompted window commonly called the challenge.  The challenge calls an HTML-based web page and allows the owner to collect information or payment to acquire the license.  The data shown in the textarea under the graphic shows the (PKI) private key portion (explained below) of your computer’s WMP security as well as some other information (in XML format).  This file looks like this:

In 2006, Microsoft introduced chaining into its DRM platform.  In chaining, the license has two parts – a root and a leaf.  The root license is bound to the computer or device while the lead contains the content key.  In this scheme, licenses can be chained together by association to a rooted key where the leaf specifically handles the content while the root handles the decryption.

In 2008, Microsoft will release a new version of DRM called PlayReady, largely in response to the ratification of WM9 as VC-1 and changes in business modeling since the release of the original DRM.  PlayReady will expand the DRM implementation significantly, supporting a much wider range of codecs and formats (including AAC and H.264 in addition to WM), be supported by the Silverlight delivery platform, and extend the ability to transfer media from device to device without loss of licensing integrity, as well as remaining backward compatible with WMDRM10.

Windows Media DRM can be used in conjunction with playlists and pointers.  Only when the DRM encoded file in the list is reached will it become activated.

Commonalities

All 3 formats have some things in common which is primarily the intent of protecting the distribution of content and tracking its usage.  The bottom line is that any content provider (an musician, a film studio, etc) has a defined need to protect, under copyright law, original content that it produces and to receive compensation for its distribution.  All formats use some form of encryption to hold some component of data though the media usage rights structures can vary widely.

All 3 formats also have one commonality in structure – they all require some form of GUID tracking.  A GUID (Global Unique Identifier) is a pseudo-random number which usually refers to the Microsoft implementation of UUID (Universally Unique Identifier).  Commonly, this is a 16-byte number (128 bits) and often represented in hexadecimal format such as:

3F2504E0-4F89-11D3-9A0C-0305E82C3301

GUIDs are used for many things, but mostly for identifying unique software applications.  In the case of DRM applications, it is a unique identifier of the software application being used to create the keys, and this information is stored in the certificate server to monitor the usage.

Distribution Platforms

Windows Media uses a wide distribution platform.  In fact, the system is largely free since all components needed to build a distribution system are also free with the sole exception of the licensing server.  Currently the biggest demand for DRM is in the business sector after a significant backlash from the consumer market in 2006 and 2007, and in fact demand for DRM implementations in the business-to-business sector has increased in the last couple of years. 

In 2005, iStreamPlanet proposed (and subsequently filed a patent application) a distribution model whereby licensing could be easily distributed through IP networks by use of Web Services.  The scope of this distribution system is rapidly becoming widely adopted whereby a third-party (such as iStreamPlanet) acting independently of the content provider and the consumer acts as an intermediary solely for the purpose of license distribution and management.  As a value added resource, the system also offer the ability to handle transaction processing and subscription management, all done via Web Service.

Political Issues

In 1998 the Digital Millennium Copyright Act was passed by Congress without even token opposition.  It was produced in an effort to make circumvention of DRM systems illegal.  In 2001 the most publicized case in which the government prosecuted any individual occurred when Dmitry Sklyarov was arrested in conjunction with work done for a Russian company (note that DRM is not enforceable in Russia).  Though acquitted, the case left a lasting impression in the digital community with respect to copyright violations and furthered work done by the RIAA against file-sharing schemes and the anti-hacker movement as a whole.

Why Should We Use Digital Rights Management

On the one side, we can argue that sharing of information is exactly what the Internet was created for and to a degree that’s accurate.  However, publication of information with consent is not the same thing as consumption without royalty.

Artistic works are the lifeblood of their creators.  Therefore, one can easily argue the usage of DRM in entertainment-based media distribution (music, movies, and so forth).  Likewise, however, any form of media can be subject to copyright, and the creators should be entitled to remuneration for consumption, or at the very least be able to protect its usage.  More so, creators of works should be able to protect their media from others claiming it to be their own.  This is the simple argument for using DRM.

What other reasons do you think DRM
should be instituted on a broad scale?

On the other side of the equation, particularly emphasized by recent consumer backlash and even litigation in several countries, is that use of DRM constitutes violations of consumer rights – that it inhibits the distribution and playability of content.  Largely the misconception has led to a general backlash against DRM as a whole but the real issue has more to do with one plaguing problem – interoperability.  In the case of France vs. Apple FairPlay, France argues that FairPlay is not interoperable thereby restricting its use and essentially “shunning out” markets and competitors – in violates anti-trust laws. 

Most consumers do not truly realize that this is the issue at hand – for most consumers, DRM is simply a means by which big business reduces sharing – acts as “Big Brother.”

What reasons would you state arguing
against the institution of DRM?

• Required Reading: Apple vs. France (BusinessWeek article), Flash DRM could put Dramatic Prairie Dog on endangered list (Ars Technica article), CES: Sony Pictures embraces DivX (Los Angeles Times article), Survey Results: Content Owners Still Believe in DRM (DRMWatch article)

• Recommended Reading: Patent Filing 2006123484 (iStreamPlanet)

• Other Resources: Windows Media Digital Rights Management

Please note that this is a beta build and not intended for production use.

[by Stephan Spencer for CNet]

Links are the fundamental vehicle that gets us from here to there on the web. Without them, we’d have no where to go, or at least a much harder time getting there. Links are, of course, deeply important to search engines as well. In fact, links and PageRank are at the very core of Google.

Spend a little time on just about any website and it won’t be long before you come across a “click here,” “click this,” or “more” link. You probably wouldn’t trade a $20 bill for $5, yet that is exactly what is happening when you use completely generic, non-descriptive anchor text with your links.

Search engines place even greater weight on links as another signal of what the destination page and site is about. While this is one of the basics of SEO, there seems to be no shortage of suboptimal links in the world. Links, whether internal or external, are too valuable to waste.

[read more]