AJAX and Flash Together
By Mike Potter from
www.riapedia.com

Many people are confused about the relationship between Flash, Flex and AJAX. It's a bit tricky, because in many cases the three technologies are similar to each other: all three allow web developers to add dynamic elements to static web pages very easily. Flex and Flash are both delivered via the Flash Player (normally used as a plugin to browsers), AJAX applications are delivered via the browser. AJAX is written with JavaScript, XML and HTML components, Flex applications are written with ActionScript, XML and MXML components.

I think that because of these similarities, many people often assume that you'll build your site using AJAX OR Flex OR Flash. The truth is, that's just not the case. There are a number of great examples of sites that are using Flash and AJAX together. Today I'm highlighting two of them: Google Finance (http://finance.google.com/finance?q=ADBE) and Yahoo! Finance (http://finance.yahoo.com/charts#chart1:symbol=adbe;range=1y).

Both sites use Flash to display graphs of stock performance - a popular use of Flash given Flash's rendering engine and performance. What I really like about Google Finance is the fact that the HTML news on the right hand side of the site interacts with the Flash graph on the left. You'll see this when you click a letter in the graph, it will highlight the news on the right hand side (or vice versa).

Google has also written a nice custom Flash component that allows you to change the date range for the graph using a slider, located just below the graph. Even cooler - expanding the graph to show more data adds on more news items (shown as letters in the stock chart), and clicking on a letter not currently shown on the webpage scrolls the HTML news to that item - very nice. Google is using Flash for the graphs, and uses the Flash Java Integration Kit (here it is used on their site: http://finance.google.com/finance/js/gen_flashelper@sys-con.com, js?v=1.88)

A Flex developer could use the Flex Charting Components in combination with the Flex / Ajax bridge (www.adobe.com/devnet/flex/flex_ajax.html) to do something fairly similar but with much less work. (In fact, Nitobi does something similar.)

Yahoo's integration with HTML comes from the left hand "Compare To:" menu item. Clicking on an item in that list will load the stock data into the Flash chart. What I like about the Yahoo implementation is that they'll also change the location in the URL bar for you, allowing you to easily copy and paste a URL so others can see the same view as you are. That allows you to do things like link to this graph showing Adobe's stock compared to Microsoft's over the past year. Yahoo also has a similar time slider to Google - roll over the "Time Range" blue item in the bottom right hand side of the graph to enable it. Notice that the URL bar changes when you select a different time range, allowing me to easily link to the same graph showing Adobe's stock compared to Microsoft's stock since 1986.

The conclusion here should be that the choice of Flash or Flex doesn't need to be an all or nothing choice. You can integrate Flash and Flex into your existing website easily, using technologies like the Flex/AJAX bridge. Adobe has also shown an AJAX bridge to Flex Data Services - I'll get into that early in 2007.

The original version version of this RIApedia post can be found here:
www.riapedia.com/2006/12/14/ajax_and_flash_together. Reprinted by kind permission of Mike Potter.

Repositories and Web 2.0
By Andy Powell from
http://efoundations.typepad.com

At a couple of meetings recently the relationship between digital repositories as we currently know them in the education sector and Web 2.0 has been discussed. This happened first at the CETIS Metadata and Digital Repositories SIG meeting in Glasgow that looked at Item Banks, then again at the eBank/R4L/Spectra meeting in London.

In both cases, I found myself asking "What would a Web 2.0 repository look like?" At the Glasgow meeting there was an interesting discussion about the desirability of separating back-end functionality from the front-end user-interface. From a purist point of view, this is very much the approach to take - and its an argument I would have made myself until recently. Let the repository worry about managing the content and let someone (or something) else build the user-interface based on a set of machine-oriented APIs.

Yet what we see in Web 2.0 services is not such a clean separation. What has become the norm is a default user-interface - typically written in AJAX though often using other technologies such as Flash - that is closely integrated into the back-end content of the Web 2.0 service. For example, both Flickr and SlideShare follow this model. Of course, the services also expose an API of some kind (the minimal API being persistent URIs to content and various kinds of RSS feeds) - allowing other services to integrate ("mash") the content and other people to develop their own user-interfaces. But in some cases at least, the public API isn't rich enough to allow me to build my own version of the default user-interface.

More recently, there has been a little thread on the UK list about the mashability of digital repositories. However, it struck me that most of that discussion centered on the repository as the locus of mashing - i.e. external stuff is mashed into the repository user-interface, based on metadata held in repository records. There seemed to be little discussion about the mashability of the repository content itself - i.e. where resources held in repositories are able to be easily integrated into external services.

One of the significant hurdles to making repository content more mashable is the way that identifiers are assigned to repository content. Firstly, there is currently little coherence in the way that identifiers are assigned to research publications in repositories. This is one of the things we set out to address in the work on the Eprints Application Profile. Secondly, the 'oai' URIs typically assigned to metadata 'items' in the repository are not Web-friendly and do not dereference (i.e. are not resolvable) in any real sense, without every application developer having to hardcode knowledge about how to dereference them. To make matters worse, the whole notion of what an 'item' is in the OAI-PMH is quite difficult conceptually, especially for those new to the protocol.

Digital repositories would be significantly more usable in the context of Web 2.0 if they used 'http' URIs throughout, and if those URIs were assigned in a more coherent fashion across the range of repositories being developed.