New Media Initiatives Blog

For our upcoming exhibition 50/50: Audience and Experts Curate the Paper Collection, we’re trying something a bit different. As you can probably tell from the title, we’re allowing our audience to help us curate a show. The idea is that our chief curator, Darsie Alexander, will curate 50% of the show, and the audience will select from a group of 180 different print works for the other half.

As with most things presented to New Media, the question was posed, “how best do we do this?”. The exhibition is being hung in the same room as Benches and Binoculars, so the obvious answer was to use the kiosk already there as the voting platform for the show. With this in mind I started to think of different ways to present the voting app itself.

My initial idea was to do a “4-up” design. Display four artworks and ask people to choose their favorite. The idea was that this would make people confirm a choice in comparison to others. If you see some of what you’re selecting against, it can make it easier to know whether you want specific works in the show or not. But it also has the same effect in reverse. If you have two artworks that you really like, it can be just as hard to only be able to choose one. The other limitation? After coming up with the 4-up idea, we also decided to add iPhones into the mix as a possible voting platform (as well as iPads, an general internet browsers). The images on the iPhone’s screen were much to small to make decent comparisons on.

Nate suggested instead using a “hot or not” style voting system. One work that you basically vote yes or no on. This had the small downfall of not being able to compare a work against others, but allowed us to negate the “analysis paralysis” of the 4-up model. It also worked much better on mobile devices.

The second big decision we faced was “what do we show”? I had assumed in the beginning that we’d be showing label copy of every work like we do just about everywhere but it was suggested early on that we do no such thing. We didn’t want to influence voters by having a title or artist on every piece. With works by Chuck Close and Andy Warhol mixed into the print selections, it’s much too easy to see their name and vote for them simply because of their name. We wanted people to vote on what work they wanted to see, not what artist they wanted to see.

Both of these decisions proved to be pivotal in the popularity of the voting app. It made the voting app very streamlined and simplified. With 180 works to go through it makes it much easier to get through the entire thing. Choices are quick and easy. The results screen after voting on each artwork shows the current percentage of no to yes votes. This is a bit of a psychological pull. You as a user know what you think of this artwork, but what do others think about it? The only way to find out is to vote.

Because of this the voting app has been a success far beyond what we even thought it would be. I thought if we got 5,000-10,000 votes we would be doing pretty well. Half way through the voting process now, we have well over 100,000 votes. We’ve had over 1,500 users voting on the artworks. We’ve collected over 500 email addresses wanting to know who the winners are when all the voting is tallied. We never expected anything this good and we have several weeks of voting yet to come.

One interesting outcome of all of these votes has been the number of yes’s to no’s over all of the works. Since the works are presented randomly (well, pseudo randomly for each user), one might expect that half the works would have more yes than no votes, and vice versa. But that’s not turned out to be the case. About 80% of the works have more no votes than yes’s. Why is this?

There are various theories. Perhaps people are more selective if they know something will be on view in public. Perhaps people in general are just overly negative. Or perhaps people really don’t like any of our artwork!

But one of the more interesting theories of why this is goes back to the language we decided to use. Originally we were going to use the actual words “Yes” and “No” to answer the question “Would you like to see this artwork on view?”. This later got changed to “Definitely” and “Maybe Not”. Notice how the affirmative answer has much more weight behind it: “Yes, most definitely!”, whereas the negative option leaves you a bit of wiggle room “Eh, maybe not”. It’s this differentiation between being sure of a decision and perhaps not so sure that may have contributed to people saying no more often than yes.

Which begs the question, what if it was changed? What if the options instead were “Definitely Not” and “Sure”? Now the definitive answer is on the negative and the positive answer has more room to slush around (“Hell no!” vs “Ahh sure, why not?!”). It would be interesting to see what the results would have been with this simple change in language. Maybe next time. This round, we’re going to keep our metrics the same throughout to keep it consistant.

The voting for 50/50 runs until Sept 15. If you’d like to participate, you still have time!

"Building the 50/50 Voting App" was originally posted by Brent Gustafson on New Media Initiatives, part of the Walker Blogs.

There are changes in store for the New Media Initiatives department. After being with the Walker for four years, I’ve taken a position across the river Minnesota Public Radio as a Web Designer/Developer. It is very hard for me to leave the Walker, but I’m excited about working on new projects for an even larger audience at MPR.

This means there is a job opening in New Media, and if you’re a web nerd, you should consider sending in your resume. My title at the Walker is New Media Designer, but the job posting is for a Web Designer/Developer. This reflects the changing nature of the work I’ve taken on over the years, including doing more back-end development work on the Walker Channel and Mobile Site, amongst other projects. In the future, we have work planned around an overhaul of major portions of the Walker website. Our tool of choice is Django, but even if you don’t have python or django experience, consider applying. I didn’t know a lick of Python or Django when I tackled My Yard Our Message, but it was easy to get up to speed and make things happen.

Full details for the position are listed on jobs site, and the deadline for applying is September 3rd.

"Changes in New Media, job opening for a web designer/developer" was originally posted by Justin Heideman on New Media Initiatives, part of the Walker Blogs.

For Walker Open Field, we wanted a way to collect community submitted events and display them on our site. We have our own calendar and we discussed whether adding the events to our internal Calendar CMS was the best way, or if using an outside calendar solution was the direction to go. In the end, we decided to do both, using Google Calendar for community events and our own calendar CMS for Walker-programmed events.

The Open Field website is based on the lovely design work of Andrea Hyde, and the site is built using WordPress, which we use for this blog and a few other portions of our website. WordPress is relatively easy to template once, so it makes for quick development. WordPress also has a load of useful plug-ins and built-in features that saved us a lot of time. Here’s how we used it an put it together:

Collecting Events
To accept event ideas from community members, we used the WordPress Cforms II plugin, which makes it very easy to build otherwise complex forms and process them. You can create workflows with the submissions, but we simply have Cforms submit the form to us over email. A real person (Shaylie) reviews each of the event submissions and adds the details to…

Google Calendar
We use Google’s Calendar app to contain the calendar for the community events. When Shaylie gets the email about a new event, she reviews it, follows up on any conflicts or issues, and then manually adds it to google calendar. We toyed with the idea of using the Calendar API to create a form that would allow users to create events directly in the calendar, but decided against it for two reasons. First, it seemed overly complicated for what we thought would amount to less than 100 events. Secondly, we would still have to review every submission and it would be just as cumbersome to do it after the fact rather than beforehand.

We also use Google Calendar to process our own calendar internal calendar feed. The Walker Calendar can spit out data as XML and ICAL. We have our own proprietary XML format that can be rather complex, but the ICAL format is widely understood and Google Calendar can import it as a subscription.

Getting data out of Google Calendar
We now have two calendars in google calendar: Walker Events and Community Events. Google provides several ways to get data out of google calendar, and the one we use is the ATOM format with a collection of google name-spaced elements. The calendar API is quite robust, but there are a few things worth noting:

• You must ask for the full feed to get all the date info
• Make sure you set the time zone, both on the feed request but add it to the events when you link tot hem (using the ctz paramater)
• Asking for only futureevents and singleevents (as paramaters) makes life easier, since you don’t have to worry about complexities of figuruing out the repeating logic, which is complicated

This is our feed for Open Field Community Events.

Calendar data into WordPress
Since version 2.8, WordPress has included the most excellent SimplePie RSS/ATOM parsing library. As the name would have you believe, it is pretty simple to use. To pull the data out of the Google Calendar items with simplePie, you extend the SimplePie_Item class with some extra methods to get that gd:when data.

Combining two feeds in SimplePie is not hard. By default, SimplePie will sort them by the modified or published date, which in the Google Calendar API is the date the event was edited, not when it happens. Instead, we want to sort them by the gd:date field. There are probably a few ways to do this, but the way that I set up was to simply loop through all the data, put it into an array with the timestamp as the key, and then sort that array by key. Here’s the code:

<?php //include the rss/atom feed classes include_once(ABSPATH . WPINC . '/feed.php'); require_once (ABSPATH . WPINC . '/class-feed.php'); // Get a SimplePie feed object from the specified feed source. $calFeedsRss = array( #walker events 'http://www.google.com/calendar/feeds/95g83qt1nat5k31oqd898bj2ako1phq1%40import.calendar.google.com/public/full?orderby=starttime&ctz=America/Chicago&sortorder=a&max-results=1000&futureevents=true', #public events 'http://www.google.com/calendar/feeds/walkerart.org_cptqutet6ou4odcg6n2mvk4f44%40group.calendar.google.com/public/full?orderby=starttime&ctz=America/Chicago&sortorder=a&max-results=1000&futureevents=true&singleevents=true' ); $feed = new SimplePie(); $feed->set_item_class('SimplePie_Item_Extras'); $feed->set_feed_url($calFeedsRss); $feed->set_cache_class('WP_Feed_Cache'); $feed->set_file_class('WP_SimplePie_File'); $feed->set_cache_duration(apply_filters('wp_feed_cache_transient_lifetime', 3600)); //cache things for an hour $feed->init(); $feed->handle_content_type(); if ( $feed->error() ) printf ('There was an error while connecting to Feed server, please, try again!'); $count = 0; // hack, but we're going to count each loop and use it as a little offset on the sort val foreach ($feed->get_items() as $item){ if (strtolower($item->get_title()) != 'walker open field'){ $eventType = 'walker'; $related = $item->get_links ( 'related' ); $related = $related[0]; if ( strpos($related,'walkerart.org') === False ){ $related = $item->get_link(); // if it's a google calendar event, make sure we set the tiem zone $related .= "&ctz=America%2FChicago"; $eventType = 'community'; } #we offset the actual starttime a little bit in case two events have the same start time, they would overwrite in t he array $sortVal = $item->get_gcal_starttime('U') + $count; $myData = array( 'title' => $item->get_title(), 'starttime' => $item->get_gcal_starttime('U'), 'endtime' => $item->get_gcal_endtime('U'), 'link' => $related, 'eventType' => $eventType, 'text' => $item->get_content(), 'date' => $item->get_gcal_starttime('U') ); $cals[ $sortVal ] = $myData; } $count++; } //sort the array by keys ksort($cals); // $cals now contains all the event info we'll need ?>

Once this is done, you can simply take the $cals array and loop through it in your theme as needed. Parsing the google calendar feeds is not an inexpensive operation, so you may wish to use the Transients API in WordPress to cache this information.

Caveats and Issues
Overall, this approach has worked well for us. We have run into some issues where the Google Calendar ATOM feed would show events that had been deleted. Making sure to set the futureevents and singleevents paramaters fixed this. We also ran into some issues using the signleevents, so we ended up manually creating occurrences for events that would have otherwise had a repeating structure.

"Creating a community calendar using Google Apps and WordPress" was originally posted by Justin Heideman on New Media Initiatives, part of the Walker Blogs.

iPad photo taken with iPhone

As part of the Open Field Toolshed this summer, we are going to have four iPads available for public checkout. With our expanding WiFi coverage and outdoor beer garden, Open Field might just be the perfect place to surf the web.

Are there any apps or e-books you’d like to see on our iPads? We’re got a few in mind already:

• Wired Magazine
• Elements
• Marvel Comics
• Scrabble
• Angry Birds HD

If you’ve got specific requests, let us know in the comments or on twitter. No promises, but we’ll see what we can do.

"What apps and books do you want to see on the #openfield iPads?" was originally posted by Justin Heideman on New Media Initiatives, part of the Walker Blogs.

Like many institutions, we put numbers for our various online presences in our annual report and other presentations: YouTube views, Twitter followers, Facebook fans, etc. For most services, this is very easy to do: log in, go to the stats page, write the big number down. We also want to include the iTunes U numbers, but for iTunes U, there is no centralized stats reporting outside of the Microsoft Excel file Apple sends iTunes U administrators every week. Tabulating the stats by hand would be time consuming and error-prone, so I wrote a short python script to automate it. Here is is:

#!/usr/bin/env python # encoding: utf-8 """ itunesUstats.py Created by Justin Heideman on 2010-05-19. """ import sys, os, glob, xlrd def main(): #change this to the path where your stats are path = 'itunes_U_stats/all/' totalDownloads = 0 for infile in glob.glob( os.path.join(path, '*.xls') ): # open the file wb = xlrd.open_workbook(infile) # get the most recent days's tracks sh = wb.sheet_by_index(1) # get the downloads from that day downloads = sh.col_values(1) #first entry is u'Count', whcih we don't want downloads.pop(0) #sum it up totalDownloads += sum(downloads) # show a little progress print sum(downloads) #done, output results print "----------------------------------------------------" print "Total downloads: %d" % totalDownloads if __name__ == '__main__': main()

This script uses the excellent xlrd python module to read the Excel files (simple xlrd tutorial here), which is roughly 27.314 times easier than trying to use an Excel macro to do the same thing. To use this, simply change the path on line 13 to a directory containing all your iTunes stats files, and run the script from the command line. You’ll get output like this:

929.0 732.0 779.0 854.0 1000.0 987.0 765.0 812.0 1275.0 1333.0 1114.0 1581.0 1278.0 1568.0 1854.0 2102.0 1108.0 1078.0 ---------------------------------------------------- Total downloads: 21149

Do note that the script is tied to the excel format Apple has been using, so if they change it, this will break. Apple explains the iTunes report fields here. This script tells you ” all the iTunes U tracks users downloaded that week through the DownloadTrack, DownloadTracks, and SubscriptionEnclosure actions”.

"Simple iTunes U stats aggregation with python and xlrd" was originally posted by Justin Heideman on New Media Initiatives, part of the Walker Blogs.