Thursday, January 10, 2008

HighEdWebDev '07

A few months ago, I went to the HighEdWebDev conference in Rochester, NY.  The following is a document I sent out of ideas derived from the conference that I thought I could apply to myself or that may be useful for our development group in general.

HighEdWebDev Conference, 2007: Rochester, NY

This is just a rough fleshing out of various ideas that came up during the conference.  I don’t know how much of this is feasible, but I thought I’d put it out there.  I did this in some order of relevance, so the ideas get more far out there as you go on. 

Testing

-       Set up a testing rivalry.  We could either do this between developers in our group, or this may be a means to work on the relationship between us and Michael Hodges group.  The idea would be to pass off systems to each other for testing.  The goal would be for the testers to find as many non-trivial issues as possible with there being an award for the group with the lowest defect rate.  The metrics on this would need to be worked on since a large project will inevitably have more defects than a small one, so maybe defects as a measure of lines of code?

-       Hire a tester.  Maybe some students or a contract worker that we bring in at the test phase of major projects.  The idea is that the ideal testing situation is to bring in someone with no ties to the project, someone where their sole goal is to find errors, without the thought that they have to fix it. Developers hate searching for bugs because we have to fix it, a tester has no such conflict.  On a related note, it would be great if the tester also has a usability background.

-       Get the ICS department involved. At the least, I can pitch the idea to professors about giving a class day to evaluate our interfaces.  Or we could make a contest where students who break the system get a prize.  Maybe we could arrange a work/study?

-       If we don’t already have one, it would be good to have a “best practices” document for testing.  It would cover all the standards (test all value limits, put in wrong data types, etc) as well as things that we may not immediately think of such as disability testing, or getting the site to work on mobile devices.  We could include a checklist that people have to go through and sign off on at the end to make sure they really think about the items.

-       Have some machines that are set up for disabled users, or get the most popular adaptive tools to run on our own machines.  Right now, I have no idea if eCAFE will work for automated reading software, or any of the other tools that people with disabilities use.  It would be great to have an old machine somewhere that’s set up with the different adaptive tools so we can make sure it works.  At a minimum, perhaps we could buy a few adaptive tool licenses to set up accounts on our own machines.  BTW, some schools have a disability office, do we?  If so, maybe we can talk to them about it.

Emergency Communications

I know this really isn’t our group, but the V.Tech people gave a talk, and it seemed a pity to just ignore it.  Also, there are other things we can do in addition to the text message broadcast that’s being worked on right now.

-       Have a backup page with minimal content and no graphics ready to go, along with the means to redirect users to that page.  When the event happened, their usage went from 15GB/day to approaching 400GB a day (193,000 hits to 2,300,000, a 1087% increase).  He emphasized that you need to have backup server capacity along with the “lite” page that load fast.  There also needs to be a crisis plan, as in who handles what.  The plan should have a strict layout of responsibilities so people know who to go to for what.  The web content guy kept hearing rumors and items presented to him as “facts,” but he knew he could only post information that came from one specific person who’s job was to verify the information.  This helped eliminate bad information from getting on the site.

-       Create a means to add a banner to all UH pages for the display of emergency notices.  Perhaps create a widget that’s embedded in the UH banner and will show a notice if posted?  Or just one that people can add to their pages that will automate the task.  Consider what happens when email isn’t available, this would be a good way to let everyone know what’s going on.

-       Have people voluntarily register their IM addresses and set up a system to send them a message if they’re on. 

-       Set up a blog of sorts that contains all important messages.  The blog could have an RSS feed that people can subscribe to.

-       Create a Facebook widget: I need to look into this, but some schools were talking about using Facebook to get the word out since many of their students had accounts there. My understanding is that Facebook allows people to create widgets/applications that users can download onto their pages.  Given this, we could create a widget that posts UH related notices, and/or events that students can add to their personal page.  I hear Facebook is offering money to developers for useful widgets, maybe we could get a piece of that.

-       Facebook flyers. Facebook has a program where you can buy “flyers” that get displayed to specific users.  It’s $5 for 2,500 page views.  In an emergency, we could pay Facebook to post flyers to all users with UH listed as their school.  We can specify if we want the flyers to be shown to graduate students, undergrads, or even alumni.  We can also specify the time period during which the flyers are displayed.  On a related note, this could act as advertising, like when eCAFE goes into wide release.

Tools:

-       Write or buy a generalized tool for automating build/release processes.  Something that does the build, sends the war to the destination, shows a “down right now” page, etc.  It’d be a bonus if we could include a widget in our sites that show a countdown to downtime.

-       Write or buy a tool to automate getting our Oracle tables and dumping them into another Oracle db, a local MySql database, or even just files.  It would be great for making our own in-house backups for when we’re about to make a bunch of changes and want to be able to compare the differences afterwards.  I don’t know if it’s possible, but a program that automates copying data from one db to another would be great, as it would save us from having to bug Jason a few times each semester.

-       Use a spider program that crawls our pages looking for broken links.  I don’t know if the main site uses this, but I doubt it given the dead links I’ve seen.

-       Get a few of the most common mobile devices, along with a checklist for developing for such devices.  The idea here is that many students are using cell phones, pdas, iphones, etc.  We could have more access to the students, and perhaps more responsiveness from them if we made sure our sites worked on those devices.  Like the “best practices for testing” idea, we could have one for this as well, and have a few in-house items to test on.

Blogs

My initial thought on this was that it probably wouldn’t be too useful to us, but upon further reflection, there are a number of possibilities for it.

-       Project specific blogs.  This would be a place where we keep users up to date on the progress of a project.  The deeper I get into users and eCAFE, the more I learn it’s ALL about communication.  To have a place where people can go to get the status of a project may be useful.  The blog, if started at the beginning of a project, could act as a history of the project.  If you let potential users (like teachers we have a relationship with) know about it, they could see how plans are shaping up and provide their input before we head into development. As the project matures, it could talk about why certain decisions were made, successes, failures, and lessons learned.  The advantage to this is it would personalize a project, giving users the realization that there are real people working on it, and that their input does affect what happens rather than thinking of it as a black hole.  It could also offer a place for user input (that everyone can see = accountability) as well as list future features.  It also provides a built-in means for searching a project for something, as well as keeping everything in a cronological order so there’s no question as to what the most up-to-date documentation is.

-       Have developers set up “Professional Blogs.”  We could all list our skills, current projects, etc.  This would help new hires know who to go to for help with specific things.  The blogs could also be places where we share technical book reviews, a listing of what books are in our offices, ideas (like this conference write up).  It could also be used for promotions if someone takes it in that direction, sort of like an extensive C.V.

-       If we did either of the above blogs, we could set up an RSS feed them all to a site where we talk about what’s going on in MIS.

Podcasts and iTunesU:

With the exception of the first idea, these likely have little relevance to our group, but I thought they were fascinating.  You can throw these out if Lassner is ever looking for new things to do (assuming you like them of course), as I don’t think we’re doing any of this right now.

-       Get video recording software that records actions on a screen.  We can use this to record typical actions that a user would want to do in one of our systems and post them as demos of individual tasks.  So the next time an instructor emails me about “How do I…”  I can point them to the video to see exactly how it’s done.

-       While podcasts in a University context are usually associated with lectures, it doesn’t have to be.  It can include visiting lecturers, special presentations, open houses, student projects, student interviews, student “storycore” (ala NPR), walking tours of campus, professors introducing their own research or research groups, or even our own “brown bags” topics for those who couldn’t go, etc.  These can be used as a recruiting tool to help students get a sense for what happens outside of class, or just to keep people informed of what’s going on.  Some campuses have started using it as an extension of their campus newspaper, so they have roving reporters that record on the spot interviews about whatever the topic of the hour is.  As a bonus, the content can be leveraged onto the main page via RSS feeds.

 

-       Bonus content or audio review.  Some campuses reported that their instructors were reluctant to record their full lectures since they feared students wouldn’t come to class.  One campus’ solution to this was to have professors record “learning objects.”  These could be short snippets that review a particularly difficult concept, or just an audio recording that students could listen to while reviewing their notes from class.  The students would still have to come to class, but they could get a refresher from the audio.  Some professors also offered “bonus content” where they covered related ideas for those who are interested, or offer extra credit.  The audio-only approach also works for foreign language courses, as faculty to include pronounciation cues.

-       Professors could offer a “course preview” via podcast.  They would record their first day of class so students could get a feel for what to expect and help them decide which class/professor they wanted to register for.

From the “Far-out” files:

-       Get someone certified in Usability.  Since hiring someone with this seems unlikely, we could train someone.  There’s a 10 day certification course offered by Usability International.  I think having a usability expert in house would be second only to getting a testing team (well, and a designer, once we lose Sandra), but it seems easier to obtain.  There are probably other programs to accomplish the same thing. 

Believe it or not, that’s the greatly condensed version.

No comments: