Andrew Vande Moere writes in his 2005 paper Form Follows Data:
[W]e can perceive a current trend in portable input and output devices that trace, store and make users aware of a rich set of informational sources. So-called ubiquitous computing is moving into the direction of location-based information awareness, enabling users to both access and author dynamic datasets based upon a geographical context through electronic communication media.
With this growing trend of streaming data in mind, Andrew goes on to say
Building automation services enable spaces to react to dynamic, physical conditions or external data sources in real time. Currently, these interactions are programmed by engineers, and imply simple action-reaction rules, such as the control of lights, security or climate control: what would be possible if these tools are offered to designers, concerned with the emotional experience of people?
If you’re an engineer, you might be wondering, “Hey! Why can’t I design ambient systems? I care about emotional experience too. Somewhat. Sort of.” As someone who majored in electrical engineering and computer science and still works with a lot of engineer types, I will tell you why. Engineers are generally not very good at the visual display of data. To engineers, the most beautiful part of a data visualization installation might be the hardware, elegant code, or the hours spent tweaking the system’s logic. Engineers are fascinated with the guts of the system.
Statisticians run into a similar problem as the engineers do. To a statistician, the most beautiful part of a display is the data. Where did the data come from? How are you processing the data? Is it accurate? Statisticians are interested in the blood of the system. Generally speaking, the statisticians don’t care so much about outward appearance.
Designers, on the other hand, are obsessed with aesthetics. Placement, colors, organization, and outward appearance are what designers work with. Designers want to make the data visualization pretty, and so they will spend hours in front of the mirror primping and putting on makeup, um, metaphorically speaking.
They All Need Each Other
Here’s the kicker though. You really need all three – engineer, statistician, and designer – to make a really effective data visualization. It can be three people, each with a skill, or one person with all three skills. Yes, I know I’m overgeneralizing with the three types, which I suppose is one of the ten mortal sins in the book of stat. I don’t care. When you’re working with a large, multivariate data stream you have to process the data, interpret the data, and finally, visualize the data. Sure, there’s plenty of stuff out there where only one or two of the skills were involved, but imagine how much more amazing those pieces could have been with the full triumvirate.
If you’re a designer who has worked with a statistician who did not care about aesthetics; if you’re an engineer who has worked with a statistician who couldn’t program; or if you’re a statistician who has worked with a designer who did not know hot to analyze data, I’m sure you can relate.
I do second your notion Nathan, and had read the paper a while back but not reflected on it the same way.
… somewhere at the edge of my mind.. part of me thinks, theres something very interesting in the tensions and tug of war, between different the extremities and perceived priorities in the areas of practice and specialism you mention. I dont think we experienced much conflict working on ‘humanflows’, because we were for the most part on the same page and could communicate with each other- and lets face it, it helped to have a statistician who was engineering and design aware and Miguel the designer who could code and deal with cleaning up data!
But conflict and confusion can also sometimes lead to quite creative results! we were missing proper punch up there! ;)
anyhow in all seriousness, I think you also make a very strong argument here for a domain of practice which is design, stat and engineering aware (im still gutted I cant find a stat dept in our university) . So, I wont be surprised if someone is reading this thinking, why don’t we get a multidisciplinary postgrad course with a view towards recruiting designers, statisticians and engineers!
Ah, you’re totally right about the need for conflict.
I got stuck in the EDA mindset again. In the engineering / stat world (the design world, I think less so), everyone always seems to be under a quickly upcoming deadline, so there’s a need to get (good) things out as fast as possible — no time for conflict and a need to come to a fast consensus.
As a result, design seems to suffer the most. It’s often an afterthought in the technical fields, which can be a problem when you want to start getting people to pay attention to you. However, a design piece lacking the ever so important backend seems to leave people asking, “It’s pretty, but what’s the point?”
When there’s a bit more time though, a bit of clash will usually be good — the point of collaboration :)