Archive for the 'Development' Category

How fast can a blind person read?

Tuesday, November 3rd, 2009

An image capture of a web page with the transcription of a Civil War-era letter displayed

You think you’re a fast reader?

You might change your mind after you listen to this recording (mp3, 4:12, 2.4MB) of a Civil War-era letter being read aloud by a "screen reading" computer application called JAWS.

The letter is one of the items in the rough draft of our "proof-of-concept" Omeka archive with an accessibility plugin (created by Cory Bohon with input from George H. Williams) designed to make navigation easier for the visually impaired.

We’ve developed a plugin for Omeka that allows a user with visual impairment to use “Access Keys” to navigate through the site by sound and memory, instead of viewing the menus and links visible on the screen. Our goal is to have a finished, working demonstration of this plugin installed on an Omeka archive of nineteenth-century documents by the end of Fall 2009. (We’ve chosen these documents simply because they were already digitized and available to us with metadata.)

In this mp3 recording, the enduser running JAWS is Marty McKenzie of the South Carolina School for the Deaf & Blind and the South Carolina Department of Education.

The other voices are Tina Herzberg, assistant professor of education at USC Upstate, and George H. Williams, assistant professor of English at USC Upstate.

The image, transcription, and metadata associated with the letter (and many other items) were generously shared by the archivists and librarians working with the Littlejohn Collection at Wofford College.

Creating Screencasts: The Definitive Guide… (not really, but isn’t it nice to think so?)

Thursday, October 1st, 2009

By George Williams and Cory Bohon

Overview

Screencasts can be a great way of showing people with basic computer skills how to accomplish more-than-basic tasks. When they’re done well, screencasts illustrate a technical and otherwise potentially confusing topic in a way that anyone who has used a computer before can understand. You create a screencast by recording and narrating your on-screen computer activity as you accomplish any number of tasks on your computer:

  • accessing online course material,
  • searching a library database,
  • formatting a Microsoft Word document,
  • or–and this is one of the things we’re doing at Look, Listen, Touch–demonstrating how screen reading software (like Apple’s VoiceOver on Mac OS X or JAWS on Windows) allow visually impaired users to access digital information.

Sites like Screencasts online monetize on the screencasts by offering up how-tos for various software applications. Their screencasts are edited with professional software, but they still follow a screencast recording structure similar to what I will talk about below.

Software Options

There are many options available to the would-be screencaster, but these are some of the most commonly used tools:

Tools for capturing video of the activity on your computer screen

ScreenFlow
$99, Mac only. [Insert other details here]
QuickTime X
[Rephrase this: (Included in the most recent OS upgrade). Insert other details here.]
Jing
Free for the basic version. $15 per year for the “Pro” version. Produces quick-and-easy but unpolished videos and audio tracks ready for publishing. [Insert other details here]
Camtasia
$299 for the Windows version. $99 for the Mac version.

Tools for editing the video that you capture

iMovie ’09
iMovie is Apple’s consumer-leve (but still powerful) video editing application. It allows you to import your recorded screen capture to add voice over, text and subtitles, and fade ins/outs to make your videos more polished and professional looking. [Insert some additional details here?]
Windows Movie Maker
[Insert some details here.]

What to consider when choosing your tools

There’s no perfect set of tools that everyone should use; each has its own strengths and weaknesses. Your choice will depend on several factors, including price and operating system, which are detailed above. You should take the following factors into consideration:

Audio quality and flexibility
ScreenFlow or Camtasia allow you to capture the full audio from the computer, while also giving you the option of capturing audio from your computer’s built-in microphone. By contrast, QuickTime X or Jing only allow you to capture from the computer’s built-in microphone, making computer audio less than stellar because of background noises.
Ease of use
If you want to quickly and effortlessly capture your screen while briefly talking about a subject and publish out for your audience, then Jing might be right for you since it has a built-in publishing platform that gives you a clean and simple URL to share your capture.

The step-by-step tutorial below describes the process as it works in a Mac OS X (Snow Leopard) environment using Screenflow (or QuickTime X) for screencapturing and iMovie ’09 for post-capture editing.

4-Step Process

Step 1: Record your screen activity

In ScreenFlow, select the camera icon in the menu bar and select “Record…”

Screencast Showing How to Start a Recording in Screenflow

In QuickTime X select File > New Screen Recording, and in the resulting window click on the record button.

Screenshot Showing How To Start a Recording in QuickTime X

Step 2: Export what you’ve recorded

Directions for ScreenFlow

Click the camera button in the menu bar and select “Stop Recording”

Screenshot Showing How to Stop a Recording in ScreenFlow

Once the video opens in the preview window, select File > Export and change the following settings:

  1. For the Preset select “Web - High” and then click the “Customize” button.Clicking Customize on ScreenFlow Export
  2. In the resulting window, select the “Settings” button underneath the “Video” sectionScreenshot Showing The Selection of the Settings Button for ScreenFlow Exporting
  3. Set Key Frames to “All,” Data rate to “Automatic,” Compressor quality to “Best,” and the Encoding to “Best Quality – Multi-pass”
  4. Click “OK”Screenshot Showing How to change specifics in Screen Flow Export for Steps 3 and 4
  5. Uncheck the “Prepare for Internet Streaming checkbox”
  6. Click “OK”Screenshot Showing How to change specifics in Screen Flow Export for Steps 5 and 6
  7. Under Dimensions, do a scale by of “100%” and click the Export button. The exporting process will take about 20-40 minutes depending on video length and processor speedScreenshot Showing the final Export options for Screenflow

Directions for QuickTime X

From the menu bar, click the stop recording button

Screenshot Showing How To Stop a Recording in QuickTime X

The movie will automatically open in QT X and allow you to export it

From the Share menu, you can quickly export it to iTunes, YouTube, or MobileMe

  1. iTunes export
    1. Select Share > iTunes
    2. Select “Computer” for the size as this is the top quality export that it provides
    3. Click Share

    Screenshot Showing How To Export to iTunes from within QuickTime X

  2. YouTube export
    1. Select Share > YouTube
    2. Signin and validate your account
    3. Type in the metadata and
    4. Click Next and Then Share
    5. Your video will be exported and uploaded to YouTube using the metadata that you just provided.

    Screenshot Showing How To Export to YouTube from within QuickTime X

Step 3: Edit the video you’ve captured

If your project requires speed more than it requires polish, then you don’t need to do much (or any) editing. In fact, for a quick and basic screen capture, you should probably just use a tool like Jing from start to finish to capture and upload your screencast.

However, if your project requires a more polished and professional screencast, then you’ll want to use a tool like iMovie. Editing and recording a voiceover will take more time than using a tool like Jing, but the results can be worth the effort.

Importing your videos

  1. File > Import > Movies; Import all of your recoreded screen captures
  2. Your videos will be imported (copied or moved; although moving the files will decrease the amount of space used) to an “event” that is created in iMovie. You can name the even whatever you’d like, but I’m calling mine “VoiceOver Screen Captures.” All of your imported videos will go here.

Screenshot Showing the Importing of videos into iMovie '09

Adding videos to the time line

  1. You can add your videos to the “timeline” by dragging and dropping the original files from the event to the above timeline
  2. Adding titles and fade ins/outs is as easy as clicking on the appropriate buttons in the toolbar and adding them (this will be different for your specific video editing application)

Adding Video To iMovie '09 Timeline

Exporting your videos with the highest fidelity

  1. In iMovie.app click Share > Export Movie
  2. Type in the appropriate file name
  3. Click the “HD” export option — this will give us the highest quality file
  4. Click “Export and the video will begin exporting to the location you specified

Export from iMovie '09

Step 4: Upload and share your screencast

  1. You can now upload the resulting .mov file to YouTube, Vimeo, or your favorite video sharing website.
  2. You will end up with a mid-range file size of roughly 40MBs for ~6 minutes of video.
  3. The file upload to YouTube or Vimeo will take around 10-15 minutes from a fast Internet connection

Are Access Keys The Future Of Universal Access?

Friday, September 25th, 2009

by Cory Bohon

Image of Keyboard

Universal Access is an interesting topic and while many companies are trying to be innovative in this area, there still needs to be more work with regards to Universal Access and website design. Most web designers (myself included) don’t spend a lot of time thinking about how the end user will access the site. Many of us spend the time to make the site look pretty or achieve an important function without paying attention to things like screen readers, refreshable braille displays, or other asistive devices for the sighted user, tactile user, or auditory user.

Access Keys could be a potential use in designing accessible web pages. By adding a bit of HTML code to a link, we can give a new type of behavior to the web browser. Users can use modifier keys and the specified access key to jump to different links on a web page. While some developers use this type of technology, which has actually been around since 1999, it’s use isn’t as prevalent as it could be.

The UK has actually specified a standard of sorts for access key usage. It goes something like this:

  • S – Skip navigation
  • 1 – Home page
  • 2 – What’s new
  • 3 – Site map
  • 4 – Search
  • 5 – Frequently Asked Questions (FAQ)
  • 6 – Help
  • 7 – Complaints procedure
  • 8 – Terms and conditions
  • 9 – Feedback form
  • 0 – Access key details

While these rules aren’t imposed on web designers, it is considered good use to develop pages using these access keys. I would love to see the US follow similarly for web design principals. If we could start using these access keys on more websites it would make them universally navigatable by different users.

One hitch to using access keys is that the web browser developers all use different modifier keys to make them work. Google Chrome uses “Alt,” Internet Explorer uses “Alt,” and Opera uses “Shift + Esc.” Apple’s Safari is the most confusing of them all, if you are using version 2.0, Mac users use “Control” while Windows users use “Alt”; if you are running version 3.0, Mac users use “Control + Option” while Windows users use “Alt.” How do you convey to your user which key they should use? If the user isn’t tech savvy, how will they know what they’re running, let alone which version? All of these differences pose problems in standardizing the usage of access keys. This is one of the things we’re trying to figure out.

You can read more about access keys on Wikipedia and WordPress.

Web Accessibility: Do We Need Changes?

Thursday, September 24th, 2009

Since last week, I’ve been working on this research project with Professor George H. Williams at the University of South Carolina Upstate. We’re trying to find out the best practices for developing accessible web sites while keeping Digital Humanities in mind. We are attempting to turn Omeka, a CMS for digital cataloging, into the most accessible form of accessing scholastic information no matter a persons disability.

While I was thinking about the different techniques we could use to make these accessibility options available, and I pondered a cool idea. What if, in the same way we can use OpenID to log into multiple websites, we could use a standard accessibility options “plug-in” that anyone could install/code into their site to make it more accessible. Different preferences, like the ability to use a screen reader or use a braille display, could be carried from one website to another without the user having to setup these options again.

Perhaps this task could be completed easily with a Firefox extension that could communicate with the code on the website to load a specific CSS file that would allow for better interaction with a screen reader or braille display.

There is the possibility that someone has already come up with and implemented this idea of a tool for universal web accessibility, and if you know of a project that currently does this same thing or does it better, feel free to leave a comment and let us know!