Just another My blog Sites site
Welcome to My blog Sites. This is your first post. Edit or delete it, then start blogging!
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
While I enjoyed researching the town of Davidson and minority dwellings within the town, my project changed a bit from its conception to its final presentation. Originally, I wanted to have an interactive map where viewers could see how the town had changed over time and how different people conceptualized the town. Unfortunately, there was a lack of data on the specific area I was researching (Brady’s Alley) which should not have surprised me given its less than ideal living conditions. With this lack of data I shifted more towards gathering newspaper clippings and pictures (What was mostly available) while supplementing these with voices of townspeople through more archival data. I wanted to avoid getting IRB approval given the time constraints and so I relied heavily on data that other students collected and archival data. Over all, my project does get accomplished what I wanted it to which was to tell a story of a place and its peoples that is hardly recognized.
As I worked within historypin (and went back and forth between historypin or heganoo and even googlemaps at times), I realized that no tool is perfect. While historypin did not have every capability I wanted, it was the closest fit to what my project aimed to do and what I had to contribute. If I could make one last suggestion to historypin developers I would suggest they think about how many ways there product can be developed. When reading over my colleagues final thoughts I noticed Joe‘s commentary on Appinventor not handling complicated data as well as he would have hoped which I completely relate to. I actually considered using several different and more complicated apps and websites including Heganoo but I stuck with Historypin and figured out how to make my ideas fit within their capabilities.
The process was different than most project processes because I had the chance to show it to family and friends and found that their responses were more helpful than I had gauged. Before this class, I assumed Beta-testing just meant testing with your colleagues to see how you felt about the product, but instead, it is much more enriching. I would have never thought to add more context without getting feedback over break.
In the end, I was able to use the subjects I love (Anthropology and History) to create a mapping exhibit which is an avenue I never expected to go down before this year. I hope my project is successful in getting its point across and I hope that people find it fascinating.
Final Project: Davidson Mapping App
Process:
Part 1: The Idea
The idea behind the Davidson Mapping app was one grounded in simplicity and practicality, meaning that the idea was to come up with something that was both a simple concept while also having practical application. Simplicity of concept was necessary because the design tools available were all complex in their own way, and the last thing a project with an impending deadline needs is a complex idea to be executed by a complex process. As for practicality, keeping a user-base in mind while designing the project would help keep the project focused instead of abstract; I would be making something that would work for people rather than just look pretty.
The basic idea, before any platform was chosen, was to create something that helped people; students, parents, teachers, ect.; get around campus and know where places were. For example, many visitors and new students are often confused about locations such as the Duke Family Performance Hall and the Lily Gallery, as those are located inside other buildings and therefore often not included in visual maps that only show buildings. In addition, sometimes the colloquial names of buildings are not indicative of what they are used for, such as Chambers being the main space for English classes, or Sloan being the music center. Therefore, the plan was to create a platform where those who were confused could understand more about the space of Davidson easily.
Part 2: Creation
Figuring out what platform to use was the first integral step to this process. I had to decide between two major options. The first was a website, which would be able to handle various levels of complexity to fit my vision for the project. However, accessibility would most likely be limited to computers and, generally speaking, people don’t tend to get lost while sitting around using a computer. An app, the second option, would be more conducive to this audience since it could be used when they are out and about around campus, but the app program, AI2, only works for Android phones and has less complex functionality. In the end, I went with the app because the decrease in complex functionality probably wouldn’t hinder me very much, as I don’t have the skills to utilize complexity anyways.
Throughout the process of creating the app, I hit a few design blocks. Originally, I had programmed the app to take users to different screens featuring each location. However, this function served to bog the app down an incredible about as keeping many screens available required a lot of processing power. Therefore, I changed the design to feature various hidden components that could be revealed. Another issue I had to overcome was the file size of the images I used. When buttons representing each location were clicked, an image and corresponding description of the building would be revealed on the screen. When simply scaling down the pictures in the app, the large file size still remained in the app’s files. Therefore, I had to manually decrease the quality and size of the images so that when put into the app’s set of media, the file size would not be ridiculous. The final problem was the lack of a search function. I had originally intended for users to be able to search for places within the app, yet that function was proving to be too difficult to program. Therefore, I included two additional functions. The first was an image of the Davidson campus at large, which would help users pinpoint where they were. The other function was one that connected to a web browser that brought up the Davidson.edu search engine. In this way, users could look up any location that they either could not find or was not included in the app.
There are a few additional parts to the creation of the app. Most of the programming is redundant copies of code for different objects that need to behave the same way. The first and main screen of the app has the most programming, and the buttons are designed to toggle the visibility of the various groups of objects. There is also programming to set all these objects as invisible, as the app sets the elements visible by default. Additionally, the text must be spaced appropriately in the designer, as the space you can see in the app creator is not the same as what will appear in the actual app; a lot of trial and error was necessary to keep the text from overlapping with different parts of other texts. The other buttons simply navigate the screens.
Part 3: Results and Moving Forward
After beta testing, the feature most desired was specific directions to the various locations based on where you were when you accessed the app. The descriptions as of now have general directions to the various buildings, namely by saying what other buildings and features neighbor the structure in question. I do believe it is possible to attain this, but the programming is complex and wouldn’t meet the primary deadline and it is not essential to use of the app. Other features brought up when showcasing the app are as follows. Firstly, during better season I will need to update the pictures with more flattering weather as a backdrop or otherwise dive into the archives to find some quality pictures of the various buildings around campus. Next, I will need to add more locations to the app, and perhaps even group them. Right now, the locations are limited to main academic buildings and other buildings that would be important for freshmen and families of freshmen, who would most likely be in need of the app. After more time I can add more locations to make the app more comprehensive. After all this, hopefully the app would be in a good position to potentially submit this app to Davidson to be distributed to various parents and students during the year.
__________________________________________________________________________
Project and the Field of the Digital Humanities:
One of the biggest challenges that Digital Studies as a whole faces is how abstract and complex its fundamental products are. There is often a high threshold for complexity leaving many creators and users confused because they lack specific knowledge of the particular processes of the Digital Studies. In the realm of Digital Mapping, the various coordinate systems, terms, and file types prevent creators from going as far beyond traditional mapping ideas as they could and keeps the layman away from using the products, as only those immersed in the study of Digital Mapping can understand the scope of the complexity of some of the projects. They may be able to see the big picture, but unlike text files or images, very few understand the mechanics of the processes. With the Digital Map App of Davidson College, I hope to create a simple linking of the ideas of geospatial data that serves as both a practical tool for navigation as well as a simple example of how geospatial data can be approached by an average user.
Stephen Ramsay and Rockwell’s “Developing Things: Notes toward an Epistemology of Building in the Digital Humanities” offers a clear and concise summation of the general issues surrounding digital studies as a whole. Ramsay and Rockwell argue that the abstract nature of Digital Studies as a whole has left many within the community questioning and arguing about what the definition is. This is in part due to the wide range of complex ideas that are a part of different segments of the Digital Humanities, how “but their work is all about XML, XSLT, GIS, R, CSS, and C” (Ramsay, Rockwell). While many average users of computers understand how text can be bolded or italicized and at least know that JPEG and PNG files refer to images, for most people the aforementioned file types are simply gibberish. In addition, in Ramsay and Rockwell’s discussion, there is no uniformity in the use of these file types across even the subsections of the Digital Humanities. Not every map is made with GIS, and not every program is run by C. This complexity is part of why it seems Ramsay and Rockwell have left out discussion of the Digital Humanities for the common man, the only noticeable omission in the article. While I would have liked the discussion there, if the Digital Humanities departments cannot define themselves, then it would be difficult for a layman to have any idea where to start.
There are many attempts to explain the concept of geospatial data, a important concept to the subject of digital mapping, to the layman with mixed results. The Environmental Protection Agency (EPA) attempts to define geospatial data for those wishing to keep records, but their definitions and procedure reveal the outdated approaches that those working outside the Digital Humanities often take, whether out of ease or necessity. While offering advice on how to store records, the EPA states that “Geospatial data records are often in special formats (e.g., oversized paper maps or data sets). Therefore, it is especially important to identify the geospatial data records with appropriate metadata, so the records can be easily accessed and retrieved with other, related records” (Environmental Protection Agency, Frequent Questions about Geospatial Data and Records). Rather than believe the EPA is ignorant to the more condensed ways of storing geospatial data, it rather seems that they must suggest less compact ways of storing data by the virtue that they are simpler for the user in the face of the overwhelming complexity that shapefiles and raster layers may bring to the uninitiated record keeper. While the FAQ may not be a good robust description of the idea of geospatial data, it must limit itself to inefficient simplicity in order to explain itself to users.
However, even without the need to focus on practical applications like record keeping, the definition of geospatial data can remain elusive. Even the handbook of geospatial data, a “user manual” for those who are trying to understand geospatial servers, must resort to relating text and webpages into its language in order to convey just what geospatial data is. While the guide book makes the claim that “Soon a search for spatial data will be as easy as a Google search for a web page (OpenPlans, GeoServer 2.6.x User Manual) they also bring up “browser” based systems and offer very few concrete examples that truly explain what geospatial data is supposed to be. The handbook tries to argue that geospatial data is fundamentally different from other types of data, yet only describes it using comparisons.
However, to understand geospatial data one only needs to look as far as the concept of spaces and places in people minds, commonly referred to as a “mental map.” Ozkul and Gauntlett’s “Locative Media in the City: Drawing Maps and Telling Stories” in Mobile Stories, serves as both an easy to comprehend discussion of what mental maps are as well as how people view geospatial data within their own minds. In their study, users were asked to “draw a map of London showing ‘frequently visited places’” (Ozkul Gauntlett 114). What surfaced did not take the form of raster layers, CSS code, or shapefiles placed by a complex coordinate system. Rather, people drew pictures and words in order to explain how geospatial data related to the real world. They also discussed concepts outloud that described how they viewed geospatial data, though they might not have personally called their ideas as such (114). This thorough discussion highlights one of the key difficulties that surrounds the abstract nature of many discussions on digital humanities. Text, pictures, and other common forms of data are not separate entities from geospatial data but rather simply another lense with which to view the various types of data that make up the world as a whole.
Data is not nearly as sectioned off into buckets of categories with no overlap as those who are obsessed with the quantitative over the qualitative might want you to think. Images like photographs can easily contain text, from a photo of a book to a simple captioned image. Text can be used to create images such as ASCII[1] art or emoticons[2]. The tools we use to create these are the same at their base as well. Webpages are made up of pixels which create both text and images, all of which are founded in the same code. There are different tools that produce similar results, but it is not the intrinsic makeup of these types of data that defines what they are but rather how we as people choose to interpret them. Likewise, geospatial data doesn’t need to be made up of completely different types of components from webpages or any other medium. What geospatial data does is combine the same elements that we use daily to produce other types of data in a way that people interpret as having to do with the space and place around them. This simplicity is something I hope to achieve with the Davidson Mapping App I am creating with the MIT aiAppInventor software[3].
Rather than trying to keep a purity of only geospatial data, the Davidson Mapping App attempts to look at text and image data through a geospatial lense. The current Davidson map[4] uses shapes and symbols as primary indicators of space, yet often that is confusing since people don’t tend to think in terms of those particular symbols but rather in terms of descriptions and mental pictures (Ozkul, Gauntlett). Therefore, the Mapping App adds textual descriptions and identifiable images to the available data to give users the best sense of where these spaces are, what they look like, and what they contain. Practically speaking, the text gives the buildings a sense of what they are commonly used for and the specific areas inside them, such as Hance Auditorium on the fourth floor of Chambers which, according to several Davidson students, was a very difficult place to locate the first time. The images help give the users’ mental maps a better foundation than the symbols; rather than simplistic shapefiles to go off of, users can have an image of the building or space in their minds that matches up very closely to what they will see when they approach the space. However, the app serves a purpose in getting users familiar with geospatial data itself as well.
MIT’s aiAppInventor is a program built around simplicity and therefore is a perfect medium to try to convey geospatial data in a clear and simple manner. The apps are programmed using predetermined blocks of code, which keeps the interface simple for both creators and users. While at first this design may seem limiting, it helps to streamline the application of use. One cannot incorporate GIS files or Excel data spreadsheets into this tool. Therefore, the cartographer and the layman are on common ground and data does not need to be translated from a complicated form back into simplistic terms. The app inventor does not work well for complicated projects, but is a great tool for understanding basic components of data and for presenting those components to a user.
In order to get definition at the higher levels of digital studies, we must first people to explain ourselves on simple terms to the average person. While there will always be an important place for discussion at the higher level of the subject, it’s important to make the Digital Humanities to be as accessible as possible for the common person as basic math, science, language or art is. Tools that appeal to our interpretation of geospatial data rather than the semantics about it will help us better understand what the essence of Digital Mapping within the Digital Humanities really is.
[1] ASCII art is made up of pictures using only the 128 characters from American Standard Code for Information Interchange. [2] Emoticons use the characters on a keyboard to denote certain facial expressions or emotions. [3] http://appinventor.mit.edu/explore/ [4]http://www.davidson.edu/Documents/About/Visit/Campus%20Map/Campus-Map-8-5×11-2013.pdfCitations
Didem Ozkul and David Gauntlett. “Locative Media in the City: Drawing Maps and Telling Stories” in Mobile Stories
“Frequent Questions: Records Management.” U.S Environmental Protection Agency. August 3, 2012. Accessed November 20, 2014. http://www.epa.gov/records/faqs/geospatial.html
Stephen Ramsay and Geoffrey Rockwell. “Developing Things: Notes Towards an Epistemology of Building in the Digital Humanities” inDebates in the Digital Humanities
OpenPlans, 2014 GeoServer 2.6.x User Manual, accessed November 20, 2014, http://docs.geoserver.org/stable/en/user/introduction/history.html
I sent out a survey to five people and then also included my family who had originally seen the project to get more formalized feedback. For my beta-test, I asked the following questions: What are the critiques of the overall format of the website; What do you think about the following features (Timeline, Glossary, Map Overlays); Does the project fulfill the goals that it sets out to achieve; What information about Davidson would you like/need to know to make the site more interesting. The website that is discussed below can be accessed by clicking here.
Style
In terms of the first question regarding the overall layout of the the website, I thought that perhaps there were too many dots and that people would not want to spend time looking through all the memories. The timeline, I hoped, might simplify this process if a user wanted to look at a specific decade. The comments that I recieved were positive about the layout and many enjoyed looking at the map. One person found the main flaw that I find with Neatline maps, which is the ability to zoom the map beyond the scope of the project, and another commented that the zoom button should be larger. One user liked the fact that the project automatically zooms in when you press a button, however, I do not like this feature and need to fix it. Another respondent had an issue with technology that prevented the satelitte image–the background of the base map–from loading. Other technological issues included a user who thought that the dots were hard to click on and see on one computer, but using the website on another computer fixed the problem. In terms of the website layout, one respondent suggested providing a route to find the main page again after entering the map, however, I believe this issue can be more easily solved if the users just press the back button on their browser. Another user reasonably suggested that I provide more a ‘user’s guide’ on the main page to help people navigate the page.
The specific features–the timeline, glossary, and map overlays–received mixed feedback. For the timeline, many respondents thought it was not easy to use, and some were misunderstood the question and, instead of looking at the timeline on the map, went back to the Neatline site and looked at the timeline page that was incomplete. In order to solve this issue, I have removed the extra page on the website. One respondent who had seen the project previously said, “I think that the layout is a bit more navigable with the dragging timeline.” Another user thought it was odd that the Neatline timeline extended far into the future and the past (I agree) and suggested sarcastically that maybe I should include future memories as well. Still another thought (as I do) that the aesthetic of the timeline is visually unappealing because it is too wide and overwhelms the map. Unfortunately, this cannot be fixed. Although the glossary page was not meant to be accessed through the Neatline page, some users, instead of finding words that hyperlinked to the page, went and looked at the glossary in order to respond to my question. Others could not find the glossary at all either from hyperlinked entries or on website. The glossary pages came form the Davidson archive, and included pictures and other quotes about the places. One user liked the picture aspect of the glossary, which makes me think I should add pictures to the main exhibit. Most appreciate the map overlays as a “cool addition,” but I do not think that most found it to be helpful in terms of thinking about the history of campus. One negative response thought that the overlay maps were, “Not very interesting, the old ones are kind of ugly lookig, the google map is the nicest.” One user though that the overlays are not an intuitive feature and he said, “Map overlays were really pretty cool, and helped me better relate the stories I was reading to the geography in which they took place- that being said, I wouldn’t have found it if you hand’t told me what to click.” For the same user that had previously faced technological issues, the overlays maps were “blurred and not helpful.”
Content
In terms of content, given the responses of the respondents, I think that my original suspicion that there are too many dots is true. Many people get tired of looking through the memories and, thus, give recommendations for entries that already exist. For example, one respondent replied that he would have enjoyed longer entries about activities that occurred in specific buildings that might not take place there anymore, which is the entire point of most entries. However, I believe that his response may have been because this particular respondent moves in the science circles of Davidson that are not as prominent on the map. Many people said they would have liked to see more modern memories although others expressed their appreciation in the historical aspect of the project. For example, a history major that reviewed the project said, “I really like the idea of being able to hear voices from on campus over the course of many years. Its a good reminder that this is a dynamic and changing place.”
Other content related feedback regarded whether the project is interesting and what information would make it more informative. In terms of the whether the project was interesting, I got feedback that ranged from responses that the project was “moderately interesting” to users who just wanted to know “Where have people made out in the last century?” One user wanted to know the source of the memory, which is something that I could include in the ‘About’ section or in a ‘User Guide.’
Conclusion
From the responses that I got, I think that I need some way to limit the user and also guide them on how to use the site. Also, because not many people were that invested in exploring the site, maybe I need to think of some way to make the site more engaging, such as including pictures with every entry, providing more maps, or entering more modern memories.
After getting my project into a presentable form, I was able to send out the file to others to take a look at the app. I got both Davidson students and students from other schools even, though coordinating with faculty over the weekend ended up being problematic. There are many improvements suggested and while I would like to address all of them, some of them are just implausible with my current range of skills.
One of the complaints was about the Davidson map itself, as the image was too blurry to see well and could not be zoomed in or moved to suit the users preference. This can be easily fixed by getting a higher resolution photo and adding scrolling capability to the screen and is something that shouldn’t take too long to implement.
Another user stated that the search function was confusing. While I admit that the web viewer of Davidson’s search engine is a little clunky, unfortunately it is the only way I can present it without creating an entirely new website, which would take more than the deadline by far and would require me to learn a lot more things. I will try to adjust the into screen text to help users use the search function clearly, but aside from that there is little I can do.
Another user also suggested that the app show where a place is on the map. While motion tracking is a bit out of my current skills, it should be possible to add some cropped sections of the Davidson map to give users a better sense of where things are. I would personally hope that the directions included in the descriptions would also be help enough, and they may be since it didn’t seem like the testers spent much time reading them.
Another final point to mention is that the test did help me find one particular glaring error, where the search screen did not redirect to an existing screen. In addition, I discovered that certain settings had to be unlocked to allow the app to work since it was being read as a “third party source.” I do not think this would be the case for an official version of the app, but I am at least now aware of the process.
For the Participants
With the limited time that I had between wrestling and traveling this weekend, I presented two example (not complete) exhibits (one in Neatline and one in Google Maps Engine) to students to figure out which type is better and/or which parts from each one I should keep or eliminate. First, I asked the participants to choose which one they preferred visually based on appearance and ease of understanding. I chose this as my highest priority question because the visual of the map is the first impression that the viewer will receive. Second, I had them decide which one had a better interactive feature. Both require the viewer to click to see the different maps for the types of students; in Neatline, the viewer clicks through waypoints, and in Google Maps Engine, the viewer clicks to toggle layers on and off. The result is essentially the same, but I chose this feature as another high priority question because it is the sole way of ‘traveling’ through the exhibit. Third, I had them compare the text features of each exhibit; Neatline presents descriptions for each way point in a single text area while Google Maps Engine presents descriptions, not for each layer, but for each marker, line, polygon, etc… of the layer. Fourth, I had them comment on color; Neatline is more limited with color than Google Maps Engine, so it basically came down to whether more color was better or didn’t make a difference. From these comments, I could determine which platform I should continue to build on and even what I should add to each one. However, I still had the participants comment on what could enhance each exhibit rather than only compare the two. I asked what could be taken away or added to the descriptions, what they would like to see (if possible) regarding paths, buildings, or even another layer ( for example: a combination layer that takes all the student variables together), etc…Lastly, I asked what they felt was missing based on their own knowledge of maps.
Neatline vs. Google Maps Engine
From the feedback, the biggest, significant differences between these two platforms are presentation of color, descriptions, and layers. On color, most of my participants preferred Google Maps Engine because each layer could contain different colors whereas, in Neatline, each layer can have a different color than another layer, but the color in each layer can only be one. The variation in color proved to be helpful in showing information in a single layer rather as well as layer to layer. What I mean by that is: in Google Maps Engine, I can make the academic buildings in every layer red, the athletic buildings blue, and the living buildings yellow. This helps viewers see the different types of places a certain student goes to AND which type of places are eliminated or added as they switch to other layers.
On descriptions, some liked Google Maps Engine, but more liked Neatline because the description is all in one place for each waypoint. I thought that more would prefer Google because they could click a building/path to see a specific description instead of reading a long description on Neatline. However, more passive interaction seemed to be what people were comfortable with. In defense of Google Maps Engine, clicking through each building for a description is more informative since it gives the title and highlights the location of each building (this would be more effective for someone who is unfamiliar with the campus). It comes down to amount of clicking vs. amount of information.
On the presentation of layers, Google Maps Engine prevailed. The feedback showed that toggling layers on and off was more effective at showing differences between the types of students than moving from waypoint to waypoint. Also, the viewer has control of seeing combinations of variables by toggling. For example, they can see all of layers at once or they can toggle underclassman student non-athlete, in a PCO and toggle upperclassman student athlete, not in a PCO. With Neatline, I would have to make specific waypoints in order to give the viewer that ability. From the feedback, it isn’t as black and white as saying one is better than the other; the combination of features is what makes one more effective. So, for the presentation of layers, I noticed that color and clicking were still playing a role into how the participants made their choices even though I separated color and layers into different questions.
As for what could be added or taken away from each exhibit, I feel that I may have primed the participants by having them compare the exhibits first. I received more feedback for Neatline referring to the addition of features; the participants wanted to see more paths and more color. For Google Maps Engine, some of the participants wanted more of an initial summary of the project before they started viewing but didn’t say much about adding buildings or paths.
My Decisions
I am going to pursue the completion of the exhibit in Google Maps Engine. It is better at presenting an argument largely because of the color variation, toggling of layers, and clicking of individual buildings in a layer. I need to figure out a way to have a brief description of my project since Google Maps Engine doesn’t have descriptions unless they are assigned to a marker, line, polygon, etc… Instead of each layer being a different color as it what in Neatline, I am going to have each type of building be a different color. So, academic buildings will be one color in all layers, and athletic buildings will be another color in all layers. This will also require me to have a legend, which I need to figure out as well (could go in the initial summary). The description of each variable will be broken into the buildings and paths in each layer. The viewer will learn about the type of student as they click through the map; this will require the viewer to actually click to see information, but I feel that it will be more effective because the viewer will see the highlighted building with the text attached to it. I won’t have to make extra layers that combine variables since the viewer has control of toggling certain layers on and off. My only worry is that the viewer will have to interact with the map on the same screen in which I edit it; in that case, I will have to direct the viewer which buttons not to press.
As I described in one of my previous blog posts I sent a questionnaire out to 10 participants. I received feedback from six over the weekend which I believe is enough to record my results.
Overall there were positive responses to my questions on functionality. Every button worked and every picture loaded, but I found a variety of critiques on the ease of use of my project. For the participants I sat down with I found myself explaining what to do a lot of times. One suggestion, that could go under style was to have each feature loaded in the sidebar as a waypoint, that way no one would accidentally skip over some features (which many participants admitted did happen).
In terms of the authors intent, the participants suggested that I place a blurb at the beginning of the neatline exhibit explaining the intent. While a few participants read through my introduction and literature review on the other exhibit pages, others admitted that those were a little long to read for a website. Many that I sat down with understood the intent once I explained how to work the neatline exhibit, but finding a way to limit my need for explanation would be helpful. I have instructions at the bottom of the exhibit but, again,one participant suggested for them to go at the top. While this is an excellent suggestion, I am not quite sure how to do this.
The questions that received the most feedback were the ones surrounding style. One suggestion was to include a variety of the images I have collected throughout my project. Because I have these already digitized, the participants argued that it would make the text seem a lot shorter if there are images to accompany it. While I do not agree that it will make the text shorter, adding pictures will add context and another visually appealing aspect. The trick now is to figure out how to add images without it getting to cluttered. I had a lot of feedback about the timeline feature. While I thought it was extremely cool that the participant was forced to scroll through time and various maps would pop up, one participant found this confusing, one was not sure when the chapters switched, and one admitted that she could not figure out how to use this feature. One participant suggested having each chapter available on the sidebar or make them visible on the actual timeline itself. While I was against putting them on the sidebar at first, the participant had a convincing argument. They said that although I want my text to be read in sequential order, one of the most powerful parts of my project is comparing maps from time periods that are very far apart.
The most useful feedback I received about the storytelling part of my project goes alongside functionality. For two participants it was their first instinct to click on the chapter title instead of introduction first. While I said in the instructions to select introduction to begin the story, two participants said that instinct will probably win over my instructions. With that they argued that my story would flow very well if I had the introduction be a part of the chapter title. I believe I want the introduction to be a separate step, but I think labeling each feature with numbers could direct the audience towards the linear story. One thing I don’t particularly like about that idea is that its interesting to click random features because many developments happened at the same time, and it allows for more interactivity. In all, the thing I will take from the suggestions about storytelling is that people will click on the chapter title first, and to make that an opening picture or statement about that chapter.
Many participants liked the interactivity of the project. One problem people ran into was the project looks different on different sized computer screens. For example, the project is very visually pleasing and easy to navigate on a school desktop computer, but a personal laptop was harder to see and click through buttons. I am not sure how to fix this besides explicitly saying that in the instructions. One participant did use her iphone with it which proved to be a huge disaster. Overall, all participants enjoyed clicking through the features, but mentioned that scrolling through the timeline was tedious. When I thought scrolling through years in seconds would not be tedious, I did not see the extra work it took participants who could not figure it out.
Lastly, I received interesting feedback on the purpose of my project. 8 5 informants said it added to their understanding of Davidson’s history and 1 said it added to their understanding of Davidson’s landscape history. This response was troubling to me. My purpose for my project was to examine social and landscape changes and how they are related, but I believe the environmental aspect was lost in the website. I think one way to fix this would be to explicitly state when I am talking about social changes, and when I am talking about landscape changes. Almost every introduction mentioned only social changes so I could rewrite that section to explicitly discuss social changes instead of presenting it as an overarching introduction to each chapter.
Along with purpose I added one question on my proposed map on the ideal Davidson. As I have already created this map I know I can add it easily, but I asked various participants what they thought and what they thought it would add. Overall 5 participants suggested that I leave the map out because it will not add to my overall purpose. 1 participant suggested that I put it in a different neatline exhibit. Because I want to spend my time making the best exhibit possible, I have decided to leave out this aspect of my exhibit. Hopefully this decision will not be a bad one.
In all, I received a variety of helpful suggestions which I plan to implement in the next few days.
Historypin is a map making tool that allows the user to place old pictures of an area over the current street view of the same place in modern day. The creators describe Historypin as a global community collaborating around history. It calls for copyrights and details about whichever photo is being overlaid and gives credit to the picture’s original owner. By placing the picture over a streetview of its current location, it juxtaposes itself between old and new showing how the space has been potentially re purposed or how the sense of place has changed over time. These pictures on maps can be shared via various social media sites making space and place through history extremely accessible.
This tool functions as a timeline that allows the user to tell a story of change over time. By showing time over time it engages the viewer in a story similar to the 21 Steps story map or mental maps like it. Mental maps are maps that tell a story for a user, usually made to represent how the creator moves through space or understands space. Although this reading was not assigned, I felt that Galindo’s “The September 11 Memorial & Museum Map” is an interesting case of a narrative map that tells historical and political stories. Like many of Historypin’s maps, this narrative app relies on archival photos and multiple perspectives. Similar to the 9/11 app, Historypin can help create educational tours of a place.
In a similar vein, geography is history. Because so many spaces are geographically similar, the usage of historical, mental maps to show space, inherently when a person creates a narrative map with tools like Historypin, they are creating a personal history. Identity in a place matters more now than ever according to Charles J. Whithers. In terms of usage, Historypin is perfect for “spatial turns”- placing landscape into a secondary lens and placing whichever subject (Urban planning, Anthropology, etc) into the forefront. Sonni would say these maps represent what the user feels about the space, Historypin maps ask the user to draw from their resources of pictures (whether personal or from archives they have access to) and allow them to show how the space has changed over time for them. If there were several pictures from people of all backgrounds, a Historypin would show a variety of changes (or things staying the same). Urban planners can look at Historypin’s to see how an area has changed culturally when trying to decide where to build and what areas to restore. Maps then become the tool for these subjects to portray various stories or historical events, with Historypin being a perfect tool.
Perhaps not everyone has the time or resources to explore archival data- Historypin is a solution to that problem. If I could change something about Historypin, I would add sound to the maps in order to tell the story with the voices of the landscape. The images can be kind of hard to place over the exact spot that you would want on Googlemaps and so, I would try to make the base map more accurate. I would recommend this tool overall because it allows people to see change over time which tells a larger story of space and place, locality and history.
Heganoo is a free mapping website that allows and encourages users to create a story or document a part of history through points of interest on a map. With this ability, people can create their own virtual tours on a map with purposes ranging from education to advertising. The Showcase section shows vast varieties of projects differing in style, purpose, and even whether a map is included (this project, here, does not include a traditional base map).
Creators have a lot of freedom in constructing their projects, but not too much freedom where it could be easy to get lost or too hard to learn. Design choices include map style (streets, satellite, terrain), color, font, language, and map feature customization (by this, I mean the creator can color things such as water, roadways, and landscapes). This allows for uniqueness and diversity between maps even though creators are executing similar steps to build their maps. Katriina Soini writes that “mapping cannot alone build a bridge between the human and natural sciences in landscape research, but it might diminish the gap between them” (Soini, 235). While Soini refers to the gap between human and natural sciences, I believe that this statement about mapping can apply to the gap between space and explanation of space. Heganoo closes this gap because it isn’t restricted to just ‘mapping’; within each new landmark, the project creator can add media such as text, images, video, and sound. The media is as high a quality as the creator uploads it; Heganoo can handle high-quality images that make the projects even more visually pleasing.
It is, however, very important that the zoom and clarity of the map be appropriate. This is vital in preventing the viewer from being lost or confused. The zoom level depends on the project; for example, zoom that shows the shapes of buildings could work for one project while zoom that shows each state could be better for another. Either way, the viewers need a way to orient themselves within the project. Also, it is beneficial to include images for either none or all of the landmarks; having some with images and some without makes it seem like the project is incomplete.
With Heganoo, the emphasis is on the narrative, and at the same time, digital mapping stands out, making this program very interesting. The narratives in these projects often form arguments about location and time, which engages the viewer more so than a traditional map without an inherent argument. For example, my Heganoo project (which Heganoo was perfect for) from earlier in the semester documented the evolution of fitness centers on the Davidson College campus; the viewer was able to see pictures, descriptions, and locations of the fitness centers throughout history at the college. My argument was that the college increased fitness centers as physical health became more important and campus population and finances grew. On the other hand, a project on the Showcase page maps the top rodeos in the United States; while this project has a narrative, there is less of an argument. Instead, its purpose is to notify viewers about which rodeos to attend and when to go. Martin Dodge and Rob Kitchin write about the power of the internet to allow people to create their own maps, but they do mention that distortion is still a problem with mapping, even digital mapping (Dodge & Kitchin). Heganoo does not eliminate distortion, but it diminishes the effects of distortion since each project has its own agenda based on the author’s creative choice. With Heganoo, it doesn’t matter as much if there is bias or distortion because the creator builds the map with a certain argument.
I would recommend this tool to others; it is an easy and effective way to construct arguments about interesting topics through digital mapping. It allowed me to create the map that I desired, and it definitely would be compatible with ideas that differ from my original. The program functions as a narrative map, and additionally, it takes the viewer on an interactive tour. Monetti might deem Heganoo as an evolved version of his literary maps, which he explains as preparing text for analysis and providing a visual of the narrative (Monetti, 53). This program ultimately allows/forces users to think about their argument in a way that isn’t limited to writing but instead focuses on mapping as the the primary objective. Like literary maps, Heganoo shows the viewer significance that might not have been understood had it only been read.