Glidewell Dental - Marketing site for BruxZir

My role was to update the website for BruxZir. They previously had a fixed width version for desktop and a mobile website.

In addition to frontend development I also advised on content strategy including creating a section for patients. This would enable marketing to patients directly so that they could ask their dentists for this product after hearing about it or doing their own research.

Technologies Used

• CSS3
• Git: Hosted at Github
• Handlebars
• Javascript
• jQuery
• Adobe Photoshop
• Adobe Illustrator

To start, I performed a content audit of the pages. This included mapping out the pages, taking inventory of text, photos, downloadable documents, links (and inspecting them for accuracy).

Here is a picture of the original site (desktop version)

The page required a lot of zooming while on a tablet. That was factored in when designing the navigational elements. The navigation was originally thumbnails for the mobile website and had a limited amount of information.

The page structure was originally going to be preserved. Then we realized the amount of content that would be filled into them with new products. Additionally, for SEO purposes we broke them down into product pages. These pages needed to be quickly accessed, so I added them to the footer.

I made the links descriptive so that users could locate where to go based on actions such as, “find a lab” but could find products bas on categories. Usualy when a user is scrolling to the bottom of the page they are looking for something. So I made sure to add a link to the sitemap. This is not a common page to add, but I think that it makes it a lot easier for some people.

Users should be able to find where they wanted to go in seconds. Also while here they might find a resource that they were not previously expecting, like “Case Gallery” or “Scientific Studies.”

I added the video to every page. Accessible from the footer. It is a very impressive video of the quality of the material in the product. So I wanted to make sure that no one left the site without watching this and leaving with lasting memory and emotion of strength.

I originally designed the video to expand to 100% height and width. But has since been changed to a modal window when a maintainer decided to use Bootstrap. When I first built the project it was built with Foundation. We had decided to use Foundation after much research. The company even paid for me to take classes on Foundation and then a class on Responsive design by Zurb.

Due to a request from management (not users) I was asked to expand various elements to a full width of a 27” mac. I did not agree with these requests as studies showed that users rarely expanded their browser to the full width of their screen. And warned that it would delay the project as various images would have to be reshot, content on various pages would be horizontal and short, etc. But management insisted because of one person.

Because Foundation could only go so wide I ended up creating a new CSS library that i modeled after Skeleton. It was pretty lean, simple to use, and served devices from an iPhone 4 to 27” mac.

But the maintainer wanted to make things uniform so he just threw in Bootstrap.

One of main concerns of the management was the ability to find labs. So I added what was meant to be a placeholder at the very top of the page.

The designers never gave me graphics, so this just remained the button link to the page to find an authorized laboratory.

The previous codebase to the lab finder page included inline CSS and inline javascript amounting to literally thousands of lines of code. I ran various search and replace commands in Sublime to get rid of the bloat. I was able to strip down to just the lab information. Then I created an excel sheet with the labs. This way information could be filled in quickly.

“Why an excel sheet?” you might ask. Well because this way there is a document that anyone can easily edit regardless of their technical capability. Otherwise you would either need to edit the static page(which could cause problems in tracking code since “we” were not using version control), edit a database (no one was technically capable there of working with databases and politics from IT prevented us implementing new solutions), or use a CMS but again because of internal politcs we would have had a hard time getting that going.

So my Excel “solution” worked so that when someone edited the document, they notified me and I updated the website. It was done manually via email, not efficient but solved the problem with the available tools. Later all I had to do was convert the data from the Excel document to a JSON format. This data was populated into a template built with Mustache.js. I tracked this in git at my own expense. After problems with the servers I decided it was a good investment even if I had to pay for it.

Later a map was request made. I suggested various reliable vendors. But my immediate supervisor rejected CartoDB and others because “what if they go out of business” so I was able to get Google maps working. This obvioulsy caused more work as not only would the code need to be changed, but as did the map. I used mapmaker. Mapmaker has since been discontinued by Google. The maintainer implemented a new system, and I planned ahead in case something happened like this, and tracked changes to the labs and kept backups.