Jefferson's Newspaper » open source

Should Your Syllabus Include a Note on Web Browsers?

E. Bell — Wed, 25 Aug 2010 01:53:51 +0000

Given that one of my primary occupational roles is providing tech support, I offer the following question in part as preemption in my own self-interest but also in the interest of exploring the scope of instruction in the digital humanities (or the “digital” anything for that matter): Should Your Syllabus Include a Note on Web Browsers? If you teach an online class or a class with a significant online component, the answer might be yes.

Whether you are using BlackBoard, a blog platform, or a “proper” CMS, if your course site is doing anything remotely interesting, one of your students is probably using a browser that is not up to the task.

I get questions all the time about browser-related issues and even when I do instructional sessions and warn against using certain old browsers, the questions still roll in. My first troubleshooting question is invariably “what browser are you using?” If the answer is Internet Explorer, that’s usually the last question, followed by many “informative” statements of (arguably) questionable relevance and utility. If nothing else, my mini-rants leave a student with — if not a full understanding of the problem — at least a sense that the “blue e” on their desktop is called a browser, that it’s used to “open the Internet,” and that there apparently are multiple options from which to choose. For many this is a revelation of no small impact.

While not the higher order stuff we (think we) should need to teach at a college level, understanding browsers can still be an opening to understanding lots of “entry level” issues in new media and web publishing. HTML, CSS, JavaScript, and more all rely on the surprisingly fragile ecosystem created by both the browser and the coder (even when the coder is a giant billion dollar company like Google, who themselves have given up on supporting old browser tech). If you plan to even broach the topic of web development and design, the browser is the natural place to start. Even if you just want your students to be able to use and evaluate web sources and digital projects, using an old browser is going to work against your sanity and their success.

Browsers are also an obvious choice for opening up discussions about open source technologies. Firefox, Chrome/Webkit, and Opera are great examples of a movement by which users have become creators/participants, and technology can — through small but scaled contributions — be bent to our will, rather than the other way around. If you are using Drupal, WordPress, Omeka or some other open source web publishing platform in your class, or if your students use open source desktop software like Audacity or GIMP, this is a natural connection. Open source is the key to so much recent innovation in education, academe and on the web more broadly, that if you don’t think being an open source advocate is part of your job, perhaps you should ask yourself why not.

Savvy students and instructors may intuitively understand that they can improve their online experiences by seeking out new approaches and alternatives when problems and questions arise, and that recency and novelty are actually important in technology, but this is by no means a norm in any non-tech sector of our culture. If you don’t know what you don’t know, you pretty much stick with what you do know — even if it sucks. I recently questioned a colleague for requiring that assignments be “prepared in MS Word”; if the end product is in the right format (.doc in their case), why require a specific software that comes with specific costs and benefits. Let students choose what software to use and note that there actually is a choice to be made (yes, OpenOffice, iWork, GoogleDocs, and more all export into Microsoft formats if desired), instead of hiding a broader question (what software to use) inside of an unnecessarily absolute decree (buy and use Word) that addresses a specific problem (students turning in papers in unreadable formats) but ignores the bigger context. This is not Microsoft hate (I like Office and, surprisingly, even Windows7), but a serious question about how we prepare students for careers that will invariably involve software and hardware choices (if not by them, than for them). So maybe your students won’t be designers, programmers, IT specialists, or whatever, but they will be consumers of technology and perhaps digital creators of another kind. Scholars and writers (not to mention managers, etc) still need to be versed in the basics of technology so they can understand the options at their disposal, the forces that shape their world, and the language with which to convey their needs and ideas (try asking an 80 year old to describe the usability and effectiveness of a piece of software or a website; these are learned skills). Connoisseurship has its utility.

Security is another issue that needs little description here. Basically, keeping your browser, your OS, and all of your other software updated will go a long way in preventing spyware, viruses and generally poor performance.

A “note on browsers” doesn’t directly address all of the issues above, but it’s potentially a start and it probably can’t hurt.

Even if you are not interested in any larger questions about digital literacy or open source advocacy, or it simply does not fall into the purview of your course, you still might want to include some kind of note on browsers, if only to reduce time spent troubleshooting and haggling with tech-averse students. So with that in mind, I offer the following:

Prefab “Note on Browsers”

This course requires extensive use of the Internet, including websites and other online resources that may require the use of a up-to-date, standards-compliant web browser. Web browsers are free to download and may be installed on any computer in a matter of minutes. Acceptable browsers include the most recent versions of Firefox, Opera, Chrome, Safari, and Internet Explorer. To ensure that your browser is updated to the most recent version, open your browser and go to Tools >> Options (PC) or Help >> Check for Updates (Mac), or download the latest version of your browser choice at http://www.browserchoice.eu

A randomized list of browser choices:

www.browserchoice.eu
This is actually the same interface that is shown to new computer buyers in the EU, where it was decided that Microsoft’s bundling of Internet Explorer with Windows was anti-competitive and potentially harmful to innovation.

IE6 No More

www.ie6nomore.com
A nice little script you can drop into the header of your site so that users of IE6 and IE7 will get a warning reading “For a better experience using this site, please upgrade to a modern web browser” with links to upgrade to the latest version of IE or download an alternative. Don’t forget to update the code when IE9 comes out in late 2010/early 2011 to be sure your students/users are taking advantage of Microsoft’s promise of greater support for existing and emerging HTML/CSS standards.

Browser-Update.org

www.browser-update.org
I haven’t used this script yet; it looks similar to IE6 No More but apparently checks for outdated versions of Opera, Safari, Chrome, and Firefox as well as Internet Explorer. Billed as an “an initiative by web designers, webmasters and bloggers who want to bring the web further and help their visitors.”

NOTE: The images above are from the very awesome looking Harmonia Pastelis Icon Pack by Teekatas

Adding a Featured Image Gallery to Omeka Using GalleryView

E. Bell — Thu, 15 Jul 2010 03:39:39 +0000

Following on my previous entry on adding an image Lightbox to Omeka, today I’ll run through the steps it takes to get a featured image gallery running on your Omeka homepage. I searched for awhile to find a gallery plugin that a.) looks good, b.) works well and c.) is not too complicated for me to figure out. Fitting the bill nicely, I found GalleryView, a fairly lightweight jQuery plugin with lots of options for your tweaking enjoyment. It’s a bit more challenging to implement than Lightbox and requires a fair amount of CSS knowledge to prettify, but this should help you get started.

Step One: Download and Install GalleryView (and edit the GalleryView CSS)

Download the GalleryView package and place it in your theme’s /common/ directory. Be sure that you have placed the whole shebang directly inside the /common/ directory and renamed the outer folder galleryview (if you use the default galleryview-2.1.1 name, you’ll need to adjust the scripts below to match). Go into your theme to common/galleryview/galleryview.css and edit the first id, changing it from #photos to #featured-gallery (or something else if you prefer, see below for details).

Step Two: Edit your Header (Scripts and Configurations)

The code below will work as is if you are using the popular Berlin theme, but if not simply replace the word berlin below with the name of your Omeka theme. Be sure the paths below match with where you actually placed your files in the previous step.

*** To save hours of confusion, watch out for typos and try using your browser’s “view source” feature to ensure that your links are reaching their destination.

 echo WEB_ROOT;?>/themes/berlin/common/galleryview/galleryview.css" type="text/css" media="screen" />

That final, multi-line script above initializes GalleryView and contains your configurations. You can change them however you like according to the GalleryView documentation, but here I’m setting the dimensions, timing, theme, etc. There are a couple other things worth highlighting here if you are not familiar with JavaScript. First of all, the string containing #featured-gallery is setting up the gallery to run automatically on images displayed in the html div with the id of “featured-gallery” – you can change this to whatever you like, but remember that it needs to match the outer div on your index page in the next step. Also worth noting, the script generally runs on a generic placeholder function called $, but in order to get around the conflict with the Prototype library (which also uses $ as a generic placeholder), I’ve included the jQuery.noConflict() line and replaced $ with jQuery.

Step Three: Edit your Index Page (Looping Items and Calling GalleryView)

The code below uses a custom loop to retrieve the images. As noted, the outer div uses the id “featured-gallery”, as well as a required class, “galleryview” — #featured-gallery is the only id or class that you can change below!

	<h2>Featured Itemsh2>
	<div id="featured-gallery" class="galleryview">
	<ul id="gallery">
		< ?php 
		//this loops the 5 most recent featured items
		$items = get_items(array('featured'=>true, 'recent'=>true), 5);
		set_items_for_loop($items);
		while(loop_items()):
		?>
			< ?php $index = 0; ?>
			< ?php while ($file = loop_files_for_item()): ?>
			    < ?php if ($file->hasThumbnail()): ?>
			    
			        < ?php if ($index == 0): ?>
		    	       < ?php echo /*Image URL*/'.item_file('square thumbnail uri').'"/>'; ?>
		    	    < ?php endif; ?>
			    < ?php endif; ?>
			< ?php endwhile;?>
			< ?php
			echo '';
			echo /*Item Title*/''.item('Dublin Core', 'Title').'
';
			echo /*Item Description Excerpt*/''.item('Dublin Core', 'Description',array('snippet'=>175));
			echo /*Link to Item*/ link_to_item(' ...more ').'
';
			?>
			< ?php endwhile; ?>

I’ve added some comments inline with the code above to describe what it’s doing, so if they make sense to you, you can probably figure out any changes you might need (for example, looping more or fewer images meeting whatever Omeka-friendly criteria you like).

*** I’m using square thumbnails in my loop because they’re easy, but you may need to adjust the max thumbnail size in your Omeka settings to avoid blurry images.

Step Four: Season to Taste

Though the example above works pretty nicely “out of the box” in a two column homepage theme, the GalleryView documentation contains a list of configuration options, so you will probably want to fool around with those, as well as your CSS, to integrate GalleryView properly into your theme’s overall aesthetic. You might also want to customize the loop in Omeka (personally, I’m not a huge fan of the one used above, but haven’t figured out a better one just yet).

Hope this has helped a few folks out there who, like me, are working near the edges of their skill set. As always, feel free to share your comments, questions, suggestions, critiques, etc. I’ll try to keep this updated as needed.

By the way, I’m planning to release a new Omeka theme that incorporates both Lightbox and GalleryView, as well as some other fun stuff, so stay tuned.

Adding an Image Lightbox in Omeka

E. Bell — Thu, 19 Nov 2009 15:03:21 +0000

Maybe it’s just me, but I had a heckuva time trying to figure out how to implement Lightbox 2 in Omeka. After piecing together info and code from here and there, then adding my own little improvements, I’ve constructed a simple little 4-step guide to document the process and, hopefully, help make this process a little less vexing for others out there who aren’t PHP and Java Script pros.

Step One: Get the Lightbox Package

The first step is to get the latest LightBox 2 package here, where you will find a quick explanation of how it works and how to get started.

Step Two: Modify and Upload the LightBox Package

Once you have the package, make sure it’s in a folder called “lightbox” and upload it to your Omeka theme directory inside the “common” directory where your header and footer files are located. Take the image files and copy them to your theme’s “images” directory.

Inside common/lightbox/js directory, find the file called “lightbox.js” and set your configurations. This is where you set your lightbox behaviors (overlayOpacity, animate, resizeSpeed, borderSize, etc.) and also where you tell LightBox how to find the images and labels to display Close and Loading. When setting the former, you can fiddle with the defaults to get the style you need, it’s pretty easy to understand. For the latter (image locations), you can use either a relative or a direct URL. If a relative location (e.g. ‘../images/loading.gif’) does not work for you, try using the direct URL (e.g. ‘http://www.yoursite.com/omeka/themes/themename/images/loading.gif’). My impression is that Omeka requires the direct URL for some reason. You could probably leave the images in the “lightbox” directory and point to them there as well.

Step Three: Modify your Omeka Theme Header

Add the script to your theme header (be sure to modify with your actual theme name):

Pretty basic.

Also, you’ll want to either copy the LightBox CSS styles into your theme’s stylesheet or move it to the theme styles directory and link to it in your header. Either way, be sure to double check that your images are properly linked. I find that having the LightBox styles included in a single stylesheet is preferable, but if you want, you can use something like this after moving lightbox.css to your theme directory:

<link rel="stylesheet" href="css/lightbox.css" type="text/css" media="screen" />

Step Four: Modify Your Omeka Items-Show Page

This is where I got hung up. The site I was working on has multiple file types — not just images, but also audio and video. I was lucky enough to find a starting point on the Omeka Dev Google Group as well as on the Omeka Forums, but the code was written for item pages with a single image file. Since I’m not great with arrays, it took me a while to come up with the imperfect code below.

	
	<div id="itemfiles" class="element">
	    <h3>Filesh3>
		<div class="element-text">
		    < ?php 
		    if (item_has_thumbnail()) 
					{
					echo 'Click the Image for Full Size';
					echo display_files_for_item(array('linkAttributes'=>array('rel'=>'lightbox[group]'))); 
										}
			else
				{
				echo display_files_for_item();
				}
			?>
 
		div>
 
	div>

This script will test if the item has a thumbnail (i.e. “is it an image?”). If it does, it will display the files as square thumbnails and give them ‘rel=”lightbox[group]“‘ – clicking on images with the “lightbox” relation in the URL will prompt the light box; if there are two or more images associated with the file, the ‘[group]‘ part will kick in to add the Next and Previous buttons. If the item file is not an image, the script calls the generic Omeka function display_files_for_item(), which will automatically call the media player (for audio and video) if needed.

A pretty easy process when you have it all right in front of you. Hope this will be helpful to someone out there.

NOTE: I’ll continue to update this post with any improvements. If you have a problem, fix, or improvement to share, please add it in the comments or catch me on Twitter (@ebellempire). I’ve also cross-posted this tutorial in the documentation wiki at Omeka.org, so feel free to contribute there as well.

Punk Rock and the Digital Humanities, part 1

E. Bell — Fri, 12 Jun 2009 01:59:03 +0000

As the dialogue on the emergent (yet increasingly passe?) edupunk movement has begun to penetrate the mainstream press, I’ve been thinking a lot about what the term might mean to my present occupation, and also about what punk rock has meant to me historically (both in terms of my personal history and also my views on History with a capital H). I’ll spare you the many cliched “life experiences” I’ve enjoyed as a result of my involvement in punk culture, and focus here on how it has impacted my views on art, literature, politics, society, technology and education (i.e. the (digital) humanities).

My friend Joe, a newspaper editor, once said something to the effect of “It’s kind of crazy how all the punks end up doing such interesting and serious work outside of punk when they ‘grow up.’” Okay, he probably said something a lot better and more impactful than that because I remember the gist of it years later. For some reason this brief conversation has stuck with me. As I moved through undergrad and grad school and into the professional world, I have consistently noticed the phenomenon in action. The best students, the best teachers, the best writers, and the best researchers all seem to have this common background. I have seen it and confirmed it in many of my (more interesting) colleagues and it shows in the work of many others whom I’ve never met. It’s a certain flair for innovation, improvisation, and investigation; a proclivity for self-education and DIY solutions; a disdain for convention and privilege; and an eye for finding humor and absurdity in unexpected places.

3 Chords is All You Need (… at Least to Start)

Yep. The Ramones first album proved among other things that you only need to know three guitar chords to make great music. But like many other punk bands, the music matured over time, becoming more complex as the artists began to hone their skills and increase their repertoire. Sometimes the music got better, sometimes it got worse as a result. Even though I never was able to master even the requisite three chords to start my own band, the “anyone can do this” attitude that punk embodied has carried over into everything I do. Most everything one might pursue has those metaphorical three chords — the trick, as with the guitar, is figuring out what they are.

In digital humanities, those three chords might be HTML, CSS, and PHP. (Maybe others have a different idea. I’m focusing here on the digital part because the humanities part – the content – is understood. Afterall, if you don’t have something to say, you shouldn’t be starting a “band.”) The degree to which you need these “chords” will vary depending on what you are trying to accomplish, as well as on the tools you use and the people you work with. But generally speaking, these three will set you up to start web publishing, and also give you a solid base for understanding other more complex programming languages and projects.

So you find the chords, you master them. Then on to the next challenge… and the next. Before you know it, you’ll be soloing on your hand-built keytar as your self-produced album rockets to the top of the prog rock charts. Or not. Maybe you’ll just keep pounding away at those same chords and finding new ways to use them. But the point is that it’s alright to start small (and/or stay small).

DIY or Die!

It’s not just that you can do it yourself but that you should. To me, there is no such thing as a major label punk rock band (at least not after about 1980). Being punk has always been about doing it yourself – sometimes out of necessity, sometimes by preference, and occasionally as an anti-capitalist or anti-authoritarian gesture. If you do it yourself, you are free to do it however you want.

Thus far, a lot of the digital humanities projects I’ve seen are tied to institutional funding and labor, proprietary content and technology, and bound by copyright and contractual obligations. It’s not that these projects are bad. Many are great. And they often benefit especially from connections gained through these affiliations. They also employ people, which is good. It’s just that they can also become organizationally bloated, unwieldy, and tenuous as a result. This doesn’t mean you have to run your semantic search think tank from your mom’s garage (though, hell, why not?), it just means keeping hierarchies in check and making sure you don’t lose control of your project, or lose sight of your goals. It also means learning as you go; tinkering, experimenting, and failing are all important.

No Rights Reserved

DIY is not about individualism, it can also be about leaning on (and contributing to) like-minded communities. Open source technologies and Creative Commons licenses are totally punk rock. Open platforms (like WordPress, Drupal, Omeka, etc.) and software packages (Gimp, OpenOffice, FireFox) share their code, encourage non-proprietary standards, and are often developed and maintained by a community of users/contributors. If you want to use them, you can do so for free. If you want to study them, make them better or bend them to your own needs, you can usually do that too. Most open source projects operate under some kind of Creative Commons license.

But open content is also important. Humanities research requires the use of all kinds of content. Running up against unnecessary copyright restrictions can be not only frustrating but can actually bring projects to a halt – especially digital archival projects operating under the aegis of larger institutions; institutions that are understandably (though sometimes paranoically) wary of litigation. There are two (or maybe three) significant archival repositories in my neighborhood. One opens its content to all comers because they have defined themselves as an institution committed to education and community. They allow hands-on access, digitization, and non-profit use of nearly everything in their collections. At the other end of the spectrum is the more hallowed institution. They believe that their collections are sacrosanct and that their artifacts exist to be preserved. They do not make anything available online and they forbid reproduction of any type (unless you pay a ridiculous fee) for fear that everyone is out to steal their content. They really believe that if they increase access, they will lose their standing. Direct quote: “These items are all we have! We can’t just let people download them! Then how will we make money or get funding?” As if they are bringing in a lot of money in their current state: offline, behind lock and key, and crippled by the analog DRM called fear of obsolecense. The people who will pay (i.e. commercial projects like documentaries), will pay anyway. If they can find your content. Overprotection creates a situation where the “wondrous” artifacts they preserve may as well have burned in Alexandria. It’s pretty annoying to know that the perfect set of historic image sits just across town, waiting to help you complete your groundbreaking, non-profit, community-based public history project, but it will cost you $1000 (or the equivalent in months of grovelling) to use it.

So why add to this problem with your own unnecessary copyright barriers? Open it up, and let people benefit from and build on your work. They’ll do it anyway, so what do you have to lose? (see also Stuart Geiger’s post on the topic). The point of your work is to make an impact (on communities, people, scholarship, your reputation, etc.). While nothing is more punk rock than throwing the ole’ “No Rights Reserved” on your blood, sweat and tears creation, CreativeCommons allows you to choose the degree of openness that suits your project, so no pressure… you poser.

Death to Posers and EduJocks

Punks hate nothing more than posers and jocks (and maybe Ronald Reagan). They are antithetical to all the punk believes in. Posers are an affront to the punk rocker’s unending need to measure and display authenticity. In edupunk and in the digital humanities (interesting how these seem to be tied together), there are also what might be called posers. We will call them EduJocks (I sure hope you heard it here first, but I doubt it). EduJocks adopt the outward persona of the digital humanist/edupunk, but lack the internalized commitment and understanding of the bigger picture. If you hear someone saying, “Well, BlackBoard is good for some things…” or “Too bad there’s no alternative to Microsoft Office/ContentDM/Adobe…”, cut them off and walk away immediately. You are in the presence of an EduJock. This could be like a Jeff Foxworthy bit. You know you’re an EduJock if… [ahem - this is what blog comments are for].

That’s it for Part 1. I’m getting tired of this right now, but I have plenty more to say. Stay tuned for Part 2, wherein I will blow your mind with another ludicrous application of the time-honored punk rock tradition of making everything you like be about punk rock.

Yes, this post ends abruptly. That’s because it’s punk rock. I’m exploring the form.

Here are some teaser topics for the next installation:

Framing: The Decline of Western Civilization

Liner Notes: The Original People’s University or Citation City

Lies My Teacher Professor Told Me

Judging an Album by it’s Cover (and/or the Record Label) or Style is Substance (the Medium is the Message)

Nihilism as a Valid Academic Perspective

Technology of Resistance?