Digital Tools

Objectives

After this lab, students will be able to:

• Create a basic webpage using HTML and CSS in order to understand the basic structure of websites
• Use GitHub to save the different versions of the HTML and CSS files created in this lab in order to understand the basic use of these tools.
• Analyze digital projects in order to see how they are created

Background Reading

• Look through the Carolina Digital Humanities Initiative’s tools page. Compare to the DIRT Directory. Bring one or two tools you could see yourself using in your project.
• Familiarize yourself with HTML and CSS throughout this week, and continue throughout the rest of the summer.  You can either read over Miriam Posner’s “HTML & CSS” tutorial and work through that, or use Codecademy’s Learn HTML and CSS interactive course. This should be something you are doing throughout the summer as you get more comfortable working with digital tools.
• Ford, Paul. “What is Code?”
• Glass, Grant. “The Black Box.”
• Marino, Mark. “Why We Must Read the Code.”
• Posner, Miriam. “How Did They Make That?”
• Van Strien, Daniel. “An Introduction to Version Control Using Github Desktop.“

Creating HTML and CSS Documents and Versioning with GitHub

1. Go to GitHub and create a new account if you need to.
2. Create a new repository. Call it whatever you want. Add a description if you want. Check Initialize this repository with a README. Click Create Repository.
3. Click Create new file and name it index.html
4. In the Edit tab, you will start coding your website. Use Miriam Posner’s tutorial for HTML to guide you. Make sure you are including the following tags and close them appropriately:
   1. HTML
      1. HEAD
         1. TITLE
      2. BODY
         1. H1 (heading 1)
         2. P (paragraph)
         3. A (link)
5. When you are done entering your code, click Preview, then Commit new file.
6. Find an image on your computer, or download one from the Internet. Name it something easy to remember.
7. Back on the Code tab, click on Upload new file and drag your image to the box. Click Commit changes.
8. Click on your index.html file and click on the Pencil icon (to edit)
9. Add an IMG (image) tag to your index.html file that points to the image file you added.
10. Click on Preview changes and see how it changed! In the Update field, put notes indicating you added an image tag. Click Commit changes.
11. Click Clone or download, then Download ZIP. Save the file to your computer. Open the .zip file, and open the folder that says REPONAME-master. Keep this folder open.
12. Open up another File Explorer window and go to your H:\ drive, and then open the public_html folder in your shared drive. This folder acts as a very basic web server, much like a very simple version of Sites, without the extra applications and code.
13. Copy the index.html and image file to the public_html folder.
14. Go to http://public.gettysburg.edu/~GETTYSBURGUSERNAME to see your web page!
15. Go back to GitHub and click Create a new file. Name it style.css
16. Add some CSS to change the background color of your page and change the color of some of your text, again using Miriam Posner’s tutorial for HTML to guide you. When done, click Preview, then Commit new file.
17. Copy and paste the line <link rel=”stylesheet” href=”style.css”> to your index.html file inside of the HEAD tags, and Commit changes. Make sure to put in the Update field that you added a link to your stylesheet. This tells your index.html file that you have a separate file on your server that has CSS information.
18. Download the .zip file again, and copy both the index.html and style.css files to your public_html folder on your H:/ drive. Refresh the page, and see what’s different!

Questions

1. How does using a program like GitHub help you track the changes in your code? How does it help other people?
2. For this project, you didn’t document your code internally, that is, include comments in it, but you did add descriptions when you updated your files in GitHub. How does documenting your code help others learn from it?
3. Code is by nature logical and hierarchical; it has to be structured in such a way that it can be interpreted by a machine. Given that, how can be critical about code? Is it possible to be critical about code in a way similar to literary/historical criticism?

Opening Up the Black Box

1. Find a digital project to check out. You can choose from the projects on the DSSF17 website, or from somewhere else.
2. Look around the site. Check for things that look familiar. Some sites that use tools like WordPress, Scalar, Omeka, etc. have similar user experience.
   1. WordPress – look for links that start with WP-
   2. Omeka – look for Items, Collections, Exhibits
   3. Scalar – look for Paths, Pages, Media, Tags, Annotations
   4. Watermarks – normally small links at the bottom of tools, similar to advertisements
3. See if there is an About page or other page that documents how the site was built, or contact information.
4. Right-click on the page and select the View Source Code menu option. This gives you the HTML code that the browser displays. Check for words or phrases that might give away different tools the site uses. Many times, you will see these in links that are enclosed in LINK and SCRIPT tags in the HEAD section (and sometimes at the very end of the page). Try copying different things into Google to see what comes up. This may be especially useful if you see links that end in .js, which indicates a JavaScript. JavaScript is a web coding language that is used with HTML and CSS to design and render webpages. It is not a tool in of itself, but it is used to create a lot of tools. You can also use tools like Wappalyzer to check to see what is being used, but these aren’t always useful (but can be a good place to start).
5. Compare two different sites that annotate an image. One uses micr.io, a JavaScript library. The other uses StorymapJS, which is in turn an enhanced version of LeafletJS.
   1. https://tuinderlusten-jheronimusbosch.ntr.nl/en
   2. https://storymap.knightlab.com/examples/bosch-garden/
6. See if the digital tools you’ve found are open source or not; some indicators are if there are GitHub pages for the tools, Creative Commons licenses, etc. You may have to do some Google searching to figure this out.

Questions

1. What site/project did you check out? Did you figure out what tools the site was built with?
2. Did your site have an About page or other documentation? How detailed was it? Was there a way to contact the creators of the project?
3. Did you see comments in the source code?
4. What would have made your site easier to understand from a technical perspective?
5. Did any of your projects use open source tools?
6. Did your projects look like they were build by professional developers? How did they compare to projects that likely did not have any professional coding support?
7. How does prying the top off the black box help you understand how to document your own project?