1. Make sure students graduate as skilled, thoughtful consumers and producers of digital media

Several smaller goals fit into this:

• Learn how to search – Read Bill Turkel’s blog. If you’re not convinced search is important, READ IT AGAIN. There is more to search than Google, and learning how various searches work—and, more importantly, how to make search for work you—is an incredibly valuable skillset beyond college.
• Learn how to manage information flow – For better or for worse, the information age is in overdrive, and all is in flux (thanks again, Bill). But there are tools and services to help you manage that flow, and it should be one of the goals of any university to help students learn how to manage that information. If we want to encourage students to expand their learning beyond the classroom (and I really think we should), then universities need to prepare students for managing the mass of information that comes with it.
• Learn how to produce meaningful, well-composed content and share it with others – Rob Wall argues that, in the 21st century, “creativity is the new technology.” Its incredible to think of the various ways people can produce and share content for equally various purposes. Anyone with an internet connection can sign up for a weblog right now, and begin producing and sharing content, right now. Anyone with an internet connection can produce and share data visualizations. Anyone with a computer and webcam can record and share video. Anyone who can search the web can find audio content, and create a podcast with it. With all of this opportunity for new ways to create narrative and share ideas comes a real need for universities to teach students new ways to compose those narratives and share those ideas.
• Learn how to critique content and methodology – Along with providing the ability to produce content in a variety of media, universities must provide the tools and skills to help students critique content, and discern the effectiveness and usefulness of particular technologies and media. One of the tenants of Mason’s PhD in History and New Media program is “critical optimism”. So, while we are optimistic about the changes that new media can bring to the practice of history, we’re critical about the specific methods that particular media employ. This is an approach that, I think, is already common in most classrooms. In my history course, I teach students how to critically read primary and secondary sources, and how to discern other methodological approaches to a particular issue. These skills are equally important—if not more important—when using and producing digital media.

2. Use free, open-source, and/or extensible tools whenever possible, and encourage faculty, staff, and students to do the same.

Universities spend countless millions on closed, proprietary systems like Blackboard and WebCT, systems that are very overbearing in their pedagogical approaches. In contrast, signing up for a weblog like WordPress is free (and there are plenty of other free options), and the uses for blogs in classes are limitless. While a little more difficult for the average instructor, Moodle is a free, open-source alternative to other learning management systems, and boasts a significant developer community contributing plugins and modules for extended functionality. There’s more this, though, than learning management systems: web browsers, word processing, screencasting, image editing, audio/video editing, to name a few. The specific tool, of course, should be chosen based on need and goals, but opting for extensible, open-source, and free alternatives will save universities money, provide more flexibility to instructors, and encourage the university community to do with software what it already tries to do with teaching and research: Contribute knowledge and resources back to the world.

3. Foster academic use of technologies that breaks down boundaries of the classroom, and the university as a whole.

As academic departments face budget cuts and lose staff positions if their enrollments are down, this may be the most difficult, but I think the most potentially beneficial, of all the goals. At the American Historical Association’s annual meeting in January, I presented on how I use technology to break down barriers to learning in my courses. Mills Kelly has written extensively on the future of the course, and argues that positive change in learning on university campuses will happen when students take individual responsibility for their own learning. Mills is particularly keen on the ideas of an iTunes-like class, where students can choose specific bits and pieces in a course that interests them. Others have spoken of the networked learner, and of learning environments that are not isolated from the rest of the world, but rather expand through a bottom-up approach. While I really like the potential for learning in a world without walls, I think there are some uses for the “artificial community” that is the classroom; Namely, that courses bring together people who would otherwise not talk to each other, and potentially allow for more diversity in perspectives. Learning based purely on social networking brings with it the danger of learning only inside the enclaves we create for ourselves based solely on who/what we like or who/what we’re comfortable with. But I think a balance can be struck, and I think universities should employ academic technologies to find and encourage that balance between classroom and independent learning.

So, there are at least three goals I think academic institutions should try to achieve regarding academic technology. Its certain good food for thought, and I’ll continue thinking about these goals for my own teaching and research. I imagine, though, that there are plenty more goals to add. So, lets help Jeff out. What would your academic technology goals be?

I also cleaned up a few custom plugins that I’ve used on ClioWeb and various other sites. These two plugins, CW Author Base and CW Page Categories, do some simple stuff, but they’ve been handy to me, so I’m sharing them here in hopes that they’re useful to someone else.

• CW Author Base—This is a really simple plugin that lets you change the base for author URLs in WordPress. You can already do this for categories and tags in WordPress under the Settings tab, but not author URLs. I think this should be part of the core, but its not. So, if you wanna change the author URL base, save this file as a .php
• CW Page Categories—Another very simple plugin that lets you add categories to a page. It includes a template function called cw_listcategories() that you can use in the sidebar to list pages under a category heading. You can also return an array of pages with cw_getpagesbycat($cat) and replace $cat with the category ID.

As always, if you have suggestions for improvement, or add you own code to these plugins, please share!

Front-end development usually can’t take place until decisions have been made about the front-end design (discussed in the last post). At CHNM, we’ve build projects where there was one designer, one front-end developer, and one back-end developer, all working in concert to build a project. And, we’ve built projects that had one person doing all three. Whatever your staffing situation, here’s what goes on in this phase:

• Photoshop mockups are translated into working HTML/CSS mockups
• Naming conventions in code are set and documented.
• Design is tested in browsers.
• HTML templates are then used to build out the final version of the site (in CMS, or as static pages)

1) Create HTML Mockups

To facilitate faster development of HTML mockups, I’ve created a “starter kit” that is essentially a directory with a basic file structure and pre-coded files for HTML, CSS, and JavaScript. You can download my example starter kit and take a look at how I set it up. The file structure I generally follow is:

	
/starter/
	index.php
	/c/
		screen.css
		print.css
		...any other CSS files.

	/j/
		global.js
		...any other necessary javascript files or libraries.

	/i/
		...any necessary images for the design. Background
                images, logos, etc.
	

My HTML and CSS files also have a basic structure I usually follow. My starter HTML file looks like this:

<body>
	<div id="skiplink" class="hide"><a href="#content">Skip to Content</a></div>
	<div id="wrap">
		<div id="header">
			<h1 id="site-title">Site Title</h1>
			<ul id="sitenav" class="navigation">
				<li><a href="#">Lorem</a></li>
				<li><a href="#">Ipsum</a></li>
				<li><a href="#">Dolor</a></li>
				<li><a href="#">Amet</a></li>
			</ul>
		</div>
		<div id="content">
			<div id="primary"></div>
			<div id="secondary"></div>
			<div id="tertiary"></div>
		</div>
		<div id="footer">
			<p>Footer Info</p>
		</div>
	</div>
</body>

This is a good point for the front-end developer to come up with (and stick to!) naming conventions for various ids and classes used throughout the site. I’ve found that using #primary, #secondary, #tertiary, and so on, gets me thinking less about the presentation of that content, and more about its relative importance. Its not a perfect solution, and sometimes I have to ditch this convention in favor of others, but the point is that you have a convention, and you follow it throughout your site.

My CSS file starts with generic styling of basic elements, followed by any global classes I use throughout the site, then moves on to each section of the page (wrap, header, content, footer). Here’s an example:

	

/* == Reset == */
@import url("reset.css");

/* == Generic styles ======== */
body {font:62.5% "Helvetica Neue", Helvetica, Arial, sans-serif; color:#222;
    background:#fff;}

/* Headings */
h1 {font-size:3.6em; line-height:1em; margin-bottom:1em;}
h2 {font-size:3em; line-height:1em; margin-bottom:1em;}
h3 {font-size:1.8em; line-height:1em; margin-bottom:1em; font-weight:bold;}
h4 {font-size:1.5em; line-height:1.2em; margin-bottom:1.2em; font-weight:bold;}
h5 {font-size:1.5em; line-height:1.2em; margin-bottom:1.2em; color: #999;}
h6 {font-size:1.2em; line-height:1.5em; margin-bottom:1.5em; font-weight:bold;}

/* Links */
a:link {}
a:visited {}
a:focus {}
a:hover {}
a:active {}

h1 a, h2 a, h3 a {text-decoration:none;}

/* Misc Elements */
p,ul,ol,dl,blockquote,address {font-size:1.2em; line-height:1.5em;
    margin-bottom:1.5em;}
ul {}
ol {}
dl {}
blockquote {}
address {}

/* == Wrap == */
#wrap {width:882px; margin:0 auto;}

/* == Header == */
#header {}

/* == Content == */
#content {}

	#primary {}
	#secondary {}
	#tertiary {}

/* == Footer == */
#footer {}
		
	

As you can see, I start out with some things already filled in (typography—font sizes, line-heights, margins), but some things I leave blank and fill in as I go. This is a personal preference, and I change things around from project to project. But this gets me started.

Using this starter kit, I build out HTML/CSS mockups based on the Photoshop mockups created in the last stage. I generally try to build the same pages that were presented to the project team, and strive to make the HTML version look and feel the same as the color mockups as much as possible. But, its important to remember than a design will never completely look the same in Photoshop and in the browser, and will rarely look the same across different browsers. Striving for pixel perfection to the color mockup across browsers, while sounding noble, ends up being a significant waste of time. The goal should be to make the HTML mockups look like the color mockups as much as possible, but also be usable and useful to the end-user. If one section of a site is bigger by one point on one browser, its probably not worth the time to figure out why. If its using a completely different typeface, then maybe you have a problem.

2) Test Mockups in Browsers

The advantage to doing HTML mockups before diving straight into the entire project is that you can 1) do the prototypes quickly, and 2) test the design in browsers before doing all the work to apply the design to dynamic content. At CHNM, we test in the following browsers:

Windows

• Firefox 3
• Internet Explorer 6
• Internet Explorer 7
• Opera

Macintosh

• Firefox 3
• Opera
• Safari

I try my best to test every single page, but I usually miss a few pages, so its good to have one or more people test your site on different browsers. When taking notes, I generally make a list that starts with the browse in quest, then a subheadings with the title and path of the page I’m looking at, and then specific issues for that page. For example:

Internet Explorer 6

Items Browse page – example.com/items/browse/

• Items content extends past page boundary
• Individual item titles not showing up
• Layout for main column and sidebar is broken (aren’t showing up side by side)

This allows me to first focus on a particular browser, then focus on a particular page (and know what its URL is), and get those issues working for that browser. I’ve found that a lot of issues on one page are similar to other pages, so solving it once usually fixes it globally. But, I like to note each problem on each page, because there may be other issues at play.

3) Applying to Dynamic Content

After you’ve completed HTML mockups and tested them in various browser, its time to use them when working with dynamic content. If your project is just going to be static pages, simply keep building out HTML pages as you did for the HTML mockups. But if you’ll be working with data in a database, now’s the time to learn a little bit about the kind of code you’ll be using to pull data into your HTML dynamically.

One piece of advice I can give on back-end development is: avoid reinventing the wheel as much as possible. That is to say, look to see if there are solutions available to make your development process easier before deciding to write something from scratch. With Omeka, the project team met early on and explored options for doing the kinds of things with wanted to do with other content management systems (Drupal, WordPress), and determined that the problems we wanted to solve required that we write something new. But even then, we did completely start from scratch. We use a PHP framework, Zend, as the base for the application, which makes development much more rapid and stable than if we wrote our own framework from scratch.

The data needs for a project can greatly impact the kinds of technology a project will need to use (or can’t use). I recommend that the development person/team make a list of any available content management systems, frameworks, and libraries and rate their qualities based on what your project needs to accomplish. For example, at CHNM we’ve use Drupal, Omeka, and WordPress for different projects based on their needs. We build Omeka, and we think it rocks, but its not right for every site. Neither is Drupal or WordPress, or any other CMS out there.

When I’m choosing a CMS or library or framework, I like to give myself some time to figure out how I would build the site with each one (if possible), determine which is most efficient and maintainable, and then go with the best choice.

Some examples:

Content Management Systems

• Drupal
• ExpressionEngine
• Joomla
• Moodle
• Omeka
• WordPress

PHP Frameworks

• CakePHP
• CodeIgniter
• Symfony
• Zend

JavaScript frameworks and libraries

• Dojo
• jQuery
• Prototype
• MooTools
• Yahoo UI

Many of you will be developing projects that rely on some kind of content management system that employs a theme API to pull content from a database. WordPress and Omeka are two such systems that I’ve worked with very closely, but other such as Drupal, Joomla, and ExpressionEngine are others that you might be using. One of the final jobs of the front-end developer is take the static HTML mockups she/he has created, and apply the HTML structure to the template files used in one of those systems. In some cases your front-end and back-end developer (if they’re two different people) will need to work together to make sure their individual contributions to the project can work together. A back-end developer, for example, may need to explain to a front-end developer about how certain theme API calls work and where to put them in the HTML template, while a front-end developer may need to explain to a back-end developer than the content a plugin generates needs to be in an unordered list with a specific id and class attribute. In short, there’s a point where the two types of development merge, usually a few weeks before the site launches.

This will also be a time when the front-end developer will have to account for specific kinds of content not covered in the HTML mockups. This will happen as content for the site gradually gets added to the database, and all the sections and pages for the site outlined in the site map emerge. You may have to add some specific styles for certain content. But the work you’ve already done will make this process much faster. Once you’ve done all of this, maybe run some more browser testing for anything new you’ve added since the HTML mockups, your site should be ready for launch!

Even though I had taken a digital history documentary class a few years ago, it still surprised me how much work creating a podcast involved. Like Dave, though, I’m pretty happy with what we came up with, despite getting a little rushed. Dave did a lot of work at the end, so most of the credit for the success of the first show should go to him. Thanks, Dave.

Our plan is to roll out a new THATPodcast show once a month. In February our show will cover Omeka, the free, open source platform for managing collections and exhibits now in development at the Center for History and New Media. We’re going to time episode two with the public release of Omeka, so be sure to check back next month!

ScholarPress

CHNM News and Dave have already pointed this out: Dave and I have started ScholarPress, a suite of WordPress plugins with academics in mind. We have two already out in the world, being downloaded as we speak, and a few more in the works.

The first plugin is Dave’s WPBook plugin, which acts as a bridge between a WordPress blog and a Facebook application. I’ve used the plugin to put my course information, pulled directly from my course website, in an application on Facebook that students can add to their profiles. Just another way to make course information available to students.

The second plugin, Courseware, was originally created by me and Josh Greenberg over the summer of 2006. I’ve used it for all of the classes I’ve taught so far. It gives you the ability to manage a syllabus, bibliography, and assignments through a WordPress blog. I’ve always set up a WordPress blog for my course site, and used Courseware to publish class assignments and meetings. The schedule page includes a link to subscribe to the schedule in a calendar application; it parses events marked up with microformats and creates a vCal file.

A few other plugins in the works:

• Gradebook—a plugin that works with Courseware to give instructors the ability to store and share grades securely with students.
• Bibliographer—I’m considering making the bibliography portion of the Courseware plugin separate, and beefing it up to do multiple reading lists, reviews, ratings, etc. Of course, it would work with Courseware.
• Footnoter—Would give post writers the ability to easily and quickly add footnotes to blog posts through the WYSIWYG editor of WordPress, and have the footnotes appear when hovering over the superscripted note.
• Highlighter—This plugin would allow readers to select a portion of a blog post or page and associate a comment with that selection.

Omeka

The biggest project I’ve been working on at CHNM for the past few months is Omeka. Put simply, Omeka is a simple platform to allow cultural institutions (museums, historical societies, libraries), or pretty much anyone, to manage and publish items, collections, and exhibits on the Web. We’ve used earlier versions of Omeka to power the Hurricane Digital Memory Bank and Object of History, and we’re using the latest releases of Omeka to run a few projects currently under development, like Gulag: Many Days, Many Lives, which is set to launch at the end of November.

If you’re interested in getting on the list of beta testers before the public release (which is early March), visit Omeka’s website for more information.

• Main Page
  • Subpage One
  • Subpage Two
  • Subpage Three

You’d want to list the same subpages on both the Main Page and the respective subpages. I came up with a simple solution. First, we need to query the post to get its information. So I set up a PHP variable $page and set it equal to $wp_query->post;. Then a create another variable called $parent_id and do a database query to get the ID of the $page variable’s post_parent. Of course, if $parent_id is empty, then that means the page has no parent, and is thus a Main Page. So, for this case, I throw in a simple if check that will set an empty $parent_id to the page’s ID, which is found using $post->ID. The full script for finding this info, which I put in the <head>, is:

1. <?php
2. $page = $wp_query->post;
3. $parent_id = $wpdb->get_var(“SELECT ID FROM $wpdb->posts WHERE ID = ‘$page->post_parent;’”);
4. if(!$parent_id) $parent_id = $post->ID;
5. ?>

Then, to actually generate the HTML for the page list, I use the following code in the body of my page template:

1. <?php if(wp_list_pages(“child_of=”.$parent_id.”&echo=0″)): ?>
2. <ul id=”subnav”>
3. <?php
4. wp_list_pages(“title_li=&child_of=”.$parent_id.”&depth=1″);
5. ?>
6. </ul>
7. <?php endif; ?>

In a nutshell, the second part of the script does two things. First, an if statement checks to see if there are in fact subpages for the page’s value for $parent_id. That’s the <?php if(wp_list_pages("child_of=".$parent_id."&echo=0")): ?> line. So, if a page doesn’t have subpages, it won’t generate the unordered list. Remember, if the page is a Main Page, $parent_id is the page’s ID (see the explanation above). Second, if the first check goes through, then the script will generate the list of pages using the wp_list_pages() WordPress template function, using the $parent_id in its argument for child_of. For more info on how the wp_list_pages() works, see the WordPress Codex page Template Tags/WP List Pages.

There might be better solutions for this kind of problem, but I thought I’d share it and see if there are ways to improve the scripts. It’s working pretty well for me, and I think there are multiple ways to use this kind of page query to make page-specific additions to your site. I do need to come up with a solution for multiple levels of pages (two or more levels deep). If anyone has thoughts on that, please leave a comment!