Digital Collections


This program for the ISU vs. University of Minnesota football game, held on October 24, 1896, has seen better days. After being used as a scorecard, presumably by a fan who attended the game, rolled up (possibly by the same nervous fan), nibbled on by insects, and hastily put back together with two separate campaigns of pressure-sensitive tape, this object has finally arrived at the Preservation Lab for treatment prior to digitization.

RS24_6_0_5_B1_f1_1896_BT_bk_cover

Back cover with notations

The treatment involves removing the tape holding the covers and leaves together and then reassembling the fragments and mending with tissue and wheat starch paste. The tape removal has been tricky so far, accounting for the majority of the treatment hours. Since there are two different types of tape, the ideal method for removing the carrier and reducing the adhesive residue has to be found separately for each kind.

Football_Program2_tape_removal

Removing the plastic tape carrier with a heated spatula.

The plastic carrier is removed using heat (or peeled straight off, if the adhesive is degraded enough), and then the remaining adhesive is removed from the surface of the paper using a combination of erasers, heat, and mechanical reduction using a scalpel blade. In some cases, the staining from the tape adhesive can be removed with solvents. For this archival object, however, the aesthetic outcome of the treatment is less important than the physical stabilization, and the staining will be left untreated.

Football_Program3_Emilie

Emilie working on a few pages at a time

It was hoped that the booklet could be reassembled after mending, but it appears the individual leaves are too fragile for that level of manipulation and will be individually encapsulated in polyester sleeves.

RS24_6_0_5_b1_f1_1896_AT_enclosure

Encapsulated pages in a 4-flap enclosure

This program is one of hundreds in the University Archives’ ISU Dept. of Athletics Football collection that have been digitized for public viewing online. Early films of ISU football games will be showcased at a tailgating event, hosted by Special Collections and University Archives at the November 11th football game with Oklahoma State. Visitors to the library’s tent will be able to view objects from the collections, such as football programs from years past, banners, buttons, commemorative beanie hats and early photographs and learn more about the history of the University and the Athletic Department.

Football_Program1_mending

During treatment: group photo of the 1896 team from the football program

Cyclone-football-team-1895

From the University Archives: image of the 1895 football team

 

Advertisements

In 2016 the Iowa State University Library completed a six-year project to digitize an entire run of the campus yearbook, The Bomb. Comprised of nearly 45,000 pages, the digital versions are not easily searchable due to the wide variety of fonts and graphic elements used throughout the decades. Just look at the text from one page of the 1911 Bomb. The font and layout are unique, making the automated transcription process nearly impossible.

LD2548-Io9b-1911-012

(“Bomb 1911”, page 9)

With that in mind, in its inaugural “Unsolved Histories” Project the Iowa State Digital Initiatives Unit has launched a crowd sourcing transcription project entitled, “Transcribed the Bomb.” It is our hope that by transcribing these yearbooks a wider audience can explore and find memories of themselves, their families and friends, favorite campus moments, and world events through the Iowa State University lens. Here is how YOU can get started:

  1. Navigate to the following website: (http://yearbook.lib.iastate.edu/) You will arrive to a page that looks like this:bomb1
  2. There are two ways to start contributing. You can either click “Sign-in” to create a profile or you contribute anonymous by just clicking “start.”
  3. If you chose to make a profile you will need to navigate back to this page and click “start.”
  4. A year of the “Bomb” will appear, after clicking “contribute now” and you will be able to begin the transcription process!!!

bomb2

5. Once you start contributing you will be asked two questions before you are able to transcribe a page. The questions include: a) Is the page black? (If the page is blank, it will be skipped and you will be taken to the next page.) b) Does this page have text? (This meaning text, images with text, tables, page numbers, etc.)

6. Then you can begin transcribing!! Here are a few tips for transcribing:

  • Transcribe exactly what you see
  • Use [Image(s)] to indicate if there is image or images
  • Hand-drawn or illustrations should be treated as text rather than images
  • Transcribe captions or image titles
  • Do not transcribe text found on clothing, pennants, sings, or other sources within the image.

bomb(5)

(Here is a view of the transcription Page)

7.Once completed you can review the text and then submit the page

8.Repeat the steps to transcribe more ISU moments!

If you need more help you can find an interactive tutorial, examples and printable instructions on the ISU Library Guide Page: http://instr.iastate.libguides.com/transcribe or feel free to contact us at any time at: digital@iastate.edu.

Good luck and happy transcribing!!

Two months ago, I posted in this space about moving the Digital Collection pages over to Drupal. The pages have all been moved over now, and they are live (http://digitalcollections.lib.iastate.edu/.) In this post, I’m going to dive deeper into Drupal and explain one of the things I really like about using Drupal: the Page Tree.  When you use the Page Tree, page names become very easily identifiable. No more: .html pages. Now pages simply end with: [page name here]. The page tree method allows logical, and easy to understand organization. There are a few items to keep in mind, and I’ll explain those as we proceed.

Say you’re on Carver’s page. That URL is:

http://digitalcollections.lib.iastate.edu/george-washington-carver

All subsequent pages associated with carver will end like this:

[carver URL]/biography

[carver URL]/resources

[carver URL]/magazine-and-journal-articles

I could have gone inside the page and drilled down further. For example, I could have had the links on the resources pages link off of the resources page. (Which would look like: /resources/magazine-and-journal-articles, signifying that it was located off the resources page, but I didn’t do that for this site.)

Here is an example of what a page tree looks like:

pagetree.jpg

Notice on the page tree page, there is a list underneath the Tree icon (Home,) and then each little white triangle turns black when you open it, and shows the pages associated with it below. folder2.jpgicons (looks like a folder,) represent actual pages, where the  link2.jpg  icon (looks like a piece of chain,) represents a link. When the selected page is highlighted (here in blue,) the Page Properties are indicated for that page. Notice that the page tree pages/links are in red. Not all page trees have links this color. After the styles were added, these link turned from default black to red. I’ll have to see what happens with the links on the Special Collection as I start to style them.

I really like the Page Properties; it gives a lot of good, self-explanatory information.  Right from this window, you can Change Settings; Make a New page/link (which will become associated with this page;) Edit the page/link; Change Permissions (I strongly recommend NOT doing anything with this, unless directed by the IT department;) View the page/link; Trash the page/link. Let’s click on the Change button.

pagetree.jpg

On Page Properties Change page, you can change the Visibility of the page, Nav Title, and Path. Save or Cancel, when done. Now, I am going to tell you about some things I learned when using the Nav Title/Path boxes. Say you have a title that goes like this: Pascal’s Photos & More. This is what the page tree path will appear as: pascal-s-photos—more. [Ed. Note: it will look like three dashes after photos, not one long dash.] Notice that Drupal takes out the apostrophe and “&” and replaces it with “-“. This is important to remember. It doesn’t mean you can’t have the page title be Pascal’s Photos & More, only that you will need to go into the path and manual change it to pascals-photos-more. You can take out the extra dashes and the path will still work. This is where the Change page of the Page Properties really become useful. The Visibility box is useful as well. Checking it off makes the become “invisible” to the public. You can still “see” the page, when you are logged in, under the Page Tree. And if you have that page linked on other Drupal pages, it will still be linked for use. This comes in handy when you have a lot of pages and you only want some to show when the menu is displayed. Here is an example of an invisible page in the page tree:

extension.jpg

The link is grey, and italicized, to indicate invisibility.

OK, let’s click Cancel on the Page Properties page to back up. There is one more feature I will share today in Drupal that is handy in a pinch. (And goodness knows, I’ve been in a pinch once or twice…or, well, never mind.) When logged in to make changes on the Drupal pages, there are few tabs across the top of each page.

pagetreeedit2.jpg

View, Edit, Revisions, Permissions, Drafts. Let’s look quickly at Revisions.

revisions.jpg

What a wonderful feature. A real lifesaver, believe you, me! If you goof-up on a page you can easily go back in time and select the revision you need, whether a minute ago, or last week. This is a nice way to work, and fairly worry free. That makes working with Drupal pretty fool-proof. Which is why so many people are able to use Drupal without much training at all.

So, remember back to May 19 of this year when I began talking about creating templates in Dreamweaver, and again on July 21, when I blogged part two of that series? And also remember how I drone on about technology always changing?

Well…. Throw those two blogs out the window and digest this: I am no longer using Dreamweaver to make our webpages. Our library has moved to Drupal for content-based webpages. And in doing so, I needed to learn it quick. Now, granted, I was given a great deal of leeway as to when to implement this for our pages. I could wait a year. But I had my own agenda. Not only did I need to move Digital Collection pages over, but also Special Collection pages. And I set my timeline to be the end of 2015. Well…why not?

Let me take this blog space to begin talking about Drupal, and my first impressions.

First, the benefit for the library is that more departments are allowed to contribute their own content, instead of having someone from IT doing it, thereby causing a delay in getting the information up to researchers. Because Digital Collections and Special Collections has been creating their own pages for several years now, we were made the testing team to see if we could get this done, and how long it would take. (We meaning: me. I have all but taken over maintaining the Special Collection pages. Brad Kuennen has taken on more responsibilities, leaving most of the fun work to me. Yea ME!)

But back to self-authoring. This is a good thing for a large portion of library departments. Allowing each department to design and implement their pages grants those departments to update their information on the fly and this pretty awesome too.

Plus, to have “templates” in place helps to maintain the overall layout theme of the university. In having a consistent design, every page of the university appears more uniform. Then there is the concept of responsive design. I myself have had issues with this very thing in the past. This is where Drupal comes in and does the heavy lifting. Once you’ve created a page, it automatically makes it responsive. In other words, whether displayed on desktop or mobile device, or tablet, the page will be displayed in the best possible manner. The image(s) will shrink down to the appropriate size and what is called a hamburger will appear (typically in the upper left or right hand corner of the page,) for the drop-down menu.

Home_hbgr

(This is what a “hamburger” looks like on a sized-down, (read: mobile) responsive page. It squishes a menu down into the three horizontal line icon; when you tap on it, it drops the menu down; again, it usually appears on mobile-designed pages.)

So, what does that mean for designing pages going forward then? Well, a lot of things. First of all, because our library has a great library-external, but on-campus, support from the ITUIS department, I don’t have to worry about consistency across web browsers as I had to in the past. The ITUIS department has worked those issues out with Drupal already. We don’t have to re-invent the wheel here; they follow ISU template guidelines and work from there. Thankfully, because Digital Collections and Special Collections are on a separate server, this allows us to maintain our sites separately, which in turn gives us even greater control over the design and layout of our pages. But what does that really mean? There are differences; let’s take a look.

Here’s our old page on desktop, created in Dreamweaver:

Home_old2

And here’s the new, created in Drupal:

Home_new

The first obvious difference is the spacing in the vertical menu on the left. Drupal doesn’t allow close spacing (at least on the theme that ISU maintains.) The slider image is wider, but height is narrower; and the dark boxes are no longer as clearly separated (no white line between them.) These images are both pretty similar on tablets; the only difference being that for Drupal, the menu runs a little longer down the side, and the boxes on bottom are clearly separated:

Home_tab_ls

BUT, take a look at the portrait view layout on a tablet.

Old Home (Dreamweaver) on mobile and tablet, portrait view:

Home_mobile_old

(In portrait, you just get a piece of the image, as it is a fixed layout. This is a desktop view of mobile device. An actually mobile device would cut off the top of the second box; but the layout is identical.)

New Home (Drupal) on tablet, portrait view:

Home_tab_port

(A lot better separation here, plus no cut-off of images.

And New Home (Drupal) on mobile:

Home_mobile

The point is Drupal makes designing responsive pages pretty easy. The most intensive part was copy and pasting the pages over from Dreamweaver, and constantly contacting the ITUIS department to get the styles displaying correctly. I’m glad I started with the smaller Digital Collection site however, because when we attempted to make the new pages go live, everything was defaulting to a wrong URL link. First, we thought we were going to need to manually re-mapped all the pages to the new pages, so that old URLs would bounce to the new page URL. Now, ITUIS has stepped in and indicated they will be able to solve this issue using another tool. We will have to monitor this unfolding drama and we will have to think it through for the larger Special Collection pages.

This post is a follow-up to Adventures in Making Templates: Part I.

In previous posts, I’ve discussed the history of our digital webpages, and the issues I had creating my first templates. I also discussed how to create an initial template page. Now, let’s turn to creating a new page using a template and additional points to keep in mind. To create a new page using a template:

  1. Open Dreamweaver, if not already opened. [I use Dreamweaver CS6.]
  1. To create a page from a template: File—>New… —>Select Page From Template, then navigate to the template page you created.

boutiquePage

Click Create button.

You will notice all your “locked in” code — code that will stay consistent on all pages — is grayed out. You will not be able to edit this area at all on this page. Go on. Try it. Select a section and try to delete it. Can’t. Be. Done. You can select it; but you can’t edit it in any way. However, the areas that are shown in blue or black text are editable areas. So, at the top, you see where I can change my meta content and name, plus page title.

boutiquePage_1

You also have to be aware that not all areas are obvious as being editable. This is where you need to be aware of your code.

This whole area marked in gray (highlighted here, with text below image) is actually editable space:

boutiquePage_2

<!– InstanceBeginEditable name=”additional styles go here” –>

 

<!–<link rel=”stylesheet” type=”text/css” href=”../cdm/css/reset.css”>–>

 

<!–additional style types go here–>

 

<!–additional css links go here–>

 

<!– InstanceEndEditable –>

 

Below is an example of code that I placed inside one of these areas:

boutiquePage_3

Notice that you can put css code, javascript; and css links within this area. This is nice to have, because some pages need additional coding that allows for variances on theme. (As I mentioned in Part I: some of our pages have elements that are unique to each page.)

Further on down the page is the space for the inside content, followed by the non-editable footer.

boutiquePage_4

It’s pretty easy to go from there. Once you have the page created, save with the actual name you plan to use and you’re set!

Here’s a comparison between our old (non-template) page on the left, and new page (created with template) on the right:

boutique_OLD-FINAL-Comparison

As you can see, there are subtle differences between the old and new pages. Here’s another example of a longer page:

boutique_bottom_1-2_comparison

One of my main issues without using a template was the variety of space between the end of text and the footer. This was a browser issues: some browsers played nice, and others didn’t. Using a template took this issue away. Our pages are now consistent whatever browser one chooses.  Having the template also made it easier for me to add elements that were lacking on every page, like the social media icons.

Templates are great when you have several pages to maintain that all have the same basic layout. They are not for all sites/layouts, but work well for web masters who have many pages with certain elements that need regular updates. I’ve had templates on my radar since I first started working on my pages. I am glad I finally learned how to create them. You may find them useful too.

The first agricultural engineering department in the world was started at Iowa State in 1905.  It’s now called the Department of Agricultural and Biosystems Engineering.  Jay Brownlee Davidson was a professor at Iowa State and is considered to be the “Father of Agricultural Engineering.”  Our archives has a lot of material from J.B. Davidson and we’ve digitized some of it to be available online in our Digital Collections:  http://www.add.lib.iastate.edu/preserv/cdm/agengineering.html

ag eng

Digital photographs were taken of entire scrapbooks that J.B. Davidson created from his trips to China and Europe.  In addition to the many photographs included in the scrapbooks, we also scanned many photographs from the early days of agricultural engineering at Iowa State.  We also have a link to our Digital Repository which has J.B. Davidson’s “Introducing Agricultural Engineering in China” from 1949.  With the variety of materials included in our Digital Collections we’ve tried to give people a look at some of the more visually interesting items in our collections and the Digital Repository includes the more scholarly works. This start could lead a curious researcher to find much more by visiting our archives.

So, to recap to my previous adventure: I had just learned how to make sticky footers that worked with our pages. I maintain many pages (34, plus a home page) for our website, and they are not all the same length. We have boutique pages. We have thumbnail pages. We have boutique pages with a little image vs. big image at the top. We have thumbnail pages that are short vs. ones that are long. We have a page that has secret embedded code so if you know the super-secret key combination, an elephant will appear in a pink tutu and dance a jig. (OK, well, maybe we don’t have that last one… but wouldn’t it be fun?) The thing is, we have a lot of pages that all basically have the same wraparound: the header, the menu, the footer is all the same. It’s the “inside,” and the length of the inside that’s different from page to page.

But let me step back a moment and give you some history. Here is what our pages looked like a few months ago:

boutique_OLD

You can see we had a vertical header across the top, along with a vertical menu. Then on the left side, we had a horizontal menu, with links that go to our pages within the site. The footer followed below, with social media icons below that and to the right. The primary reason I wanted to move to templates is that updating 34+ pages individually can be overwhelming at times, even if all you’re doing is copying and pasting. I thought knowing how to create templates might make it easier to maintain the pages.

I got my first chance when I was working on re-designing the Special Collections web pages; all their pages are template-centric. I thought it should be pretty easy to figure out. It would be how I usually figure things out: a combination of Firebug and reserve engineering; but digging through code, I had an issue with wrapping my brain around how to write the thing. That was frustrating!

I went back to my old standby of research; studying; reading. Looking at a made template can be quite confusing. It doesn’t seem logical that it could work. And indeed, my first few attempts were ugly. I’m even embarrassed to say that I might have accidentally messed up the main Special Collections’ old template in trying to figure out how to get the templates to create correct layouts.

One Friday afternoon, I was so frustrated, that I decided to leave work early and have some “me” days. My son, Ian, and I just bummed around all afternoon, had take-out chinese food, (my fortune was: “Now is a good time to finish up old business,”) and I just generally acted juvenile all weekend. That made all the difference in the world. When I got to work, I pulled out the fortune, placed it right beside my monitor and wrote the code for my first template. (Just goes to show, “me” days can be worth their weight in gold.) Here are the things I learned with that first template I created:

  1. Open Dreamweaver, if not open already. I use Dreamweaver CS6.
  1. Create and design a html page: File—>New…—>Blank Template. Select HTML template. I just selected <none> for Layout style, but the choice is up to you.

blank_template

Click Create button.

This is what a blank DW template doc looks like.

BT_inside

  1. There are certain areas that you will want to leave blank in order for you to change for each page you are creating. For example the name: Don’t change that. Keep in mind, that everything “inside” the

<!– TemplateBeginEditable name=”doctitle” –>

<!– TemplateEndEditable –>

will stay editable. Everything outside of that section will be locked into the template. So, everything that you want to stay the same in every document MUST BE OUTSIDE THE GREEN <!— Template…Editable  —> sections. I cannot stress this enough. This is a very important point to remember.

  1. Add additional <!— Template…Editable —> sections as needed. Don’t be shy creating these sections, but don’t go cray cray either. I added one for additional styles and another one for my inside details, and third one for stat counter code at the bottom of the page. (I used the auto generated head section for my Google Analytics stats, but I also keep stats through StatCounter, and that requires different code for each page.) So, I created three additional <!— Template…Editable —> sections. The ones I listed are probably the most you really need to add. Remember, you only need these sections for code/html that you want to be able to change individually on pages, not universally.

From this point on, just create the page like you would create a normal html page, with css documents; javascript; and html.

When you go to name your template page, use a name that anyone can clearly understand. I named mine boutiquePage. The page will save with a .dwt. This is the page you will open up and edit when you want universal changes across all your template-based pages.

For example, if you have a menu that needs updating, open up this document and make the changes here; once you have saved the document, a dialog box will appear:

update_template

Click Update button.

Another dialog box will pop up and give you an update.

update_template_2

Click Done or Close button (which ever one applies,) to dismiss the dialog box. Old documents tied to this template (and new ones created after,) will now contain this update.

If you go into a document connected to the template, you can see (via the greyed out text,) that the information has been updated:

update_template_3

Further, you can check in Preview to see the live view:

update_template_4

Once you have made the change to the template, and saved/updated the other documents, you will need to upload all affected pages again to your server.

We’ll explore making new documents and changing certain elements with those new documents for my next blog, slated for July 21, 2015. Until then, happy coding, and may HTML forever be in your favor.

Next Page »