Digital Tool Evaluation: Esri Story Maps

Since I was here last year and already had to do a quick Digital Tool Evaluation, I decided to take a different approach this year. I will talk about a tool I have had to use a lot this past year- Esri Story Maps from ArcGIS.

ArcGIS  Esri Story Maps is a tool that requires payment. At Gettysburg College, we gain access through the school. It is one of the tools used frequently in classes and other projects.  The mapping system can be used to create maps, narratives, and engaging visuals. It is not limited to one style of map or navigational experience. This system can be used to make different styles of maps, from the narrative Cascade to the functional Tour. Cascade focuses on how information is presented and delivered to audiences rather than creating a map. In fact, it can be made without using a conventional map at all. Tour, meanwhile, is a more traditional map tour that provides coordinates, pictures, and some information. Its style is not suited for in depth analysis, however. It serves to function as a map above all.

These maps can be embedded into sites, but it can also function as a site itself. While other mapping systems we use during the fellowship can also be an independent site, Esri story maps look better standing on their own.

The system is fairly easy to use. The interface is navigable for new users and tutorials exist to help master the tool. It takes time to learn everything, but it is not so difficult that it requires outside expertise.The website includes a blog with information about how to make and use story maps in engaging ways.

This tool is used by the school for many projects. While I will not use it for my own work, it has been useful for many other projects, from Killed at Gettysburg to the eventual Named Spaces website. It requires users to supply data, like coordinates and images, but does not require users to build a map from the ground up. Coding knowledge is not needed to make a sleek map. The college does, however, use another facet of ArcGIS to create maps for use in projects, like the Jack Piers Projects trench maps. Maps are supplied for those who cannot or do not want to build their own.

Some features could be improved, however. Inputting coordinates is tricky. I have input coordinates that are used in other mapping systems fine only to be taken to Antarctica while in Esri. The solution, I learned through trial and error, is to put reverse the coordinates. I don’t know why this discrepancy exists, but it can be frustrating. There is another method for inputting coordinates, but it is only specific to three decimal places and is not as accurate as it could be. The markers can also be moved on accident very easily, requiring constant reentering of data or approximating location to set the map back to how it was supposed to look.  

There are some questions supplied by the Criteria for Digital Tool Evaluation that I never thought about beforehand. These questions look into the documentation and data of the tool. I had never critically considered these issues before, as the tool always seemed good and secure. In the past week, I was alerted that the site would transition from HTTP to  the more secure HTTPS in order to increase security of the data. Esri does collect user data, but vows in its privacy statement to “use your personal information only for the benefit of Esri and our affiliates.” The code, meanwhile, is open source and hosted on GitHub for others to see. Esri encourages developer modification and collaboration through its code. As stated before, it does require subscription to use. This paywall limits the amount of people who can use the tool.

All in all, this tool is versatile and effective at what it does. It can be used to create maps and engaging visuals. While there are some tricks to be learned when using it, it is not prohibitively difficult to use. I will continue to work with these story maps to create engaging visuals and narratives.

Reflection #2

One of the most interesting digital tools that we learned last week was StoryMapJS. StoryMapJS is a great digital tool to tell stories that have geographical data associated with them. For me, I liked StoryMapJS better than utilizing ArcGIS because it is more user-friendly, both as a creator and an audience. ArcGIS was very confusing to me, while StoryMapJS just requires easy plug-in for great results.

This digital tool will be able to help me answer the important places that practice performance in Gettysburg, mapped out. This digital tool is free to use, which is great because it follows the ideology of accessibility of digital humanities. StoryMapJS requires location, text, and images. It would be important to make sure whatever media I use is free use. It is very important to me that the tools remain open source.

Some biases that StoryMapJS have made is that every ‘map’ is geographic in its nature. So, even if it is analyzing a painting, it is still reading as a map, technically. While that can be great, sometimes it may not be the best option, as images need to be extremely large in rendering.

I can not see how often the code is updated, so I don’t know if that would mean that something would break and never be able to be fixed.

Some other possible issue with StoryMapJS is that certain data is not great for mapping. While this will work for me because my data is condensed to one area, for data that covers the globe, it would be dizzying and annoying to use. The tool is easy to use and does not require outside expert or special technical skills.

I think that would use StoryMapJS for my project because it would add another layer of depth to my website.

Week Two Reflective Essay

One major difference between traditional and digital humanities is the analysis not only of not only content material but also its means of presentation. Digital Humanities (DH) appealed to me because last summer I did very traditional research and presented my findings in a formal critical essay. While I enjoyed the work and was proud of the product, I was acutely aware that access to such research was severely limited. In tone as well as form, a formal essay tends to be inaccessible to those outside of academia. While many digital tools aim to rectify this, they should nonetheless continue to be evaluated critically.

For this project, I want to make secondary research available to students and teachers, but I also want to make the texts themselves available. Moreover, I want students to be able to engage with the text as they read, the way they would be able to flag or even mark a physical text. For that reason, I’m interested in using an annotation tool to allow students and teachers to make comments on the primary texts. Group annotation fascinates me for its ability to allow for conversation among readers rather than belated dialogue that is so often the result of conversations across published works, but it nonetheless raises questions about who can and should be allowed in those conversations. My instinct is to allow all comments from all parties because negative feedback is an important part of the reading process; texts are not only valuable if they are faultless. Still, some negative comments could affect the availability of the work in that teachers may not choose to use this site for their students if some annotations are offensive or otherwise not school appropriate.

This itself raises further questions about who is allowed to join in the discussions in academic settings. My aim with this project was to eschew the coded languages of academia – those unspoken expectations about what counts as “scholarly.” While the availability of free annotations removes such expectations as writing in full sentences and not using contractions (generally separating spoken from written language along a false dichotomy), some expectations are maintained such that some amount of vetting for comments would be appropriate.

In addition to the fact that, for this project, the finished annotation would have to be deemed appropriate, inputting the annotation itself requires a certain amount of familiarity with the tool. The major source of inaccessibility in DH at large is the fact that it inherently requires technology to access it. Although technology is becoming more widely available throughout America, it is not universally familiar; even for those who have access to the internet, it is not always widely used. Thus, although many annotation tools are intuitive for regular users of social media (is not a comments section just a space designated for annotations?) and the internet at large, it may not be as clear how to use such tools if the internet is not familiar to a given user. In order to ameliorate this in my project, I intend to create a page that uses clear text and visuals in order to explain how to use the annotation tool, thus allowing for greater access. I think that this process of bridging gaps between expected use and possible use is a key aspect of DH, which annotation makes clear.

Reflective Essay 2

I’ve chosen to critically evaluate Timeline JS because I think it’s an interesting tool that will be very useful for me but one that I will have to use very carefully. There are certain aspects of Timeline JS that seem very effective and well put together, but with everything created by humans there are inherent assumptions made that I must watch.

One of the best aspects of Timeline JS is that it is open source. This allows many people to use it and is not only a tool for the wealthy. When I looked on their website they also seemed to have impressive documentation. The instructions for use were straightforward and easy to understand. You could probably figure it out on your own if you had to. There was also a technical documentation section where they had further instructions. Lastly, there was a clear FAQ section just in case problems arose or there was still confusion on the part of the user. From their website it really seemed as though they wanted this tool to be accessible to all people of all technical abilities and make everything as easy as possible. This was further demonstrated by the fact that one only needs the website and excel to use this tool. They also made it clear that you are able to put many types of media in the timelines you create so it supports all different types of visuals and styles of presentation. There are many ways in which the creators of Timeline JS have attempted to be conscientious and create a good experience for their users.

Because of the nature of this tool, there are inherent assumptions that the makers have made. The first one that comes to my mind is the nature of time itself. Time is a human construct, and we use it to measure things to make more sense out of them. But what if these things are not measurable by time? When we use time for things like this, we often end up attempting to fit something into a box that perhaps shouldn’t be fit into a box. This is especially important to me because I am working with eras, which are by nature, time bound, and yet there is great disagreement as to what these boundaries are. Many people think that the modern and postmodern eras are not really measurable through time because their ideas endure past the era and came into being far before. We are attempting to measure the flux and change in people’s beliefs through time and yet that assumes that people’s beliefs are time bound in a way.

A tool like this is also difficult because when we have a timeline we are choosing which events to put in this timeline and inherent biases come along with those choices. Which markers in history are we choosing to use? Whose history are we using? When we place certain events next to each other, is there risk that we are creating the guise of correlation when in truth they may have not been related at all? The problem with timelines are that they create a certain narrative that we want to make by using a strong rhetorical device that can easily be manipulated negatively. We must be very careful to choose our markers carefully and to not introduce correlation where it does not exist.

Nevertheless, I will use this tool for my project because, while these terms are difficult to place in time, it does make them easier to understand. They are products of and influencers on the times in which they were situated and so placing them into those physical years and events in those years will help.

ILE Reflective Essay #2

This week we learned about several tools we have access to and can incorporate into our websites. For this week’s reflection I would like to focus on Timeline JS – a tool I will become very familiar with by the end of the eight-weeks. Timeline JS is an open source tool developed by Knight Lab at Northwestern University. This digital tool is beneficial to projects that require a display of chronological information. After the user enters information into Google Sheets, the timeline created, and is ready to be embedded into the webpage.

Several assumptions are made by the developers like access to a Google account, understanding of Google Sheets, comprehension of the English language, and ability to add videos, images, external links, and social media. The tool can be used to present multi-faceted stories; however, it is up to the creators to pick the information which can lead to biased presentation of research. Timeline slides can be changed by using the mouse to click on the left/right buttons on the timeline or the left/right buttons on a computer keyboard. Although the tool appears to be unbiased, it allows for information to be presented from biased perceptions.

Key features of the tool focus on the adaptability and wider variety of media that can be added to the timeline. We have seen examples timelines with tweets, videos, images, documents, external links, and text. Timeline JS is different from current styles of timelines. Many organizations are leaning towards vertical displays of information (see ILE Project Charter for examples) – however, user interaction consists of scrolling down the page. I have not found a vertical timeline with external links; I have not had the time to properly interact will a wide range of timelines to understand the programs used, but I do know that creating the timeline within the page allows for HTML modification.

Basic use of the tool is not difficult because the downloadable Google spreadsheet provides several examples of the information needed to create a clear display. Something I recently learned was that the information does not need to be entered in chronological order Timeline JS to display it as such. (Neat, right?) Knowing this feature exist is great because I will often check the spreadsheets for missing information because I sometimes misarrange dates, but a mistake like this will not cause my timeline to be out of order. Timeline JS requires the user to have a Google account with access to the Google Drive – this permits Timeline JS to collect and display the information chosen by the user. The data of the timeline is owned by the publisher or location of information; I have to make sure I correctly cite the information I use in case someone else is interested in finding the same information.

Questions regarding Timeline JS must be sent to those working at Knight Lab – the website clearly states that the request can only be processed if they are in English. Due to the lack of tech support, questions might not be answered in a prompt manner. Unfortunately, I was not able to find anything with a schedule or time frame for tool updates. Modifications can be done to the timeline, but they require some understanding of CSS/HTML. Sometimes I forget the code for some changes, but a quick Google search helps with code. I am looking forward to working in Timeline JS, I believe it is user friendly and with a few code modification, I can design the timeline to reflect my vision.