Digital-Collections


I spend a lot of my time on the internet. It’s a part of my job; usually I’m creating pages, updating, or creating new collections. But lately, I’ve been spending even more time on the web doing research. Our department, Digital Initiatives, has gone through some transitional changes since the first of the year. The biggest one being that we have a new (or, rather: permanent), director: Kim Anderson. She has some cool ideas of how she wants our webpages set up. One idea, that she would like to see incorporated ASAP, is that she wants to have a layer over the top of our current page (http://digitalcollections.lib.iastate.edu/), that directs researchers to either our CONTENTdm boutiques/pages, or to other new pages/collections yet to be implemented. In addition, this main page will have, perhaps, the department’s pertinent information, (or links), as well: staff, tools used, mission statement. That sort of thing.

So, here I have been: looking through and finding similar pages that we may find inspiring for the eventual page layout that we create. I broke it down into two sections, both real-life examples: a “tools” page (which we’d like to create that shows our researchers what we used, both applications wise and equipment wise): and a new “Digital Initiatives” page. Sounds easy enough, right? Well, you know nothing is easy in Lori’s world. Nut .’N. Honey. No, it’s not. I can now understand why Kim wanted to sicced this little gem of a project on me. Not only isn’t there much out there, but as I have been doing this, I have found that, by and large, there really isn’t a “standard” when it comes to describing what we do, and how it’s managed.

It is hard to find separate pages within other academic libraries that demonstrate the importance of this distinction. Since our school is in the Big 12, I’ve looked at all those library sites in search of other Digital Initiatives departments. (Sadly, only schools that made my list where two schools no longer in our league.) I’ve looked at hundreds of “Digital Initiatives” links. In addition, I’ve looked at hundreds of additional general academic library sites. There are only about a good two handful of links that I care to share with our director. Fifteen to be exact. The rest either consolidate it in with another departments, (Digital Repositories; Special Collections; IT;) or don’t even get mentioned at all. And of the ones I have listed, even some of those are a part of these other departments. One university listed their digital collections as a part of their “slides” collections. Sometimes, they have a link to Digital Initiatives and that link sends the researcher to a CONTENTdm collections page. It was just like they were setting these pages up to be a regular library web page. Digital Collections are like exhibit pages. (We call our main collection pages, like: http://digitalcollections.lib.iastate.edu/charles-christopher-parry, boutiques.) I honestly believe that the most innovative digital exhibits are the ones that are easy to navigate; merge well with the items they are showcasing; and make learning fun and informative.

This reminds me of a true work event that I was involved in back in my Tribune days. The paper there had the foresight to see “digital” papers were the coming thing. However, they didn’t have the foresight to involve enough knowledgable persons about the layout of such a site. They didn’t go to one of the composition designers to ask advice. Goodness knows, a designer would have a better understanding of layout. But no…they went to one of their coders who had a general idea of what webpages should look like, and had happened to take one class on web coding at college several years previous. In hindsight, if they noticed this at all, they would have been wiser to have had a collaboration between the coder and a designer. The web pages turned out to look very basic and were very un-intuitive about navigation. Long story short: yeah, email could take you to the webpage for the Tribune, but navigating to pages off the “cover” was a nightmare. The sections navigation made no sense and sometimes one had to jump through several pages to get to the article. I felt sorry for the coder. Person was doing the best they could. But that’s what I thought about when I was researching other library’s Digital Collection pages. I’m starting to see a pattern in my research. It boils down to this: academic libraries seem unsure, themselves, of exactly what Digital Initiatives entail. I’m not talking about the “in the trenches workers” (though there might be some of that too). I’m talking about Administration.

Mostly, this pattern shows a lacking in understanding, and also how poorly forward thinking libraries have become in watching and implementing trends. Our department has been in place for well over eight years. We are modest in development, but the future looks bright for more robust collection developments. I believe we have a very passionate staff that understands digital collections, (although there is always room for growth and enlightenment)!

I know that Digital Initiatives is a merging department. I’m lucky we have a Dean that understand this, and have a passionate director who has cool ideas for not only collections, but our department’s future. I am hopeful that with this new direction that we will not only exhibit digital collections, but that we will innovate and lead the way for Digital Collections departments in other libraries in the future.

Until recently, I had never really given much thought to copyright.  There have been a wide variety of materials that I have been given to digitize and put online in our Digital Collections, however, somebody else had always decided before it came to me that we were allowed to put it online.  I was given whatever copyright statement was necessary for that material, I included it in the metadata for that digital collection, and that was all I needed to know.

Recently I have been asked to help out with our Digital Repository for a while.  Part of the work I’m doing includes checking some articles written by our faculty that have been published, to see if we are allowed to put them online in our Digital Repository.  Sometimes It’s easy to figure out and other times it takes some searching.  If it’s not obvious from looking at the published article online, I use the SHERPA/RoMEO website which shows if and how a publisher allows use of articles from their publications.  Sometimes they allow the original work to be put in an institutional repository like ours but they don’t allow us to use the published PDF version of the article from their web site.  Sometimes they allow us to use the article but they have an embargo period of anywhere from 6 to 48 months.  If so, we wait the specified amount of time after the original publication date before we put it online.

Some articles are published under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.  Works produced by employees of the U. S. Government as part of their official duties are not copyrighted within the U. S.  So if there is an article with a co-author who is an employee of the U.S. federal government, then we can use that as well.  I’m certainly no expert on the subject, but it has been an interesting introduction into the world of copyright.

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.

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.

It’s that time of year again, when warm spring weather signals the end of classes and brings on graduations.  This week is finals week here at Iowa State University and it will end with commencement ceremonies.  We scanned many of the earliest commencement programs from our archives and made them available online in our Digital Collections. http://cdm16001.contentdm.oclc.org/cdm/search/collection/p16001coll27

Over the years, there are a variety of styles of printing and constructing the programs, with one even being held together with yarn.  Besides the programs, some include a list of commencement week activities.  It can be interesting to look back and see how things were done long ago compared to today.  You can see what kinds of music was played, the guest speakers and what they spoke about, and names of graduates and their areas of study.  One program from 1880, shown below, has an entry which reads “Shall We Encourage Irish Immigration” which is an interesting look at how some topics of popular concern have evolved over time.

Here is the front cover of a program from 140 years ago and a page of another program from 1880 tied with yarn.

cover

I have all these great ideas floating around in my head for our web pages at any moment in time. Some of them are hilarious, never-will-do, ideas; but sometimes, I see something and I think: that should be easy enough to create for our page(s), right? Isn’t it just code that needs to be massaged? If I can figure out how to tease it just right, it should fit nicely in with our pages.

Sticky footers were such a piece of code that looked simple enough to implement. It’s just a footer at the end of the page; it is always hanging out down there; and, no matter how long or short the page scrolls, it stays at the bottom. Basically, it is a reverse (or mirror,) of a header that run across the top all the way, with the main part centered in the page. I wanted to use sticky footers because I was moving to templates on the re-designed pages; when using templates, the height of the page can vary, but the elements on the page stay the same. Well, what sounds easy isn’t always as such, as I (again) found out when I started to re-design our web pages. When will I ever learn? Probably, maybe, hopefully never, because I’m having too much fun finding solutions to problems.

Let’s start at the beginning of my struggle, and that always begins with research. Most sticky footers that I have seen go all across the bottom of the page, like so:

example_1

Then, there are sticky footers that always show “at the bottom,” even when, technically, it isn’t the bottom of the page:

example_2

I didn’t want either of these, exactly. I wanted something that stayed at “THE” “VERY” bottom of the page, and something that didn’t go all across the bottom. Like:

example_3

Doing a Google search, brings Mr. Fait’s page up first. Here is the css code for sticky footers:

 

* {

margin: 0;

}

html, body {

height: 100%;

}

.wrapper {

min-height: 100%;

margin: 0 auto -155px; /* the bottom margin is the negative value of the footer’s height */

}

footer, .push {

height: 155px; /* ‘.push’ must be the same height as ‘footer’ */

}

 

/*

 

Sticky Footer by Ryan Fait

http://ryanfait.com/

 

*/

 

Placing this in a css document and saving it, or placing at the top of the html doc between <head></head> divs should give the effect wanted. That’s it! Everything should work…right? Not so fast, little grasshopper. I couldn’t get this code to work as easily as advertised. When this happens, one of the first things I do when I see a sample of code I like is to go into Firebug (this can either be built right in, as it is in Firefox, or it can be downloaded for most other browsers. This browser app working right in the browser to “show” the code/html/css used in the layout of the page. This little app is indispensable for web designers.) In this case, I am using Firefox, so, here it’s located on the top, left of the search box. It looks like a little bug, and might be grayed out:

Firebug

Looking at Firebug revealed that this was a very simple layout. I’m sure it works great with designers who have very simple pages. Alas, my pages are complex, and maybe, er…messy, even. Plus, I have over 35 pages I maintain. As it, luckily, turns out: there are several designers who devote pages to nothing but creating sticky footers. And after searching, and using Firebug to explore those pages, I came across this one:

 

/*

Sticky Footer Solution

by Steve Hatcher

http://stever.ca

http://www.cssstickyfooter.com

*/

 

* {margin:0;padding:0;}

 

/* must declare 0 margins on everything, also for main layout components use padding, not

vertical margins (top and bottom) to add spacing, else those margins get added to total height

and your footer gets pushed down a bit more, creating vertical scroll bars in the browser */

 

html, body {margin:0;}

 

.wrap {min-height: 100%;}

 

#main {overflow:auto;

padding-bottom: 5px;}  /* must be same height as the footer */

 

#footer {position: relative;

margin-top: -70px; /* negative value of footer height */

height: 70px;

clear:both;}

 

/*Opera Fix*/

body:before {/* thanks to Maleika (Kohoutec)*/

content:””;

margin:0;

float:left;

width:0;

margin-top:-32767px;/* thank you Erik J – negate effect of float*/

}

 

I liked this one a lot because the designer goes into explicit detail about how to incorporate this code and issues known to using it. Also, it had additional code for Opera and code for use on IE 6 and lower (although I didn’t use that part of the code, and anyone using IE 6, in my humble opinion, is a very sad potato, indeed.) However, the css document listed on this page still wasn’t enough for me. Firebug revealed that another css was also used (called finerstyle.css.) After I copied that css code and placed it in its own document, I finally made the code work exactly as I thought it would. Which, again, highlights the super power of Firebug. And why one should always investigate pages. That’s the great thing about the internet and Firebug. Working hand in hand, you can find what you need and how to use it. Having finally accomplished my perfect sticky footer, I turned my attention to building templates for the updated pages. I’ll discuss my adventures in templates next time. Until then, happy coding.

Next Page »

Follow

Get every new post delivered to your Inbox.

Join 889 other followers