William Wade

It is often difficult for someone outside of a small group to understand the problem at hand or to imagine possible productivity boosts that technology can provide. Working with and learning from the group, who will be using the technology, brings quality solutions to the forefront and smooths implementation. Technology can solve many problems, but using it like a sledgehammer will only cause more troubles.

In 2010 at the Soft Wheat Quality Lab, I found a lab standing on the advent of data overload. New machines and processes were collecting more and more data. After working and learning the current processes, I designed and built a custom database and interface that enabled the lab to handle the new data easily while allowing a smooth transition for the old data. The system was released gradually while being constructed. I used the system as I built it and was able to incorporate feedback quickly.

I have worked with several libraries and platforms.

Preferred:

• HTML5/CSS3/Javascript
• jQuery
• MODx
• PHP
• Yii Framework

Others:

• Amazon Product API
• XML
• MooTools
• WordPress
• Joomla
• CodeIgniter

I can work with almost any CMS and website. I handle design, design-to-template, content, administration, and any combination of these. Links to clients and some of my work is under History - Contract Jobs.

Server OS Skills

• Linux - Expert
• BSD/Unix - Intermediate
• Windows Server - Intermediate
• OS X Server - Novice

Server Services

• Apache/Web - Expert
• Bash Script - Expert
• FTP - Expert
• MySQL - Expert
• Samba - Expert
• Active Directory - Intermediate
• NFS - Intermediate
• OpenSSH - Intermediate
• Rsync - Intermediate
• LDAP - Novice
• Postfix - Novice
• Proxy - Novice
• iptables - Novice

Desktop Skills

• Linux
• Windows
• BSD/Unix
• OS X

In 2008, Bryan College had a problem. The college application for admission was outsourced to a multi-college system. We suspected that the redirection to a different domain alone was costing us applicants as well as the length of the application. We were also unable to gather contact information from partially complete applications and were retyping the application into our student information system.

We choose to develop our own system that would integrate with our existing student information management system. We began to inspect our application and try to discover what was essential information needed. Through the process, I managed the developer and communication with the various departments. When we had finished, the average application completion time decreased by 75%. The applicants were using an application that was consistent with our brand. Status notes and documents for the process to acceptance were available to the applicants 24/7. We also gathered all of the information directly into our recruiting and student information system. Bottom line result was that the new application directly contributed to almost double the number of yearly applicants.

While managing the application project, we worked hard to simplify and clarify the application process. The information collected on the application was important for five different departments, each with different information needs. Yet, the system was confined to the structure of the current student information system. I balanced needs and communicated with each department to produce the best possible experience for the applicants.

When I arrived at the Soft Wheat Quality Lab in 2010, the lab was storing information in a multitude of locations and formats. There had been some attempts at compiling limited databases in Microsoft Access, but these were ill constructed and fell far short of the needs.

I designed an implemented a system that smoothly transitioned the lab to a relational database with a web based interface. Each step of the current process was learned before designing the new system. Data input methods varied based on needs and experimental methods. The system remains dynamic and allows for easy creation of new forms and import templates. Lab members easily adjusted to new methods as the system mimicked the best practices they developed.

In 2009, I met with several college friends with whom I had worked on drama and theatre in the past. I had a crazy idea, design a 30-45 minute program with drama and dance and take it on tour for a month. I designed a general show template, and collectively we designed each piece.

While creating it was important for me to help the team keep focus on the end goal. If a section was at an impasse, I would either make a choice from the options or we would move on and return to the section at a later time. The creative process had a lot of changes and these often disrupted previous features we liked. The end result was a path that was littered with discarded good ideas, but it led to quality.

I believe that personal discovery is critical when teaching how to work with computers. Learning a recipe allows the student to only perform an action in a particular situation, but computers are constantly changing. Students who can discover solutions on their own are often able to handle changes without additional training.

When teaching a concept, multiple ideas need to be transferred:
Why does this work?
What does this do?
What other forms can it take?
What might make it not work?

I have also had the opportunity to teach basic computer skills cross-culturally in the Philippines. I had to learn how to communicate the basics of desktop computer usage and encourage exploration.

In the summer of 2007, I started the first survey of historical mining remains of the Dayton Coal & Iron Company in Dayton, Tennessee. I received a grant from the Appalachian College Association and worked all summer locating and attempting to identify sites from company records and physical remains. The project was carried out independently communicating regular reports to two advisers.

The research has recently enabled funding for more detailed surveys and supports a future bid for the site to become a registered historical location.

In 2011, I first had the idea of building a random product picker using Amazon.com's Product API. All of the work on Browse The River is mine, from the design, art, and programming. The most difficult part was working with an API that was built to show people what they wanted, as I needed items that people might not.

This was my first experience working directly with a full "cloud" API. It also exposed me to some of the risks of working with the "cloud." Amazon discontinued a function I was using to reach into the unselling depths of their catalog. However, Browse The River is always finding new ways to show the world random products.

In the spring of 2011, I wondered what the world of Douglas Adam's Hitchhiker's Guide would look like if the galaxy had Twitter. Would the Vogons be able to trim their poetry to 140 characters? What would the news media be spreading, and most importantly what about the spam?

Several chapters have been written, but you will have to wait until mid-2013 before we launch.

We gathered a total of five people and began to choose music, themes, and possible locations. Before long I was creating a website, contacting locations, and writing script ideas. We spent a full week before traveling creating and perfecting each piece. The show was well received, and ended with our largest audience of approximately 1,000.