Category: Technology

Cosmic Champions – winners of Cosmic Collections competition announced

I originally posted this on the Science Museum developers blog.

In case you missed the announcement on twitter or elsewhere, the winners have been revealed…

Our thanks to everyone who participated, commented, critiqued or cheered the project along.

And here's the announcement page from the Science Museum website

Via the Internet Archive

Find out who won our Cosmic Collections competition.

Cosmic Champions

Last October, we launched a competition to release hundreds of stories from the Cosmos & Culture exhibition on to the web. We invited astronomy enthusiasts, designers and web developers to create their own websites with our objects – and the results are now in.

There were two competitions, to create websites for adults and for the 11-16 age group. We didn’t get enough entries in the second group to award a prize, but the quality of the entries in the adult group was so high that we’ve decided to award an extra prize for that.

Overall winner (£1000 prize)

Simon Willison and Natalie Down
Entry at http://cosmos.natimon.com/
The judges felt that Simon and Natalie’s entry made the best use of our collections data, as it allows users to browse objects by people, places and celestial body, making links between them. Judge Chris Lintott describes it as 'having a wikipedia-like quality of sucking the user in for just one more click'.

Runner-up (£750 prize)

Ryan Ludwig
Entry at http://www.serostar.com/cosmic/
The judges were really impressed with the visual appeal of Ryan’s entry, particularly the image gallery with thumbnails and zoom function.

The judges also commended Ray Shah’s entry (http://collection.thinkdesign.com/), particularly the function for users to add their own data.

What happens next?

We’ll be working with our winners to incorporate the best aspects of their entries into a finished product. We will be launching it on the Science Museum’s website in February, so watch this space!

Notes

1) The competition judges were:

Christian Heilmann
A geek and hacker at heart, Christian Heilmann has been a professional web developer for about eleven years. He has been nominated "standards champion of the year 2008" by .net magazine in the UK and he currently sports the fashionable job title "International Developer Evangelist" spending his time speaking and training people on systems provided by Yahoo and other web companies that want to make this web thing work well for everybody.

Chris Lintott
Chris Lintott is a post-doctoral researcher in the Department of Physics at the University of Oxford. His research looks at the analysis of star formation, including being principal investigator for the Galaxy Zoo project. He is also co-presenter on the Sky at Night program alongside Sir Patrick Moore.

2) Entries to the competition were assessed under the following categories:

  • Use of collections data
  • Creativity
  • Accessibility
  • User experience
  • Ease of deployment and maintenance

3) The Cosmos & Culture exhibition is supported by the Patrons of the Science Museum with additional support from the Science & Technology Facilities Council, STFC.

Performance testing and Agile – top ten tips from Thoughtworks

I've got a whole week and a bit off uni (though of course I still have my day job) and I got a bit over-excited and booked two geek talks (and two theatre shows). This post is summarising a talk on Top ten secret weapons for performance testing in an agile environment, organised by the BCS's SPA (software practice advancement) group with Patrick Kua from ThoughtWorks.

His slides from an earlier presentation are online so you may prefer just to head over and read them.

[My perspective: I've been thinking about using Agile methodologies for two related projects at work, but I'm aware of the criticisms from a requirements engineering perspective that doesn't deal with non-functional requirements (i.e. not requirements about what a system does, but how it does it and the qualities it has – usability, security, performance, etc) and of the problems integrating graphic and user experience design into agile processes (thanks in part to an excellent talk @johannakoll gave at uni last term.  Even if we do the graphic and user experience design a cycle or two ahead, I'm also not sure how it would work across production teams that span different departments – much to think about.

Wednesday's talk did a lot to answer my own questions about how to integrate non-functional requirements into agile projects, and I learned a lot about performance testing – probably about time, too. It was intentionally about processes rather than tools, but JMeter was mentioned a few times.]

1. Make performance explicit.
Make it an explicit requirement upfront and throughout the process (as with all non-functional requirements in agile).
Agile should bring the painful things forward in the process.

Two ways: non-functional requirements can be dotted onto the corner of the story card for a functional requirement, or give them a story card to themselves, and manage them alongside the stories for the functional requirements.  He pointed out that non-functional requirements have a big effect on architecture, so it's important to test assumptions early.

[I liked their story card format: So that [rationale] as [person or role] I want [natural language description of the requirement].]

2. One team.
Team dynamics are important – performance testers should be part of the main team. Products shouldn't just be 'thrown over the wall'. Insights from each side help the other. Someone from the audience made a comment about 'designing for testability' – working together makes this possible.

Bring feedback cycles closer together. Often developers have an insight into performance issues from their own experience – testers and developers can work together to triangulate and find performance bottlenecks.

Pair on performance test stories – pair a performance tester and developer (as in pair programming) for faster feedback. Developers will gain testing expertise, so rotate pairs as people's skills develop.  E.g. in a team of 12 with 1 tester, rotate once a week or fortnight.  This also helps bring performance into focus through the process.

3. Customer driven
Customer as in end user, not necessarily the business stakeholder.  Existing users are a great source of requirements from the customers' point of view – identify their existing pain points.  Also talk to marketing people and look at usage forecasts.

Use personas to represent different customers or stakeholders. It's also good to create a persona for someone who wants to bring the site down – try the evil hat.

4. Discipline
You need to be as disciplined and rigorous as possible in agile.  Good performance testing needs rigour.

They've come up with a formula:
Observe test results – what do you see? Be data driven.
Formulate hypothesis – why is it doing that?
Design an experiment – how can I prove that's what's happening? Lightweight, should be able to run several a day.
Run experiment – take time to gather and examine evidence
Is hypothesis valid? If so –
Change application code

Like all good experiments, you should change only one thing at a time.

Don't panic, stay disciplined.

5. Play performance early
Scheduling around iterative builds makes it more possible. A few tests during build is better than a block at the end.  Automate early.

6. Iterate, Don't (Just) Increment
Fishbone structure – iterate and enhance tests as well as development.

Sashimi slicing is another technique.  Test once you have an end-to-end slice.

Slice by presentation or slice by scenario.
Use visualisations to help digest and communicate test results. Build them in iterations too. e.g. colour to show number of http requests before get error codes. If slicing by scenario, test by going through a whole scenario for one persona.

7. Automate, automate, automate.
It's an investment for the future, so the amount of automation depends on the lifetime of the project and its strategic importance.  This level of discipline means you don't waste time later.

Automated compilation – continuous integration good.
Automated tests
Automated packaging
Automated deployment [yes please – it should be easy to get different builds onto an environment]
Automated test orchestration – playing with scenarios, put load generators through profiles.
Automated analysis
Automated scheduling – part of pipeline. Overnight runs.
Automated result archiving – can check raw output if discover issues later

Why automate? Reproducible and constant; faster feedback; higher productivity.
Can add automated load generation e.g. JMeter, which can also run in distributed agent mode.
Ideally run sanity performance tests for show stoppers at the end of functional tests, then a full overnight test.

8. Continuous performance testing
Build pipeline.
Application level – compilation and test units; functional test; build RPM (or whatever distribution thingy).
Into performance level – 5 minute sanity test; typical day test.

Spot incremental performance degradation – set tests to fail if the percentage increase is too high.

9. Test drive your performance test code
Hold it to the same level of quality as production code. TDD useful. Unit test performance code to fail faster. Classic performance areas to unit test: analysis, presentation, visualisation, information collecting, publishing.

V model of testing – performance testing at top righthand edge of the V.

10. Get feedback.
Core of agile principles.
Visualisations help communicate with stakeholders.
Weekly showcase – here's what we learned and what we changed as a result – show the benefits of on-going performance testing.

General comments from Q&A: can do load generation and analyse session logs of user journeys. Testing is risk migitation – can't test everything. Pairing with clients is good.

In other news, I'm really shallow because I cheered on the inside when he said 'dahta' instead of 'dayta'. Accents FTW! And the people at the event seemed nice – I'd definitely go to another SPA event.

Cosmic Collections – the results are in. And can you help us ask the right questions?

For various reasons, the announcement of the winners of our mashup competition has been a bit low key – but we're working on a site that combines the best bits of the winners, and we'll make a bit more of a song and dance about it when that's ready.

I'd like to take the opportunity to personally thank the winners – Simon Willison and Natalie Down in first place, and Ryan Ludwig as runner-up – and equally importantly, those who took part but didn't win; those who had a play and gave us some feedback; those who helped spread the word, and those who cheered along the way.

I have a cheeky final request for your time.  I would normally do a few interviews to get an idea of useful questions for a survey, but it's not been possible lately. I particularly want to get a sense of the right questions to ask in an evaluation because it's been such a tricky project to explain and 'market', and I'm far too close to it to have any perspective.  So if you'd like to help us understand what questions to ask in evaluation, please take our short survey http://www.surveymonkey.com/s/5ZNSCQ6 – or leave a comment here or on the Cosmic Collections wiki.  I'm writing a paper on it at the moment, so hopefully other museums (and also the Science Museum itself) will get to learn from our experiences.

And again – my thanks to those who've already taken the survey – it's been immensely useful, and I really appreciate your honesty and time.

Museum design patterns (from the GLAM API wiki)

I originally posted this on the Museums and the machine-processable web Museum design patterns page.

Inspired by the Yahoo! Design Pattern Library and expanding on situations particular to museum content (particularly exhibitions and catalogues), audiences and context (from stereotypes of museums as boring and dry to issues around authority and trust in cultural heritage)…

These design patterns might be useful for coming up with common data structures that could inform a shared schema for linking across collections, help provide a framework for sharing audience evaluation and comparing visitation figures, etc.

A bit of an experiment – let's see if it sticks.

If you're using design patterns already, do any that particularly need adapting come to mind?  Or can you share some behaviours you've noticed that are typical of museum audiences?

Suggestions for simple starting points also welcome!  I've put some very initial rough thoughts below – with any luck there are existing current typologies out there that could replace this.

Design patterns

Encouraging debate, comments

Participation rates on museum blogs and other commenting sites are often low, perhaps lower than the equivalent content might attract on a non-museum site.  How have the most successful sites encouraged participation and comment?

Search patterns

[share what you know!]

Typology of museum sites (as a context for more specific design patterns)

NB: many sites will contain a mixture of types, though often collections or exhibition sites are presented as 'microsites'.

Brochure-ware

Do these still exist?

Experiential exhibitions sites

From shiny interactive/multimedia brochureware to games tied to the gallery experience/content.

Exhibition catalogue sites

Presentations of exhibition content, usually replicating curatorial or physical organisation methods used in the physical gallery or a translation of the print catalogue into a website.

Online-only exhibition site

Is this just about the level of interpretation – narratives, thematic contexts etc wrapped around object records?

Collections catalogue sites

Online catalogue, generally with organisation structures that replicate the management structures or subjects of the museum.

References

Comments on the wiki page

Comments (8)

Nate Solas said

at 3:19 pm on Jan 22, 2010

I've been doing an informal survey of how institutions present their online collection, and how they handle decisions like "advanced search", stemming of keywords, and whether they use an implicit AND or OR between multiple keywords. Hopefully I can summarize some of that into a few design patterns? If nothing else maybe I'll post the table here and let others go at it!

Mia said

at 11:29 pm on Jan 26, 2010

Good idea! Let me know if you want us to test the descriptions out for you, or to pass around a survey or something.

Mia said

at 7:13 pm on Feb 1, 2010

Nate, have you seen this? http://searchpatterns.org/

Nate Solas said

at 7:26 pm on Feb 1, 2010

Just today. A day late to help my paper, alas! I've read a bunch of Morville's blog – he's pretty good at presenting the big ideas in an understandable way and that new book and site seem awesome. I'll have to see if I can get the Walker to pay for a copy for me… :)

Richard said

at 6:31 pm on Aug 18, 2010

Mia,
Do you have a sense of the granularity you are looking for? The pattern libraries I've been using seem to focus on smaller snippets of interface (e.g. how to do a button, or an ordered list, etc. or Morville's search patterns). Would it be useful to re-frame the question of cultural heritage patterns at the same level? e.g. the Image/Tombstone pattern, which maybe used across different types of sites (or site functions). The point of this is to provide other developers re-usable/re-mixable code/style patterns, no?

I have some thoughts on this from a more research/analysis focus, but I don't think that's what you're getting at here. I can post more if that's of interest.

Mia said

at 1:13 am on Aug 19, 2010

That's a good question – I don't actually mean the patterns are that broad, just that the application and desirability of a pattern will depend on the type of site, or the section of the site. For example, you could possibly build a pattern around providing the basic when/where/how much information – if successful, the visitor would be able to find that and be on their way to the actual museum within a few seconds. But if you'd spent a lot of time creating video content about an exhibition, you'd hope the visitor would stick around long enough and see enough to be convinced to take the next step, whether that's booking tickets or whatever.

Mia said

at 1:15 am on Aug 19, 2010

And yes, please do post more! I think, to my mind, even image/tombstone depends on context – how big should the image be, how many images, interpretative or qualified dates in the tombstone data, etc.

Mia said

at 5:36 pm on Aug 26, 2010

Must read later: http://welie.com/patterns/showPattern.php?patternID=museum

Cosmic Collections – do one thing and do it well

I originally posted this on the Science Museum developers blog, filed under: API,competition,cosmosandculture,mashups — mia @ 7:03 pm

The Cosmic Collections competition has been running for a few weeks now, and while we’ve been sucked into a vortex of other projects, I’ve been keeping an eye out for feedback from the public.

As a result, I’ve realised that there may be some mismatch between the way mashups tend to work, and the scope we’ve suggested for entries to our competition. The types of interfaces someone might produce with the API may lend themselves more to exploring one particular idea in depth than produce something suitable for the broadest range of our audiences.

So I’m proposing to change the scope for entries to the competition, to make it more realistic and a better experience for entrants: I’d like to ask you to build a section of a site, rather than a whole site. The scope for entrants would then be: “create something that does one thing, and does it well”. Our criteria – use of collections data, creativity, accessibility, user experience and ease of deployment and maintenance – are still important but we’ll consider them alongside the type of mashup you submit.

This might mean producing a mashup for one particular way of exploring the objects, or exploring a sub-set of the objects. It’d then be up to us to combine the winning mashups into a larger site that works for our audiences.

What do you think? If there aren’t any huge objections, I’ll go ahead and update the criteria. Of course, if you’ve been working on something and feel it’s unfair to change the criteria at this stage, let me know and we’ll work something out.

As a reminder, here are the basic details for the Cosmic Collections competition:

How to take part

1. Check out the data here

2. Get some help:

Read our tips for entrants, check out these mashup resources, and get some info about our audiences. Check out the documentation and connect with other people who want to enter the competiton. You can also join the Google group or use the hashtag #coscultcom in conversations on Twitter.

3. Get inspired

Visit the exhibition and check out these videos about the exhibition

4. Get creative and get mashing!

5. Send us a link to your entry.

Email us by midnight on November 28 (GMT) – you don’t need to pre-register.

(And the title? I’m a big fan of the Unix philosophy, “do one thing and do it well”.)

'Cosmic Collections' launches at the Science Museum this weekend

I think I've already said pretty much everything I can about the museum website mashup competition we're launching around the 'Cosmos and Culture' exhibition, but it'd be a bit silly of me not to mention it here since the existence and design of the project reflects a lot of the issues I've written about here.

If you make it along to the launch at the Science Museum on Saturday, make sure you say hello – I should be easy to find cos I'm giving a quick talk at some point.
Right now the laziest thing I could do is to give you a list of places where you can find out more:
Finally, you can talk to us @coscultcom on twitter, or tag content with #coscultcom.
Btw – if you want an idea of how slowly museums move, I think I first came up with the idea in January (certainly before dev8D because it was one of the reasons I wanted to go) and first blogged about it (I think) on the museum developers blog in March. The timing was affected by other issues, but still – it's a different pace of life!

On 'cultural heritage technologists'

A Requirements Engingeering lecture at uni yesterday discussed 'satisfaction arguments' (a way of relating domain knowledge to the introduction of a new system in an environment), emphasising the importance of domain knowledge in understanding user and system requirements – an excellent argument for the importance of cultural heritage technologists in good project design.  The lecture was a good reminder that I've been meaning to post about 'cultural heritage technologists' for a while. In a report on April's Museums and the Web 2009, I mentioned in passing:

…I also made up a new description for myself as I needed one in a hurry for moo cards: cultural heritage technologist. I felt like a bit of a dag but then the lovely Ryan from the George Eastman House said it was also a title he'd wanted to use and that made me feel better.

I'd expanded further on it for the first Museums Pecha Kucha night in London:

Museum technologists are not merely passive participants in the online publication process. We have skills, expertise and experience that profoundly shape the delivery of services. In Jacob Nielsen's terms, we are double domain experts.  This brings responsibilities on two fronts – for us, and for the museums that employ us.

Nielsen describes 'double usability specialists' or 'double experts' as those with expertise in human-computer interaction and in the relevant domain or sector (e.g. ref).  He found that these double experts were more effective at identifying usability issues, and I've extrapolated from that to understand the role of dual expertise in specifying and developing online and desktop applications.
Commenters in the final session of MW2009 conference described the inability of museums to recognise and benefit from the expertise of their IT or web staff, instead waiting until external gurus pronounced on the way of the future – which turns out to be the same things museum staff had been saying for years.  (Sound familiar?)

So my post-MW2009 'call to arms' said "museums should recognise us (museum technologists) as double domain experts. Don’t bury us like Easter eggs in software/gardens. There’s a lot of expertise in your museum, if you just look. We can save you from mistakes you don't even know you're making. Respect our expertise – anyone can have an opinion about the web but a little knowledge is easily pushed too far".

However, I'm also very aware of our responsibilities. A rough summary might be:

Museum technologists have responsibilities too.  Don’t let recognition as a double domain expert make you arrogant or a ‘know it all’. Be humble. Listen. Try to create those moments of understanding, both yours from conversation with others, and others from conversation with you – and cherish that epiphany.  Break out of the bubble that tech jargon creates around our discussions.  Share your excitement. Explain how a new technology will benefit staff and audiences, show them why it's exciting. Respect the intelligence of others we work with, and consider it part of our job to talk to them in language they understand. Bring other departments of the museum with us instead of trying to drag them along.

Don't get carried away with idea that we are holders of truth; we need to take advantage of the knowledge and research of others. Yes, we have lots of expertise but we need to constantly refresh that by checking back with our audiences and internal stakeholders. We also need to listen to concerns and consider them seriously; to acknowledge and respect their challenges and fears.  Finally, don’t be afraid to call in peers to help with examples, moral support and documentation.

My thoughts on this are still a work in progress, and I'd love to hear what you think.  Is it useful, is it constructive?  Does a label like 'cultural heritage technologist' or 'museum technologist' help others respect your learning and expertise?  Does it matter?

[Update, April 2012: as the term has become more common, its definition has broadened.  I didn't think to include it here, but to me, a technologist ia more than just a digital producer (as important as they are) – while they don't have to be a coder, they do have a technical background. Being a coder also isn't enough to make one a technologist as it's also about a broad range of experience, ideally across analysis, implementation and support.  But enough about me – what's your definition?]

Join in our ‘cosmic collections’ mashup competition

I originally posted this on the Science Museum developers blog, filed under: competition,cosmosandculture,mashups — mia @ 2:20 pm

I won’t repeat the information already available on the Cosmic Collections launch event, and I’ll simply link to the page containing more information on judging criteria, prizes and timelines…  I just want to use this post to encourage you to sign up for the launch and head over to the competition wiki to find some team mates to turn your brilliant mashup idea into a working website.

Science Museum posts on collections online and more, 2009

I originally posted this set of posts on the Science Museum developers blog.

September 10, 2009: Working out collections online – your questions?

Filed under: collections,design,requestforcomment — mia @ 8:59 pm

I’ve been slowly putting together a list of research questions to try and tackle as I re-work our collections online (with our very own blogger, the transport curator David Rooney) and the ‘Online Stuff‘ section.  I’ll write up the process and my ideas as I go, but in the meantime – what’s your number one question about presenting museum collections online?  It could be ‘does x work better than y’, or ‘do people really want z’, or anything that’s been hanging around at the back of your brain. Leave a comment below or tweet @mia_out.

And speaking of collections online, check out the V&A’s Collections Search, just out in beta today.  There’s so much to explore and the interface is a delight.  Congratulations to all involved!

Comments (3)

September 3, 2009: Save the date – Cosmos and Culture launch event

Filed under: competition,cosmosandculture,mashups — mia @ 6:02 pm

A very quick post to let you know that we’ve set a date for the launch of the Cosmos and Culture website competition I’ve mentioned earlier.

The launch event will be held at the Science Museum on Saturday, October 24, 2009.  We’re planning a curator’s talk about the Cosmos and Culture exhibition, and we’re looking at ways to help people meet potential team mates – some kind of ‘hack matching’ thing.  We’ve made it a Saturday so that most people should be able to come, and it’ll be open to anyone.  More details to follow as we work them out!

At this stage, the competition submission date will be November 28, 2009, and we’re aiming to have the winning website(s) live to the public by mid-December.

If you’ve got any questions, leave a comment on this post, or tweet with the hash tag #coscultcom.

April 24, 2009: Some on-going work on museum APIs

Filed under: API,design,requestforcomment — mia @ 10:20 pm

Just a quick note to say we haven’t abandoned this blog, but at the moment I’ve been concentrating on working out issues around schemas/formats, content, and functions for re-usable and interoperable cultural heritage data on a wiki.

There’s a list of things you can do if you work in a museum or are a developer interested in using museum data – jump in!

Top ten tips for selling your IT project

I'm spending two days in Manchester for the JISC event, Rapid Innovation in Development. I've already had some interesting, inspiring and useful conversations and I'm looking forward to tomorrow (and more importantly, getting some quality programming time to try them out).

The event has a focus on helping developers effectively market their projects or ideas to wider audiences (aka 'normal people'). With that in mind, here are my notes from Alice Gugan's talk on her 'top ten tips for selling your project'.

She pointed out that it's not exhaustive but does list the key tips to focus on.

  1. Focus on your audience. Who they are, their interests, their technical level. If you're talking to a journalist, talk to who they're writing for.
  2. USP – what is yours? How does your project really change the lives of your audience? This is your main message. What makes your project stand out?
  3. Short and snappy sub-points. Not too many, make sure they lead logically on from your main message.
  4. Be confident. Be sure of your ground, be believable, be enthusiastic.
  5. Project your voice!
  6. Engage eye contact with your interviewer – if you have to scan your notes, still try to make eye contact with the audience.
  7. No gimmicks! They can be great but they won't necessarily make people remember what your project was about.
  8. No jargon! It's often a barrier to your audience. This includes acronyms.
  9. Practice, practice, practice. But keep it fresh, enthusiastic and believable.
  10. Test it on a stranger and adjust according to their reactions.

All good points! Based on years of geek conversations across several domains, I'd suggest making your pitch into a story about the engaging/useful/inexpensive/secure (etc, you get the picture) experience someone has while using your product. You can always bring out the technical details and features list later – once you've got people interested.

It's often hard to step back from the detailed perspective and remember how to talk about your project who haven't been living with it daily, but if you can't do that it's hard to make the best of your work by sharing it with a wider audience.

Focusing on your audience can be tricky – it's easier for pitches than more general presentations, but working out how to address audiences with different levels of technical or sector knowledge can be tricky. Maybe that's why I like user stories as pitches – it makes you step back from the acronomic** detail and think about what really makes your idea unique.

** Yeah, I made that up, but it's a nice cross between acronyms, macro and moronic.

[Update: thanks to Paul Walk for Alice's surname.

Also, I've found myself thinking about the event quite a bit since Friday – both in terms of the tips for presenting technical projects to non-technical staff, and generally in terms of the useful tips and inspiring ideas I picked up in conversation with other attendees.  Congratulations to all concerned for a great event!]