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."

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.

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:

• jQuery
• prototype
• script.aculo.us
• MooTools
• dojo

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.

Amazon's new look (with a bit of transparency)

Just today I asked if anyone used drop-down menus anymore, and here Amazon have gone and launched a new design that uses them.

I don't know how many people would notice, but I like that they've provided a link (in the top right-hand corner with the text, 'We've had a redesign. Take a look') to 'A Quick Tour of Our Redesign'. The page highlights some of the changes/new features and provides answers to questions including 'Why did you change the site?', 'How did you decide on this design?' and 'What's different?'.

I'm guessing they've done their research and found that kind of transparency helps people deal with the changes - I was hoping to blog about our web redesign process, and I think this shows its worth doing. I wonder how many people notice the 'redesign' link and are interested enough to click on it.

Nielson on 'should your website have concise or in-depth content?'

Long pages with all the text, or shorter pages with links to extended texts - this question often comes up in discussions about our websites. It's the kind of question that can be difficult to answer by looking at the stats for existing sites because raw numbers mask all kinds of factors, and so far we haven't had the time or resources to explore this with our different audiences.

In Long vs. Short Articles as Content Strategy Jakob Nielsen says:

• If you want many readers, focus on short and scannable content. This is a good strategy for advertising-driven sites or sites that sell impulse buys.
• If you want people who really need a solution, focus on comprehensive coverage. This is a good strategy if you sell highly targeted solutions to complicated problems.

...

But the very best content strategy is one that mirrors the users' mixed diet. There's no reason to limit yourself to only one content type. It's possible to have short overviews for the majority of users and to supplement them with in-depth coverage and white papers for those few users who need to know more.

Of course, the two user types are often the same person — the one who's usually in a hurry, but is sometimes in thorough-research mode. In fact, our studies of B2B users show that business users often aren't very familiar with the complex products or services they're buying and need simple overviews to orient themselves before they begin more in-depth research.

Hypertext to the Rescue
On the Web, you can offer both short and long treatments within a single hyperspace. Start with overviews and short, simplified pages. Then link to long, in-depth coverage on other pages.

With this approach, you can serve both types of users (or the same user in different stages of the buying process).

The more value you offer users each minute they're on your site, the more likely they are to use your site and the longer they're likely to stay. This is why it's so important to optimize your content strategy for your users' needs.

So how do we adapt commercial models for a cultural heritage context? Could business-to-business users who start by familiarising or orienting themselves before beginning more in-depth research be analogous to the 'meaning making modes' for museum visitors - browsers and followers, searchers or researchers - identified by consultants Morris, Hargreaves, McIntyre?

Is a 'read more' link on shorter pages helpful or disruptive of the visitors' experience? Can the shorter text be written to suit browsers and followers and the 'read more' link crafted to tempt the searchers?

I wish I could give the answer in the next paragraph, but I don't know it myself.

IE8 and web standards

A quick pointer to the Joel on Software piece 'Martian Headsets' on IE 8 and standards:

The IE 8 team is in the process of making a decision that lies perfectly, exactly, precisely on the fault line smack in the middle of two different ways of looking at the world. ... it’s the difference between "idealists" and "realists".

Recommendations for AJAX and accessibility

A new Webcredibles article, AJAX accessibility for websites, highlights some of the potential benefits and disadvantages of AJAX technologies.

The section on recommendations for AJAX and accessibility was particularly useful, and a lot of the advice probably applies to non-traditional browsers such as mobile phone users. Basically:

• Inform users early in the page that dynamic updates will occur
• Highlight the areas that have been updated
• Don't change the focus
• Offer the option to disable automatic updates
• Ensure the site works if JavaScript isn't enabled

Final diary entry from Catalhoyuk

I'm back in London now but here goes anyway:

August 1
My final entry of the season as I'm on the overnight train from Cumra to Istanbul tonight. After various conversations on the veranda I've been thinking about the intellectual accessibility of our Catalhoyuk data and how that relates to web publication and this entry is just a good way to stop these thoughts running round my head like a rogue tune.

[This has turned into a long entry, and I don't say anything trivial about the weather or other random things so you'd have to be pretty bored to read it all. Shouldn't you be working instead?]

Getting database records up on the website isn't hard - it's just a matter of resources. The tricky part is providing an interesting and engaging experience for the general visitor, or a reliable, useable and useful data set for the specialist visitor.

At the moment it feels like a lot of good content is hidden within the database section of the website. When you get down to browsing lists of features, there's often enough information in the first few lines to catch your interest. But when you get to lists of units, even the pages with some of the unit description presented alongside the list, you start to encounter the '800 lamps' problem.

[A digression/explanation - I'm working on a website at the Museum of London with a searchable/browsable catalogue of objects from Roman Londinium. One section has 800 Roman oil lamps - how on earth can you present that to the user so they can usefully distinguish between one lamp and another?]

Of course, it does depend on the kind of user and what they want to achieve on the Londinium site - for some, it's enough to read one nicely written piece on the use of lamps and maybe a bit about what different types meant, all illustrated with a few choice objects; specialist users may want to search for lamps with very particular characteristics. Here, our '800 lamps' are 11846 (and counting) units of archaeology. The average user isn't going to read every unit sheet, but how can they even choose one to start with? And how many will know how to interpret and create meaning from what they read about the varying shades of brown stuff? Being able to download unit sheets that match a particular pattern - part of a certain building, ones that contain certain types of finds, units related to different kinds of features - is probably of real benefit to specialist visitors, but are we really giving those specialist visitors (professional or amateur) and our general visitors what they need? I'm not sure a raw huge list of units or flotation numbers is of much help to anyone - how do people distinguish between one thumbnail of a lamp or one unit number and another in a useful and meaningful way? I hope this doesn't sound like a criticism of the website - it's just the nature of the material being presented.

The variability of the data is another problem - it's not just about data cleaning (though the 'view features by type' page shows why data cleaning is useful) - but about the difference between the beautiful page for Building 49 and rather less interesting page for Building 33 (to pick one at random). If a user lands on one of the pages with minimal information they may never realise that some pages have detailed records with fantastic plans and photos.

So there are the barriers to entry that we might accidentally perpetuate by 'hiding' the content behind lists of numbers; and there is the general intellectual accessibility of the information to the general user. Given limited resources, where should our energies be concentrated? Who are our websites for?

It's also about matching the data and website functionality to the user and their goals - the excavation database might not be of interest to the general user in its most raw form, and that's ok because it will be of great interest to others. At a guess, the general public might be more interested in finds, and if that's the case we should find ways to present information about the objects with appropriate interpretation and contextualisation, not only to present information about the objects but also to help people have a more meaningful experience on the site.

I wonder if 'team favourite' finds or buildings/spaces/features could be a good way into the data, a solution that doesn't mean making some kinds of finds or some buildings into 'treasure' and more important than others. Or perhaps specialists could talk about a unit or feature they find interesting - along the way they could explain how their specialism contributes to the archaeological record (written as if to an intelligent thirteen year old). For example, Flip could talk about phytoliths, or Stringy could talk about obsidian, and what their finds can tell us.

Proper user evaluation would be fabulous, but in the absence of resources, I really should look at the stats and see how the site is used. I wonder if I could do a surveymonkey thing to get general information from different types of users? I wonder what levels of knowledge our visitors have about the Neolithic, about Anatolian history, etc. What brings them to the website? And what makes them stick around?

Intellectual accessibility doesn't only apply to the general public - it also applies to the accessibility of other team's or labs content. There are so many tables hidden behind the excavation and specialist database interfaces - some are archived, some had a very particular usage, some are still actively used but still have the names of long-gone databases. It's all very well encouraging people to use the database to query across specialisms, but how will they know where to look for the data they need? [And if we make documentation, will anyone read it?]

It was quite cool this morning but now it's hot again. Ha, I lied about not saying anything trivial about the weather! Now go do some work.
(Started July 29, but finally posted August 1)

At UK Museums and the Web 2007 I suggested looking at how other sites differentiate user-generated content from institutionally-created content. In that light, this post could be of interest: Newspapers 2.0: How Web 2.0 are British newspaper web sites?

Over the last two weeks I've reviewed eight British newspaper web sites in depth, trying to identify where and how they are using the technologies that make up the so-called "Web 2.0" bubble. I've examined their use of blogs, RSS feeds, social bookmarking widgets, and the integration of user-generated content into their sites.

Why Your Web App Sucks lists basic but important reasons why your web application might suck.

Is My Web Site Ineffective? 'Two Ultimate Web Design Checklists' for non-profit organisations.

Clay pipe recording at MoLAS and "Clay tobacco pipe makers' marks from London" website

[Update, December 2011: if you're interested in clay pipes, you may be interested in Locating London's Past. The site also has an article that explains how Museum of London Archaeology (MoLA) Datasets - including clay pipes and glass - have been incorporated into the site.  NB: other than adding these links, I haven't updated the original 2006 paper below, so it doesn't include any enhancements made for this new work.  On a personal note, it's lovely to see that the sites, and the backend work behind them, still have value.]

Wheel symbol with pellets between the spokes, c 1610-40.

I'm just back from giving a paper at the Society for Clay Pipe Research Conference, held at the LAARC today. I thought I'd share the content of my paper online so that other people interested in digitising and publishing collections online could see how one particular project was implemented.


Some interesting feedback from the question session afterwards was that other archaeological units, museums or researchers might be interested in publishing records to the same site. In that case, I'd be happy to review the structures so they could be generalised (for other identifiers, for example) and publish them as an open standard along with more detailed information on the digitisation process.


Anyway, here's the text of the paper:

Clay pipe recording at MoLAS and the stamped makers’ mark website

Mia Ridge, Database Developer, Museum of London

SCPR ANNUAL CONFERENCE, September 16th 2006

London Archaeological Archive and Research Centre, Mortimer Wheeler House

Summary

The paper discusses the process from initial specification through requirements gathering, database design, development of the database application and website, to publication online.

Introduction

The project began with a proposal to create a database of clay tobacco pipe makers' marks from London:

"...a physical and digital database of clay tobacco pipe makers’ marks found in excavated contexts from London, dating to between c 1580 and 1910. This will encompass examples of makers’ marks, both stamped and moulded, on pipes made in London and imported from further afield, both in the UK and on the Continent. ... The digital version of the database will be made available online, as part of the MoLAS website"


The work had two parts - enhancing the MoLAS Oracle database so that it could record more detailed information about the maker's marks; and creating a website to publish the marks and related images and information online.

Requirements gathering

'Requirements gathering' is the process of scoping and defining a project. The first step towards this is to define the internal and external stakeholders; the second is to determine their requirements. Internal stakeholder requirements include modified forms and structure for recording enhanced data and analysis, while external requirements relate to the publication of the data to defined groups of website users. It is important to define the targeted users of your website so that its content, site architecture and functionality can be tailored to them.


The targeted users of the site were largely determined by the subject matter. The main users will be specialists, followed by general adults. Site functionality, considered as search or browse capabilities, was determined as a balance between the purpose of the site, the needs of its visitors and the content and infrastructure we have available.


The database and website also had to be expandable to provide for greater temporal or geographic coverage, including collections throughout the Greater London area. Finally, in order to design data structures that would best meet the needs of the project, I had to consider nature of the material to be recorded.


The first discussions with Jacqui and Tony were about the requirements for the website. We then met to review the existing Oracle data structures and discuss the necessary changes. I asked lots of questions about how makers marks related to clay pipes - where, what kind and how many might appear on a pipe? It was important to understand how they varied, and which properties of position, type and method were significant, as well as to understand the exceptions. As you know, one 'IS' stamp is not necessarily the same as another 'IS' stamp - the trick is to enable to application to understand the difference. In this process, the aim is not to uncover the detail of the subject but to understand how its typologies are constructed.



Once the requirements have been determined, data structures were designed accordingly. These were presented to Jacqui and Tony, and reviewed in response to their feedback. Prototype forms were then designed to allow data entry, and the same process of feedback and modification followed. Significant changes were made after testing and further modifications were made as necessary during the implementation process as the practical implications of the modifications became clear.


One of the challenges of database design is balancing the benefits of recording in a more structured way, which provides for much greater flexibility in analysis, search and publication against a smaller learning curve and greater efficiency in data entry. For example, as different types of information are separated out of free text or general comments into more precise fields, the time required to record each entry increases.



As the data structures were finalised, queries were run to populate the modified structures with existing data, where possible.

Database design and development

The MoLAS Oracle database is used by our archaeologists and specialists to record field, find and environmental data. It has been developed in-house over many years and is one of the largest databases of its kind in the UK. As the database and forms are maintained in-house, we are able to modify it to meet our needs as required for projects or day-to-day business.


In the MoLAS database an individual pipe record must have a unique combination of sitecode, context, accession number and form that is different from any other pipe record. This unique identifier forms the basis of the database application. This combination of identifiers, called a 'primary key', can be used create links from a pipe with a particular mark to possible pipe makers. The sitecode can also be used to link to information about the particular excavation. Should a specialist desire, they can also link to other finds from the same context as well as related excavation and environmental data. The existing table structure was modified to support recording clay pipes and maker's marks in a more semantically structured way, with more detail and additional attributes.




The existing comments field was split into four new fields: general comments, maker comments, publication references, and parallels. I ran a report that listed all the existing comments so they could be manually reviewed and separated out into the relevant content areas.


A new field was added to mark pipe records that were to be published on the web. Other enhancements included new fields such as completeness, mould, manufacturing evidence, fabric, pipe length, links to photographs and illustrations, as well as a new numerical field, 'die' to allow the recording of individual dies known to be have been used by a single maker or workshop. The final new field was one that allows a particular pipe to be marked as containing the best example of a particular mark.


Some of the new fields required the creation of lists of values. These appear as drop-down menus on the data entry forms, and are used to make data entry faster and reduce errors. They are implemented as tables and can be designed so the values can be edited or added to as required.


When creating new fields, it's important to judge the effect on existing data, particularly in a project that can only selectively enhance records. As the project grant covered the enhancement of records for 120 marked clay pipes made between c 1580 and 1680, a small percentage of the entire dataset, many existing records would not have any data for the new fields. If it is not possible to go back and record the relevant information in the new field for each existing record, might that affect the validity of the data set as a whole? Will queries or searches return unexpected results if values aren't recorded consistently? Sometimes it is possible to apply a default value for existing records, or to mark previous records as 'not recorded'.


New tables were created to record information about known pipe makers. This includes their name, address, earliest and latest known dates, and free text including documentary evidence for this information. As this information is recorded in the database rather than in text files, it can be more easily searched and combined with related information and pipes for publication.


Additional tables were created to record the relationship between a mark on a particular pipe and a possible maker, including the probability of any pipe being related to a individual maker plus any publication references.

Content preparation

Enhancing database records

The basic process for enhancing stamped pipe records was:

1. Add the webcode 'CoLAT' to the pipes that will be included in this project


2. Add the photo number to the Photo number field


3. Review and update the pipes entries


4. Create the makers entries


5. Add pipes to the sub-form on the makers form to create the link between pipe and definite/probable/possible maker

Two queries were created to help monitor progress and give an idea of how the data would look on the website. One was a report showing which records have been successfully marked up for export to the website. The other showed how the links between makers and pipes would be displayed and could be used to check the success of a link created between a mark and possible maker.

Other content preparation

While the technical database and website development and specialist recording work was underway, Jacqui had organised for the MoLAS photographer to take photos of the marks that were going to appear on the website. The photo number was then recorded in the database. The scripts that generate the website use this to link the right image to the right pipe and mark for display on the web page. Jacqui also wrote text for inclusion on the site and definitions of codes used in the database were created, to make the published records more user-friendly and clear to non-specialists.

The website

The address of the website, 'Clay tobacco pipe makers' marks from London' is http://www.museumoflondon.org.uk/claypipes/
It is held as a 'collections microsite' within the Museum of London website structure.

The front page

The front page is designed to provide direct access to the data while contextualising the content, making the current scope of the project and the goals of the site immediately clear. It also allows us to thank our funders.


The design of the website was based on templates developed for the LAARC site. The front page introduces the navigation and title banner, which remain consistent throughout the site. There are three immediately clear 'calls to action' for the user on the front page: browse maker's marks, browse makers, and search for marks.

Browse maker's marks

http://www.museumoflondon.org.uk/claypipes/pages/marks.asp

In this section of the site, you can view thumbnails of the best example of each mark. The initials or description of the mark are listed with each thumbnail. This means you can search the text of the page for a particular mark, and also aids accessibility and helps search engines index the site, while still being visually appealing.

View mark

From the list of marks, you can access the page for a particular mark. Where appropriate, this page contains a more detailed description of the mark; images of all the pipes with that mark plus the sitecode, excavation context number and bowl form for that pipe. It also displays the dates associated with that form and the die number for each pipe on the page. Each image of a mark is also a link to the particular pipe page.

View pipe

Each pipe page contains the initials or description of its makers mark, a description of the pipe, its burnishing and milling as well as information about the excavation in which the pipe was found. This includes the address, easting and northing of the site. It would be possible to link to the full site record in LAARC, particularly when the LAARC site has been redeveloped. The page also lists any possible or known makers and the certainty of their being the maker of that pipe. The name of each maker is a link to the maker.

View maker

This page displays the name, address, earliest and latest dates plus any additional commentary and publication references for the maker. It also lists each pipe they might have made with the probability of their being the maker.

Browse makers

http://www.museumoflondon.org.uk/claypipes/pages/makers.asp
This page displays a list of all makers on the site. The name of each maker is a link to the full information about that maker, as above.

Search

http://www.museumoflondon.org.uk/claypipes/pages/search.asp
The search for this site is fairly simple, but the functionality can be expanded if necessary.
It searches the description field for a match to the search term.

About the project

http://www.museumoflondon.org.uk/claypipes/pages/about.asp

This section contains excellent information for general visitors and specialists about the project, why clay pipes are important for archaeologists, the clay pipes of London as well as a glossary and references. These pages contextualise the study of clay pipes, enriching the general visitor's experience and providing specific information about the background to tobacco pipe makers’ marks found in excavated contexts from London for specialist users.

From the database to the website

The first step in publishing the enhanced content online is getting data from the internal database to the web server. The web server is the computer that sends out the pages when a visitor clicks on the link.


SQL scripts run on the MoLAS server extract data from the MoLAS Oracle database and other sources, combining them into a form suitable for publication on the website. This data is stored in tables on the web server database. Information about the archaeological sites is drawn from data published through the London Archaeological Archive Resource Centre (LAARC) web site. This data is linked throughthe sitecode on the pipe or mark database record.


The scripts also combine information that has been stored separately into the publication format according to the relationships defined in the database. For example, they may bring together a pipe with possible makers through the pipe marks recorded. Where necessary, the database extraction scripts also extract the code definitions from List of Value tables. These translate a value like the mark position code 'BR' into the more user-friendly 'on the bowl, on right side as smoked'.


The website is generated by another collection of scripts, using a web scripting language called ASP. These scripts can be thought of as templates that contain placeholders for different types of information or images. When a page is requested, the script runs and fills the appropriate information in the appropriate part of the template.


Because these templates dynamically generate the pages, the design and the content are separated. This means the site can be expanded as new records are added to the database. Updated or new content can appear on the site instantly, without waiting for IT resources to be available. It's also easy to update the templates so that new fields can be viewed, new links generated or additional search parameters added. The graphic design (the 'look and feel' of the site) or the site navigation can be updated in a single script and the change is immediately visible across all site pages.


The 'about' section of the website also contains 'static' pages. These pages do not change when the content of the database changes. However, they use the same scripts to generate the design and navigation so can easily be changed as necessary.


One of the requirements for the site was that it was accessible to search engines. As the project did not have a budget for marketing the site, search engines were going to be the main source of website visitors. The site was designed using 'semantic markup' which not only helps search engines understand the structure of the site, but also aids accessibility for people with disabilities.