Assignment Blog: Final Project 2

This blog will be my last for the course .  I spent the last two weeks fine-tuning the details of my project site, primarily by reviewing each page in detail for errors and omissions;  ensuring that my CSS code was clean and tight; and, above all, ensuring that everything looked the same in all browsers, particularly Safari (and yes, it even works on my iPhone!).  My only true frustration had to do with manually inserting apostrophes and quotation marks for all of my text. My pages used a lot of these symbols; but, quite maddeningly, using the simple <q> coding did not display the properly curved symbols in Safari. When viewed in Chrome, Firefox, and even IE, these symbols came out perfectly with the <q> code.

I asked Prof. Petrik how I might remedy that issue, and she told me to use the “Insert>Special Character” option. This technique allowed me to select from the top bar of the Dreamweaver menu menu the correct apostrophe and quotation marks and insert them into the text; in each case, they appeared as either &#8220 (left quotation mark), &#8221 (right quotation mark), and &#8217 (apostrophe). And so, to ensure that Safari users would see the same thing, I had to manually insert these symbols one at a time by selecting the “Insert>Character> Symbol” features — a task that took me hours to perform. Cutting and pasting this code did not work; I had to make no fewer than four clicks each per entry. But I guess that if we’re going to develop Web sites that look the same across all Web browsers, we have to go to these lengths to get it right. My task would likely not have been so ominous had I used the “Insert>Character” feature at the outset. My only hope is that the developers-at-large figure out a way to allow the same code used in Dreamweaver and other Web-site-creation platforms to speak the same language across all browsers.

Overall, I feel rather proud of my Web site. Naturally, I will continue to tweak it even after the course ends. I intend to keep it active for the foreseeable future and to build another site this summer to host photographs and maps from my last book that never made it into the final published product.  But you can bet on one thing: As soon as the course ends, that crappy Portfolio site of mine is coming down! Hallelujah!

Steve Rusiecki

Note: As of Sunday, 3 May 2015, I have not seen any other student blogs upon which to comment.

Comment on Nathan’s Final Project Blog: “Building a Website”

Nathan’s Final Project Blog: “Building a Website”

Nathan expressed concern over how best to add multiple pages to his Web site. In his blog, he stated that he is copying both the HTML and CSS pages from one new Web page to another. Actually, I learned a better way thanks to a tutorial. Instead of creating multiple separate Web pages, you can create multiple pages within the same Web site that share the same CSS code. After I created my main (or home) page, I selected “Save as” and created my next page — all within the same folder. After renaming the file, I then modified the page with whatever content I wanted. I followed this same process to create all of my internal Web pages. If I wanted to do something unique to each new page’s style without interfering with other the other pages’ design, I simply used CSS Designer and selected as my style source the option “style.” This option allowed me to create inline CSS right on the new page while still drawing on design code from the main CSS file. I found this technique to be much easier and a lot less work. And I agree with Nathan: Getting all pages to work in concert with each other is challenge that requires an extreme amount of attention to detail.

Steve Rusiecki

Assignment Blog: Final Project

Well, the Final Project is finally here! I would to discuss my adventures with my gallery page this week. I had two choices to make:  (1) Create a gallery page that could host 12 images per the technique offered on the Dreamweaver 2014 CC tutorial, or (2) Create a gallery page using the image-enhancement technique shown to us by Prof. Petrik in class, which limited me to only nine images. Initially, I wanted to include the maximum number of cover or front-page images for each of my page’s three source publications. The tutorial’s technique allowed me to include four images for each publication, all with a nice color change to light blue when hovering over the image. After clicking on an image, the user was taken to a separate page with an enlarged version of the cover or front page matted against a white background and floated left. At first, I liked this technique, because it highlighted, without distraction to the user, the holistic impact of  experiencing the design, imagery, and typography of these publications much like the average American did during World War II.  The only downside to this approach was that I had to create 12 separate Web pages with a “return to gallery ” link on each page, causing the user to open numerous tabs on each click. I could not figure out how to avoid that dilemma.

I was eager to try Prof. Petrik’s technique; but, when I tested the image enhancements on my gallery page, they jumped out too quickly and were too large. The suddenness of that transition almost seemed violent — not an effect that I wanted for this Web site in particular.   I almost went back to the clunkier method until Prof. Petrik told me after class that I could adjust the speed and sizing of the image enhancements without creating a problem in the code. I went home and played with the CSS a bit; and, lo and behold, it worked perfectly. I made the images appear less suddenly (but not too slowly), and their enhanced size — roughly 1.5 times the normal size — looked great. I was sold on Prof. Petrik’s technique, and I’m happy that I was able to make it work to my satisfaction. Frankly, it’s the better way to create a gallery. Now I’m off to tweak the rest of my site and see what else I can improve upon.

Steve Rusiecki

Comment on Mason’s Design Blog: “Update on Design Project”

Mason’s Design Blog: “Update on Design Project”

I sympathize fully with the struggles Mason has outlined in his blog about finding ways to ensure that his Web site’s design captures his selected time period.  And, like Mason, once I found what I wanted to include on my own site, the real struggle became finding ways to make it work. As Mason explains, some techniques were easier to master than others. Tinkering with a background image was a big one for me, and Mason seems to be bumping along that rough road now. All I can say is that he is on the right track by experimenting with those backgrounds that may or may not work.

I wanted my font style to reflect a “newspaperish” feel to it as well; but, in many cases, and like the font style Mason selected, some newsprint-style fonts are tough to read on a Web page. I settled for one, leitura-news, that gave the feel of of old 1940s newsprint and was easy to read online.  I feel that this compromise was essential in order to grab a user’s attention and make him or her stay on the site. I would recommend to Mason that he seek another serif font for his main body that is a little easier to read than his current selection.  And I just love the parchment backdrop in the main body. Wow! It looks great!

Steve Rusiecki

Comment on Alyssa’s Design Blog: “Web Design Assignment”

Alyssa’s Web Design Blog: “Web Design Assignment”

I enjoyed reading about Alyssa’s thinking behind why she chose the colors for her Design assignment and how she selected the images and font style to support her theme.  I followed the embedded link to her Web site and was able to see the draft version. Her choice of purple in the headers — and her font style in particular — really capture both the sense of the media storm that encompassed the Richmond capitol building disaster in 1870 as well as the sense of mourning that accompanied it.  The newspaper-style font in the <h1>  headers look fabulous.  The images are particularly good, and I liked the way she vignetted Mr. Chahoon’s image — although perhaps resizing it in Photoshop might eliminate some of the “pixelation” that is still evident. I had the same problem with a few of my images, and re-sizing them in Photoshop was not always the best solution. In fact, I had to abandon some of them outright. Overall, Alyssa’s design looks great, and I can’t wait to see the final product.

Steve Rusiecki

Assignment Blog: Design

For weeks I’ve been blogging about how I thought that black, white, red, and blue were the colors that best represented  the period I was trying to evoke visually on my Web sites — World War II.  Professor Petrik chided me to be more adventurous in adding color to my sites — that it wasn’t a horrible thing to “stretch” a little. My standing fear had been that stark color contrasts might fail to capture the World War II era and, most concerning of all, cause my site to appear “cartoonish” and disrespectful to the men who died on D-Day. But after learning how to colorize photographs in Photoshop and locating actual color images of D-Day, I realized that I could bring more color into my sites and still capture a proper visual representation of the era. Most importantly, though,  I couldstill do justice to the sacrifices made by the men who assaulted the beaches.  Therefore, I was determined to add more color to my Design assignment in order to complement my newly discovered color D-Day photographs and to make the site more visually appealing.  And, above all, I wanted to bring to bear all the skills I had learned throughout the semester, so I used my colorized image of Eisenhower and other design features to add some visual appeal that had been generally lacking in my other assignments.

The background image was going to be my greatest challenge, though.  But before I tackled backgrounds, I wanted first to add something visually appealing and colorful to my <h1> header, which seemed a bit dull. I located a nice color digital image of the Supreme Allied Headquarters Expeditionary Force (SHAEF) shoulder patch. Using what I learned about “position: absolute,” I inserted it to the right of the <h1> header area, and it looked great. The color hinting in the patch allowed me to bring in more colors to the site.  The image’s placement  worked just fine when viewed in Internet Explorer, Chrome, and Firefox. Unfortunately, the SHAEF patch appeared offset when viewed in Safari. After several hours of toying with the CSS, I somehow combined some commands for “position: absolute” with “float image: right,” and everything worked fine. Don’t ask me what I did; all I know is that it worked. It was an annoying glitch — to say the least.

For the background image, I selected a color D-Day image of GIs posing in front of their landing craft in England. The picture had some rich blues, reds, khakis, and greens — all colors that would work nicely with my site design. When I set the image as a background, it fit beautifully. I was particularly happy that the image featured a black GI, a much needed visual acknowledgement of the all-inclusive nature of the American contribution on D-Day.  The only problem is that the image was too clear and bright, taking away from the central focus of my Design site, the subject of which was Eisenhower’s “Great Crusade” message on D-Day. Professor Petrik urged me to lighten the image’s opacity in Photoshop, which I did — with excellent results. When I added the  image as my background, the color was still there but not as pronounced — or as overwhelming — as before. The main body of the site stuck out nicely, and I even changed the font color of my <h2> headers to green, which also worked well.

For the moment, I’m happy with the site. I plan to use a lighter opacity on the background images for my Final Project’s Web pages, and I’m excited to see how they will look.  In the meantime, I’ll keep plugging away!

Steve Rusiecki


Comment on Ben’s Blog 8: “Interactivity”

Ben’s Blog 8: “Interactivity”

Ben is absolutely correct in his assessment of The Lost Museum Web site’s “Achilles Heel”: Interactivity should enhance and not limit the historical experience.  In making a major facet of the site a game designed to figure out who torched the museum, the overarching cultural and historical importance of the site seems to take a back seat.  As I mentioned in my own blog, I watched my son grow up playing many historically themed games and thinking he was getting at the underlying meaning behind the event or period in question. Not so. Defeating the game’s algorithm became the primary objective to the exclusion of all other factors. And, as Ben rightly points out, users of The Lost Museum can become quickly mired in following the “algorithmic bread crumbs” while ignoring the purpose and meaning behind Barnum’s artifacts and underlying thematic message.

Further, I think Ben is onto something by likening the site to a copy of Frank Leslie’s Illustrated Newspaper that, although rife with wonderful engravings and imagery, would be meaningless without the necessary textual explications and the context attending such explications. In other words, visualization is great if it serves to clarify –  not obfuscate — the historical argument.  Granted, The Lost Museum offers some of that textual context up front; but, once the game begins, it’s off to the races. The dominant theme becomes finding the guy with the pack of matches and not necessarily the reason why he (or she) may have torched the building. Could the arsonist have been a Confederate sympathizer who, in a fit of pique over a display of Jefferson Davis disguised as a woman, decided to light up Barnum’s building as a show of unity with the recently defunct Confederate States of America? Hard to say. I’m sure the users who view only the textual descriptions of each attraction will get some meaning from the site while others will simply enjoy the cutting-edge visualizations of the virtual tour — all enhanced by Flash Player but sans descriptions.  Ultimately, and as Ben rightly argues, interactivity has to serve the overarching argument. The Lost Museum falls short here.  Granted, the site represents a great effort; but, as historians, we must be careful that our Web sites have more “bang” and less “flash” — or at least a good balance of both.

Steve Rusiecki

Comment on Mason’s Blog 8: “Interactivity on the Web”

Mason’s Blog 8: “Interactivity on the Web”

Mason made some excellent points about the nature of interactivity on the Web. In particular, Mason discussed the potentially “cheesy” appearance that an otherwise serious historical Web site might have if the designers leaned too far toward the gaming aspect of interactivity.  Such an appearance would almost certainly undermine the historical message and cause the site’s purpose to fall flat.

I’ve never been a big fan of video games, primarily because I find them to be tedious and predictable.  The goal of these games always seemed to be how the player could master the designer’s algorithm and win the “gold ring” in the end.  Arghhh. Not for me. I watched my son grow up playing video games, many of them with historic themes, only to find out after quizzing him later that he learned next to nothing about the game’s historical setting. He was more focused on “beating” the algorithms or finding codes online that would allow him to bring German Tiger tanks onto a medieval battlefield and “win the day.” No contest there. And certainly no learning, either. But I must admit to being amused when I watched a bunch of knuckleheads in heavy armor and on foot trying to escape a high-velocity 88mm round fired from the King Tiger.  Again, no contest there.

Like Mason, I admire the efforts of historians like Edward Ayers and Michael O’Malley who have delved into something different, something unknown, to try and create a new Web-based “language” that can enhance, or possibly even replace, the way we historians present our arguments and subject matter.  Like these men, the visual component to history is extremely important to me, and the Web offers so many possibilities in this regard. I am happy beyond words to have learned how to create and publish a Web site in Clio II, but I wish I had more technical expertise to contribute to the efforts of historians like Ayers and O’Malley.  But right now, I just want to ensure that my online historical efforts don’t become goofy avatars of fantasy-based Nintendo video games.  History, for the most part, is not a game. We can have fun with our historical subject matter, though, but not at the expense of forfeiting the meaning behind that subject matter.

Steve Rusiecki

Reading Blog 8 (History 697): Just How Active Should Interactive Be?

The search for a dialectical, interactive, historically focused  Web paradigm that enhances a user’s ability to experience history online still seems to have eluded us.  And by “us,” I mean those historians who believe in the necessity of the visual component to enhance our understanding and experience of history.  I agree fully with Joshua Brown’s contention that “[o]ur consciousness of the past is inextricably bound by pictures”; but I am equally sympathetic to his lamentation in the same 2004 article, “History and the Web, From the Illustrated Newspaper to Cyberspace,” that “multimedia has failed to coalesce into a new form and still operates as a fragmented collection of different types of information.”  At the time Brown published this article, Edward Ayers’s remarkably innovative and groundbreaking Valley of the Shadows Web site was a mere 10 years old. Ayers and his colleagues had struggled to form a new type of  online “language” through multimedia that would allow users to interact with (albeit poorly) scanned images of primary-source documents assembled in a such a way that they — the users — could ascertain the nature of the historians’ argument in the absence of a stated thesis. In other words, Ayers and company were seemingly trying to make pseudo-historians of the interactive Web user, an effort that I still applaud. But Ayers’s efforts, in my estimation (and as as Brown further attested), fell flat — unfortunately. More than a decade later,  the Valley of the Shadows site is still up and running with virtual galleries (like The Lost Museum site) that allow users to move through the evidence (now no longer scanned but transcribed) in a sequence of his or her choosing. But the historian’s “heavy hand” must intercede at some point to distill in narrative form the essential aspects of the argument. Thus, we as historians cannot seem to escape the need to engage in what Brown termed the “resolutely textual” nature of the historical argument. I wish I had the answer to this conundrum, but I don’t.

Like Joshua Brown, I am a firm advocate of marrying up the textual with the visual in order to communicate a historical argument more effectively. In previous blogs, I explained how I struggled with two different publishers to include as many maps and photographs as possible into my two World War II-themed books and how the Web has helped to cast off the strictures of such cost-based limitations. But how can we interweave the textual and the visual in an interactive way on the Web that will bring a new experience to the historically interested user? I struggled with this problem as I planned my Final Project for the course. How could I marry my visual representations to my argument in a unique way?  First of all, I recognized that I could not escape the textually based nature of an argument presented in a traditional linear form.  The closest I could come to allowing a user to select the flow of the argument was by organizing the different parts of my text into discrete hyperlinks arranged at the top of my Web page.  Users could begin with the introduction or conclusion and then work through the argument thematically in a sequence of their choosing.  But I could not get away without embedding notes into the main body of the text to ensure that my analysis remained clearly grounded in primary- and secondary-source material. In effect, I was simply adapting a monograph-style format to a Web-based structure. Not much innovation there.

Where my Web-based argument took on a new dimension, though, was in how I planned to use images to illustrate the impact of my historical assertions. Since my analysis focused on the Army’s print-media campaign to sustain all soldiers’ motivation to fight and win, the visual impact of presenting images of the print products themselves would add a new dimension of insight into my argument. I selected high-quality digital images that I took of the many print sources I owned and sprinkled them strategically and carefully throughout each page of my Web site.  The positive effect exceeded my expectations; the illustrations added greatly to the substance of my argument. But the one problem nagging me was that a user could not interact with the images by enhancing them or manipulating them. I researched Zoomify and found that the technique of enlarging specific details of each cover of The Stars and Stripes, YANK: The Army Weekly, and Army Talks was not what I wanted for my users (but Zoomify is really cool for things like maps, so I’m keeping it handy for future Web projects!). I wanted my users to see enhanced — but complete — versions of these publications’ covers so that they could understand the collective effect and visual impact of how the Army made them appeal to the average soldier. I decided, for interactivity purposes , that I would try the gallery approach and include images that, when selected, would jump to a page with a larger (but not overly large) version of the publication so that the user could more fully appreciate the combined use of the headlines, photographs, and feature stories unique to each edition.  The downside was that I had to create separate HTML pages (12 in all!), each with the larger image that I linked to the smaller image located on the gallery page. The final effect was worth the effort, though.  My user audience now had two interactive features on the Web site: (1) sequencing choices using the navigation bar, and (2) the ability to view 12 enhanced versions of the publications referenced in my historical argument.  But was I offering enough interactive options to keep a user engaged? Hard to say. I’m a rank amateur at the Web-site trade, and I’m still learning. Perhaps audio and video clips from period news reports would further enhance the argument and a sense of the historical period that I’m describing. But those approaches are well beyond my abilities right now. Search features and surveys seem okay, but I’m not sure they would be useful for my Final Project Web site. The gallery seems to be my best option for the moment.

In sum, Joshua Brown’s 2004 assertion that we have yet to crack the code on a new Web-based “language” to communicate history more effectively on the Web still holds true today.  We’ve certainly made some great strides thanks to software enhancements over the years, but I’m having a difficult time envisioning a replacement to that medium with which we historians communicate our historical arguments most effectively — the book.  The ability to add many more illustrations, photographs, and other visual representations to enhance our Web-based historical arguments is a step in the right direction, and I’m excited to see what I can feature in future Web sites. But finding a new “Web language” that will take us to the next level seems daunting at best.  We can only keep trying to find it through experimentation. Onward!

Steve Rusiecki

Comment on Alyssa’s Blog 7: “Accessibility”

Alyssa’s Blog 7: “Accessibility”

I’m glad to see that I wasn’t the only one to run some of my Web pages through the WAVE accessibility evaluation tool. I thought that the few errors that “popped” (some of which I could fix easily) meant that I was in pretty good shape overall. And then, after reading Alyssa’s blog, I realized that I could do much more to improve my accessibility “score.” Alyssa used both WAVE and Achecker (not sure what that second  one is!) to evaluate her Web pages, and she came out waaaay on top! Her stuff was nearly perfect. Her only “ding” was that she did not identify her Web sites’ language — one of the same “dings” I received from WAVE for my pages. For the most part, Alyssa had clearly learned from her experience in library school how to code a page properly to ensure accessibility.  She has certainly set a high bar for the rest of us!  I’m inspired to go back and try and figure out — with renewed vigor — the  errors that WAVE reported on my Web pages. My thanks to  Alyssa for leading the way and setting the standard for all of us. Well done!

Steve Rusiecki