Reflections on My Interactive Exhibit Design Project

In the Beginning…

As the term comes to an end, it’s time to reflect on my Interactive Exhibit Design project and what I learned from the course. I decided to take Interactive Exhibit Design to continue learning about digital tools and how we interact with them as historians as well as consumers of culture and technology. This was a great opportunity to think in different ways and learn new skills, specifically working with Max 7.

When I first started brainstorming about what I wanted to build for the project, I had envisioned designing a working mechanized lock, controlled by a Max 7 patch, which would allow people to see how a lock operated to move boats between different levels of water. We were learning how to create interactive programs with Max in class and I wanted to apply that new knowledge to something I already understood. Having worked for the Trent-Severn Waterway for four summers, I understood how locks worked, but also knew how often visitors asked questions about them. This was especially true if someone wanted to know how they worked and there were no boats around. I set out to make a program that would allow people to interact with a virtual lock and learn more about its function and operation. I quickly realized, however, that it takes a lot more time than I had anticipated to learn a new program and to get to a level where I was happy with the result. This meant that the physical model of the lock did not end up being as sophisticated as I had planned.

The Code

As for my Max 7 patch, our professor Bill Turkel helped me smooth out the visualization of the water rising and falling in the lock to better recreate what an actual lock looks like. He also helped to rework my patch so that it was less convoluted and more efficient. There were fewer patch cords, which made it much easier to understand how the various components interacted and what each activated on the lock. The revised patch also showed me that there are lots of different ways to create a program but that some are more efficient than others.

A lot of this project was trial and error – working to figure out which parts of Max were the most useful for what I was trying to create. This meant there were long periods of sitting and thinking, followed by mad bursts of creating pieces of the patch and then tweaking them to make the display look cleaner. Max is relatively flexible in terms of changing what you can see in its “Presentation Mode” which was very helpful throughout this project. That being said, I realized too late that once you set a certain size for an LCD display, you couldn’t expand it without changing the values in your program to match the new dimensions. This meant the display was quite small which made it hard to see unless you were right in front of the computer.

While most of my patch works quite well, there are still a couple of issues that I wasn’t able to resolve. Most notably, both of the gates can be opened at the same time and the gates can be opened even if the water is not at the right level (i.e. if the water is up, the lower gate shouldn’t be able to open and if the water is down, the upper gate shouldn’t open). This is virtually impossible in real life because the water has to be at the same level in order to open the gate. This was a great example of how a digital representation of something like a lock may not be entirely accurate if the person who designed it doesn’t know how to transform this logic into program components. If I were to continue on with this project, this glitch would be the first thing to work out.

To demonstrate how the program works, here is a short video that shows what the patch does and why:

The Physical Model

The physical lock was constructed from a variety of materials I had lying around my house such as cardboard and tissue paper. I used a Makey Makey sensor to connect the different components of the lock to the computer program so that when a person moved the gates or the water level, the gates and valves in the Max program would respond. Unfortunately, the program seemed to work better on my computer than it did when I hooked up the model. The way I had designed the lever to move the water up and down would get stuck on the parts of the box, which meant sometimes the water in the visualization stopped moving at the halfway point. I also covered one of the sensors for the gates at first and had to adjust the model so the Makey Makey sensors would connect. This was an easy fix but showed me how easy it is for something to not function the way you were anticipating.

I will openly admit that I am not particularly artistic. The model was very rough, and if I had been designing this to actually go into an exhibit, it would have had to be much more stable and user-friendly. I also should have written out descriptions for what each piece of the model (the gates and levers) was and how to operate them in order for someone who didn’t know about locks to interact with it and not get frustrated.

A frog riding up and down the lock (unfortunately the Dollar Store didn't have a small boat).
A frog riding up and down the lock (unfortunately the Dollar Store didn’t have a small boat).

Final Thoughts

Using Makey Makey and Max 7 together was a great way to combine a digital program and a physical model. These tools work very well together and made it much easier to decide how many parts on the lock would move and what that would look like (the Makey Makey only has four sensors, so you can only have four things operating in a Max patch). They may have been relatively simple tools to use, but combining them gave me a better appreciation for how sensors can help provide interactions with digital programs.

After our project presentations, Bill and a few students in the class were discussing how much we take for granted when we interact with models or screens at museums. We have come to expect sophisticated interfaces that work seamlessly, like navigating through a site like Facebook. What people don’t realize, though, is how many hours have gone into developing those sites to make them user-friendly. I think this is part of the reason that I had to scale back my original idea. The site I based my program off of was easy to navigate and intuitive to use, so I thought it wouldn’t be too difficult to replicate. This experience showed me just how much time and effort goes into making something work properly and still be accessible to users.

This project gave me a greater appreciation for the digital tools and interactive displays I encounter online and in museums. There’s a lot more to a program than what the end-user sees. Thinking into the future, it’s important to create interactive exhibits that are easy to use and understand (or that have appropriate instructions) and to realize that there will probably be issues that you won’t realize exist until someone interacts with it.

Building a Lock

The lock is now (digitally) functional! After a lot of help from Professor Bill Turkel, I finished my Max 7 patch to control the lock. Bill helped me to reorganize and smooth out how the ‘water’ in the lock looked when it was moving up and down. This greatly improved the visualization of the lock for anyone who wanted to interact with it. It also demonstrated how there are a lot of different ways to code for similar things; finding a more efficient way to structure my patch made it easier to see what components were important for each part of the display. It also made it significantly easier to see the whole patch at one time.

To get a sense of how each patch looked overall, here are images of the first and second patches:

After I finished up the code, it was time to build the physical lock that would interact with the Max patch. I used cardboard, felt, tissue paper, and too many staples to create something that at least somewhat resembled a lock (this project reconfirmed why I am not in fine arts…). My original idea had been to have the lock essentially mechanized, but as time went on I realized that the design I had envisioned was too complicated for the amount of time I had to complete the project. Instead, there is a lever that someone interacting with the lock can move up and down. When the Makey Makey wires connect with the tinfoil, it triggers the valves to open and close on the computer screen. Similarly, when the gates are opened on the physical model, a light flashes on the Max patch.

Before I could finish off the lock, I had to install the Makey Makey device inside it and make sure all of the wires were connected properly. This was pretty straightforward although I had to be careful that the felt from the outside didn’t block the connections on the gates and walls of the lock.

This slideshow requires JavaScript.

Once the Makey Makey was up and running, I spent some time making sure that everything was working properly. It may not look particularly sophisticated, but this project stretched my understanding not only of the mechanics behind a lock, but also how that logic can be translated into a digital environment.

Here’s what the final product looked like:

Stay tuned for a final reflective post on my experiences from the Interactive Exhibit Design course!

Working Through the Lock

In my last post, I discussed my project for the Interactive Exhibit Design course I’m taking this term. Building off of that idea, I’ve been working in Max 7 to lay out the way a lock that moves boats from one level to another operates. It turns out that physically operating a lock can be easier than designing a digital version of one!

I’m a big fan of doodling and drawing things out to get a better sense of how different things relate to each other. So, to try to figure out how the virtual valves and gates should work together, I put a pen to paper:

Writing in pen on paper. There are a series of lines representing the different steps of a lock that boats would travel through.
My pen-and-paper rendering of how the gates should not be able to “open” at the same time, plus some Max tools (LCD) instructions that allow someone to build rectangles inside a window – this is how I’m constructing the virtual lock for now.

These are some of my initial attempts at creating “if” statements that ensure that both of the gates or the two valves can’t be opened at the same time. Ask any lock attendant how that would work out… It wouldn’t be a good day for any boater trying to go through the locks.

Using LCD and Sprites in Max 7, I have essentially come up with a graphic representation of the different water levels on either side of a lock. Now my challenge is to find a way to connect the LCD screen to the controls I set up to “operate” the lock and to make sure that the screen doesn’t completely reset after it is used. This means diving into the Max tutorials to figure out how to set some of the rectangles as a background that the Sprites operate on top of.

A series of grey buttons with commands that control a screen that has three blue rectangles representing water and two black rectangles that represent lock gates.
The LCD screen showing the “water” and “gates.”
A series of buttons and connections that are activated when clicked on in Max 7.
The “operating” controls for the lock. I still have to work out the “if” statements that will ensure both gates can’t be opened at the same time. Ideally, I will attach a Makey Makey to my computer and a 3D version of a lock to make it easier to see exactly how a lock works.

I also have to figure out how to properly construct the “if” statements and controls for the lock. The easier part of this will be creating messages explaining why someone interacting with the virtual lock can’t have both gates open at once.

So far, this project has been moving pretty slowly as I gain a better understanding of the Max program as well as the constraints I have to explain in the design. Once I get past that point, hopefully everything will be smooth sailing!

Thinking About Interactive Exhibit Design

This term, I’m taking a course in Interactive Exhibit Design as part of the Public History program at Western. We’ve spent the last few weeks tinkering with different interactive platforms such as Makey Makey and using the Max 7 software. I’ve realized a number of things so far. Firstly, I’ve taken for granted how easy it is to act as a user of well-designed interactive activities in museums or public displays. It’s a lot harder to actually program a device to facilitate that interaction.

We started out connecting Makey Makey devices to home-made “controllers” that could be used to interact with a Max patch. The hard part wasn’t connecting the Makey Makey to my computer, but having the flexibility to set up what hitting a button would trigger. For example, my partner for the exercise and I built a controller and were attempting to play Tetris with it. While we could control the blocks moving down and side to side, plus getting them to rotate, there weren’t enough interfaces with the Makey Makey to have a working “pause” button. This complicated how we could play. Because the Makey Makey has set keyboard keys associated with its inputs and outputs, it made it hard to use our controller to play structured games that required specific keyboard keys to be fully functional. Luckily, for our projects we can use Max to set how users interact with what we are designing. This means that when I’m creating a Max patch, I will only use specific key controls within the patch. Someone interacting with the patch using a controller wouldn’t have to know this for them to be able to use the controller, though.

A computer hooked up to a set of wires and a cardboard controller. The computer screen shows an ongoing game of Tetris being played.
Playing Tetris with Makey Makey! Our controller is to the right, connected to all of the wires.

This gets me to my project idea. I’ve worked for the Trent-Severn Waterway for the last few summers, and have learned so much about how locks operate. Visitors to the locks usually don’t know exactly how they work, though. There is a really neat interactive learning tool that lets people operate an animated lock:

An animated lock for boats, with controls that allow people to "operate" it. There are two sets of valves, gates, and traffic lights.
This is a look at the virtual lock activity. There are controls for the valves, gates, and traffic lights. You can get the tugboat to go up or down through the locks by using the controls at the bottom. From http://www.pragmasoft.be/carnets/geo/ecluse/ecluse_simulation.html.

What I’m going to be doing is recreating the function of this activity using Makey Makey and an external controller. Hopefully, I will be able to connect it to a model of a lock to make it easier for a user to walk around it and see how a lock actually works.

It’s going to be a busy few weeks, but I’m looking forward to seeing how this project evolves and what I learn from the process!

Changing Times: Technology and an Abundance of Historical Resources

Technology is changing the way we think about and do History. Generally speaking, historians have always suffered from a lack of complete source materials. Not every document has been preserved, and historians have had the job of piecing the surviving records together like a puzzle in order to recreate events and hypothesize about what happened. Now, however, there are new ways to preserve and protect historic sites and records, and the Internet and new technology makes it much easier to find and share information.

Take for example Historic Scotland‘s ongoing project: they are using lasers to scan 3D monuments around the world in order to preserve the details of these structures and to create realistic, digital models of them. The idea is that if buildings or monuments, such as Mount Rushmore, were destroyed by causes like weather or pollution, these 3D scans would be able to create accurate models of them. This would allow continuing generations to see what they had looked like, and could even help with conservation or rebuilding efforts. Instead of these monuments being lost to time, 3D modelling has the potential to preserve a copy of them indefinitely.

Mount Rushmore, featuring four former presidents of the United States.
A photo of Mount Rushmore – one of the monuments the Historic Scotland team is scanning for their project.

Instead of losing the historical accuracy of a site, this project gives historians and archaeologists lasting access to points of cultural significance and preserves a more complete record of a site. There is less to piece together when trying to figure out what something looked like, or how the surrounding landscape changed over time. By creating 3D scans of monuments and buildings, these researchers are helping to increase the historical accuracy of the records that capture these sites.

Another way that technology is helping to improve History and outreach is through monitoring data. Because historians are usually working with incomplete data, the idea of having full access to information on a subject is very appealing. By preserving not only “born-digital” sources, but also monitoring how people interact with emails, webpages, and other digital mediums, there is huge potential for capturing vast amounts of data. The problem becomes, then, how to analyze it. As the article Everything, Too Cheaply Metered points out, “…while the value of ubiquitous monitoring seems nil at first, data streams of trivial actions are often the streams that become most valuable later on.” By collecting large amounts of data, researchers are able to find patterns in the mundane and also pick out events or documents that are outside the ordinary.

In order to analyze this growing wealth of information, there are a number of tools that historians can turn to. For example, to find patterns in large quantities of data, we can use text analysis and topic modelling to pull out the key themes in anything from a collection of books to song lyrics from different decades. A couple of easy-to-use tools are Google’s Ngram Viewer, which lets you compare the frequency of different words over time, and Voyant, which lets you create visually appealing word clouds, along with highlighting the most frequently used words in a selection of text.

Diving into using new technologies can be both scary and exciting. Technology is changing the way we do history, helping to preserve more information and knowledge. Whether it’s scanning buildings and monuments, or analyzing large amounts of digitized text, new technology is creating a new way to study history.

An Interesting Project Using SketchUp

Today in class we were sharing updates on our second assignments for the course. There were some really interesting projects using a wide range of platforms and tools. We were also giving everyone feedback to hopefully help with the projects.

I was reviewing Nicole’s SketchUp project on the Pinhey’s Point Historic Site. The site has an interesting architectural history, in that parts of the building (such as the original kitchen) have been destroyed but the ruins have been kept intact. I liked that Nicole has a specific audience in mind for her project; she hopes that it can be used to help provide access to the parts of the museum that are not accessible to those with disabilities. This not only gives a purpose for the project, but also gives it a clear application outside of the course assignment.

A picture of the ruins of the old kitchen. The stove and chimney are still standing, but the rest of the kitchen has been destroyed.
Some of the ruins from Pinhey’s Point Historic Site.

Nicole also made good use of primary sources such as architectural drawings to help create her model. The specific measurements help to give it a more realistic look. By using the drawings to help draw the model, she was able to create an accurate representation of the site. Users could potentially see this as improving their digital experience because the model tries to maintain the historical accuracy of the museum. Nicole balanced these architectural drawings with best estimates on the design of the wooden structure that was in-between the museum and the ruins of the kitchen, but that no longer exists. This demonstrated creativity and a willingness to step outside exact measurements in order to still have a replica that is as accurate as possible with the available resources. Nicole mentioned that while she had specific dimensions to work from, SketchUp doesn’t create certain structures, like curved walls, very easily. This meant that she had to take a bit of artistic license to build the model, but it looks like everything fits together quite nicely. By geo-locating the model on SketchUp, she also increased the level of authenticity.

Being able to explore the model on the internet is a great idea to encourage people to explore the digital site and potentially get them excited about visiting the physical site itself. Nicole mentioned that she was looking at using the LightUp plugin for SketchUp to create a tour through the interior of the model. This would be really neat because it would allow users to explore the model without a guide. If that didn’t work, however, she could always create a video tour instead. While it wouldn’t be as interactive for users, there may be a greater opportunity for adding interpretive information and highlighting key features that users may skip over if they were exploring it on their own. A video would make a user’s learning more directed, but might be more useful for sharing the main message of the site.

Overall, it looks like Nicole has a great start on her final project. She has used a variety of digital tools including SketchUp and geo-locating to create an accurate and visually appealing model. She is aware of her intended audience and has thought through how she can make the project accessible as well as use it as a tool to help people interact with the museum itself. I can’t wait to see what the finished product looks like!

Historians and Video Games

When I think about video games, history isn’t the first thing that comes to mind. However, video games can be a powerful way to engage people in history and historical method. In Robert MacDougall and Tim Compeau’s article, Tecumseh Lies Here: Goals and Challenges for a Pervasive History Game in Progress, they state that, “For a game to work as meaningful pedagogy, its lessons must be embedded in its very mechanics and procedures, in the stuff players manipulate and the actions they perform.” This means that the purpose of the game has to be centred on the core activity that players participate in. It also means that historians have a big role to play in the design process of the game to make sure that the historical message is successfully portrayed. In order to learn something about history from a video game, the game’s core activity has to be focused on what is being taught.

But what happens when you try to study history in a game that wasn’t intended to teach players about certain parts of the past? Sid Meier’s Colonization allows players to play as explorers from European empires that have come to North America to colonize it. Players interact with First Nations groups and work to build up their settlements. The purpose of the game is to increase your trade network and build up resources, and it teaches players about basic trade systems in the New World.

The main map for Colonization.
The main map for Colonization.

In the game, players have to play as an explorer from a European nation, but Trevor Owens and Rebecca Mir decided to change the code in the game and play as a Native. Owens posted a blog on their experiences playing in this different role. While changing the code didn’t seem to phase them, the realities behind the game design hit when they realized that Native players had no agency in the game. Compared to the European colonizers, playing as a Native gives you virtually no options for game play. The inability to actually participate in the game as a Native without changing more of the game’s code speaks to the design decisions that Meier and his team made, as well as the social implications of what those decisions mean. Natives were not considered “human” in the game and therefore did not have any role to play aside from being a tool that the European colonizers could exploit.

The cover page for Sid Meier's Colonization.
The cover page for Sid Meier’s Colonization.

This is an extreme example of a game where a minority group was dehumanized and stripped of their ability to make meaningful decisions or actions. Until you switch the setting for Native players to “On,” though, players might miss this. If historians had been involved in creating the game, would this have changed? Maybe not, but by studying the code, we can understand the reflections of the designers and of history on the subject. Meier did not intend for his game to teach about inequality between Natives and Europeans, but by tweaking the code for the game, we can comment on what the decisions that were made say about how we perceive Native groups in relation to European settlers. Historians can look at the game and study the intrinsic biases that it presents while re-imagining an aspect of history.

Historians have an interesting role to play when it comes to video games. They can be seen as consultants in the design process, but can also analyze a game after it has been launched for its implicit or explicit representations of groups or events. I would argue that having historians involved in creating games based on historical events can help to limit the kinds of biases that appear in Colonization, but they can also evaluate whether or not these biases are fitting with the time that is being used for the game. Historians can help to open up discussions about what lessons are being taught in video games and draw awareness to issues such as the ones with Colonization.

 

Digital Landscapes: The Train Station in London, Ontario

For our Digital History class, we had to choose a building or landscape that had seen change over time. I chose to look at the train station in London, Ontario. It’s been a part of London since the 1850’s and has changed along with the railway companies that have used it.

The London train station before the 1920's.
The London train station before the 1920’s.
The VIA station in downtown London, Ontario.
The VIA station in downtown London, Ontario today.

Here is what I was up to:

Railway transit has been an integral part of Canada’s industry and growth. With such a large amount of space to transport people and goods across, the railways were essential to speed up this process. London is no different in this respect. London was a major rail centre in Southern Ontario and the expansion of the railway transport in the 1870’s corresponded with the industrial boom in London. The train station on York Street has had a dynamic past. It was the place where people first entered the city, and also was a central location for the railways that ran through London towards Toronto and Windsor. It provided a way for London to interact with the rest of Canada in a timely manner. The railway system helped to link Canada together, and the train station in London connected the city to that broad network.

The changes that the train station has undergone demonstrate not only architectural change, but also follow the dynamic history of London and how new technologies have had an impact on transportation. Unlike some of the historic buildings in London, the train station has been torn down twice and rebuilt to better suit the needs of its users and the businesses that depend on it. The station’s history reflects some of the larger changes that have happened in London and also shows how the public interacts with the railway system and how that relationship has not been static. For this project, I studied the time period from the 1850’s to the present in order to explain the reasons that led to the major changes in the station’s appearance. This was a longer timeframe than I had originally anticipated covering, but it allowed me to create a better narrative and go through the changes in the companies that used the station, such as the Grand Trunk Railway and Great Western Railway.

To show the evolution of the train station over time, I used the program Timeline JS to create a timeline featuring the significant dates in its history with respect to the building but also the companies that used it. The timeline layout is ideal for demonstrating how not only the station itself but also the space around it has changed over time. Timeline JS is relatively simplistic, but it allows viewers to focus on the story that is being told. It also displays the chronology well by having slides that you can move through and a running timeline along the bottom to help you orient yourself in time. I did have some issues with Timeline JS, however. To input information into the timeline, I essentially filled out a Google Drive spreadsheet. This worked well, but the program does not let users create separate paragraphs within an entry. This takes away from the overall display of the timeline because it bunches citations together with the text and makes it harder to read. If I were doing the project again, I would probably have used another program that gives you more flexibility for how to display the text.

To make the timeline more visually appealing, I used an assortment of digital tools and sources. By using a range of media, it brings photos, videos, and text together instead of someone having to search through a number of sources to find them if they were interested in the topic. I used aerial images from the Map & Data Centre at Western University overlaid on Google Earth to show how the block around the train station has changed. I also made use of the Fire Insurance Plans the Map & Data Centre has to show the different parts of the station as well as the yards and hotels around it more clearly. To put the photos I had altered onto Timeline JS, I uploaded them to Flickr and then imported the photo URLs to the Timeline JS spreadsheet. This was because Timeline JS requires all media used to be web-based for it to be displayed on a timeline. I also took a few of my own photos to represent the current look of the station. Additionally, I incorporated newspaper articles and a YouTube video that depicted the more recent changes to the station. Using a variety of digital formats helped to make the timeline more engaging for potential viewers.

An image overlay of the railway station in 1922 using Google Earth.
An image overlay of the railway station in 1922 using Google Earth.
A portion of the Fire Insurance Plan from 1881 that was used to show the station's shape and the buildings around it.
A portion of the Fire Insurance Plan from 1881 that was used to show the station’s shape and the buildings around it.

For background research into the station and the companies that used it, I consulted a number of books and webpages. The sources are included in the timeline. By investigating the history of the Grand Trunk and Great Western Railways, I discovered how they competed against each other and then eventually amalgamated when faced with the challenge of maintaining low prices for their customers as well as trying to stay ahead of the Canadian Pacific Railway Company. I found H.A. Lovett’s report from 1924 on the folding of Grand Trunk very insightful because it showed the different pressures that railway lines faced and how they had overextended themselves, which eventually led the company to collapse. It was also interesting to learn how much the government supported all of the railways while also allowing them the freedom to make decisions with respect to merging as long as it did not drive shipping prices up too much.

From my research into the topic, it seems that this project may be one of the first to compile information on the train station over the course of its long history. Many of the webpages mentioned its origins and present condition, but few detailed its transition over time as the railways it serves competed with each other and changes as they amalgamated with other companies or were bought out. The timeline links the historical changes to visual images instead of only discussing what happened. It enables viewers to see progress over time and hopefully the reasoning behind the changes that were made.

Whether viewers are railroad enthusiasts or local history buffs, the story of the York Street train station is quite interesting and truly reflects how dynamic the railway in London has been over time.

To see the final product, please click here. Thanks for taking the time to check it out!

Networks and the Digital Humanities: Respect the Code

The Digital Humanities are making more and more use of Computer Science tools. But how well do these tools suit our needs? Scott Weingart’s post, “Demystifying Networks,” tries to analyse that very question. Weingart starts by outlining what he means by network: a way of showing that different objects or nodes are related to each other. By using a network, a researcher is saying that these nodes are connected and that the connections between the nodes matter.

Here’s where things get tricky for Digital Humanists – networks in the context of Computer Science usually show only one type of relationship, whereas we try to connect information on a number of levels and show how different topics or objects relate to one another. The example Weingart used to explain this dealt with books. He discussed how we link the authors of books to the books they write, but if we then wanted to connect books to one another things get complicated and fast. Computer programs, as of yet, don’t deal well with bimodal information particularly well, and so the graphic results and connections you would get by trying to show both of these relationships at once would not be as accurate as we would like. This means that while we might think that using a program such as Gephi to determine how central a node is in a relationship between a group of nodes, if we try to compare authors, books, and book topics we would probably get muddled results. One of the images that Weingart uses definitely demonstrates how results can get lost as the amount of related information increases:

This image depicts how connecting more and more information can make results too dense and potentially meaningless because everything is so closely related.
This image depicts how connecting more and more information can make results too dense and potentially meaningless because everything is so closely related.

I think that the major point that comes out of Weingart’s post is that people studying the digital humanities have to stop relying so heavily on Computer Science to create the algorithms for our projects. We have a different set of issues that do not focus on only one or two variables at a time, so we need tools that work for us. Now, Weingart also stated that not every project has to use networks to be successful. Not all data is suited to this sort of analysis and creating dense networks that show every point is connected is not a useful way to interpret data. So do Digital Humanists have to reinvent the wheel? How much knowledge does a Digital Humanist need in Computer Science to create data that addresses the questions we are asking?

We have to realize that digital tools have their own limitations. They can be extremely helpful to analyse information, but unless there is more input from Digital Humanists, these tools will not reflect the answers we are searching for. I think that Digital Humanists do not have to become experts at coding, but overall we have to have a better understanding of how programming works so we can at least engage with Computer Scientists to help develop the complex systems required for analysing interactions between the many different types of things that we study. Digital Humanists should not be afraid of using programming to help with their research, but we do have to respect that it can be challenging to design tools that reflect our traditional research methodologies. By working with Computer Scientists to develop tools instead of relying on tools that do not reflect our research needs, we will be able to use digital tools more effectively and better understand the results digital tools provide us with.

Twitter as a Tool for Connecting People to History?

I would like to preface this post by saying that I am not currently a Twitter user and Twitter has always seemed like a strange form of networking to me when it’s used in an academic context. Although  I know a lot of people who use Twitter, before reading the blog posts by Suzanne Fischer and Deevybee I hadn’t really thought too seriously about how Twitter could fit together with History. Academics was not the first thing that came to mind when dealing with the short posts Twitter is known for. But as Suzanne Fischer pointed out in her blog, From Off the Wall: historical diaries on Twitter there is a large community of historians that are active on the site. I always assumed that there was just too much information to keep up with. But Twitter isn’t just a place to get news on your favourite celebrities or what your friend had for lunch and users have the choice to follow people and organizations or not. It can act as a place to interact with like-minded individuals who are interested in history or any other subject.

Now a site like Twitter cannot operate without active users as Deevybee. Reading Deevybee’s blog on how to use Twitter, it became apparent that when people actively contribute to the site, users can reach a wide audience and use it to branch into longer discussions on topics that interest them if they follow links to blogs and other discussion forums. It’s neat to think that you can communicate with people you don’t know but share a common interest in a topic.

Part of what has made Twitter so popular is that you don’t get “information overload” in a post compared to the longer articles you might find on blogs or in academic journals. It also gives users the choice to follow links that are interesting to them and only follow the people and organizations they choose to. Deevybee’s comment that Tweeting too frequently can turn people away from following a user made a lot of sense. I would rather choose to follow links that are interesting to me or read Tweets that are well thought out than be bombarded with information that doesn’t concern me. The fact that Twitter users can follow and unfollow accounts makes it easier to control how much you see and whom you receive updates from. For Twitter to be useful to public historians and the rest of the historical community, PHer’s have to actively Tweet engaging Tweets to encourage others to get involved in history and provide feedback for sites and exhibitions.

Another surprise that came out of Deevybee’s blog was the emphasis on proper Twitter etiquette. In a posting format that is so short, I was happy to see that giving credit to sources you use, whether by citing them or retweeting posts you find interesting, was not only encouraged but expected. This tied into Fischer’s comment that Twitter can relate to history not only through writing formats but also through its stylistic features. She pointed to the fact that Tweets are reminiscent of telegrams in the sense that they are short and to the point, or like quick diary entries that show part of the life of an individual. Seen in this context, Tweets are not all that far outside of more old-fashioned ways of communicating. However, Tweets can reach a much larger audience than a telegram or diary entry would have been intended to.

Twitter, if used wisely, can provide a neat way of interacting with the public and creating a discussion around historical topics or events. I’m not saying that Twitter and other social media sites should be the only way the general public connects with historians but it’s a great jumping-off point for larger questions and issues. I think I’ll have to actually sign up for Twitter to get the full effect of how it can be used as a discussion tool, but it seems like it’s a good medium for people to start getting involved with history.

Sources Cited:

Deevybee, “A Gentle Introduction to Twitter for the Apprehensive Academic,” BishopBlog (14 Jun 2011)

Fischer, “Historical Diaries on Twitter,” Public Historian (23 March 2011).