RPP Cookie Settings
Accept and close
Our festive Video!
December 21, 2016
Seasonal Greetings
December 20, 2016
Celebrating our Mentors
October 27, 2016
New Street Square Complete
October 14, 2016
Parker House starts on site
August 30, 2016
RPP go skiing!
April 1, 2016
1 New Street Square Tops Out
January 29, 2016
2016 here we come....
January 11, 2016

IT Case Study: Bollards on the system
October 31, 2016

One spring afternoon, the studio were all informed of an emergency, and all team members were ordered to meet in the courtyard, at once.

Not knowing what to expect we descended to the courtyard to find Mark (Project Leader/probably the strongest man in the office), with a cardboard box on his head, next to a pile of weights. Fortunately, Shaula (Operations Partner) was quick to end the confusion, and introduce us to the disaster that was ‘bollards’.

“This is the RPP server (pointing to Mark), and each of these 1kg weights represent 1 megabyte”.
Mark was then handed a weight, and asked to run to a table and back. Commentary came from Shaula, explaining that this represented a file being created on the system. A further weight was added and Mark ran, again. This charade continued with more and more weights being added; Mark’s pace began to drop, until eventually the cardboard box fell off his head.

However, the ordeal did not stop there. The weights were merely a warm up for something far more onerous. In 2011 RPP designed a cast iron bollard for the Merchant Square project, and the first sample, weighing 500kg, currently resides in our office courtyard. Mark was asked to carry this cast iron bollard to the table and back. Despite Mark’s superior level of strength, the bollard could not be lifted, let alone moved.

To help put this into context we know that Architects go through a very long study cycle to get qualified, the duration is a minimum of 7 years. During this time they independently learn to use computer software to create their designs, and one of the most common between students is Photoshop.

Photoshop is a great piece of software and our architects quickly master the programme. One of its greatest strengths is its ability to ‘fix’ any problem, it’s the Swiss-army knife of software. Furthermore, we believe that one of the other reasons for its success is that most closely resembles the manual process you’d experience when sketching with pen and paper.
When facing life in an architectural studio most people will find it easier to use the tools they are most familiar with, therefore Photoshop becomes the software of choice for most of the activities in the design process. It’s a bit of an unconscious choice… and it’s normally not an issue… however sometimes other software can give you the same result but more efficiently.

A few months ago, one of our architects created a new way of visualising floor plans using Photoshop, giving it a lovely sketch effect. Our clients were very happy and so were other architects in the studio who promptly adopted the same technique for their projects. In no time our server storage became full and support started to investigate the cause of this sudden growth. It transpired that the beautiful sketch effect floor plans were creating huge Photoshop files, having a substantial impact on the whole network and its performance.

Our support team looked for a solution and came up with a new technique, using Illustrator instead of Photoshop.

After a few months of testing our support team were confident the new solution was more agile, although nothing is ever perfect it was certainly creating less impact on our workflow and infrastructure than the previous Photoshop solution. This new technique using illustrator was creating much smaller files, which had less impact on the network, faster to print and quicker to update.

At this point the challenge was not the new software workflow and technology, but convincing our architects that with a very small amount of training they would benefit by using another software to create the desired output.

At RPP we believe that is not enough to just tell people that they should do something… if they do not understand why something has to be changed, there is little chance that whatever new technique is proposed is adopted at all. Especially if something comes as second nature and new techniques require some effort.

So the question is why did the support team go to all that effort?

The bollard emergency was an excellent way in which for us to visualise and appreciate the size of the files we create. As a result, our approach to creating files has changed. By involving the RPP support team at the beginning of a drawing, the correct steps and software are now used, and bollards are no longer created on our system.

Instead of using Photoshop, illustrator is now used for rendered plans and elevations, and rather than the files being 5 GB in size, they’re now no more than a few megabytes. Poor old Mark should have no problem lifting that!