Manoa Exchange was created with the UH Community in mind. The purpose was to create a website that only the UH community could use to buy and sell products. It was mainly geared to those that were in the dormitory or another housing nearby and either wanted to sell their furniture or one of their other items, or buy one from someone that didn’t want it. Users were free to sell anything they wanted though, only if it was appropriate. The admin was allowed to edit and delete items and accounts depending on reports submitted by other users, otherwise, they could participate too.
I worked on part of the mock-up pages, did the back-end of the profile, category pages, and made sure all the different branches didn’t have a conflict when merged together. The mockup of the landing pages, profile pages, and category pages were my doing. The color scheme of the site was based on the landing page banner. I decided on something simple and not extravagant that would would away from the main purpose of the site, and had certain things, like the buttons, stand out.
I was part of a group of three people that had worked on this website, I knew ahead of time that there was most likely going to be merging errors. To minimize this and made sure it all worked, I decided to be the one to merge each branch and carefully make sure that it wouldn’t break anything already in the master branch and adjust the code. This of course meant having to recheck schemas when it was changed, the default data, and other redirecting links and functions that could have been messed with.
Along with making sure it merged properly, I made sure that the pages looked cohesive and similar enough that it belonged to the same site.
Working in a group on a larger scale project than what I am used to made me realize quite a bit of this. Even if you plan ahead with what you want to do in each milestone, there will always be things that you just don’t expect and you will have to change your application accordingly.
When doing the functionality of some things, some problems could arise that you just hadn’t expected. For example, we were supposed to have a search page that listed all items and allowed filtering and searching by keyword, but that did not end up in the final code. I tried different ways, using the given search component from react, creating my own with input or the form, but it didn’t work. Redirecting didn’t work properly, would not bring in the search word and the bar would disappear. So I decided to scrap the search bar and leave it just on the search page, but that didn’t work either. So we had to take out a major part of the code, but luckily, we already had the category pages to work, so we had that to fall back on.
And sometimes, it isn’t the code that goes wrong, it’s the people you work with or other things that you don’t have control over. You might not work well with your teammates or they might misunderstand and do something else entirely or not do their part of the work. You just have to just adjust, pick up their slack or go the extra mile to make up for when they take up too much time on something that should have been simple.
I knew going into this project that communication is key. We met up in person and had a way of contacting each other when we were not meeting up. We talked when we needed help on certain things and even went for outside help when it was needed. But clearly, that was not enough.
Some things might seem simple at first glance, but in reality, it could be very complicated and mess you up in the end. So my advice?
Don’t underestimate what you’re doing, no matter how simple that task.