Category: Projects

This project was so much fun to work on! The programming department approached our department to design our Total Touch POS system E-receipts. So any time someone who orders from a Total Touch POS system can get their receipt emailed to them. So tens of thousands of people will be receiving it.

This needed to be made on a single stylesheet containing HTML and CSS. It sounded straightforward. We got to it and before the day was over, came up with a few designs for them to choose from. They gave us our feedback and chose one of the designs. Great! We were astounded by how easy it was. Boy, were we in for a wake-up call.

A day later we get an email from the head of the programming department. It was of the E-receipt. It looked nothing like how we had designed it. None of the colors were right. Most of the content was missing. Everything was spaced weirdly. We had no idea what happened.

Challenges

So, it turns out that e-mail clients read code a little differently than web browsers. By “a little” we me “a whole lot”. And, to make it worse, we also found out that each email client reads code differently from other email clients! Most can’t even read a <div> tag, let alone CSS period. We needed to completely redo everything.

Time to Adapt

We had to do a whole lot of research and a bit of consulting. This took us multiple days because there was so much to learn.

• For the CSS, we knew some things we wrote worked. We kept what worked and threw out what didn’t. Any new styling we did had to be done with inline CSS.
• For HTML, we had to get rid of <div> tags. And for those of you who don’t know, that is what most HTML consists of. But, we learned that we could use tables. Tables in HTML are used to make exactly that. Tables. They have rows and columns and would be the lifeblood of this receipt template.
• We also had to consider how email clients changed the look of the template. Specifically, Gmail and Outlook.  After what felt like an eternity of Googling. I found out that you can write conditional logic in HTML. This blew my mind. We could now write code specifically for Gmail, and code specifically for Outlook. They will still look a tiny bit different from each other (mainly because Outlook doesn’t like to read colors very well). But, it was absolutely good enough.

Testing

So when you are building an email template of this nature, it is paramount that you test it rigorously. Not only did we need to test it on every email client, but we need to test it on every email client on every type of phone. That sort of made it go from difficult to impossible rather quickly. There is no way that we can do that. We don’t have the time or resources for that.

That is until we found a program that would do just that. Email On Acid is a program that will allow you to test your template in over 200 different ways all at once. It saved the day. We were able to send out two more designs that we knew would work.

Conclusion

When you are building an email template, “compromise” is the name of the game. Flashy is nice but it is not the primary goal. In the end, we found a middle ground that we were all happy with. This was a HUGE learning experience for us, but also an absolute blast. I am so proud of my two coworkers, Jamie and Jacob. This was the first time the small team of us could collaborate on a single project together. Truly, this was an amazing experience.

Hoppy Trails is a full-stack application that allows registered users to view a full list of breweries in Cleveland, OH, and be able to review them. The second primary feature is viewing curated brewery “trails” based on what makes them great. Users can view those breweries and mark trails as ‘Complete’ when finished. Marking a trail ‘Complete’ adds a stamp to their profile. From gathering and constructing data in SQL to creating a review system from scratch, this app utilizes everything a group of us learned from Tech Elevator. During the two-week build process, we had daily stand-up meetings with our project manager, along with a weekly check-in with our project owner.

Tech Stack Used:

– Database: SQL Server
– Backend: .NET, C#
– Frontend: VUE.JS, CSS, JavaScript, Bootstrap

During the Build

We were very excited to do this project. All of us in the group enjoyed beer slightly more than the average person, so it was easy to stay motivated. Early on we found it was easiest to split the duties based on people’s strengths. Two on the backend, two on the frontend, and one (me) maintaining the database. I feel like this allowed us to be very efficient early on and check off a lot of our goals fairly quickly.

Our project owner was in charge of the overall vision. Whatever they say, goes. One of their goals for us was to have suggestions for people not wanting to spend time looking for breweries that fit their preferences. We had a bunch of ideas for people’s preferences but we narrowed it down to four given the time constraint.

• Family-friendly
• Dog-Friendly
• Budget-Friendly
• Including a patio

During our meeting with the project owner, we thought that instead of just listing breweries out, we should turn them into bar crawls. And so, the name “Hoppy Trails” was born.

We also decided that one principle that we need to stick to is ease of use. We wanted to minimize the amount of clicks or taps it took to get what you came there for.

Challenges

Apart from this project needing to contain everything we learned over an intense three-month period. Most of the challenges that we had to overcome were time management and keeping a level head. Even though our project owner had clear goals we needed to meet, we wanted to go above and beyond for all of those goals.

There was the occasional “Can we even do this?”, but we were able to lean on our coding instructors to help us if we got too ambitious.

What Would I Change?

Nothing. It was perfect.

I’m obviously kidding. One of the biggest things I would change has nothing to do with the app. It was having everyone in the group work on one aspect of the project. This made us extremely efficient at the start, but it made it hard to fix bugs when they inevitably came.

Conclusion

Overall I was very happy with the overall functionality of the app. We hit all of our goals and stuck to our core principles. We had a tiny hiccup in our final presentation when looking at a user’s profile but it was an easy fix. This was an amazing learning experience and Tech Elevator made a huge effort to mimic a real-life work project.