Showing posts with label web development. Show all posts
Showing posts with label web development. Show all posts

Friday, 27 April 2012

What are the right questions about museum websites?

It should be fairly simple to answer the question, 'what's the point of a museum website?' because the answer should surely be some variant on 'to further the mission and goals of the museum'.

But what is it about being online, about being on or of the web that problematises that answer?

Is it that there are so many other sites providing similar content, activities and access to knowledge? Is it that the niche role many museums play in their local communities doesn't translate into online space? Is it that other sites got in earlier and now host better conversations about museum collections?

Or is the answer not really problematic - there have always been other conversations about collections and ways of accessing knowledge, and the question is really about where museums and their various activities fit in the digital landscape?

I don't know, but it's Friday night and I should be on my way out, so I'm going to turn the question over to smarter minds... What are the right questions and why is it difficult for a museum to translate its mission directly to its website?

Update, the next day... This quote from an article, Lost professors: we won’t need academics in 60 years, addresses one of my theories about why translating a museum's mission into the online context is problematic:
...there are probably several hundred academics in Australia who lecture on, say, regression analysis, and very few of us could claim to be in the top 1% – actually only 1% of us.

The web allows 100% of the students to access the best 1%. Where is the market for duplication of mediocre course material by research academics?
I'm not saying any museum content is mediocre, of course, but the point about the challenges of the sudden visibility of duplicated content remains. If the museum up the road or in the next town has produced learning activities or expert commentary about the same regional/national history events or objects, does it further your mission to post similar content? What content or activities can you host that is unique to your museum, either because of your particular niche collections or context or because no-one else has done it yet?

Also, for further context, Report from 'What's the point of a museum website' at MCN2011 and Brochureware, aggregators and the messy middle: what's the point of a museum website? (which is really about 'what forms do museum websites take'), and earlier posts on What would a digital museum be like if there was never a physical museum? and the related Thoughts towards the future of museums for #kulturwebb, What's the point of museum collections online? (Angelina's succinct response: digital content recognises audience experiences, providing opportunities for personal stories to form significant part of the process of interpretation) and finally, thoughts about The rise of the non-museum - museums are possibly the least agile body in the cultural content market right now.

Thursday, 5 November 2009

Organisational pain

If you work in a large organisation (or a cultural heritage organisation of almost any size), you may find cathartic release in reading this response to criticism of a large website from a member of its internal webteam:
...simply doing a home page redesign is a piece of cake. You want a redesign? I’ve got six of them in my archives. It only takes a few hours to put together a really good-looking one, as you demonstrated in your post. But doing the design isn’t the hard part, and I think that’s what a lot of outsiders don’t really get, probably because many of them actually do belong to small, just-get-it-done organizations. But those of us who work in enterprise-level situations realize the momentum even a simple redesign must overcome, and not many, I’ll bet, are jumping on this same bandwagon. They know what it’s like.
As always, I'm not particularly pointing the finger at my own institution, but I've definitely been there. Cultural heritage institutions tend to have bonus! added! overload on web teams, so the list of improvements you want to make is always much longer than the resources you have available.

Friday, 4 July 2008

How to build a web application in four days

There's been a bit of buzz around 'How To Build A Web App in Four Days For $10,000'. Not everything is applicable to the kinds of projects I'd be involved in, but I really liked these points:
  • The best boost you can give you or your team is to provide the time to be creative.
  • You'll come back to your current projects with a new perspective and renewed energy.
  • It will push your team to learn new skills.
  • Simplify the site and app as much as possible. Try launching with just 'Home', 'Help' and 'About'.
  • Make sure to build on a great framework
  • Be technologically agnostic. If your developers are saying it should be built in a certain language and framework and they have solid reasons, trust them and move on.
  • Coordinate how your designers and developers are going to work together.
  • Get your 'Creation Environment' setup correctly. [See the original post for details]

"The coolest thing to be done with your data will be thought of by someone else"

I discovered this ace quote, "the coolest thing to be done with your data will be thought of by someone else", on JISC's Common Repository Interfaces Group (CRIG) site, via the The Repository Challenge. The CRIG was created to "help identify problem spaces in the repository landscape and suggest innovative solutions. The CRIG consists of a core group of technical, policy and development staff with repository interface expertise. It encourages anyone to join who is dedicated and passionate about surfacing scholarly content on the web."

Read 'repository or federated search' for 'repository' (or think of a federated search as a pseudo-repository) and 'scholarly' for 'cultural heritage' content, and it sounds like an awful lot of fun.

It's also the sentiment behind the UK Government's Show Us a Better Way, the Mashed Museum days and a whole bunch of similar projects.

Friday, 27 June 2008

Scripting enabled - accessibility mashup event and random Friday link

Scripting Enabled, "a two day conference and workshop aimed at making the web a more accessible place", is an absolutely brilliant idea, and since it looks like it'll be on September 19 and 20, the weekend after BathCamp, I'm going to do my best to make it down. (It's the weekend before I start my Masters in HCI so it's the perfect way to set the tone for the next two years).

From the site:
The aim of the conference is to break down the barriers between disabled users and the social web as much as giving ethical hackers real world issues to solve. We talked about improving the accessibility of the web for a long time - let's not wait, let's make it happen.
...
A lot of companies have data and APIs available for mashups - let’s use these to remove barriers rather than creating another nice visualization.

And on a random Friday night, this is a fascinating post on Facial Recognition in Digital Photo Collections: "Polar Rose, a Firefox toolbar that does facial recognition on photos loaded in your browser."

Wednesday, 4 June 2008

Nice information design/visualisation pattern browser

infodesignpatterns.com is a Flash-based site that presents over 50 design patterns 'that describe the functional aspects of graphic components for the display, behaviour and user interaction of complex infographics'.

The development of a design pattern taxonomy for data visualisation and information design is a work in progress, but the site already has a useful pattern search, based on order principle, user goal, graphic class and number of dimensions.

Saturday, 31 May 2008

'Finding yourself with Fire Eagle' at WSG Findability

On Wednesday I went to the WSG London Findability event, and I've finally got the last of my notes up.

The final talk was from Steve Marshall, on 'Finding yourself with Fire Eagle'.

Steve doesn't work on Fire Eagle but made the Python library.

Fire Eagle is a service that helps you manage your location data.

Most location-aware applications have two parts - getting the location, and using the location.

Better model - distribute the location information, but the application getting the location still has to know who's using it.

Even better model: a brokering service. Fire Eagle sits between any 'getting' applications and any 'using' applications, and handles the exchange.

[FWIW, 'Fire Eagle is a brokering service for location data' is probably the best explanation I've heard, and I'd heard it before but I needed the context of the 'get' and the 'use' applications it sits between for it to stick in my brain.]

So how does it work? In the web application context (it's different for desktop or mobile applications):
Web app: app asks for Request Token
Fire Eagle: returns Request Token
Web app: user sent to Fire Eagle with token in URL
Fire Eagle: user chooses privacy levels and authorises app
Web app: user sent back to callback URL with Request Token
Web app: app initiates exchange of Request Token
Fire Eagle: Request Token exchanged for Access Token
Web app: app stores Access Token for user

You can manage your applications, and can revoke permissions (who can set or get your location) at any time. You can also temporarily hide your location, or purge all your data from the service. [Though it might be kept by the linked applications.]

How to use:
1. Get API key
2. Authenticate with user (OAuth)
3. Make API call

Concepts:
Locations can be a point or a bounding box.
Location hierarchy - a set of locations at varying degrees of precision.

[There was some good stuff on who could/is using it, and other ideas, but my notes got a bit useless around this point.]

In summary: you can share your location online, control your data and privacy, and easily build location services.

Discussion:
Question: what makes it special? Answer: it's not coupled to anything. It plays to the strengths of the developers who use it.

'Fire Eagle: twitter + upcoming + pixie dust'.

URLs are bookmarkable, which means they can be easy to use on phone [hooray]. It doesn't (currently) store location history, that's being discussed.

Qu: what's the business model? Ans: it's a Brickhouse project (from an incubator/start-up environment).

All methods are http requests at the moment, they might also use XMP ping.

Qu: opening up the beta? Ans: will give Fire Eagle invitations if you have an application that needs testing.

I had to leave before the end of the questions because the event was running over time and I had to meet people in another pub so I missed out on the probably really interesting conversations down the pub afterwards.

My notes:
Looking at their hierarchy of 'how precisely will you let application x locate you', it strikes me that it's quite country-dependent, as a postcode identifies a location very precisely within the UK (to within one of a few houses in a row) while in Australia, it just gives you the area of a huge suburb. I'm not sure if it's less precise in the US, where postcodes might fit better in the hierarchy.

I've also blogged some random thoughts on how services like Fire Eagle make location-linked cultural heritage projects more feasible.

Thursday, 29 May 2008

'Building websites with findability in mind' at WSG London Findability

Last night I went to the WSG London Findability event at Westminster University, part of London Web Week; here's part two of my notes.

Stuart Colville's session on 'Building websites with findability in mind' was full of useful, practical advice.

Who needs to find your content?

Basic requirements:
Understand potential audience(s)
Content
Semantic markup
Accessibility (for people and user agents)
Search engine friendly

Content [largely about blogs]:
Make it compelling for your audience
There's less competition in niche subjects
Originality (synthesising content, or representing existing content in new ways is also good)
Stay on topic
Provide free, useful information or tools
Comments and discussion (from readers, and interactions with readers) are good

Tagging:
Author or user-generated, or both
Good for searching
Replaces fixed categories
Enables arbitrary associations
Rich

Markup (how to make content more findable):
Use web standards. They're not a magic fix but they'll put you way ahead. The content:code ratio is improved, and errors are reduced.
Use semantic markup. Adds meaning to content.
Try the roundabout SEO test
Make your sites accessible. Accessible content is indexable content.

Markup meta:
Keywords versus descriptions. Tailor descriptions for each page; they can be automatically generated; they can be used as summaries in search results.
WordPress has good plugins - metadescription for auto-generated metadata, there are others for manual metadata.

Markup titles and headings:
Make them good - they'll appear as bookmark etc titles.
One H1 per page; the most meaningful title for that page
Separate look from heading structure.

Markup text:
Use semantically correct elements to describe content. Strong, em, etc.

Markup imagery:
Background images are fine if they're only a design element.
Use image replacement if the images have meaning. There are some accessibility issues.
Use attributes correctly, and make sure they're relevant.

Markup microformats:
Microformats are a simple layer of structure around content
They're easy to add to your site
Yahoo! search and technorati index them, Firefox 3 will increase exposure.

Markup Javascript:
Start unobtrusive and enhance according to the capabilities of the user agent.
Don't be stupid. Use onClick, don't kill href (e.g. href="#").
Use event delegation - no inline events. It's search engine accessible, has nice clean markup and you still get all the functionality.
[Don't break links! I like opening a bunch of search results in new tabs, and I can't do that on your online catalogue, I'll shop somewhere I can. Rant over.]

Performance and indexation:
Use 'last modified' headers - concentrate search agents on fresh content
Sites with Google Ads are indexed more often.

URLs:
Hackable URLs are good [yay!].
Avoid query strings, they won't be indexed
Put keywords in your URL path
Use mod_rewrite, etc.

URI permanence:
"They should be forever". But you need to think about them so they can be forever even if you change your mind about implementation or content structure.
Use rewrites if you do change them.

De-indexing (if you've moved content)
Put up a 404 page with proper http headers. 410 'intentionally gone' is nice.
There's a tool on Google to quickly de-index content.
Make 404s useful to users - e.g. run an internal search and display likely results from your site based on their search engine keywords [or previous page title].

Robots.txt - really good but use carefully. Robots-Nocontent - Yahoo! introduced 'don't index' for e.g. divs but it hasn't caught on.

Moving content:
Use 301. Redirect users and get content re-indexed by search engines.

Tools for analysing your findability:
Google webmaster tools, Google analytics, log files. It's worth doing, check for broken links etc.

Summary:
Think about findability before you write a line of code.
Start with good content, then semantic markup and accessibility.
Use sensible headings, titles, links.

WSG London Findability 'introduction to findability'

Last night I went to the WSG London Findability event at Westminster University. The event was part of London Web Week. As always, apologies for any errors; corrections and comments are welcome.

First up was Cyril Doussin with an 'introduction to findability'.

A lot of it is based on research by Peter Morville, particularly Ambient Findability.

So what do people search for?
Knowledge - about oneself; about concepts/meaning; detailed info (product details, specs); entities in society (people, organisations, etc.)
Opinions - to validate a feeling or judgement; establish trust relationships; find complementary judgements.

What is information? From simple to complex - data -> information -> knowledge.

Findability is 'the quality of being locatable or navigatable'.
Item level - to what degree is a particular object easy to discover or locate?
System level - how well does the environment support navigation and retrieval?

Wayfinding requires: knowing where you are; knowing your destination; following the best route; being able to recognise your destination; being able to find your way back.

The next section was about how to make something findable:
The "in your face" discovery principle - expose the item in places known to be frequented by the target audience. He showed an example of a classic irritating Australian TV ad, a Brisbane carpet store in this case. It's disruptive and annoying, but everyone knows it exists. [Sadly, it made me a little bit homesick for Franco Cozzo. 'Megalo megalo megalo' is also a perfect example of targeting a niche audience, in this case the Greek and Italian speakers of Melbourne.]

Hand-guided navigation - sorting/ordering (e.g. sections of a restaurant menu); sign-posting.

Describe and browse (e.g. search engines) - similar to asking for directions or asking random questions; get a list of entry points to pages.

Mixing things up - the Google 'search within a search' and Yahoo!'s 'search assist' box both help users refine searches.

Recommendations (communication between peers) - the searcher describes intent; casual discussions; advice; past experiences.
The web is a referral system. Links are entry doors to your site. There's a need for a relevancy system whether search engines (PageRank) or peer-based systems (Digg).

Measuring relevance (effectiveness):
Precision - if it retrieves only relevant documents
Recall - whether it retrieves all relevant documents.

Good tests for the effectiveness of your relevance mechanism:
Precision = number of relevant and retrieved documents divided by the total number retrieved.
Recall = number of relevant and retrieved documents divided by the total number of relevant documents.

Relevance - need to identify the type of search:
Sample search - small number of documents are sufficient (e.g. first page of Google results)
Existence search - search for a specific document
Exhaustive search - full set of relevant data is needed.
Sample and existence searches require precision; exhaustive searches require recall.

Content organisation:
Taxonomy - organisation through labelling [but it seems in this context there's no hierarchy, the taxon are flat tags].
Ontology - taxonomy and inference rules.
Folksonomy - a social dimension.

[In the discussion he mentioned eRDF (embedded RDF) and microformats. Those magic words - subject : predicate : object.]

Content organisation is increasingly important because of the increasing volume of information and sharing of information. It's also a very good base for search engines.

Measuring findability on the web: count the number of steps to get there. There are many ways to get to data - search engines, peer-based lists and directories.

Recommendations:
Aim to strike a balance between sources e.g. search engine optimisation and peer-based.
Know the path(s) your audience(s) will follow (user testing)
Understand the types of search
Make advertising relevant (difficult, as it's so context-dependent)
Make content rich and relevant
Make your content structured

I've run out of lunch break now, but will write up the talks by Stuart Colville and Steve Marshall later.

Wednesday, 28 May 2008

Google release AJAX loader

From the Google page, AJAX Libraries API:

The AJAX Libraries API is a content distribution network and loading architecture for the most popular open source JavaScript libraries. By using the Google AJAX API Loader's google.load() method, your application has high speed, globaly available access to a growing list of the most popular JavaScript open source libraries including:

Google works directly with the key stake holders for each library effort and accept the latest stable versions as they are released. Once we host a release of a given library, we are committed to hosting that release indefinitely.

The AJAX Libraries API takes the pain out of developing mashups in JavaScript while using a collection of libraries. We take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.



There's also more information at Speed up access to your favorite frameworks via the AJAX Libraries API.

To play devil's avocado briefly, the question is - can we trust Google enough to build functionality around them? It might be a moot point if you're already using their APIs, and you could always use the libraries directly, but it's worth considering.

Monday, 19 May 2008

Setting up a personal webserver: quick link

Personal web servers on a laptop or desktop machine are very handy if you're looking for a local development environment. This article offers a few options for Mac, Linux and Windows: Set up your personal webserver.

Thursday, 8 May 2008

Notes from 'The API as Curator' and on why museums should hire programmers

These are my notes from the third paper 'The API as Curator' by Aaron Straup Cope in the Theoretical Frameworks session chaired by Darren Peacock at Museums and the Web 2008. The slides for The API as Curator are online.

I've also included below some further notes on why, how, whether museums should hire programmers, as this was a big meme at the conference and Aaron's paper made a compelling case for geeks in art, arty geeks and geeky artists.

You might have noticed it's taken me a while to catch up on some of my notes from this conference, and the longer I leave it the harder it gets. As always, any mistakes are mine, any comments corrections are welcome, and the comments in [square brackets] below are mine.

The other session papers were Object-centred democracies: contradictions, challenges and opportunities by Fiona Cameron and Who has the responsibility for saying what we see? mashing up Museum and Visitor voices, on-site and online by Peter Samis; all the conference papers and notes I've blogged have been tagged with 'MW2008'.

Aaron Cope: The API as curator.

The paper started with some quotes as 'mood music' for the paper.

Institutions are opening up, giving back to the communitiy and watching what people build.

It's about (computer stuff as) plumbing, about making plumbing not scary. If you're talking about the web, sooner or later you're going to need to talk about computer programming.

Programmers need to be more than just an accessory - they should be in-house and full-time and a priority. It boils down to money. You don't all need to be computer scientists, but it should be part of it so that you can build things.

Experts and consumers - there's a long tradition of collaboration in the art community, for example printmaking. Printers know about all the minutiae (the technical details) but/so the artists don't have to.

Teach computer stuff/programming so that people in the arts world are not simply consumers.

Threadless (the t-shirt site) as an example. Anyone can submit a design, they're voted on in forum, then the top designs are printed. It makes lots of money. It's printmaking by any other name. Is it art?

"Synthetic performances" Joseph Beuys in Second Life...

It's nice not to be beholden to nerds... [I guess a lot of people think that about their IT department. Poor us. We all come in peace!]

Pure programming and the "acid bath of the internet".

Interestingness on Flickr - a programmer works on it, but it's not a product - (it's an expression of their ideas). Programming is not a disposable thing, it's not as simple as a toaster. But is it art? [Yes! well, it can be sometimes, if a language spoken well and a concept executed elegantly can be art.]

API and Artspeak - Aaron's example (a bit on slide 15 and some general mappy goodness).

Build on top of APIs. Open up new ways to explore collection. Let users map their path around your museum to see the objects they want to see.

Their experience at Flickr is that people will build those things (if you make it possible). [Yay! So let's make it possible.]

There's always space for collaboration.

APIs as the nubby bits on Lego. [Lego is the metaphor of the conference!]

Flickr Places - gazetteer browsing.

[Good image on slide 22]: interpretation vs intent, awesome (x) vs time (y). You need programmers on staff, you need to pay them [please], you don't want them to be transient if you want to increase smoothness of graph between steps of awesomeness. Go for the smallest possible release cycles. Small steps towards awesome.

Questions for the Theoretical Frameworks session
Qu from the Science Museum Minnesota: how to hire programmers in museums - how to attract them? when salaries are crap.
Aaron - teach it in schools and go to computer science departments. People do stuff for more than just money.

Qu on archiving UGC and other stuff generated in these web 2.0 projects... Peter Samis - WordPress archives things. [So just use the tools that already exist]

Aaron - build it and they will come. Also, redefine programming.

There's a good summary of this session by Nate at MW2008 - Theoretical Frameworks.

And here's a tragically excited dump from my mind written at the time: "Yes to all that! Now how do we fund it, and convince funders that big top-down projects are less likely to work than incremental and iterative builds? Further, what if programmers and curators and educators had time to explore, collaborate, push each other in a creative space? If you look at the total spend on agencies and external contractors, it must be possible to make a case for funding in-house programmers - but silos of project-based funding make it difficult to consolidate those costs, at least in the UK."

Continuing the discussion about the benefits of an in-house developer team, post-Museums and the Web, Bryan Kennedy wrote a guest post on Museum 2.0 about Museums and the Web in Montreal that touched on the issue:
More museums should be building these programming skills in internal teams that grow expertise from project to project. Far too many museums small and large rely on outside companies for almost all of their technical development on the web. By and large the most innovation at Museums and the Web came from teams of people who have built expertise into the core operations of their institution.

I fundamentally believe that at least in the museum world there isn't much danger of the technology folks unseating the curators of the world from their positions of power. I'm more interested in building skilled teams within museums so that the intelligent content people aren't beholden to external media companies but rather their internal programmers who feel like they are part of the team and understand the overall mission of the museum as well as how to pull UTF-8 data out of a MySQL database.
I left the following comment at the time, and I'm being lazy* and pasting here to save re-writing my thoughts:
Good round-up! The point about having permanent in-house developers is really important and I was glad to see it discussed so much at MW2008.

It's particularly on my mind at the moment because yesterday I gave a presentation (on publishing from collections databases and the possibilities of repositories or feeds of data) to a group mostly comprised of collections managers, and I was asked afterwards if this public accessibility meant "the death of the curator". I've gathered the impression that some curators think IT projects impose their grand visions of the new world, plunder their data, and leave the curators feeling slightly shell-shocked and unloved.

One way to engage with curatorial teams (and educators and marketers and whoever) and work around these fears and valuable critiques is to have permanent programmers on staff who demonstrably value and respect museum expertise and collections just as much as curators, and who are willing to respond to the concerns raised during digital projects.
There's a really good discussion in the comments on Bryan's post. I'm sure this is only a sample of the discussion, but it's a bit difficult to track down across the blogosphere/twitterverse/whatever and I want to get this posted some time this century.

* But good programmers are lazy, right?

Tuesday, 15 April 2008

How I do documentation: a column of bumph and a column of gold

All programmers hate documentation, right? But I've discovered a way to make it less painful and I'm posting in case it helps anyone else.

The first trick is to start documenting as soon as you start thinking about a project - well before you've written any code. I keep a running document of the work I've done, including the bits I'm about to try, information about links into other databases or applications, issues I need to think about or questions I need to ask someone, rude comments (I know, I look like such a nice girl), references, quick use cases, bits about functions, summary notes from meetings, etc.

Mostly I record by date, blog style. Doing it by date helps me link repository files, paper notes and emails with particular bits of work, which can otherwise be tricky if it's a while since you worked on a project or if you have lots of projects on the go. It's also handy if you need to record the time spent on different projects.

I just did it like this for a while, and it was ok, but I learnt the hard way that it takes a while to sort through it if I needed to send someone else some documentation. Then I made a conscious decision to separate the random musings from the decisions and notes on the productive bits of code.

So now my document has two columns. This first column is all the bumph described above - the stuff I'd need if I wanted to retrace my steps or remind myself why I ended up doing things a certain way. The second column records key decisions or final solutions. This is your column of gold.

This way I can quickly run down the items in the second column, organise it by area instead of by date and come up with some good documentation without much effort. And if I ever want to write up the whole project, I've got a record of the whole process in the column of bumph.

You could add a third column to record outstanding tasks or questions. I tend to mark these up with colour and un-colour them when they're done. It just depends how you like to work.

It's amazingly simple, but it works. I hope it might be useful for you too. Or if you have any better suggestions (or a better title for this post), I'd love to hear them.

Friday, 11 April 2008

Notes from Advanced Web Development: software strategies for online applications at MW2008

These are my notes from the Advanced Web Development: software strategies for online applications workshop with Rob Stein, Charles Moad and Edward Bachta from the Indianapolis Museum of Art at Museums and the Web 2008 (MW2008) in Montreal. I don't know if they'll be useful for anyone else, but if you have any questions about my notes, let me know.

They had their slides online before the presentation, which was really helpful. [More of this sort of thing, please! Though I wish there was a way to view thumbnails of slides on slideshare so you can skip to particular slides.]

The workshop covered a lot of ground, and they did a pretty good job of pitching it at different levels of geekdom. Some of my notes will seem self-evident to different types of geeks or non-geeks but I've tried to include most of what they covered. I've put some of my own comments in [square brackets].

They started with the difference between web pages and web applications, and pointed out that people have been building applications for 30 years so build on existing stuff.

Last year's talk was about 'web 2.0' and the foundations of building solid software applications but since then APIs/SDKs have taken off. Developers should pick pieces that already work rather than building from the bottom up. The craft lies in knowing how to choose the components and how to integrate them.

There are still reasons to consider building your own APIs e.g. if you have unique information others are unlikely to support adequately, if you care about security of data, if you want to control the distribution of information, or if a guarantee of service is important (e.g. if vendors disappear).

Building APIs
They're using model driven development, using xmlschema or database as your model.

Object relational mappers provide object-oriented access to a database. Data model changes are picked up automatically and they're generally database-agnostic so you can swap out the back end. Object relational mappers include Ruby, Hibernate (also in .Net), Propel and SQLAlchemy.

IMA use Hibernate with EMu (their collections management system) and Propel. They've built an 'adaptive layer' for their collection that glues it all together.

Slide on Eclipse: 'rich client platform', not just an IDE. Supports nearly every language except .Net; is cross-platform.

Search
Use full-text indexes for good search functionality. They suggest Lucene (from apache.org) or Google gears. Lucene query types offer finer control than Google e.g. fielded searching [a huge draw for specialist collections searches], date range searching, sorting by any field, multiple index searching with merged results. Fast, low memory usage, extensible. Tools built on Lucene include Nutch (web crawler) and Solr - REST and SOAP API.

Bite size web components and suggestions for a web application toolkit
Harking back to the 'find good components' thing. Leverage someone else's work, and reduce dev/debugging costs - in their experience it produces fewer errors than writing their own stuff.

Storage - Amazon, Nirvanix, XDrive, Google, Box.net. Use Amazon S3 if accessed infrequently cos of free structure.

Video - YouTube, Revver, blip.tv also have developer interfaces. The IMA don't host any video on their website, it's all on YouTube.

Images - Flickr, Picasa. [But the picasa UI sucks so please don't inflict that on your users!]. Flickr support for REST, SOAP, JSON.

Compute (EC, Amazon web service) - Linux virtual machines. Custom disk images for specific requirements. Billable on use. See slides on costs for web hosting.

Authentication services - OpenID, OAuth.

Social computing
Consider social computing when developing your web applications - it's evolving rapidly and is uncertain. Facebook vs OpenSocial (might be the question today, but tomorrow?). Stick with the eyeballs and be ready to change. [Though the problem for museums thinking about social software applications remains - by the time most museums go through approval processes to get onto Facebook it'll be dead in the water. Another reason to have good programmers on staff and include content resources in online programs, so that teams can be more flexible while still working within the overall online strategy of their organisation.]

Developing on Facebook
Facebook API - REST-based API. Use their developer platform - simpler than original API calls. JSON simpler than XML responses. Facebook Query Language (FQL) reduces calls to API. Facebook Markup Language (FBML). HTML + Facebook specific features, inc security controls and interfaces features. [There's a pronoun tag with built-in 'they' if not sure of gender of person. Cute.] Lots more in their slides.

Widget frameworks
Widgets are the buzzword that hasn't quite taken off. The utility isn't quite there yet, so what are they used for? Players are Google, Netvibes (supports more platforms including Apple Mac dashboard, Yahoo, iGoogle, etc) but is Adobe AIR the widget killer? Flash-based runtime for desktop apps. e.g. twhirl. Run as background processes, and can access desktop files directly, clipboard, drag and drop. [I downloaded the AIR Google Analytics application during the session, it's a good example.]

Content management
The CMS is the container to put all the components together. A good CMS will let you integrate components into a new site with a minimum of effort. [Wouldn't that be nice?] Examples include Joomla, WordPress, Drupal, Plone.

There aren't slides for the next 'CMS tour' bit, but they gave some great examples.

Nature holds my camera: they tried visitor blogging with a terminal in gallery so people could ask questions.

They talked about the IMA dashboard. [I asked a vague question about whether there was a user-driven or organisational business case for it - turns out it was driven by their CEO's interest in transparency, e.g. in sharing how they invest monies, track stats and communicate with their visitors. It helps engender trust and loyalty e.g. for donors. Attendance drives corporate sponsorship so there was a business case. It's also good for tracking their performance against actual actions vs stated goals.]

The advantages of using a web application toolkit - theromansarecoming.com took $50,000 to build for a four month exhibition. It hit the goals but was expensive. [The demo looked really cool, it's a shame you don't seem to be able to access it online.]

Breaking the Mode was built using existing components on the technical side, but required the same content investment i.e. in-house resources as The Romans Are Coming. The communication issues were much better because it was built in-house - less of a requirement to explain to external developers, which had some effect on the cost [but the biggest saving was i re-usable component] - the site took 25 hours to build and IT staff costs were about $1000. [So, quite a saving there.]

They demonstrated 'athena', the IMA's intranet. It has file sharing and task management and is built on drupal, looks a bit like basecamp-lite but without licensing issues. "Everything you do in a museum is project-based" and their intranet is built to support that.

There was discussion about whether their intranet could be shared with other museums. Rob Stein is a firm believer in open source and thinks it's the best way to go for museum sector. They're willing to share the source code but don't have the facilities to support it. There's a possibility that they could partner with other institutions to combine to pay small vendors to support it.

[I could hear a sudden burst of keyboards clicking around me as the discussion went onto pooling resources to create and support open source applications for stuff museums need to do. Smaller museums (i.e. most of us, and most are much smaller than MoL) don't have the resources for bespoke software or support but if we all combined, we'd be a bigger market. Overall, it was a really good, grounded discussion about the realities and possibilities of open source development.]

Back to the slides...

Team Troubles
[It was absolutely brilliant to see a discussion of teamwork and collaboration issues in a technical session.]

Divide and conquer - allow team members to focus on area of expertise. Makes it easier to swap out content and themes.

They're using MVC - Model (data management), Controller (interaction logic), View (user internface). They had some good stuff on MVC and the web in their slides (around 77-79). They also discussed the role of non-technical team members.

Drupal boot camp
[This was a pretty convincing demo of getting started with Drupal and using the Content Construction Kit (CCK) to create custom content types e.g. work of art to publish content quickly, though I did wonder about how it integrated with ORMs that would automatically pick up an underlying data structure. Slide 103 showed recommended Drupal modules. It's definitely worth checking out if you're looking for a CMS. If you're on Windows, check out bitnami for installation.]

Client side development
"The customer is always right"
They talked about the DOM (document object model) and javascript for Web 2.0 coolness.
They recommended using Javascript toolkits - more object-orientated, solve cross-browser issues, rapid development. Slide 109 listed some Javascript toolkits and they also recommended Firebug.

Interface components
They should be re-usable, just like the server-side stuff. They should some suggestions like reCAPTCHA, image carousels and rating modules. Pick the tools with best community support and cross-platform support.

CSS boilerplates
Treat CSS like another software component of web design and standardise your CSS usage. Use structured naming for classes and divs in server-side content generation. Check out oswd.org for free templates.

XML in the real world
They demonstrated Global Origins (more on that and other goodness at www.ima-digital.org/special-projects) which uses XML driven content.

Questions and discussion
I asked about integration with legacy/existing systems. Their middleware component 'Mercury' binds their commercial packages and other applications together. e.g. collection management system extraction layer. [This could be a good formalised model for MoL, as we have to pull from a few different places and push out to lots more and it's all a bit ad hoc at the moment. I think we'll be having lots of good discussions about this very soon.]

Some discussion about putting pressure on vendors to open data models. It's a better economic model for them and for museums.

Their CEO is supportive of iteration (in the development process). The web team is cross-department, and they have new media content creators.

[I was curious about how iterative development and the possibility of making mistakes work with their brand but didn't want to ask too many questions]

They made the point that you have a bigger recruiting pool with open source software. [Recruiting geeks into museums has been a bit of a conference meme.]

They give away iPods for online surveys and get more responses that way, but you do have to be aware that people might only give polite answers to survey questions so pay close attention to any criticism.

The IMA say you should be able to justify the longevity of projects when experimenting. Measure your projects against your mission, and how they can implement your mission statement.

So, that's it! I hope I didn't misrepresent anything they said.