The Dream:

Build a tool to allow access to Olive customer sites

As many Olive customer sites are authenticated (behind a paywall), Olive developed a methodology to interface with any subscriber/circulation system. Authenticated users are returned to a protected Olive site via an "authenticating" URL, which contains, among the various query string parameters, and MD5 hash value based on a shared secret passphrase. To improve Olive's (and, initially, my own) ability to troubleshoot problems and manage the vast number of client sites we have, I built a tool ("QA Authenticator") that not only lists all of our client sites, but, as needed, will generate the site-specific authenticating URL.

Initially built for my own use, this tool evolved into a company-wide resource for the Professional Services, Production, and Sales departments.

The Thought Process: Challenges

The first iteration of this tool used a JavaScript include as the data store. As I learned jQuery and its AJAX function, I rebuilt the site using jQuery and jQueryUI, with an XML datastore. I then created an Editor tool to allow Olive personnel to edit the content of this XML datastore. As XML is quite heavy, the next (and current) iteration replaced the XML with a JSON datastore.

The Build:

The QA Authenticator tool has been used at Olive for over ten years, and is currently on version 6.1. Because this site contains proprietary data, it is not publically accessible. While it does run client-side, it is fully mobile compatible using CSS3 media queries and manually set breakpoints.

In addition to being used internally, certain large multi-publication clients have been granted access to stripped down versions of QAA that allow them only access to their publications.

The Dream:

Update Isle of Man Manx Heritage Archive Site

Along with digital replica editions, Olive offers an archive inteface providing browse and search access to scanned historical data. The Isle of Man government purchased Olive's ActivePaper Archive application to be hosted within their own data center in Douglas, Isle of Man. I travelled to Isle of Man in April of 2010 (and was subsequently trapped there thanks to the eruption of Eyjafjallajökull) to train them and set up their archive site.

Then, in 2016, Olive updated our archive application from APA v3 to APA v5 (moving from an ASP based desktop-only application to an HTML5, ASP.NET-based, responsive design). With the new version came the opportunity to redesign and rebuild their archive site, all done remotely.

The Thought Process: Challenges

I worked extensively with the Isle of Man team on their redesign. They wanted their site to integrate smoothly with non-Olive "Newspapers" site. Once the design was finalized, I built the mock-up within the Olive self-hosted environment, and, once the skin was approved by the client, I remoted into their environment and performed the software and skin upgrade.

The Build:

The build was completed to the customer satisfaction. Now users of the Isle of Man library archive can search and browse all thirty-two (and counting) publications contained within their Olive application, both on desktop and mobile devices.

This site is behind a paywall, so no demo is available.

The Dream:

Redesign of the Chicago Tribune digital replica edition

When initially onboarded by Olive Software, the Chicago Tribune and other Tribune Publishing titles where configured using Olive Software's standard "Olive Digital Edition" template. However, as this did not match the design and feel of Chicago's dot-com site, in 2013 they contracted for Olive to redesign their digital replica edition. Eager for the challenge, I volunteered for this task.

The Thought Process: Challenges

The Olive Software skin (UI) architecture was based on a template (containing all common and default elements of an Olive skin) and a "skin" (delta files specific to the publication implementation). The Olive Digital Edition application was built on a ASP.NET back-end with custom Olive handlers and controls, and tied into a Flash-based publication viewer. (Olive has since retired the "Olive Digital Edition" application, replacing the Flash component with a pure HTML5 display.)

The Chicago Tribune design was significantly different from the Olive template, while maintaining same basic functionality. I had to decontruct the original template, isolate each component, modify as needed, and build a new template following Tribune's design specifications. In addition, the new UI had to be in itself a new template, as Chicago was only the first of the Tribune publications to use this new design.

The Build:

I was able to successfully implement the new design, and replicate this across ten publications. When I was unable to interpret specific handler behavior, I was able to isolate the specific questions that needed answers and received necessary assistance from my R & D team in Israel.

The customer was very satified with the revised design, and used it for several years. It was only when Olive retired the Flash-based ODE that Tribune, now TRONC, chose another replica edition vendor.

The Dream

Initial build of my personal/professional website

After studying HTML5, CSS3, and jQuery, in 2011 it was time for me to build my own website. I wanted to showcase my technical and design skills, as well as build a site that was unique. While I remain proud of "version 1" of rbrianredd.com, the navigation is non-intuitive, and many aspects of it are now dated.

NOTE: This was pre-Bootstrap, so the carousels that are in place were coded by scratch in jQuery.

The Thought Process: Challenges

Along with the aforementioned manually coded carousels (I built my own carousel prototype and reused), the original rbrianredd.com contains many CSS3 effects to provide movement, and heavy use of jQuery to provide navigation (mousing over the five icons around the central gryphon will display menu detail, and clicking will open a modal, also manually encoded). The page makes heavy use of iFrames to access multiple pages within the site's structure.

While initially I intended to make the site responsive, this never came about (until the advent of version 2 of the site).

The Build:

This site suited me well for several years, until my studies of Bootstrap, and more advanced JavaScript libraries/frameworks (Angular, React, etc) prompted me to revisit it; thus the current redesign.

The Dream:

Update the Bartlett Innovation Group website using Angular

One of my previous coworkers showed me his website, www.big-inc.net, and as I was learning Angular at the time through Coursera, I offered to update his website for him. He was glad to accept the offer.

His origina site was initially built quickly from a template, and was full of styling errors, badly designed functionality, and an overall poor user experience (UX). As it had been designed to replicate the effect of a single-page application while not actually being one, it seemed to perfect opporuntity for me to cut my Angular teeth on.

The Thought Process: Challenges

The original site was built of four different pages; I redesigned this as a true single-page application using Angular 2. Doing so allowed me to not only clean up the styling errors, but to improve the overall feel and experience of the site while maintaining the original branding and content.

The Build:

As this was my first solo Angular project (without following the lead of a professor or lesson plan), it acted as a good test of my Angular skills. While Angular is ultimately designed for more data interaction than this site required, the general navigation and component structure of Angular resulted in a clean user experience.

The one challenge we have since run into in terms of doing a true deployment of the new site is that BIG-Inc's current hosting is offers limited support of Angular. We continue to work on getting a solution to this. In the meantime, a deployment version is visible here, and the source code is available on my GitHub here.

The Dream:

Convert a Photoshop mock-up into a functioning website

As I did in 2011 (see RRT PSD to Web Code Challenge below), in 2017 I took a coding challenge to convert several multi-layered Photoshop PSD files into functioning website. Like the RRT challenge, this was to be as close to pixel-perfect as possible; unlike RRT, Ten Realty was already had the requirement of being adaptive and mobile friendly. I was given four PSD files of differing breakpoints and tasked with making an adaptive website.

The Thought Process: Challenges

While I was allowed to use any technologies I wished, I discovered that the breakpoints of the four PSD files did not match the defaults available in Bootstrap. I found myself, therefor, determining my own breakpoints and building the site mobile-first using SCSS (Sassy CSS).

The Build:

The project was completed within a week (working on it part-time) and impressed the team reviewing it. I had learned from my experiences with the RRT Code Challenge (along with several additional years of web development under my belt), and this challenge proved to be an exciting and fun one to perform.

The Dream:

Convert a Photoshop mock-up into a functioning website

In 2011, I took a coding challenge to convert a multi-layered Photoshop PSD file into functioning website. This site was to be as close as possible to a pixel-perfect replica of the source document, and was to not only use the latest available technologies, but also remain fully IE6 compliant. I was given a week to complete this task.

The Thought Process: Challenges

As they say, the only way to eat an elephant is one spoonful at a time. The first step was to isolate the different components (navigation, content boxes, etc) of the PSD and reconstruct them in HTML. Then, using extracted graphics from the PSD and CSS, i converted the framework of the website into a fully functional version of the mockup. Some components (rounded corners, etc) were particularly difficult, as IE6 did not support CSS3. While CSS3 was employed, IE6 fallbacks were also implemented.

This was the first instance where I used the carousel code I later employeed in rbrianredd.com and other sites (remember, this was pre-Bootstrap).

The Build:

The project was completed by the deadline, and met with resounding approval by the team reviewing it.

Some items of the initial coding (in-line JavaScript, etc.) was brought to my attention, and with the experience of my first build under my belt and encouraged by feedback I'd received, I built a second version of the site in just under two days (available here). For the second version, I made it mobile responsive and improved the overall coding.

This was an invaluable experience.

The Dream:

Build a new site for Opinicus Soaps

When my wife started her handmade soap company, Opinicus Soaps, she set up her website through a hosting/shop solution, and was forced to use their template to create her site. To create a better site, she turned to me to build one from scratch, using HTML5, CSS3, and jQuery.

The Thought Process: Challenges

I worked with my wife to collaboratively design a new website, utilizing the newest techonologies available in 2012. Navigation is tab-based, with multiple pages containing information on products, processes, and what current Renaissance Festival her shop is at. In addition, it looks to her separate store site where customers can purchase her products online.

The Build:

We had hoped that we'd be able to replace her existing website (http://www.opinicussoaps.com) with the new one, we were ultimately unable to do so (her current provider doesn't support uploaded HTML, and still requires the use of their template). The mock-up is available here.

Now, the site design is dated. However, as we explore more options with her current website provider, we may re-address this project using a more up-to-date design and the latest available web technologies.

The Dream:

Create a simple personal task manager app using Ionic 2 and Angular

In order to learn Ionic 2 (and to help me stay organized), I decided to build a simple Ionic 2-based task manager app, using device local storage to store tasks as JSON objects. The app has a user sign-in, and allows for the creation, editing, and review of tasks.

The Thought Process: Challenges

Even though this app was initially built for local use only, the login component was essential for future development, where the data will be stored on a server. Using Angular's modular architecture and services, I was able to create a unique task data store for each user. While the initial app build uses local storage, the modular design will allow for a relatively easy transition to server-based data store using MongoDB or Couchbase, and the JSON data design insures that each user's data will remain separate and unique.

The Build:

The primary screen displays the next due task and the next due high priority task. Left-rail navigation allows users to go the Tasks page (which lists all active tasks), create New Tasks, and review Completed Tasks. Users can also edit tasks and clone tasks. Tasks themselves are have a title, description, scheduled date, priority, category, and flag for recurrences (which will automatically clone a task once complete). In addition, each task has an array of list items available (useful for shopping lists and the such) which can be completed individually.

Because of the number of task manager apps available, I have no plans at this time to release this into any stores (although the adhoc APK is available for anyone interested).

The Dream:

Create an app for Renaissance Festival shops to manage product repair orders

I was contacted by a small shop that makes and repairs hand-made one-of-a-kind puppets at Renaissance Festivals. They travel around the country going to various shows, and needed a way to manage receipt of puppets to be repaired. They asked for an app that can sit on their employee’s phones that will allow them to take pictures of puppets when they receive them, detail the necessary repairs required, and attach the customer details so that when the repairs are done, they know exactly who to return them to.

The Thought Process: Challenges

While initially built for a single specific customer, RepairIT was designed to be used by any company with similar needs. After an initial setup (where the app pulls specific shop details from an online JSON-server, including branding), employees will be able to open orders detailing necessary repairs, and then "upload" those orders to the shop owner. The initial build of this app uses the device's native email application to send these orders via email; eventually, however, this information will also be uploaded to a Node.js server and stored in a MongoDB or Couchbase database.

The Build:

When a client returns merchandise for repair, the shop associate will use the RepairIT app to get the client's information, detail the necessary repairs, and use the device's native camera to take pictures of the merchandise; a unique order ID number will be assigned to each order. Then, once internet is available, the associate will "upload" (initially via email, eventually via REST API) to the shop management team, where these orders can be monitored from receipt through completion of the repairs and delivery back to the client.

Utilizing NativeScript and Angular, the app levarages the device's native capabilities (such as the camera, email, and local notifications) to allow for orders to be created and sent. Locally, Couchbase Lite is used to store the orders details, and this will make for an easy integration with a server-based MongoDB or Couchbase database.

This is still a work in progress and has not been released to the customer (as of June, 2018); eventually, however, I plan on releasing this to app stores (freely available but with a nominal set-up fee and a subscription-based data-storage and management portal service).

The Dream:

Convert a text-based game written in BASIC to a visual web-based game, and also teach myself JavaScript

Back in 2002, I had the desire to teach myself JavaScript. What better project to use this on than a web-based visual adventure game, based off a a text-based game I had written in BASIC on my Commodore 64 the decade previous.

This was a time when HTML tables were used as the primary design framework for most websites (this was also the end of the era of animated gifs).

The Thought Process: Challenges

While extremely dated now, Zane's Tower was cutting edge at the time. Instead of depending on tables, I discovered this new DOM element called the DIV, which was only supported by IE5 at the time. Using DIV's, I was able to produced the layered effects required for the game to function.

The Build:

I still find myself playing this game every once and a while. Modern browsers and screen sizes make for some challenges (the game was designed for browser windows no larger than 680 pixels wide), but the game still functions. I keep meaning to come back to it, using with modern technologies such as HTML5, CSS3, and jQuery or Angular.

Update: Now that I've had some experience with Ionic and hybrid mobile app development, I'm thinking the next version of this will be a mobile app.

The Dream:

To create a dynamic night sky web application for the fictional world of Lyr

When I am not working, in school learning new web development skills, or doing personal web development, I write fantasy novels. As of now I have completed six novels, three in a single series and three stand-alone, and three in what I would consider final drafts.

The World of Lyr is not in any of my currently completed works. I had an idea for a world with three moons, and the story revolved around our hero doing something before the next quadruple eclipse (at which time, if our hero is unsuccessful, the world would be destroyed). To get a feel for what living under a sky with three moons would be like, I decided to write a web app that would replicate it, based on the day, time, and location on the planet of Lyr you stood.

The Thought Process: Challenges

Who would've thought web design could involve so much math! I learned more about sines, angles, radians, and the such building this page than any writer (or web designer) should need to. The page is built around a circular "sky" (representing the sky as you look up), and each moon is defined by its orbital period and relative size. Then, based on calculated positions of each moon in relation to the sun and the viewer, shading is applied in the form of border-radius CSS code.

The Build:

The page is lacking in documentation so if you're unfamiliar with the three moons and the calendar it may be hard to navigate. But in the end, it is a fully functional and kind of fun exploration of what living in a world with three moons could be like (and, more appropriately, the power of the web as a tool to fire the imagination.)

The Dream:

To convert 1990's Wizards of the Coast board game RoboRally into a web application

RoboRally is a board game where players each play insane robots on a dangerous futuristic factory floor racing each other for flags while trying to avoid being killed by their environment or opponents. Each player is given a number of program cards (based on their robot's current life total); with the cards the player programs their robot to move, and then hilarity ensues.

I've always thought this boardgame lent itself to a computer game. In 2012, once I discovered the finer details of jQuery animations, I set upon the task of doing just that.

The Thought Process: Challenges

RoboRally is a game with multiple boards, and features on each board with their own functionaity. For instance, some conveyor belts will move a robot one square; others will move them two. There are gears that turn one way or the other. There are even pushers and squashers. Luckily, each thing happens on its own phase, which makes for controlling them easier.

The first step was to break the game into layers. Then figure out a way to define each layer on each square. Determine order in which things happen, figure out how to apply each action to the pieces on the board. Program necessary animations.

The final challenge was the opponent robots. Figuring out how to program your own robot was easy; figuring out how to apply "intelligence" to the choices of your opponent robots was more difficult. I wanted to avoid the "brute-force" method (where each possible combination of cards was checked and the best choice ultimately applied); instead, I did these checks on a per-card basis: which available card got the robot closest to it's goal? Then, which of the remaining cards gets them closest? And so on.

This is to say, they are not very intelligent. However, there is a method to their madness (and, perhaps, to mine).

The Build:

The end result is a functional and fun solo game. I tried to include detailed instructions, although having foreknowledge of the board game definitely helps.

NOTE: This is not a licensed version; this is intended for personal use only. I do not own any of the rights to this game, and it is placed here as an example of my coding skills only.

The Dream:

To convert Downfall of Pompeii boardgame into React web app

The Downfall of Pompeii is a boardgame from Mayfair Games in which 2-4 players first populate the tranquil city of Pompeii as it rests peacefully in the shadow of Mount Vesuvius, and then try and save as many as you can as Vesuvius erupts and threatens the Pompeiians with fiery death. Fun for the entire family!

Like RoboRally, I always felt that the Downfall of Pompeii was not only exceptionally fun, but also lent itself to a computerized version. In early 2020 I endeavored to do exactly that.

The Thought Process: Challenges

Since I had been working professionally with React for over a year, I decided to try my hand at using React to build my Pompeii web app.

It is, in many ways, a simpler game than RoboRally, with literally many fewer moving parts. There is nearly no true animations in place, and only one board. However, in order to make sure that the artificial intelligence of the non-human players was much more "intelligent" than the robots of RoboRally, I had to play around with graph theory and rudimentary decision matrices. (See my versions of the island problem and "surrounded by lava" as my explorations of these). The result is a much more enjoyable gaming experience, I feel, as the computerized opponents are much more capable than my poor dumb rally robots. If I only knew then what I know now... who knows, I may re-write RoboRally someday after all.

The Build:

The end result is a fully functional game that 2-4 players in any combination of human or AI can play. The instructions are much more comprehensive than RoboRally's, and while the graphics and animations may not be as exciting, the gameplay is still, I feel, smooth and intuitive. I was even able to grant the six AI players slightly different personalities, so each plays with a slightly different strategy based on how each player values different criteria (courageous, social, and lawful).

NOTE: This is not a licensed version; this is intended for personal use only. I do not own any of the rights to this game, and it is placed here as an example of my coding skills only.