Examples of Development

Phoenix

Development for the Phoenix Project began in the end of August 2008 in an attempt to produce a piston catalog that was several months behind due to numerous delays in a system that was outsourced to another developer for this purpose. This system uses the ACES industry standards data in order to natively store part to application mappings.

The piston catalog template was finished in the middle of October 2008 and the catalog was finished and ready for print in the begining of November. The project soon expanded to include the rest of the light vehicle product lines. Since its inception it has produced six catalogs for print and numerous electronic PDFs. Each of the print catalogs required different ways to manipulate and sort the data as well as what and how it was displayed.

Phoenix started out as a one to two user system with around 200 SKUs. Currently, phoenix is actively used by around 10 users and manages over 15,000 SKUs. Over the course of the development, phoenix has had to be as efficient as possible. The sheer amount of data associated with certain engines makes for some massive pages in size with the largest showing around 1000 applications. Javascript has been employed on many pages to find ways to help the user's experience such as checking hundreds of boxes at a time or using asynchronous javascript calls to refresh data on parts of the page so the user does not have to reload the page after every click.

From the start of this project, I have worked directly with the end users in order to make sure the processes made sense. When a user has an idea of something to save time, it is my goal to find ways to implement this and make sure it follows there ideas rather than my interpretation of them. Some examples in this project is the ability to copy applications from part to part, recall the last search when adding an engine, and numerous different reporting tools.

One of the challenges of this project was working with a relatively young industry standard, which still has a lot of data issues. From the start, it was discovered a lot of data was incomplete or completely missing. A large part of the development has focused on providing a means to override the data for internal use, while still preserving the standard as much as possible to be able to export it to customers within the industry.

Screenshots will be coming soon.

Once a part has been entered, Phoenix returns a page showing part images and other basic information about the part such as its lifecycle staus, related parts, and it bill of materials.

This is the main screen used by Phoenix's userbase. At the top it displays a brief overview of the parts using catalog headings to show what the part describes. The green header describes the Engine Base, the engine's most basic information mainly its displacement. The blue header is the Engine Config giving more detailed information such as the engine's VIN and/or Engine Code, aspiration, manufacturer, etc. The color of the text in the titles and headings indicates if anything is selected within a block. Blue means all are check, Black is partially checked, red imean nothing within that group is checked. With the large amounts of data that can be tied to a part, the options on the right help with load times. Anytime a part is tied to more than two engines, it will only show the Catalog Overview section. The user must select the engines from the right to bring them up.

This page allows the user to add an engine to a part. As there are over 10,000 engines currently in the VCdb standard, with each selection it will further narrow the selection through the remaining boxes. In the picture above for a 351 cubic inch Ford, it is showing 8 engine versions versus the 112 that exist in the entire standard. These are updated using asynchronous javascript calls so the user never leaves the page. A similar set of functions is available to search vehicles as well to help narrow down the over 150,000 vehicles in the standard.

One of the unique developments in phoenix versus other solutions that had been looked at was the ability to set the qualifiers (part/application notes) in a dynamic fashion. By constraining these using attributes it allows the users not to have to revisit the qualifiers every time they update coverage. For example, if a note is applicable to all applications, no boxes are selected and any application is added will be tied to that qualifier.