Just a heads up, I’m going to start this post off with a personal story. If you’re not interested and just want to learn more about the product we are working on, please feel free to jump forward. 😄
In 2013, after years of waiting, I won the lottery. Well, not the lottery, lottery. But the season ticket waitlist lottery. Finally, I received the opportunity to purchase tickets for the upcoming Chicago Bulls season.
Having just come off of a Derrick Rose-less second-round playoff loss the previous season to Lebron James and his Miami Heat, I couldn’t have been more excited. The Bulls would be getting their MVP back and were primed for a deep playoff run. …
I have wrestled with how to answer this question for a year or so now. At first, I was a hard no. As a designer at a digital agency I thought it felt cheap, lazy, and a misuse of a client’s trust to re-use components, modules and page styles between projects. I felt, pretty strongly, that each project should have its own unique experience and this experience started with a custom design system.
While this statement holds some truth, I’ve come to realize that it’s not about the style of interface elements on the page, but rather how those interface elements get a user from point A to point B that crafts the unique experience each project demands. …
As a front-end designer at a service-oriented development firm it can be hard to maintain a design to code work flow that is both efficient and practical. While there are more tools and plugins than ever at our disposal, there are also more tools and plugins than ever.
But similar to other designers in our position, our team struggles with maintainability and consistency. The work flow of turning static designs into responsive web components is tough. Type sizes are forced to change based on content overflow issues, viewport sizes cause well-defined design components to break, and spacing is never correct (no matter how hard we try). This puts our designers in a precarious position. To what extent should their design elements match the product’s font-end components? Moreover, how much time should be invested into creating pixel perfect parity? …
At Made by Munsters, our Rails projects use dotenv to load environment variables for development and test Rails servers. dotenv reads a file (by default, the appropriately named
.env) that contains a simple list of name=value pairs and loads each as a new environment variable entry. For instance, a
.env file with these contents:
SERVER_URL = http://api.example.com/
SECRET_SERVICE_KEY = '123-opensesame'
dotenv would read that and populate Rails variables
ENV['SECRET_SERVICE_KEY']. This discussion won't cover installing dotenv, but it's a simple process and you can read the project's installation instructions to get yourself started.
Because environment variables frequently hold confidential details, such as secret keys, those
.env files shouldn't be checked into source control. That protocol works to keep secret keys secret, but architecture has some…
At Made By Munsters we work with companies of all sizes. Some are brand new start-ups. Others are well established, long-standing businesses. Yet, we treat all companies the same when hired to design and or develop their products.
Our process always starts with an explanation of our design and development goal.
That goal: Build for day one. Don’t focus on what’s to come a year from now or even three months from now. Focus on your first release.
Our team looks at the immediate needs and problems our client may be facing and then as a team we define a solution that best fits the first release needs. …
Made by Munsters was named by Clutch, a Washington-based B2B research and review firm, as one of the top web design firms in Indianapolis.
This was an unexpected surprise, but one we don’t take lightly. At Made by Munsters, we’ve worked extremely hard in building quality products with our partners and scaling our world-class team of designers and developers with the best talent.
Our small, but mighty team is proud to be named among the other companies in Indianapolis. …
Data, it’s one of the most important aspects in web development. Studying how users interact with a product can only help to make it stronger, not harm it.
If a team or company can understand what causes their users to leave their site or click a buy button, they can enhance the product’s experience and increase its overall user satisfaction.
How do web designers and developers collect data? And more specifically, how do agencies or studios building web applications, get their clients to buy into the idea that spending time collecting data is the right move financially?
At Made By Munsters we collect data regardless of the client’s buy-in. That might should harsh. But give me a chance to explain. You might side with me after you hear me out. …
There are a number of forces driving the need to increase resiliency in the face of poor network conditions. Web pages are increasingly being replaced by long-running (single-page) web applications, where the web app might be able to continue to work through temporary network disruption or even work fully offline. Mobile apps often encounter this problem, as users move in and out of WiFi or cell service range, with both connectivity and the quality of connection varying over time.
Naturally, developers build apps in environments where network connectivity isn’t an issue — frequently the connections stay local to the development environment. That’s fine for being efficient while building out code, but it can also lead to a false confidence about the performance of the code in real-world situations. …
The Schlep app, built for longtime client Schlep, lets Schleppers manage their upcoming jobs, and search a job board for new jobs they can take. Schleppers supply the vehicles and muscle to help clients move heavy items across town or just up a few flights of stairs (clients schedule the requests through Schlep’s eCommerce site). …
Managing git branches when branching off multiple feature branches can be a pain. What branches have been merged and can any be deleted?
Within my first few months at Made By Munsters I came to realize that I needed a better workflow for managing my branches.
Let’s break down the current workflow. First, at the beginning of a sprint we create a
sprint_deploy branch with the date that it was created. This branch is based off the master, because master has the latest code base. From this point, we branch off of
sprint_deploy into several feature branches.
Each feature branch is named according to the user story it is addressing, as well as, time stamped with a creation date. For instance
feature_addAdminLogin_7_21_16 will contain code that is primarily used to add the admin login functionality. …