Skip to content

Lesson 03 – September 5, 2017

How Lo(fi) Should We Go?

Texts to have read:

Work to have done:

  • A registered GitHub account, with a completed "Hello World" tutorial
  • A brief reflection posted to the blog under the "reflections" category
  • Post three images that we can start remixing

Believing and Doubting Stolley (10-15 min)

Thanks for your reflections! I've seen those that came in by midnight or so.
Quick favor to me: if you haven't yet done so, please add a category to your post; it helps me justify using WordPress in light of the Voice of Karl Stolley in my head that tells me it's massive overkill for what I need and will trap me in software updates forever. In his words:

Ask someone why they chose a particular technology for a project, and you will often find one little feature driving the decision. It’s astounding, for example, to discover that people choose to set up WordPress to run a small website simply because they wanted a way to repeat the navigation across the four or five pages that made up the site. For that one feature, they pay the tax of securing a database connection and applying software updates for the life of the project, lest the infamous pharma hack or one of its many variants compromise the site. Had such a small site been built with basic HTML, or a static site generator like Jekyll or Wintersmith, no updates beyond those routine to the web server itself would likely be needed.

Ugh, it's like a dagger to the heart! Anyway, here's my plan for this section:

  • Brief spiel on believing and doubting (Elbow)
  • If we play the believing game with Stolley, what's the takeaway?
  • If we play the doubting game with Stolley, what's the takeaway?
  • What questions do you have?
  • EXT: Did anyone notice the little link at the top to the Readme page? How, if at all, does that page change your sense of the article?
  • EXT: Let's think about genre and audience for a moment. This was published in the same venue as Sorapure's Flash-or-PDF piece about the Five Principles of New Media: the online-only academic journal Kairos: A Journal of Rhetoric, Technology, and Pedagogy.

Is version-control just for code?

  • Let's have a look at Stolley's revision history.
  • Despite what you may read in some old websites (a reminder that Google is not always an infallible source of up-to-date information), GitHub can handle images – and even show differences between versions. However, this is only true of "lo-fi" individual image files – not "hi-fi" project files that contain multitudes of images within them.
  • Side note: some of you may be interested in

Studio time: Practice with GIMP / Photoshop (30 min)

As you might imagine, this is one of those hi-fi tools that Stolley was talking about: the GUI interface that "hides" what's going on behind the curtain, the complicated array of buttons that will probably change every time there's a new version.

I'm not interested in your mastering this particular piece of software. What I'm after, instead, is the kind of things it can do, wants to do, makes easy to do – that is, what actions the tool affords.

  1. Pick a few images to work with from the galleries below, and download them to a scratch space.
  2. Open GIMP (or Photoshop, if GIMP isn't here yet) and File > Import as Layers
  3. Play around with layers and selections to get a sense of what it can do
    • ALT:if you're already familiar with image editing tools, have some fun with your files! Show off to or give guidance to your classmates!
  4. Have a look at your revision history. In what ways is this like what Git lets you do? In what ways is it different? Can you think of any ways to combine the two?
  5. When you've had a chance to play around for a while,
    • save the project to your Box/Dropbox/Drive, and
    • export the image as a .png file.

For more on image file formats, try a search for the options you're curious about – there's lots on wikipedia, e.g. – or start with the top two results on this Stack Overflow thread: "What is the difference between “JPG” / “JPEG” / “PNG” / “BMP” / “GIF” / “TIFF” Image?"


I'm further taking advantage of the affordances of WordPress and dynamically querying the database to pull out every image within the three Asset categories we've assigned so far. When you add a new image, the galleries will update. (And, because this gallery type likes to make one image more prominent than the others, I've told it to randomize: every time you refresh or revisit the page, it'll have a different image in the featured slot.)


Studio Time: Working with Git / GitHub

I want to suggest that you commit your changes to the image files you're working on, both to get comfortable working with the system, and to get you into the habit of saving a commit message every so often. (So much better than just hitting save and overwriting your previous iteration, and having no idea when you come back to it, two days or two weeks or even two months later, what you were actually working on.)

BUT I'm not sure if these lab computers have Git installed, or if they'll let you install it if they don't. SO if you have your own computer, by all means proceed!

Here's a super-quick installation overview (posted using GitHub's "gist" system for publishing quick one-page snippets).

Alternately, you can download the GitHub desktop application, which, despite Gabi's legitimate concern that we get over any fears of the command line, is actually quite handy for partial-file commits and intuitive diff views. Yeah, it can't do everything; it can get you more comfortable with the flow, so you know what commands to want to give in the command line.

If all else fails, you can use the GUI on the GitHub website to create a new repository ("repo") and upload files to it, with commit messages. This approach has limits: for one, it's a lot harder to wrap several file changes in a single commit.

I'll float around and see where I can be helpful!

EXT: there's always the option, in a studio class, to start on the homework.

Homework for Next Time

  • Administrative
    1. If you haven't yet, please fill out the Tech Comfort Survey.
    2. If you have filled out the survey, please schedule a conference with me at your convenience.
    3. Install GIMP on a machine that you're likely to use at home
  • Inputs
    1. Read pages 63-76 in Writer/Designer, which is part of chapter 4. It deals with "Ethics of Collecting Sources and Assets."
    2. Read quickly through the Stanford library's website on Copyright and Fair Use, paying particular attention to the section on Measuring Fair Use: the Four Factors and anything else that seems especially pertinent to you.
    3. EXT: Watch an introductory tutorial on GIMP if you want something extra to help you get oriented. There's a Lynda tutorial called "GIMP Essential Training" that covers a lot (it's like 5 hours long), but starts with a 5 minute intro to the interface.
    • You can access Lynda tutorials through; look for the link in the sidebar. lynda link, screenshot from my.pitt sidebar
  • Outputs
    1. Consider: where did you find the images you posted for lesson 3? Are you able to get back to them easily? Did you embed any citation information when you posted them to our website? Do you have permission to reuse or modify these images?
    2. Update or change the info in our media library, as necessary. (Go to the dashboard, then Media, then Library, and use the filters to navigate.)
    3. Write any questions you have so far – about any of our readings, but perhaps especially about ethical sourcing – and post them to our blog under the Reflections category.

1 thought on “Lesson 03 – September 5, 2017

  1. gabikeane

    Discussion of Stolley and Github:
    -if you understand lo-fi, your use of hi-fi tools will be more effective
    -lo-fi makes collaboration makes it easier
    -a journal of your work
    -looking at Stolley's file history: techy, cutesy, and writing revisions. Uses a hi-fi program like Evernote, why?
    -examples of hi-fi things: WordPress, but that's relative. Use the simplest thing possible, and only complicate from there (maybe)
    -#2: expression should not be trapped by production technologies (ie the HTML that WordPress makes is not as human readable as a lo-fi production of a site might be)

    -Can we redefine what lo-fi and hi-fi are?
    + Fi=fidelity. How close are you to the real thing? (based on audio)
    + in context, not beautiful, rich, user experience based GUI (graphical user interface)
    + history of how computers work: punch cards to punch tape (basis for binary), then compilers come later (writing human readable code and then translating it into binary)
    + as we move into GUIs, we abstract away from the machine itself
    + think about this in the context of Automation from Sorapure. This is good and useful, but Stolley wants us to understand and give consent about our content
    + GUIs open up a whole new era of publishing and self-publishing (but sometimes you are the product)

    + is Stolley talking about code usually?
    + I don't know code, but....
    + Is version control limited to text?
    - No, but is it better for text? Comparison and changes are more useful and accessible.
    - Comparison will not be as clear with non-code and non-plain text files, but you still get your commit messages and previous versions
    - Github will allow you side by side, swipe, and sometimes difference modes in some browsers. Still quite a bit of functionality!
    - Github is great for backing up files

Comments are closed.