Beyond the Button

The Future of Museums in the Information Age

bryan kennedy — Wed, 30 Apr 2008 09:10:16 -0600

Maxwell L. Anderson, the director of the Indianapolis Museum of Art published a manifesto of sorts about technology in museums this last year. Jennifer Trant, on of the organizers of the Museums and the Web conference says that his work is a key reason that Museums and the Web will be in Indianapolis in 2009.

Visualizing visitor opinion with Google Charts API

bryan kennedy — Fri, 25 Apr 2008 19:46:49 -0600

Over at Science Buzz we are interested in exploring controversial issues in contemporary science with our museum visitors in new ways. In the past week we rolled out a kiosk and website that asks visitors to read through some medical scenarios, asking them questions about the situation along the way. Specifically the stories are about embryonic testing, a guardian's right to deny treatment, and assisted suicide.

We present the visitors with these scenarios via a web interface and collect their answers to the questions using the Drupal webform module. The webform module is a great tool for soliciting multiple types of feedback in a structured fashion. While webform has some reporting tools they are really designed for the administrator and don't visualize the data in an easily readable fashion.

Google Charts API

I was thinking about all sorts of complex ways to dynamically generate graphs with special image libraries, but that would likely take weeks to complete. In stepped the Google Charts API which lets you create charts, graphs, and even maps on the fly with a simple URL. The charts are served up as PNGs that are dynamically generated live from Google's servers each time the report page is loaded based on data you pass in the URL string. Very simple.

How we tied it all together

Visitor completes our scenario survey using the Drupal webform module, which stores their answers in the database
The visitor is sent to a results page with a call to a function in our custom drupal module called answers_report
The answers_report module pulls the answers out of the database and formats them into a PHP array.
Then we use this great go-between for the Google Charts API and PHP called, GoogChart.
GoogChart turns our PHP array of data into a big long URL which we can use to tell google to generate our pie chart.
We drop that URL into a HTML img tag and viola, there's our graph of user opinion.

Will it work?

I'm a big graphs and charts nerd. They help me visualize lots of information, but I am curious to see how visitors respond. Will these charts help generate some interesting conversations on the forums around each of these topics? Right now we don't have enough data to really tell, so go and tell us what YOU think.

Are you using the Google Charts API? If so how?

Museum copyright issues hit the main stream news

bryan kennedy — Tue, 22 Apr 2008 09:04:40 -0600

Michael Geist, the keynote speaker from Museums and the Web 2008, has a great feature in the BBC today. Highlights from the article:

In 2006 the V&A museum in London made all digitized images from its collection free for reproduction in academic journals and books
The National Gallery of Canada actually charges more for public domain images than copyright ones, an average of $379 (canadian).
Many museums around the world use restrictive and expensive licensing fees for images in the public domain.

Geist was a great speaker on these issues and I'm excited to see some of his ideas make it into the mainstream media with regards to museums.

Museums and the Web 2008 and the backchannel

bryan kennedy — Fri, 18 Apr 2008 13:24:23 -0600

The backchannel at this year's Museums and the Web (#mw2008) was especially active and important to my experience at the event. Check out some of the ephemeral cast out as a result of the discussion.

Twitter, Flickr, and the Blog feed

More and more folks got addicted to the backchannel feed this year. Thanks to Mike Ellis' OneTag system everyone's tweets got aggregated into one thread via the #mw2008 tag for all to follow at conference.archimuse.com....and elsewhere

One of the most exciting aspects of the #mw2008 tag for me was social in nature. By following the people posting on #mw2008 I was able to make TONS of new twitter and flickr friends who are specifically posting on issues and ideas that I care about already (museum folk). In this way the backchannel serves as a new high bandwidth networking tool.

As these tools become a more important method for fully experiencing a conference both live and remotely we will need new ways to visualize the large amount of data and content that is created. Stamen design's visualization of the backchannel at the 2006 ETech conference looks like an interesting first start.

Did any of you fellow mw2008 attendees have any cool backchannel experiences?

One last twitter link...check out your own tweet cloud. Here's mine.

Slowing Down

Chach Sikes — Tue, 08 Apr 2008 15:26:32 -0600

Flash camp

I attended mn.swf camp. This event was an all-day "Flash camp," held in Minneapolis (organized by the Minnesota Flash/Flex programmer's group and presented by Flashbelt.)

There were about a dozen presentations, mostly focused on using Flex and AIR â€“ two software packages that are positively dreamy for museum interactive developers.

Presentations about slowing down

Two lectures about process struck me. These are rooted in standard software development. One presenter, who talked a lot about â€˜tips and techniquesâ€™ for developers was Jason Grey. Another presenter talking about 'slowing down' (Danny Patterson, one of the authors of Advanced ActionScript 3 with Design Patterns.) Both talked about the benefits of slowing down, and how developers can push back against the development process to enable a better development process. The rest of this entry will discuss techniques presented by both presenters about how to 'slow down' the development process. A lot of the techniques may be standard for managers -- but are filtered by my perspective of a museum multimedia developer.

The tips

Usually, in the development process, the idea of slowing down is very foreign (especially in the museum worldâ€¦since it is already pretty slow as it is - and we are always trying to catch up with mainstream media expectations.) It is also a threatening and scary idea to tell project managers that you need to go slower â€“ or to offer a bid on a contract job that is extra long, worrying that you might not get the bid on a project that is super-cool.

Some qualities of a good developer

Patterson dispelled the myth that a fast developer is a good developer â€“ it is possible that a good developer could be fast â€“ but a good developer will also have the qualities of being thorough, conscious (making plans), analytical. The ability to work quickly is then a result of that process of being thoughtful.

A better arc for a project

He discusses the idea of â€˜project velocityâ€™ â€“ which he knows well as someone who has a lot of experience in software engineering. He says that project managers have an idea that the development process starts at the beginning, and works steadily to completion finishing perfectly at the end. He says that in reality, the last 5% takes 95% of the time working with that model. (True!)

He says that when the development starts slowing down â€“ the symptoms of a project manager having mismatched expectations about how a project should proceed appear. These symptoms usually take the form of continuous daily meetings â€œAre you done yet? Are you done yet? Why are you taking so long?â€ â€“ and really, all the harder stuff falls at this point: the documentation, maintenance, server configurations..and more!

This is a very bad model. The result is that developers, who are tired already, are basically getting the last ounces of strength beaten wrung from them, they start hearing about whatâ€™s coming up next, and how they have to deal with all the testing. Itâ€™s a very bad time and people just want the project to be over with.

Instead, Patterson presents a different idea â€“ that develop follow a gentler progression to start, and build lightly through the production phase, until near the very end when you can build momentum. (Perhaps this is also rooted in a family of management practices? Well, I donâ€™t know. Iâ€™m a developer.)

Plan a lot more, make the end of the project easier so it can be more positive

To achieve this, he proposes this model of development.

1. Planning
People sit far away from the computers. They develop clear formal specifications for the project. What will it do? What are we all expecting? Do we have everything we need?
As a tool for planning any programs one might write, he recommends UML â€“ the unified modeling language created for software engineeringâ€¦which is a way to diagram parts of a program.

Get the hard stuff over with first
Patterson recommends getting the documentation over with first...because otherwise you are four times less likely to ever do it (he cited a study about this.)

Will too much planning conflict with our plans to do agile development?
When discussing this practice with some colleagues, we wondered if this model conflicts with the idea of agile development. Probably not -- if you use agile development as a planning tool, or if you have some good habits of working even within your agile development. I can certainly benefit from both models of working.

Also, this does NOT mean that having clear plans takes years to work out every little last detail until it's perfect. You can have a clear small chunk of a specification to get started with - and then go about your normal iterative design process.

Here's my list of some problem areas for large institutions trying to get 'innovative' with technology:

Your organization needs to support this work
Developers should not have to bear the brunt this responsibility
Your staff will need training. Time needs to be set aside for experimentation and working on the 'shop'
Don't make your developers compete for the fun projects Causing developers to feel like they have to compete to get to do the fun stuff will force them into competitive situations - where some will win, and others will become disengaged.
Establish a community of quality work Allowing anyone to get away with crappy work will give everyone else a reason to not bother to do everything they ought to do. Also, if work is shared -- one project full of hacks will allow others to hack that project...and it will quickly get messy.
Don't skip clean up. If you develop, you should make time to clean up your code, fix your comments, fix â€˜kludgesâ€™, â€˜refactorâ€™ your code (meaning, break it up, or completely re-write it in order to avoid â€˜code smellâ€™)
Don't skip documentation. you should write out full documentation from the very beginning, and be building to the documentation and not the other way around.
Don't skip testing. Developers can plan to write out all the ways in which your product can break. They can learn about real testing scenarios. If your developers have no access to fresh testers, you can really help them to find those people. In my experience, there are super formal testing...which is part of evaluation usually -- but then there is just functional testing for which most people need reminding.
Don't skip evaluation. This one is pretty well vetted in the museum world.
Don't skip automation. You can and should investigate automation toolsâ€¦for your file transfers, file formatting, tests, archiving â€“ anything you can. That time will be well spent because it makes your documentation more robust.

2. Development: In this phase, work doesnâ€™t go very fast, but it is building slowly.

3. Alpha: before Alpha testing, momentum starts building. Parts of the project start coming together, you start getting feedbackâ€¦youâ€™ve done all the hard work already and this gives you the ability to have enthusiasm about your project. This momentum gets you through your testing and evaluation phases.

4. Beta: The momentum is still going. Pattersonâ€™s main note about this part of the process is that any changes you make have to be RE-tested.

Some notes for developers

Both presenters gave a few tips for developers wanting to push back and make their work environment more sane. These are pretty similar to guidelines for contractorsâ€¦but worth revisiting in the light of the museum world.

Always ask for a full formal specification. This is typical in contracting jobs â€“ because you need a legal document to refer to about what you are supposed to build.
But how do you apply this in the crazy non-profit world of museums? What if you work in a situation where you are designing new things, donâ€™t know what you are going to be making, or are trying to respond quickly. The presenters did not discuss this, but the essence of what they are saying is that you can really benefit by that sit-down process, especially if you love to get your hands dirty, or notice that you are mired down making zillions of quick fixes to 20 different projects. That time to reflect might just help you decide your priorities, or whether or not the fix you were planning is really a fix at all.
Work on your estimates. The other big tip that he gives is that you should try to not set a bad precedent for yourself of giving overly short estimates, or trying to out-compete your beloved colleagues by offering to do something faster. Before you freak out about that one, he advises this: itâ€™s better in the long run. When he hires people, he checks to see that they donâ€™t cut corners. Employers who think faster is better...well, are they going to be very good employers who help you grow to your real potential? And anywaysâ€¦why are they cutting corners?
So build in to your estimates all of the time you will need to fulfill a project according to the full development process. So, if you can never find time to clean up after yourselfâ€¦add that in. If you donâ€™t have time to think about roles and responsibilities, commenting, documenting, testing, evaluatingâ€¦budget and estimate for all of that.

Some coding recommendations:
- Invite co-workers to your desk to check out your code.
- Have 'clean up day' and have someone go over all the code
- Set up a system to call out people on things that they didn't fix that week.
Books for inspiration and information

Refactoring: Improving the Design of Existing Code by Martin Fowler

Code Complete: A Practical Handbook of Software Construction by Steve McConnell

Designing interfaces for the color blind

bryan kennedy — Fri, 04 Apr 2008 20:09:50 -0600

Museums have done an enormous amount of work making their spaces and exhibit interfaces accessible to those with physical differences, limitations, and disabilities. However, we have lots more work before we can claim such progress with digital and media interfaces.

One easy thing we can do right is design websites and media interactives for for the colorblind. An estimated 8% of the male population (roughly 12 million folks in the US) have some form of color blindness that can make it hard to use interfaces that rely on color to convey information.

I use two simple tools that help me test my designs for color blind users. They let me see what my work looks like through the eyes of some one who can't see the various differences between the shades of green, blue, or red.

Color Oracle

Color Oracle is great because it turns your entire screen color blind for a moment. Any movement of the mouse or clicks turn the display back to "normal."

Sim Daltonism

Sim Daltonism gives you a color blindness portal or window that lets you see little parts of your screen color blind live. This can be real nice for flash and moving images. But this can also be more memory and processor intensive if you are on a slow computer.

Both of these apps are for the Mac and I don't have any first hand experience with any PC tools. But Daltonize lets you test your interfaces over the web. You can upload an image and filter it for various types of color blindness.

I'd love to hear your tips about how you work to make your visual interfaces more accessible to all viewers.

This could have been avoided

bryan kennedy — Fri, 04 Apr 2008 19:27:59 -0600

courtesy William SpaetzelFifth grader, Kenton Stufflebeam, has pointed out an error in a museum exhibit about geology at the Smithsonian that's been out for the public to see for 27 years. By building mechanisms for visitors to share their knowledge and ideas we can avoid this sort of issue in the future. Many museum folk immediately worry about accuracy when we talk about new experiences that let visitors contribute and share authority with our institutions. In this case the expertise flowed from visitor to museum instead of the other way around.

We are hiring

bryan kennedy — Mon, 31 Mar 2008 21:55:49 -0600

courtesey Piero SierraThe Science Museum of Minnesota is hiring a Drupal developer to work as part of the team that operates the award wining Science Buzz website and exhibit.
Application deadline: April 9, 2008.

Science Buzz is expanding in many ways. Your expert Drupal, PHP, and web coding skills will help us:

develop Mentor Buzz, an online community focusing on the needs of mentors and their students talking about science
create unique web features focusing on contemporary issues like the 35W bridge collapse, Hurricane Katrina, or even male pregnancy!
build web enabled exhibits that allow other museums around the country that allow their visitors to hook into the Science Buzz community
create new tools that help our visitors create content along with us...we like to share authority
and more...

Learn more about the job...

Tools of the trade

bryan kennedy — Fri, 28 Mar 2008 07:55:12 -0600

courtesey Ard Hesselink
This Friday I thought I would post on some of the tools that our web/media group has been using lately.

Assembla

Writing code is hard. Writing code in a group that might not even be on the same floor, building, or state is much harder. Assembla is a set of the key collaboration tools that programming teams need, all rolled into one off-site package. SVN, Trac, a wiki, and even Scrum reporting tools. We initially used it as a stop-gap measure while we got our own SVN server up. Now we're finding it hard to tear ourselves away.

IRC

IRC (Internet Relay Chat) has been around for a long, long while, but we hadn't really thought of it as a work tool until real recently. After two of our finest web/media developers returned from the 2008 DrupalCon, they informed us about a whole 'nother world of Drupal support and discussion living on the IRC channels. I tried it out for a couple of hours one Sunday I was amazed at how much live help was out there for some complex stuff I was trying to figure out. I'm on a mac so I use Colloquy to get on Drupal's IRC channels. Obviously this isn't Drupal specific. There are many channels for the topic you are currently banging your head over right now.

ScreenKeys

What's cooler than a button? A button with a little display built in. Screenkeys are little programmable LCD screens in buttons and switches. These could be quite fun for customized and changing content. The options for control in a game could change every time a visitor plays. We aren't using these yet but I just threw them in for fun.

Any of all those crazy acronyms throw you for a loop? Post a question about how we are using these tools and I'll try and fill you in.

Belated IMLS Web Wise linkroll

bryan kennedy — Thu, 27 Mar 2008 22:25:06 -0600

I recently had the pleasure to speak the IMLS WebWise conference about some of the work that we have been doing with Science Buzz. This was an interesting meeting because it mixes the world of traditional museum with a wise group of people from the library field as well. For those of you who don't already know, those librarians are about 5 years ahead of museums when it comes to sharing authority with their visitors. Many of us thinking about new ways to use technology in our museums are looking to the library world for leadership.

Here are few of the coolest projects that I learned about in Miami Beach (oh yeah did I mention that the conference was in Miami Beach...poor me).

George Mason University's Center for History and New Media is an exciting group of talented software developers and that blend a unique approach to education and learning around history. They talked about two projects:

Zotero - A firefox plugin that gives you an iTunes style tool to track, tag, and archive to various nerdy academic resources you need to follow as you research weavers shuttles of the Appalachian Mountains, Tractors of the Upper Midwest, or the personal stories told around Hurricane Katrina. As more and more academic research moves online I am sure that Zotero will become more and more of a standard for researchers of all ilks to manage their many academic resources.
Omeka - Think of Omeka as the WordPress of "Collections Online." After some initial configuration Omeka will be a simple content management system to build collections based websites. I am particularly encourages to see the Omeka team focusing on smaller museums and building some community tools right into the software.

My other favorite discovery hits close to home. As a matter of fact I walk past this museum on my way to work every day. The Minnesota Historical Society is experimenting with GIS resources in conjunction with their collection of historical maps and aerial photographs. On their True North website you can overlay interesting data sets like current agricultural land use and historical Indian land use before European settlement. I really like this project because it exposes a set of map based tools to the general public.

Did you discover something new at WebWise? I'd be interested to hear about it.