Indecisive Decision — http://indecisivedecision.net/

My First Portfolio Project

14 min readJun 24, 2020

A blog post about my experience with the final project.

At the end of Year 1 at Holberton School we have to complete what is called the Portfolio Project. This happens to be the what I believe is the biggest project we’d face within these 3 trimesters. The portfolio project gives students the most freedom they’ve ever had for a project to create whatever they’d like, using the experience they’ve garnered thus far.

For our end-of-foundations project, my team created a web application called Indecisive Decision. One of our original thoughts was to make some sort of randomizer or generator and after going through the same ideas over and over again, we realized we needed something that would help someone facing indecision make a decision. With that, we figured a single web application that gives a user the opportunity to make a decision on a multitude of subjects would be extremely helpful. Given our time frame, we decided on making two deciders available for the MVP: restaurants and recipes… which we later on re-evaluated and ended up focusing solely on the restaurant side instead.

Before getting farther into the project, let me introduce myself and my team!

An image of each team member — The entire team who worked on Indecisive Decision

On the left was my partner Mitchell Moscovics, whose main role was Dev-ops and server deployment. On the right was my partner Ezra Nobrega and his main role was Back-end and user configuration.

And then there was me, Michelle Giraldo. I was mainly in charge of the Front-end. More specifically, I mainly worked on the decider and setting up user interaction.

You might be wondering why I said we ended up re-evaluating. That’s because after a week of work, I noticed we weren’t completing our goals at the pace we needed and expected to. This meant we either weren’t going to get everything done by the deadline or they’d be completed half-haphazardly. Our original plan and projected timeline was inaccurate and needed a change. With this in mind, I suggested changes to our plan to account not just for this, but for the time needed to get through struggles originally unaccounted for. In the end, our timeline looked something like this:

Week 0:
Mitch started on the AWS configuration, Ezra formed a file structure with Django, and I created the repo to start what we’d need for our web page. I spent this week creating a home page and setting up login/signup.

Week 1:
Our MVP should be working at the end of this week, and that’s when I realized we were very behind. I decided to scrap my work and solely focus on the Restaurant Decider. By the end of this week, Mitch finally got the server deployment fully functional as well as the database hosted. Ezra got Django serving the website, and implemented the Yelp API query for the decider.

Week 2:
This was our final week before our final presentation. Now that the Yelp API was working, I was finally able to focus on setting up the results and parsing information returned from that query. Mitch created the landing page and Ezra decided to add User accounts.

NOTE: This timeline doesn’t display the 3 weeks spent before week 0 on research and project approval.

I really wanted to make sure the Restaurant Decider was accessible and straightforward enough for anyone of any age to understand. To do this, I curated a large test group, made up of around 70 people ranging from about 8 to 60 years old. I constantly was asking for opinions and implementing the thoughts I heard most of.

Personally, what I wanted to do more than anything was create a product that was just super polished, and made to the best of my ability. I wanted something to showcase my creativity and how earnest I am. Whatever I would end up working on, I wanted it to have at least some usefulness or have some sort of features that makes one think “oh!” or “that’s pretty neat”.

In reality, I feel that way about any role I would have to fulfill. I was tasked with the front end because the rest of my team didn’t have any interest in it at all. I didn’t mind though because I knew I had an eye for detail and want literally everything I make be well-rounded. I also didn’t mind getting more comfortable with HTML, CSS, and jQuery. So my personal focus was making content that any user would enjoy and find helpful, while honing my acquired skills even further.

Why I Chose to Work On This Project

How did I end up working with my team?

To be completely honest, I originally felt insecure in my ability to work alone. I was worried about creating good, fool-proof content in time. I was scared of making something that I wouldn’t be proud of or ending up overwhelmed. This caused me to ask Ezra months in advanced if I could work with him during the final project. Then when the deadline for team creation was coming up, I asked Mitch if he would like to work with us as neither Ezra or I had worked with him yet.

Let me just tell you real quick that by week one, I fully realized how wrong I was and had zero reason to doubt myself.

But so after our team was formed we needed an idea. After contemplating for a while and being indecisive on what we wanted to create, something to help ease the indecision sounded like a great idea! We then talked a bit more about what everyday topic one might be indecisive about and came to the conclusion of food as one could be unsure about what to eat. Personally, my friends and I would constantly waste so much time just trying to decide where to eat. There were even times at Holberton where a group of us would have to actually whiteboard to figure out what where we would like to go. Growing up, my family always decided to eat at Chili’s because we didn’t know where else we could go. With this in mind, I saw this as an opportunity to really provide a useful tool for not just an individual, but a group of people.

Originally, we had the idea of creating Indecisive Decision, an entire web application that had many options a user could select they needed help deciding between. Randomization and generation were going to play a big part in this application, but as I mentioned earlier, we had to cut that down into something more feasible. I convinced my partners to focus on creating just the Restaurant Decider for now and hopefully be able to implement other Deciders in the future.

Some Project Accomplishments

Our architecture, technologies, and features implemented.

Architecture Diagram

Technologies Used

Each role used different technologies. For the Front-end, I used: HTML, CSS, and Javascript — or more specifically, the jQuery library. The entire Back-end was made using Python and Django, and the database Ezra used for the project was MySQL because of it’s easy integration using Django’s ORM. For Dev-ops, Mitch used Amazon Web Services such as Elastic Beanstalk for overall server deployment, Relational Database Service for database hosting, and Route 53 for domain and DNS set up.

We generally chose the technologies we did because of the want to learn either new languages or known languages further in-depth, as well as our financial limitations. This especially had an impact on our Dev-ops role as Mitch had to find what he could use for free.

As my partners weren't the least bit interested in working front end, and since I know I look at even the smallest of details, I took it upon myself to work Front-end. I then decided it would be great to get more of an understanding of these languages and how they worked together to make an amazing product. Before this point, I was unable to 100% projects with HTML/CSS. My main motivator of using jQuery was the want to have neat features to enhance user experience, plus it seemed cool and I wanted to learn more things that I could do with it.

I also found out how to create HTML templates in Django, allowing the creation of a base template and any other HTML file to inherit it. It was pretty cool and gave Ezra and Mitch a base to work with on their web pages — keeping a uniform theme throughout the website.

Features Implemented

I’m happy with the features I have implemented while working on the Restaurant Decider. All of these features were carefully thought about to enhance user experience. These features include Indecisive Decision’s mobile compatibility, the ability to delete every and any result currently displayed, a button that will randomly remove a result until there’s only a single one left, and the fact that the phone number is actually a link.

First off, mobile compatibility. Since the beginning, I was working hard to ensure the website would remain responsive and functional between not just desktop and mobile, but on multiple browsers for each. Currently the size in which the decider is at shouldn’t cause any issues appearing on any device. The header and footer will change depending upon screen width while the layout of results will re-shape when needed. They’ll always appear uniform as any results on the same horizontal line will expand to have the same height. This can all be easily tested on desktop by enlarging and shrinking the window of the web application.

Now comes the features involving removing results. There is a little ‘x’ at the top right corner of every result. This allows the user to remove any specific result, adding utility. If the user has many results, there may be some they know for fact they don’t want — so why keep it there? Now lets say with the results that are left, they can’t choose between. Luckily, there is a button that will randomly remove a result for the user. This way if they are facing indecision between the results left, the choice could be made for them.

Another little neat feature is the fact that the phone numbers on each result is actually a link to any phone app you may have, not just on mobile, but on desktop too! That way the user can easily call with any questions they may have.

My Most Difficult Technical Challenge

Of course there were many challenges: technical and not, but some were actually fun!

Believe it or not, I would say my biggest technical challenge was getting the mobile version of the website working. More specifically, I was having issues with the layout. The footer would not stay at the bottom of the screen. I had the idea that the footer should always be at the very end, so if the user had to scroll then they wouldn’t see it until they scrolled all the way down.

I can’t tell you how many times I thought I fixed it but it wasn’t the case. For example, it would work on Android but not iOS. It would work on Firefox but not Chrome. At one point it seemed like it was finally staying below… until the user brought their keyboard up and now the footer was right above it. I fixed it after a bunch of tries… or so I thought. Once I implemented the results, the footer wouldn’t actually move down but stay stuck in the middle of the page, as it was where it appeared initially.

After dedicating more time to just inspecting each element and figuring out what exactly would happen as the decider was used, I found the real issue. It turned out that when the results were populating the container they were being dynamically added to, the container was never expanding past it’s initial size. This meant that practically all the results were bleeding, causing the footer to stay where it was as it was technically below the container. To fix this, I changed a couple of things:

The footer text on mobile is shorter than on desktop.
The results were then placed into a second, separate container that became a flex box with a flex-wrap.
Each container now has a min-height of 100%.
The position of the footer had to be absolute.

Images of Some Footer Struggles

Honestly so many of my problems turned out to be because of layout… a great heads up for the future!

Here are some images of the footer issues I’ve had at different points in time.

Some Things I’ve Learned

I honestly learned a whole lot during this project.

In summary, I would say this project was a really great learning experience. For some technical take-away, I would say using Django to create HTML templates and allow for HTML inheritance is really awesome! I saw how useful it was and can only imagination how much time and space could be saved on bigger projects. Also, I knew jQuery was cool but now I feel like it’s even more amazing after seeing more features of it. I honestly want to play with it more to completely understand see how much of a game changer it is. It really resonated how much a dynamic vs static web page can differ in what they have to offer.

If there were some things I could’ve done differently… in all honesty it would’ve been trying to do this project on my own or electing myself as project manager. Since we didn’t really have one, communication was really bad and I wonder just how much more we could’ve done if we had planned appropriately. I wish there was someone to not necessarily enforce but influence effective scheduling with more practical due dates. This way everyone’s time would’ve been used more efficiently. Almost an entire week of work for me was thrown out, if we had prepared better maybe I wouldn’t have encountered that situation. There are also some neat technologies I learned about after completing the project that I wish I could’ve looked into sooner, like Sass.

Some things I have learned as a software engineer is that I am more than capable of doing my job and doing what is tasked of me. I literally had no reason to doubt myself as I originally did and now know I won’t make that mistake again. I love learning and if I’m asked to complete a task I may not know how to do, I’m not worried that I can look into it and figure it out. I always want to do a job well done because otherwise it doesn’t feel complete to me. I also learned to vocalize my thoughts and opinions sooner, especially if I genuinely believe it is for the betterment of the project.

Although this final project has secured some peoples thoughts on their future engineering path, I wouldn’t necessarily say it’s the same for me. I had some questions about what kind of engineering path I would like to follow, and still do. After this project though, I have no doubts that I would do well in web-stack. I honestly already felt pretty confident in server management and Back-end, but I still want to go into the AR/VR specialization that Holberton provides for year 2 students. Afterward, I would really like to complete the Web-Stack specialization in my own time to create an awesome website portfolio and possibly create websites for people in my free time.

Throughout this blog post I would say I’ve been communicative on beliefs that have been confirmed as a result of this project. I was unsure in my ability to take on a big project like this by myself, but after completing it all… I actually want to. In the future, I know I want to help take the initiative and be one of the big caretakers to ensure that what I’m working on is a well rounded project.

In Conclusion

I would say I am super duper uber excited to work on bigger projects. Although Holberton projects can be fun, generally their projects are small and everyone provides the same end product. I want to actually use my skills and create something kind of unique that anyone can use. If it helps make them smile or ease their everyday life, then that sounds like such an epic win!

I’m honestly so excited for the future, to continue learning and growing not just my software engineering skills, but soft skills too. I had some great ideas for this MVP that were, unfortunately, unable to be implemented before the presentation. So let me mention my idea here real quick…

Now that user accounts are implemented I can see all the benefits to — not adding favorites — but dislikes! So hear me out, if a user would not want to have certain restaurants appearing, it would make their lives (interacting with this app of course) so much easier if they can just get stop it from appearing as a result. This would be especially helpful for those who may be picky eaters or have certain dietary restrictions. They could mark a restaurant as a dislike or as unwanted, keeping a list that they can edit if they ever change their minds, and filter them out from the results provided to the user.

Honestly I could go on and on about this, especially since I have other ideas to add to Indecisive Decision’s functionality and utility. I want this to be a product that anyone could use often and eagerly.

If this blog post hasn’t been able to show the kind of person that I am, then let me tell you. I am always hardworking — even in the tasks I may not enjoy as much. I don’t just have an eye for detail, but am also intuitive and eager. I’m ready to show that again and again as I work on projects in the future. I’m actually getting excited as I write this, I can’t wait to see all the more progress I will make in another year’s time and the projects to follow!

Thank you for reading!!

Important Info and Links

This Specific Portfolio Project, Indecisive Decision:

GitHub Link to the project repository:
https://github.com/michellegsld/indecisive_decision
Deployed Project Page (Restaurant Decider):
http://indecisivedecision.net/
Project’s Landing Page:
http://indecisivedecision.net/landing/

Fun Progress Pictures!

Scroll through in order to view how things changed visually. I sadly don’t have more images to really showcase the changes and progress, but wouldn’t you say the final product looks drastically different from these experiments?