Losing Touch before the Storm: The Branching Surprises

The phrase too many chefs spoil the broth is partly true, if you do not have order and consistency throughout a project, the resulting factor becomes a mess of different styles, ingredients, and expectations, making not only a horrible soup but an interesting example to the care needed when working on a project. Whether it’s cooking or construction or even the digital construction that is programming, the adage can only prove true if you do not make yourself clear.

Last week I talked about the importance of communication and the need to communicate more clearly and it seems like this week the message is really similar. But at the same time there is a light at the end of the tunnel I assure anyone who would read this. When we left off, our group had a general idea but no solid motion forward besides analyzing code. By the Thursday, Ed and I had gotten in contact with our team members Jarrett and Paul in order to make sure we were all running the same track. This is where the issue got rather fascinating.

Throughout our class, we had gone through our assignments using high amount of communication between our members (from the Original Visualization with Bao and Ed, to my partnering with Ed to do the Bio Heat Map) and as such we’d always have a good amount of information about where we were and what was in our trunk. This time with Jarrett and Paul, I had run into a new factor I hadn’t considered, branches. For anyone who hasn’t been part of a programming project a branch is an offshoot of a project designed to key in on certain features which would then be reintegrated into the system when it was time to make a final product, or left out if incomplete or proven unnecessary. To our surprise, Jarret and Paul both had created Branches for themselves while Ed and I had been looking at our base code in the trunk.

We had talked it out and soon our project was back in line, but communication very important and as we found out as the week went on, the concept of merging the project wasn’t as clearly stated and once again there was a small stall when we found that Jarrett had branched. It was not a major issue for Ed, who was focused on the ticker and the visualization, but for me, the need to integrate the transitions which Jarrett had worked on into our portion of the code was a concern and while I had started making adjustments, Jarrett had already finished them!

With that integrated into the system we began to fine tune the process. Not wanting to waste effort we looked at the system and prepared to make one that was visually acceptable as a demo for our class.


-The Billboard with dummy data, each panel capable of rotation.

With communication clearer the fine tuning ran smoother than what we were on before. Seeing that the layout wasn’t as stable as we would have liked I went ahead and set up some styling to hold the formatting for our demo, and also started filling in the areas with graphical content. Placeholders in place we were able to get several screens in all together.



-A different set of items here.

With Paul’s Designs, Jarret’s transitions, Ed’s knack for visualization, and my really picky emphasis on visual consistency we were able to make a suitable demo with dummied data, each panel operating in its own timing. It was thanks to our ability to talk it out that we came out with a working product and knowing that, I would hope that anyone who wants to work on a project which requires things that are closely tied together consider always keeping your communication open and clear, so that effort can be directed to good products.


-The boards panels may be the same in some pictures but you can tell that some are in mid fade as it shifts to a new panel