Web Design for Literary Theorists I: Introduction to HTML
Upcoming SlideShare
Loading in...5
×
 

Web Design for Literary Theorists I: Introduction to HTML

on

  • 320 views

First in a series of workshops for graduate students in the Department of English at UC Santa Barbara. ...

First in a series of workshops for graduate students in the Department of English at UC Santa Barbara.

More information: http://patrickbrianmooney.nfshost.com/~patrick/ta/lead-ta/web-design/

YouTube screencast with audio: http://youtu.be/7Sv0LLGgi9A

Statistics

Views

Total Views
320
Views on SlideShare
320
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Web Design for Literary Theorists I: Introduction to HTML Web Design for Literary Theorists I: Introduction to HTML Presentation Transcript

  • Introduction to Web Design For Literary Theorists First Workshop: An Introduction to (X)HTML 11 April 2014 Patrick Mooney Co-Lead TA, 2013-2015 Department of English UC Santa Barbara
  • Objectives for this workshop series ● To learn the basic skills involved in building a small website for a course or section. ● To actually build such a web site, and to do a good job of it. ● To engage in practices that minimize the labor required to do so. ● To make your teaching practices more visible on the web. ● To be able to read various versions of HTML in other places on the web.
  • Objectives for today’s workshop ● To learn the basics of HTML, the standard markup language for web content. ● To understand the assumptions that HTML makes about your content, and to leverage those assumptions to produce a web site that is attractive and easily “parsed” by a viewer. ● To engage in practices that will allow you to participate effectively in the later workshops in this series. ● To begin actually constructing a static section website. View slide
  • Details, details ... ● I’m going to be moving over a lot of details rather quickly today. ● You don’t need to memorize them all. – There are great references on the web, of course. – This presentation will be online in a few days. – What’s important is that you pick up major concepts and work along with them. – Come talk to me in my Lead TA office hours if you have questions! ● A collection of useful links is online at http://is.gd/todoho. View slide
  • Why have a course/section website? ● Section websites give your students a central place to look for information. – Handouts. – Notes and announcements. – Policy documents. ● Helps to make your teaching practices easily visible on the web. ● Helps to establish an identity for you on the web. – Helps to link your teaching practices to your online identity. – One of our recurring concerns throughout this series of workshops will be increasing the visibility of your web presence.
  • Why not just use some other service? ● Any choice you make for web presence management has some downsides. As with everything in life, no solution is ever perfect. ● Here are some downsides to building a web site by hand with HTML: – You have to learn HTML. (Not hard, especially for literary theorists.) – You have to see your content in a non-word- processing based way. (i.e., you have to think primarily about content and structure rather than presentation.) – You have to find someone to host the content. (Not difficult, nor necessarily expensive.)
  • Why not GauchoSpace? ● GauchoSpace imposes its own structure and presentation on your content. – In my personal opinion, GauchoSpace’s layout is horrible. – Many of you have interacted with students who have a hard time finding information on GauchoSpace. This is partly because GauchoSpace’s design is poorly thought out and does not leverage existing web-based information-seeking practices. ● GauchoSpace is access-controlled. – Your teaching practices are only visible to people enrolled in the course, and only while they are enrolled in the course.
  • Why not some free blogging service? ● Free blogging services tie your content to a particular provider. – You can’t easily move your website from, say, Tumblr to WordPress without re-doing a lot of work. ● All free blogging services restrict what you can actually do with your HTML code. – This is a bad thing for reasons I won’t fully explain until later in the quarter. ● Blogging services impose their own information ontology onto your content.
  • Why build a web site with HTML + CSS? ● It’s not that hard. ● You gain full control over how your text is presented. ● You gain full control over how your text is organized and ontologized. ● You can easily move your content elsewhere with a minimum of work if your content provider … – goes out of business – cancels the service you use – stops providing adequate service.
  • What you won’t learn in these workshops ● Everything about every version of HTML. ● Everything about producing cutting-edge designs. ● How to produce web sites with active content. ● More than a little bit about search-engine optimization. WHICH IS TO SAY … ● Some of the information you’ll get here is partial or moderately simplified (but it’s honest and, I think, sufficient). ● You’re not going to walk out of here with the skills to be a professional web designer. ● However, you will walk out of here knowing enough to present your content to your students – and the world – in a way that reflects positively on you.
  • How the Web Works: Quick Refresher ● You type an address (URL) into your browser’s address bar. ● Your browser interprets the address to discover which server (another computer on the Internet) holds the requested document (“web page”). ● The document is fetched from that server. ● Any supporting documents are also fetched and interpreted. ● Your browser interprets and displays (“renders”) the document in a way that is compliant with standards. ● The user then (hopefully) reads and/or otherwise
  • ● Your web site will consist of multiple HTML files and any other supporting documents. ● Any images (videos, audio, other media) that are needed for your web site are not part of the HTML file itself, but separate documents.
  • So, HTML ... ● stands for “Hypertext Markup Language.” ● is the standard way of describing the structure of textual documents on the web. – HTML is not a “programming language.” There are no commands. There are no variables. It just describes the structure of a text. ● does not give you complete control over every tiny aspect of how a document appears in the user’s browser. ● can be read and understood by every piece of software that deals with textual documents on the web. ● Is a standard administered and maintained by the World Wide Web Consortium (W3C).
  • Some HTML coding examples ● HTML consists of text marked up with tags that indicate the structure of the text that is being marked up. ● There are several dozen legitimate tags (many of which you will never use). Each begins with < (the less-than sign) and ends with > (the greater-than sign). ● Tags can have attributes (characteristics). Certain attributes for certain tags are mandatory. <img src="kitten.jpg" width="200" height="100">
  • Tags in your document ● Each tag that you open must be closed before the end of the document. ● Technically, tags should be closed in the reverse order in which they were opened. Correct: <i><b>Example</b></i> Incorrect: <i><b>Example</i></b> ● Some tags (those that are not containers for textual content) can be self-closed: <img src="kitten.jpg" width="200" height="100" />
  • A quick reminder ● The texts that you work with are already “marked up” in various ways – paragraphs, pagination, chapter divisions, emphasis, punctuation – are all (in a sense) paratextual elements that give you hermeneutic clues. – All you’re doing with your HTML markup is making (a certain set of) hermeneutic clues explicit. “Every page, even a blank page, even a page of George W. Bush’s ignorant and vapid prose, is n-dimensional.” — Jerome McGann, Radiant Textuality: Literature After the World Wide Web (p. 184; ch. 6)
  • A minimally acceptable XHTML document ● The <!DOCTYPE> declaration is (to you) a string of gibberish whose purpose is to tell the browser what flavor of HTML you’re using. ● The xmlns= attribute on the <html> tag tells XML parsers how to parse the HTML. ● You can just look up these values, or (even better) use existing documents as templates.
  • Some Useful Block-Level Tags <blockquote></blockquote> – you know what this does, right? <h1></h1> – marks a top-level heading <h2></h2> – marks a subheading <h6></h6> – marks a sub-sub-sub-sub- subheading <p></p> – marks up paragraphs <ul></ul> – unordered lists (bullet points) <ol></ol> – ordered lists (numbers, letters) <li></li> – a list item
  • Some Useful Inline Tags <abbr title="Modern Language Association">MLA</abbr> – an abbreviation <br /> – a line break. <cite></cite> – marks a citation. <code></code> – marks up computer code. <em></em> – marks text that is emphasized. <img src="a URL" alt="some text" /> – embeds an image. <strong></strong> – marks text that is very strongly emphasized. <q></q> – marks a quotation.
  • The <img> tag <img src="fakebeard.jpg" width="480" height="640" alt="a man with a fake beard" /> <img src="http://i.imgur.com/HndKeBY.jpg" width="480" height="640" alt="a man with a fake beard" /> ● The src attribute is the location (URL) of the image itself. ● The width and height attributes (measured in pixels) are hints to help the browser render the page without having to wait for the image to download. ● The (mandatory) alt attribute tells browsers for visually impaired users what to say instead of displaying the picture. ● Note that, because it’s not a container for text, the <img> tag is self-closed.
  • Some image considerations ● The fewer images you use, the more quickly your web page will render, because each image has to be fetched separately. – You can ameliorate the rendering delay by using the width and height attributes. ● Using a bunch of spurious damn images just because you feel like using a bunch of spurious damn images is often considered to be unprofessional, or at least poor design. – Keep the focus on what matters. ● Use the alt attribute to provide cues for visually impaired users.
  • Some image considerations ● Image file sizes will often be much larger than the size of the HTML document that refers to them. Hosting them elsewhere than on your own server can save you money. – However, if you’re using images that are hosted on a site other than your own, make very sure that that’s OK with the site from which you’re linking them. ● A rule of thumb: use the JPEG format for photographs, and PNG for line-drawings and other non-photographic images.
  • The <a> tag ● Creates links: <p><a href="http://gauchospace.ucsb.edu">GauchoSpace login page</a></p> ● Creates anchor points inside a document to which you can link: <a name="no-very-late-papers" /> <h2><a name="no-very-late-papers">Late paper policy</a></h2> ● A link to an anchor point: <p>Details are spelled out in my <a href="http://patrickbrianmooney.nfshost.com/~patrick/ta/s14/eng13 3so/section-guidelines.html#no-very-late-papers">late paper policy</a>.</p>
  • Different ways to specify URLs ● You can always specify a full URL any time a URL is required (with <a>, <img>, etc.). <a href="http://gauchospace.ucsb.edu">GauchoSpac e login page</a> <img src="http://i.imgur.com/HndKeBY.jpg" width="480" height="640" alt="a man with a fake beard" /> ● However, this is cumbersome if you have to do it all the time, so there are also ways to specify URLs relative to the URL of the document doing the specifying.
  • Partially specified URLs There are several possibilities, each relative to the URL of the document containing the partial URL. If the base URL of a document is, say, http://patrickbrianmooney.nfshost.com/~patrick/ta/index.html … ● Not specifying any folders: <img src="bulletpoint.png" /> means “the file ‘bulletpoint.png’ in the same folder as the document referring to it”: http://patrickbrianmooney.nfshost.com/~patrick/ta/bulletpoint.png
  • If the base URL of a document is, say, http://patrickbrianmooney.nfshost.com/~patrick/ta/index.html … ● In a sub-folder of the current folder: <a href="s14/eng133so/index.html"> means “the file ‘index.html’ in the folder ‘eng133so,’ which is in the folder ‘s14,’ which is in the current folder”: http://patrickbrianmooney.nfshost.com/~patrick/ta/s14/ eng133so/index.html – Note that the URL does not begin with a slash ● In the folder above the current folder: <a href="../personal.html"> means “the file ‘personal.html’ in the folder above the current folder”: http://patrickbrianmooney.nfshost.com/~patrick/personal.html
  • If the base URL of a document is, say, http://patrickbrianmooney.nfshost.com/~patrick/ta/index.html … ● Full path from the root (top-level) folder: <a href="/~patrick/personal.html"> means “the file ‘personal.html’ in the folder “~patrick,” which is in the top-level folder”: http://patrickbrianmooney.nfshost.com/~patrick/personal.html – Note that the URL does begin with a slash ● The fact that you can refer to other documents in these ways is a good reason to have a sensible file system layout that you can remember.
  • Tables for presenting information Begins the table Table heading A table row A table row Ends the table <table> <tr><th>Name</th><th>Grade</th></tr> <tr><td>John Smith</td><td>B+</td></tr> <tr><td>Ana Garcia</td><td>A-</td></tr> </table> ● A table consists of individual rows (and should have a header); each row contains individual table data “cells” (<td></td>). ● In the 90s, it was common to enclose entire documents in a table to control document layout. Don’t do this. Tables have a semantic meaning. Also, this interferes with screen readers.
  • Special characters in HTML documents ● Begin with an ampersand; end with a semicolon. – Replace reserved characters that have special meanings: &lt; means the less-than sign: < &gt; means the greater-than sign: > &amp; is the ampersand: & &quot; is the (non-smart) double-quote mark: " – Provide a convenient way to enter characters that you can’t easily type: &eacute; is a lower-case E with an acute accent: é &Eacute; is an upper-case E with acute accent: É &pound; is the British currency symbol: £ &copy; is the copyright sign: © – Case matters.
  • Tags you’ll see, but shouldn’t use <b></b> – bold text <big></big>, <small></small> – to change text size <blink></blink> – is primarily used to ensure that people hate you. <center></center> – for centering text <font></font> – for font size and face <i></i> – italic text <sub></sub>, <sup></sup> – subscript, superscript. <u></u> – underlined text
  • Good Semantic XHTML Practices (some are mandatory) ● Follows semantic rules and is formally valid. ● Tags and attributes are entirely in lowercase. ● Every tag is either self-closed or closed after the end of its content occurs. – Reminder: tags are closed in the reverse order in which they were opened. ● Attribute values are enclosed in quotation marks. ● Code is easily readable by you so that changes are not painful to make.
  • ● Because the rendering of HTML collapses whitespace (spaces, tabs, carriage returns), you can put in as many spaces (tabs, carriage returns) as you want to make your meaning and structure clear to yourself – without affecting how your document looks when the user’s browser renders it. ● Describes the structure of the text, rather than attempting to control appearance. – To put it another way, you should separate appearance from content. – We’ll talk in detail about controlling appearance at our next workshop.
  • Attributes for any tag ● <tag id="something"> – Attaches a unique ID to an individual tag for some purpose of your own. ● <tag class="something something_else"> – Indicates that the tag belongs to one or more groups that you yourself designate for some purpose of your own. ● <tag style="some valid styling information"> – This is a poor overall strategy for styling your text, for reasons we’ll talk about at our next meeting, but not a bad way to see quickly how things look.
  • Tags that do nothing (that’s visible) ● <span></span> – marks an inline group of text for some purpose of your own. <p>I thought that <span class="book-title">1Q84</span> was a very disappointing novel.</p> ● <div></div> – marks a block-level group of text for some purposes of your own. <div class="document-header"> <p>I was very disappointed by <cite>1Q84</cite>.</p> <p>However, I quite enjoyed <cite>Infinite Jest</cite>.</p> </div> ● We’ll talk about these extensively next time.
  • A few words about validity & standards compliance ● You can get away with writing bad HTML, and it may look OK when rendered. However: – Invalid HTML renders differently in different browsers. It’s also very hard for machines to parse in other ways. – HTML that is presentational rather than semantic involves vastly more effort to maintain. – Presentational, non-semantic HTML limits your ability to make your web pages intelligible to machines instead of people. ● Google search ● Screen readers for the visually impaired ● Other web applications …
  • Making sure it works ● Write good HTML in the first place. – Make it intelligible to you. – Semantic, not presentational. – Use a text editor that helps you to check validity with features like syntax highlighting. ● Check formal validity with the W3C’s validator. – You can also use it to clean up your code. ● Test on at least two different browsers. – Ideally, you should also test it on several devices: ● Your phone, different operating systems, etc.
  • Intro to web information ontology ● Don’t try to put everything on one page. Break information into multiple documents, each of which is … – More or less complete in itself. – Linked to other, related documents. ● And linked back to your home page. ● Use good journalistic writing practices. – Most important information first in any document. – Crucial information is “above the fold.” – Your semantic markup helps to show the structure of your document to the viewer.
  • ● Organize your files in a series of folders that makes sense to you and provides an epistemological indication in the folder path of how the information is categorized. – Remember that your folder path will become part of the URL when you upload your site. – Make each subfolder increasingly specific in some sense. ● Include an index.html file in each folder. – Generally, a good practice here is to make each index.html file a menu that provides an overview of what’s in that folder, or in the subfolders it contains.
  • A suggestion … ● You won’t really have learned anything today unless you apply these skills in the near future. – Take your existing section guidelines handout and produce an HTML version. – Start setting up a section website. You can take one of mine as a model, if you’d like. – Produce HTML versions of any other documents that you have the time and inclination to produce. – Run them through the W3C’s validator and resolve any problems. – Come talk to me in my office hours if you hit any snags!
  • Building a minimalist personal web site ● You should have a main page with a blurb about who you are, plus links to major other information on the site. (Having some color on it somewhere is often thought to be a good idea.) ● Good pages to have might include: – Web collections you’ve built for students. – Your CV. – Links to you on other places on the web. ● Linking back to your web page from your LinkedIn, Facebook, academia.edu, Twitter, Flickr, Google+, and other profiles is a smart move. – A “personal info” page (if done thoughtfully and tastefully).
  • Where we’re going next (or, let’s talk about scheduling) ● Our second workshop will introduce CSS, or Cascading Style Sheets. – This will serve as an introduction to how you control the presentation of semantically encoded HTML. – We will also talk about hosting your content once you have some content to host. – Week 5? Week 6? ● Our third workshop will present some additional, related topics: – Making your content meaningful to search engines and other text-parsing software. – Preventing search engines from indexing your content. – Google Scholar’s article-inclusion guidelines. – Week 9? Week 10?