In this episode, we talk to Mike Pearson about improving outcomes for infants with cardiac conditions and data visualization using Clojure.
David Hockney
“A Bigger Picture”
Cambridge Center for Mathematical Sciences
Millenium Mathematics Project
Nrich.maths.org
Winton Center for Risk and Evidence Communication
Understanding Children's Heart Surgery Outcomes
Matthieu Betteille's Clojure implementation of CSS modules
Mike’s EuroClojure talk
David Nolen’s EuroClojure talk
Nexe
The show is available on iTunes! You can also subscribe to the podcast using our podcast feed.
You can send feedback about the show to podcast@cognitect.com, or leave a comment here on the blog. Thanks for listening!
EPISODE COVER ART
AUDIO PRODUCTION
PRODUCER
Our theme music for this episode is Thumbs Up (for Rock N' Roll) by killthenoise with Feed Me which was used under a Creative Commons License.
0 Likes
In this episode, we talk to Mike Pearson about improving outcomes for infants with cardiac conditions and data visualization using Clojure.
RUSS: Hello, and welcome to Episode 115 of The Cognicast, a podcast by Cognitect, Inc. about software and the people who create it. Obviously I’m not Craig Andera. I am in fact Russ Olsen. Craig has moved on from Cognitect to pursue new challenges, and certainly everyone at Cognitect, and especially The Cognicast crew, wish him all the best.
The Cognicast is going to continue on in 2017 with new hosts including Carin Meier, Tim Baldridge, and Stuart Sierra. But this week we are bringing you an episode that Craig was kind enough to pre-record for us.
And before we get started, we do have just a couple of announcements. The Baltimore Clojure user group is meeting, well, tonight, as we release this podcast. That’s Tuesday, December 20th, 2016. You can get the details at www.MeetUp.com/Baltimore-Clojure, but you better be quick.
Also, the Toronto user group is meeting on January 17th, 2017, so you’ve got a little more time there. That’s at www.MeetUp.com/Clojure-Toronto.
And that’s about it. So without further ado, here is Episode 115 of The Cognicast.
[Music: "Thumbs Up (for Rock N' Roll)" by Kill the Noise and Feed Me]
CRAIG: I believe then we are ready to go, right?
MIKE: Right.
CRAIG: Okay, then.
MIKE: Okay.
CRAIG: Cool. Let’s kick it off. Well, hello, everyone. Welcome to The Cognicast. Today is Friday, November 11th in 2016. And I am very pleased today to welcome to the show Mike Pearson. Welcome to the show, Mike.
MIKE: Thanks very much, Craig. Good to be here.
CRAIG: Well, so we ran into you at – I wasn’t there, but several other Cognitects ran into you at EuroClojure where you gave a very interesting presentation. They came back, and they said, “Oh, we should definitely have Mike on the show.”
I said, “Oh, that sounds great.” I then had a chance to look at your presentation and I was like, “Well, yeah, we definitely want to talk to this guy.”
But before we get into all of that and the other topics for today, I will start you off with the question that we always start our guests off, which is a question about art. This is the thing where we ask our guests to relate some experience of art, whatever that means to them, anything at all. So I know that we talked about this beforehand, and you said you had something in mind, so what would you like to share with us?
MIKE: Yeah, well, when you said that you wanted to start with a question on art, I thought, wow, that’s good. That’s my area because I like graphics. I’m a visual man, really, so visual arts is where I’m at.
I think the thing I wanted to share was just an artist that I really respect and admire is David Hockney. He did a show at the Royal Academy in 2012 where he put on – what was it called? Oh, yes, it was called A Bigger Picture, and it was kind of a standard, very classic set of paintings, drawings of the area around Bridlington, which is in East Yorkshire, North East Yorkshire on the coast.
I guess, in a way, this sounds really boring because it’s just classic landscape art, but it was totally stunning, totally stunning. The colors that are used, the clarity of color was incredible, and the way that he just made me see the world again in a different way. When an artist does that, you know that they’re good.
CRAIG: Mm-hmm.
MIKE: I just love the way he thinks about painting. He says things like, “To be an artist you have to use your brain, use your hand, and use your eye,” and I think that’s a really good summary of the skills that he brings to it.
I don’t know whether it’s been in the States, that exhibition. But if you get a chance to see that work, especially at full size, it’s totally mind-blowing.
CRAIG: That sounds really cool. I mean it occurs to me to wonder whether it’s actually harder to use a–I don’t know if this is the right word, but–mundane subject, like just–
MIKE: Yeah.
CRAIG: –the view out the window.
MIKE: Yeah, something that impressionists have all done, and it’s kind of hackneyed, isn’t it, the landscape. But seeing a modern artist and a new perspective on landscape painting after everything that’s been done over the past few hundred years, I thought it was incredible.
CRAIG: Very cool. Do you do anything in the way of producing art yourself?
MIKE: I have done, yes. I haven’t done a lot recently, except for graphics at work, Web graphics and the like. But I have done some acrylics, and I’ve done some sculpture. I’ve done some wood sculpture. I used to be into making anatomically nice looking horses out of wood, which was good fun.
CRAIG: Cool. Well, awesome. Well, I think this is the problem with putting this question at the beginning is that I for one would be–
MIKE: It leads you in all sorts of different places, doesn’t it?
CRAIG: It does, and that’s not a bad thing in and of itself. The only issue is that we almost always have the guest on because they have done something that we found technically interesting.
MIKE: Yeah.
CRAIG: And I’m always like, well, I’d love to keep talking about that, but we do want to turn our attention to – although, I guess in your case–and we’ll get to this in a minute, but I will tease a bit by saying in your case–the segue here is maybe a bit less abrupt than it might be for other guests. But we’ll come to that.
MIKE: Okay.
CRAIG: Meaning – well, I’ll just hint a little bit. We are going to talk about visualization, which I think is a super interesting topic. But anyway, before we do that, though, I realize that I forgot to give you a proper introduction. I wonder if you would mind making up for my deficiency and introducing yourself to our audience briefly.
MIKE: Yeah, certainly. Okay. Mike Pearson. I work at the Cambridge Center for Mathematical Sciences, which is part of the university. It’s really the math faculty in the university.
I haven’t, I mean I’ve been working with groups mostly in the educational area. Those groups have been looking out to the general public rather than towards research, so it’s been – I mean the main group I’ve been working with is called the Millennium Mathematics Project because it was set up in the year 2000. And we’ve published a number of websites aimed at schools and a kind of Scientific American/New Scientist sort of site, which was explained in mathematics to the general public, especially applied mathematics.
Some of those sites have been really, really popular. The nrich.maths.org mathematics site, and this is used by teachers all the way across certainly the U.K. a hell of a lot, and across the world as well, problem solving mathematic sites. And they’ve required various visualization over the years, which I’ve been producing. That’s where I’m coming from.
More recently, I’ve moved over into the stat side, and I’m helping to work with a new project called the Winton – and it’s got a very long name. I haven’t learned it yet. It’s the Winton Centre for Risk and Evidence Communication, if that makes any sense to you.
CRAIG: Mm-hmm. Mm-hmm.
MIKE: It’s all about balanced communication of evidence, so whatever means we need trying to avoid things like Brexit happening again, I guess.
CRAIG: Yes, and so this was, to some degree, the topic of your talk. I think I will attempt to summarize it and hopefully not do too badly. I should mention, by the way, that I got a chance to see your talk. As we record this, it says at EuroClojure. It’s not out yet, but it will be very likely by the time this show goes public.
MIKE: Oh, that’s interesting. Have you got any dates yet on that, because obviously I’m interested at this end?
CRAIG: I don’t know a particular date. We can certainly – offline, we’ll ask the people in charge and see if they can give you something more. But I think it’s a matter of weeks, not months.
MIKE: Sure.
CRAIG: It shouldn’t be too long. Certainly by the time this comes out, I expect that people will be able to view your talk, which I thought was very interesting. I think you addressed the topic of the visualizations that you considered, rejected, and ultimately settled on–
MIKE: Yeah.
CRAIG: –as part of a very important project relating to – well, maybe I’ll throw it to you. I wonder if you could relate to our audience what the topic of your talk was and maybe some of the challenges and discoveries that you made in the course of doing that project.
MIKE: Yeah, certainly. Well, the talk was mostly about a project that I was involved in. We called it – I mean all these academic projects have a silly acronym, and this was called PRAiS2 because it was about partial risk adjustment in infant surgery. That makes PRAiS if you put it all together.
CRAIG: Okay.
MIKE: But it was about child heart surgery. It’s about correcting congenital heart disease. There have been, over the years, a lot of statistics gathered about the performance of surgeries, about surgeons, about performance of hospitals, which are summarized in whether children die or not 30 days after the surgery. If they survive 30 days then that’s a win. If they die, obviously that’s not so good.
This was triggered by a whole long history of heart surgery, which dates back to 1944 when it started in Baltimore. We had an unfortunate experience in the U.K. in Bristol in the late 1980s where the unit there was having much, much higher death rates than were to be expected. There was a lot of controversy at the time. There hadn’t been enough evidence gathered, and people were just learning how to assess that evidence. So a whole set of procedures were put into place to make sure that in the future we could assess how hospitals were behaving and really audit their performance. It acts as sort of an early warning system to make sure that we were on top of anything that might be going wrong in the hospital, like a consultant who is going a bit gung-ho and trying new techniques without any due respect for the needs of parents, this sort of thing.
CRAIG: Yeah, so this was a really interesting talk to me on a number of dimensions. One was certainly I really love it when I hear about people applying our craft, profession, whatever the word is–
MIKE: Yes.
CRAIG: –to helping people.
MIKE: Yeah.
CRAIG: I think there’s a lot of work, and it’s not a bad thing, but a lot of times it’s, okay, well, I’m building. Maybe in my spare time I’m building. You know I like to do flight simulators, and I’m building tools to make that more enjoyable, and that's great. But then I hear about someone using software to improve the chances of children surviving heart surgery, and I’m like that’s the stuff. So I thought that was great.
Maybe I have a question, which is kind of a stupid one since the answer is likely obvious, but is that something that you valued about this project was the fact that you’re contributing to hopefully saving children’s lives? I mean I have to imagine it is.
MIKE: Well, I think that’s taking it a bit far. We’re not necessarily immediately helping to save children’s lives. This is, in a very boring sense, an audit of hospital performance. But if we learn from bad factors and good factors, then obviously, yeah, I guess it may help to save a few lives.
But, yeah, I mean it was a real privilege to work on this project. I thoroughly enjoyed it, and working with clever people who know what they’re doing and everybody had his own specialty, his or her specialty, and the whole project pulled together in a way that you rarely see. Also working with the parents of the children because we met them in focus groups.
Often they brought their children with them, and they used those focus groups to tell us about the experience they had with going through the surgery with their children. They were looking at the Web tools that we were developing at the same time and feeding back and saying whether they thought this or that was important to say or whether a certain word jived with them or not, or whether a graphic jived with them. It’s just a huge privilege to meet these people because, honestly, it’s a very stressful and traumatic time for them.
CRAIG: Yeah, so you’ve touched on one of the other really, really interesting, for me, takeaways from your talk, which was this phenomena that I think we run into a lot, which it’s not a disconnect, really, but it’s a difference in perspective between the people that are producing a tool–
MIKE: Yes.
CRAIG: –and the people that are consuming it.
MIKE: Yes. Yes, there’s a huge difference. Yes.
CRAIG: Yeah, and you had a couple great examples of places where, as a programmer, I would have looked at your initial take on things and said, “Oh, yeah. I see where they’re coming from because my viewpoint is always ‘let me understand the model’.”
MIKE: Yeah.
CRAIG: But you arrived at something different because you weren’t communicating with programmers. You were trying to do something else. Maybe you can make that more concrete for people.
MIKE: Well, maybe I should go back to the central visualization of the Web tool that we presented because I think that kind of sums up the process that we went through. Really, the problem that we had is that when you’re trying to assess how a hospital is performing, you have to assess it against some standard, so you might have a hospital that, in the past year, has a 97% survival rate, 30-day survival rate for children postoperatively. Well, how do you know whether that’s good or bad? Ninety-seven percent sounds high, but if all the other hospitals are up at 99%, 98%, and a few of them are down at 96%, maybe 97% is not so good.
Obviously what you have to do is get a predicted range within which you would expect the hospital to be performing. But that predicted range should be different for each hospital because the hospitals take on different cases. Some of them specialize in quite complex surgery. Some of them specialize in the less risky cases. So the predictive range is going to move with the hospitals’ specializations and with the particular intake of children they’ve had during the year. That’s where this risk adjustment comes in.
You can imagine that trying to explain how that predicted range is calculated and how it’s totally dependent on the children that are visiting the hospital and have their operations are not at all to do with the hospital itself is where you have to gain the trust of people. That’s the core concept you have to get over that the way it works is that the children come into the hospital. They’re assessed.
You can imagine that the consultants and the doctors are going through a checklist of problems that they have to correct. They have their x-rays. They have their ultrasound. The doctors do a diagnosis. They understand what the disease is. They get their 3-D imaging, and they, in advance if you like, fill in a form to say this is the situation. That form is the input of our statistical model.
I’m beginning to lose the thread here.
CRAIG: That’s okay. We were talking. No worries. No, I’m right with you, though. I mean we were talking about – go ahead.
MIKE: Yeah, so if you can imagine a hospital that’s doing 500 or 600 children during the year, doing operations on those, then you’ve got 500 or 600 risk assessments. Each of those can go into our statistical model and out will come a risk factor for that child. You might say this child has a 70% chance of surviving the surgery. This child has a 99.9% chance of surviving the surgery. That’s purely from the statistical model.
You would never communicate those numbers to a parent because they only make sense in aggregate when you’re looking at the whole hospital. But that’s kind of the process that we go through. We have all these children coming in. They are assessed individually. Then you can run a kind of – well, it’s a mathematical model to assess what the predicted range of outcomes in aggregate for that hospital should be for that year.
That’s what we were trying to explain, so it’s not an easy thing to explain to the general public or to journalists. It’s quite key that we do this because if you get it wrong, if you get the communications wrong, then really all hell breaks loose, as it has done in the past. We’ve had closures of the Leeds General Infirmary for a few weeks because something went slightly wrong and some journalist got the wrong end of the stick and started making rather incorrect, publishing incorrect articles or, rather, intentious articles about a hospital that was just slightly out of the norm, but could have happened by chance. That’s the sort of thing we’re trying to avoid.
CRAIG: Right, and so I saw you showed a couple things that kind of speak to that. One maybe minor example was you have a case in your UI where you had the ability to display some statistic that had to do with a percentage chance of something occurring.
MIKE: Yeah.
CRAIG: It’s a range, and then where a particular data point was on that range.
MIKE: Yes.
CRAIG: And the range was generally quite narrow. You know, 96% to 100% was what you were showing.
MIKE: Yes. Yes, well, the Leeds Hospitals are doing very well these days. Their overall survival rates are very high, so the ranges are between something like 96% and 99% survival.
CRAIG: Right, and so you showed. You had the ability to show that narrow range so that you could actually see enough detail to draw whatever conclusions need to be drawn. But then you said it was really important that you be able to also show the full range from zero to 100.
MIKE: Yeah.
CRAIG: So you can get sort of an absolute view. I thought that’s the type of thing that I find absolutely fascinating because I’ve been doing a little bit of minor work in visualization lately.
MIKE: Yes.
CRAIG: It feels to me like when you find that sort of thing, and maybe this is just me, you immediately know it to be correct or it feels like really valuable. You hit it and you’re like, “Oh, yeah, well, obviously that’s useful.” But from the other side of it, like when I’m starting out to try to present information, it takes me what feels like a really long time to get past my own blindness or inability to perceive that and to arrive there.
It always feels like a lot of work and a big payoff. I’m wondering whether, A, that’s the same for you and, B, whether in your experience that it becomes easier or there are techniques that lower the activation energy, if you will, to arrive at that state of really appropriate and useful visualizations?
MIKE: Well, in that particular example of the zero to 100% range or the 94% to 100% range would be making a choice or making a slider that takes you between those two extremes, it’s really just an example of looking at absolute risk or looking at, in a way, well, un-based–
No, it’s not relative. Excuse me. It’s looking at a sub-range or a whole range, and it’s very, very easy to misinform people just by expanding a graph, by expanding the range of a graph. One thing that the statisticians in particular are very hot on is making sure that people do get the whole picture.
Obviously here we’re comparing hospitals, or we could be comparing hospitals. There isn’t a big difference between 96% and 96.5%. But if you’re on an expanded range going from 94% to 100% in your graphic, then that looks enormous. So it’s really quite important to show people where you are on the scale and to give them a feel for the fact that they are dealing here with very small differences in survival.
Another problem that the statisticians will point out is the framing of these numbers that we’re talking here about survival. We could also be equivalently talking about mortality. We could be talking about – I’ve been saying 96% to 99%. Well, that’s a difference of 4% and 1% in mortality terms. Then you could have a journalist picking up on that and saying, well, this hospital has got four times the mortality rate of this other hospital because it’s at 96% instead of 99% survival. So the framing there is also really important.
CRAIG: Yeah, absolutely. You mentioned a couple times that some of these insights came from the statisticians. Was that always the case?
MIKE: Yes, I mean that – no, that was not always the case. In fact, that was – well, I mean the statisticians and the psychologists prepared the bulk of the text of the Web tool. There was a lot of explaining to do, and a lot of it has to be done in text. But the parents, the journalists, the health professionals that came into the focus groups were really what this project was all about. We drove it from those focus groups.
We had something like eight focus groups in total. We just went through a cycle of preparing initially something on paper for them and getting some feedback, some reaction to initiate the text and the few diagrams on paper. Then taking it in each cycle through, so successive iterations until we had people saying, “Yeah, this is what we want to do. This makes sense, and this helps us through it.” That was the process we went through, and it was really important to take it from the users.
I also think it was really important for the technical people–and I mean me. I was the technical person–to be involved with the users at that stage because I do think that we have something to offer there that very often we can provide solutions that others do not see because they don’t know what’s possible. There were many occasions when a problem would come up and you could offer some alternatives and then users who were present–parents, whoever–would make an immediate decision as to which ones they would prefer.
CRAIG: Hmm. I guess that’s all really – and you know I think there’s a sense in which that idea of tight feedback loops of direct connection between users and developers. I mean these aren’t new ideas, right?
MIKE: No, they’re not new ideas in the industry, Web development in the industry, but they are new ideas in the health community in many ways. It’s quite surprising.
When we’ve published a paper, Christina Pagel, who is the project director and, well, I suppose all of us contributed to it, were publishing papers on this. The feedback that we’ve had from the academic community is basically saying, “Yeah, this is fantastic, but this is a model that we should be following in future health projects, future statistical health projects.” Maybe it’s the case that the industry and the Web industry is a little bit ahead of academic practice here.
CRAIG: Maybe. Certainly I think it’s something that we arguably stole from manufacturing, right?
MIKE: Yeah.
CRAIG: With all the Lean and everything, but what I was wondering too was, based on this experience, because I think there are some differences from maybe typical Web development, whatever that means.
MIKE: Yeah.
CRAIG: In the experience you had, whether there’s anything that you saw that you would definitely carry forward to future projects. I don’t know what that would be. Maybe it’s this idea of the focus groups or whatever, but was there anything where you’re like, oh, well, even if I’m not working in healthcare at some point in the future, I would still do X. Were there any lessons like that for you?
MIKE: Well, I suppose since we’re on a Cognicast, I’m going to talk about Clojure at some point.
CRAIG: Yeah, please.
MIKE: I’m definitely going to be taking that through. One of the things that I found was that these cycles that we went through, focus group to producing a new prototype to develop publishing and then another focus group, and so you’re going around a loop. There’s a lot that has to happen in that loop. Each focus group generates a huge amount of material, and that has to be processed, written up, and we have to then make decisions on what are the key things that we must implement.
The facilitators would write this all up, and Sense About Science helped us. They’re a sort of charity company in London who helped. That will take them some time. There’s a lot to do, a lot to process. Then the statisticians and myself and the psychologists would discuss and then react. And so there was a process that we went through on each iteration before I could even get started in implementing the next round. Typically I’d have maybe a week to get the next iteration out before the next round of focus groups.
So I should say at this point I’m getting on a bit. I’m 64 years old. I like things to be easy, and the way I think ClojureScript helped in this case was simply the fact that I could think it all through in one language. I didn’t have to go into HTML, JavaScript, even CSS. I didn’t have to, and I certainly was aware of all that happening in the background, but the language I was thinking in was the same. The data structures I was thinking in was constant all the way through. It just made it easier to fit into my head and to react quickly to what was needed.
That’s an experience that I was very pleased with, and I don’t think I was doing anything out of the ordinary there. I was just being an engineer doing the job, but with these tools I felt I was being more productive than I would have been in another style, JavaScript or Angular world, which is the world I’d just come from. I was very happy with that, and I’ll certainly be taking those practices forward.
CRAIG: Cool. You mentioned CSS, by the way.
MIKE: Yeah.
CRAIG: I think you implied, or at least I certainly inferred that you’re doing something other than writing CSS in a static file using the CSS syntax. That’s something I’ve been kind of interested in. Is that what you were doing, or am I wrong?
MIKE: Yeah, I’ve been very interested. I suppose I’ve talked about Angular, and I suppose that morphed into Web components and … (indiscernible, 00:32:20) and all those sorts of things. One of the things that they had, which I thought was very useful, was this idea of being able to localize your CSS definitions to within a user interface component because there are some things that you – where you want to make the decision as to how things look at component level. You don’t want that to be influenced by global CSS in the file, so you have to find ways of localizing that CSS.
CSS is, honestly, a horrible sort of – it goes everywhere. It’s kind of one vision. I find it’s really hard to control it.
Since doing this project, I’ve been looking around at ways of getting that kind of approaching into the ClojureScript React realm framework, and I came across a little library by Matthieu Beteille. He has done a ClojureScript implementation of CSS modules, which I haven’t really used that in Angular yet, but I think it looks very promising. I’ve tried a few demonstrations with it, tried a few little ports of components with it, and I’m not sure whether that’s the all seeing, all dancing example of what’s needed there, but it’s certainly moving in the right direction. And I think it does help you.
You end up coding CSS in Garden syntax, which is like Hiccup. I think that’s a good way to go. You can then extract the CSS files from it. And if you want to publish in a classic … (indiscernible, 00: 34:17) unique classic way … your CSS is separate from your code.
CRAIG: Yeah. Right. The thing that kind of tipped me off that this might be a good idea was, I was talking with Alan Dipert and Micha Niskin on a recent show, and they mentioned hoplon UI.
MIKE: Oh, yeah. Yeah.
CRAIG: Right, and so they talked about the fact that CSS doesn’t really – it’s not really a language, right? You don’t have any mechanism of composition or abstraction or reuse.
MIKE: Yeah.
CRAIG: Hence, things like Sass and LESS.
MIKE: Yes.
CRAIG: I was like, well, yeah, I want those things. And so I haven’t looked at the thing you mentioned. I forget the name of it, but the CSS modules thing. I’ve looked at Garden a bit.
MIKE: Yeah, it’s quite big in JavaScript. There was this library called CSS Modules and a Web distribution service.
CRAIG: Cool.
MIKE: Distributions of it, which works very good.
CRAIG: Did you wind up–? On the project that you did, you said you were looking into these approaches on the project that you did.
MIKE: Yeah, I’ve looked at those since I finished this project.
CRAIG: Gotcha.
MIKE: But for future work and in the current work I’m doing, yes, I’m definitely going down that road.
CRAIG: Interesting. Yeah, I definitely have to check that out myself. Yeah, I appreciate the tip there.
MIKE: And this is just yet another way of pulling, you know, everything what we’re doing in Web development into the one language. I really do think that helps you think about it.
CRAIG: It’s certainly a great help or someone like me who has spent the bulk of their career avoiding the front end and focusing on the back end. And so having to move over into this world, it’s definitely helpful.
MIKE: Yes.
CRAIG: That aspect of it is helpful for me now that I’m doing more work with things that people actually have to look at, interact with, and hopefully not hate.
MIKE: Yeah, absolutely. People do hate this stuff if you get it wrong.
CRAIG: Well, I certainly do. Yeah.
MIKE: Yeah.
CRAIG: You mentioned something, actually, I think that this touches on a bit. You used the word “trust.”
MIKE: Yes.
CRAIG: And I was like, whoa, that’s a really interesting concept for a user interface. How do you – and there’s probably not a simple answer to this, but what are your thoughts on the role of and the mechanisms by which we can achieve trust via user interface? It’s kind of an odd concept, right?
MIKE: Oh, gosh. Yeah, I think that’s quite hard. Yeah. I’m not sure whether a user interface can do a whole lot. It’s more about where you’re coming from, and it’s the whole picture. I think if you’re reading a site, which is trying to give you information about something on which you may be making a decision that the first thing you want to know is that you’re getting unbiased opinions. Really not opinions either, but that the site is giving you the information in a way, and that information comes from good, reliable sources.
In data visualization, you’ve got to be quite careful what you put, that your sources are quoted, and you’re not funded by one side of the argument, for example. The classic kind of way to lose trust. We have to have a balanced approach and be seen to be balanced as well. How that comes up in the visualization, I’m not sure, but there are certain things that you should do.
The framing thing that I just talked about, whether you talk about mortality or you talk about survival, we started out talking about both because we knew that framing mattered, matters to people. You can say the same thing and quote death statistics instead of survival statistics, and it sounds completely different. It gives people a completely different feeling for the numbers. But they’re both equally right, so we wanted to talk about both initially, and that’s where things like the focus groups are really important because, as you go through it, you realize that you can’t talk about both.
You can’t talk about both in the same way simply because it confuses people. If you’re quoting one number, and it might be a survival number or it might be a death number, there’s too much for them to hold in their head. They need it. They need it straight, so that’s the case where the balance of mortality against survival went in the favor of survival, although we do still put mortality figures at the table.
Does that help answer the question? There’s all sorts of judgments that you have to make.
CRAIG: Well, I mean, unsurprisingly to me, if I can grossly paraphrase you, it’s that software is about people.
MIKE: Yes.
CRAIG: Which is a theme that you know we’ve hit on this show over and over again. And, of course, people are complicated, irrational, and don’t have a very good capacity for objectivity, especially around numbers, especially in the margins. You get up into these 96%, 98% numbers.
MIKE: Yes.
CRAIG: They just don’t make sense to people.
MIKE: Sometimes it’s makes more sense not to use the numbers. Sometimes the words can be more important because there’s very often uncertainty in these numbers. You can make a figure sound accurate just by giving it a number. You might say 96% survival rate. Fine. But what’s the error in that? If the error is between 4% either way, then maybe you should just be saying, well, it’s in the 90s or it’s a very high survival rate, and try and keep numbers out of it if you just don’t have the evidence to back up a hard figure. Figures can confuse people and give the wrong impression. They can give a false sense of accuracy.
CRAIG: Mm-hmm. Yeah, I really see that connected to the idea of using the focus groups that you did because I imagine–correct me if I’m wrong–that one of the things that you were trying to assess with those was the way that people emotionally reacted to the information you were presenting.
MIKE: Yes. Yes. I suppose the one thing that we needed to do in explaining this predicted range was to use the idea of an icon array where each icon was representing a child, and we want the icon to encode things like the risk of that child dying, so we used color for that and also the age of the child because the older children have a lower risk of dying than the very young babies. We needed images for those children, and also we needed to progress the animation through to what happened when the child unfortunately occasionally died, so we needed an icon for death, for a dead child. That’s the sort of thing that obviously is really hard. It invokes an immediate emotional response.
Yeah, so we had some graphics back from animators initially, which showed – they were very nice, hand drawn, little cartoons of children. In turning these into icons for dead children, my first thought was death, black, and let’s make the child white on top of the black instead of having the colored image that we started out with. What I hadn’t realized was that we were ending up with a rather ghostly picture of a child ghost on a black background. Of course this is not what you need.
I think we went through a focus group with the professionals, with this icon in the … (indiscernible, 00: 43:19) first, and the professionals, the doctors, the journalists looks at us and says [gasp], “You can’t show that to parents. That’s totally inappropriate,” which was fine. But then the following week we did show it to parents and, interestingly, the reaction there was far more muted. It was far more, you know, “Yeah, that’s okay,” because they have the reality, and the color of an icon is not so important to them as what’s actually happening to their child.
Without going through those focus groups, you would not appreciate that, and those clear lips. It’s very dangerous to try and anticipate the reactions of a completely different group, as the professionals did of the parents. You will very likely just get it wrong.
CRAIG: Mm-hmm. Hmm. Yeah, that’s really interesting. I love – my favorite projects are always the ones where I’m most connected to the person that owns the problem. That’s not always the user.
MIKE: Yes.
CRAIG: That’s not always possible, right, like if you’re doing a large website.
MIKE: Yeah, sure.
CRAIG: But, yeah, I love being connected to someone who can say this is what it should be or this is what it shouldn’t be. That always – those projects always feel a lot better than when there’s several layers of indirection–
MIKE: Yeah.
CRAIG: –or group ownership of a problem, which is not inherently bad, but when it’s done in such a way that decision making or opinions are diffuse, that always – that’s interesting. It must have been a really fascinating experience for you. Had you done–? I know you’ve done Web development before. Had you done a–?
MIKE: Yeah. No. To be honest, no. I’ve been fairly sheltered from the industry in working in the university with these outward facing projects, yes, towards school teachers mostly. But I think that our practice here has not been as clearly user driven as it should have been. And I suppose I have the enthusiasm of the near fight here. I’ve suddenly got myself tuned into this and realizing, wow, this is really important.
CRAIG: Mm-hmm. What was the – if you could talk about it, what was the impetus for this? What was the thing? Who or what force introduced this mechanism into an environment where maybe it wasn’t happening before?
MIKE: It was at the start of the project. Obviously Christina had to put in a funding proposal to get money for it and went through the National Institute of Health Research. She proposed to tack onto the end of a project, which was essentially to revise the statistical model in light of the new data that had come in the last few years. She proposed to add on a communications element to make sure that the results were communicated clearly, accurately, and in an unbalanced way – sorry, in a balanced way to everybody. And in order to do that, she tacked on a focus group at the end.
The funders came back to her and said, “This is a really good idea. I don’t think we’ve done this before, but let’s do it. But let’s not just have the focus group at the end. Let’s have them run it all the way through the project and from the start of the project. And can you drive the project from the first focus groups?” Actually, it was our funders that requested this and surprisingly, they’ve responded very positively through the whole process.
CRAIG: Very cool. This is all really interesting. I just have been – I mean it’s inherently interesting, but I’ve also been so interested in the topics around visualization and of course always in the intersection of the people aspects of software, which in my opinion are dominant, and the technical ones–
MIKE: Yes.
CRAIG: –which I’m also deeply interested in, so cool stuff.
MIKE: Yeah.
CRAIG: I always like to make sure that we leave time in the conversation to talk about other things that the guest would like to bring up, if anything. I don’t know if you have anything in mind. Sometimes people do. Sometimes they don’t. But you know as we kind of approach an hour-ish, which is our general timeframe–happy to go longer if we’re in the middle of something good–I always like to say, well, so that’s awesome. That was kind of the thing I had in mind that we would talk about today. Are there other things that you would like to bring up or discuss?
MIKE: Well, let me see. I suppose we could talk a little bit about my journey towards Clojure and ClojureScript, if that’s of interest.
CRAIG: Oh, yeah, please. I love origin stories. Yeah, please. I’d love to hear that.
MIKE: A little bit about that, so the work I was doing in education was mostly Flash based, which is possibly a bit of a no-no term these days. But I think, at the time, this will be through about 2003 to the Steve Jobs denouement in 2010, it was the best technology for a small group of one or two people to support a lot of small interactives. Because you could get material out into the browsers and because it was going into essentially the Flash player, a virtual machine, you had a consistent environment that you could aim for. And you could – and you had a good graphics environment and with new things like Flex and Flash Builder coming along, you had a good IDE and development system. There was a lot going for it.
When we suddenly realized that this was no longer going to be appropriate in the future and started making the move into HTML5 and JavaScript, it really felt for a long time, you know, what could I go to? What could I turn to? Where are the standards here? Where are the tools that I can use?
I suppose until I’ve hit on Clojure, I’d been through most of them. I mean At EuroClojure David Nolen put up – you’ll probably see it if you haven’t seen it already. He put up a slide of how he feels about JavaScript development, which was a picture of one of these enormous organs with all the buttons. There must have been 200 or 300 multicolor buttons there. It was a really good impression of, I think, what a JavaScript engineer feels JavaScript is like. There’s just so much to choose from, so many different ways to go, and it feels like you’re walking on quicksand the whole time.
I went through GWT. I went through Clojure. I went through various research projects like Noble, Dojo, Accenture, DART, Angular, Cappuccino, and Splat , all those things. You have to explore them. It takes an enormous amount of time. And it’s really unproductive time.
When I finally started tuning in to a functional program, not Clojure in the first instance. In the first instance I went through CoffeeScript and then LiveScript and then Haskell and then Elm, and finally got into Clojure and ClojureScript. Suddenly I feel, ah, this works. This is a good – this is a big enough solution to cover the whole field because up until then we kept on falling off the edge, the things I needed to do that the framework didn’t cover. But here I feel you’ve got it covered in a way.
I’m feeling I’m back in that old kind of way of working that I used to be in Flash. I’ve got a firm base that I can trust. So that’s what it feels like now.
CRAIG: Yeah. It’s interesting. I agree. I feel the same way, right? I mean I think the idea of simplicity, this idea of small pieces you can put together in different ways is where that comes from.
MIKE: Yes.
CRAIG: You know what I mean?
MIKE: Yeah.
CRAIG: You can.
MIKE: Sure.
CRAIG: Because you’re always going to be able to – well, always is a strong word, but you’re more often going to be able to go–
MIKE: You have enough, enough in your head, which it describes the problem simply enough so that you can cope with the rest of it.
CRAIG: Right.
MIKE: But when you’re coping with stuff that when you’re never sure that you’re starting on the correct basis, I think it holds you up. You can’t take it forwards in the same way.
CRAIG: Right. Right. Yeah, so the other thing that you said that kind of tweaked something in my head was you mentioned Flash.
MIKE: Yes.
CRAIG: And how Flash was valuable to you in the problems that you were solving in part because you were able to leverage the browser as the delivery mechanism–
MIKE: Yes.
CRAIG: –or at least the Web as the delivery mechanism and the browser as the–I don’t know-host. I’ve lately been playing a little bit with Node, and I know that–
MIKE: Oh, yes. Yes, I’ve done a fair bit of that too.
CRAIG: Yeah, well, it’d be interesting to get your perspective on that because I feel like there’s some opinion out there that Node, that there’s equivalence drawn between Node and JavaScript. And because JavaScript is viewed by some people–
MIKE: Well, I think Node has done an awful lot to make JavaScript usable because until Node NPM, those package managers came along, JavaScript was just impossible. You just had no way of connecting individual bits of work together in a consistent way. Even with Node, it’s just one of two or three different mechanisms that you can use to define what modules, but at least it’s there and it’s something that you can hang a hat on to a certain extent.
Yeah, I’ve got no objection to using JavaScript libraries when they’re there and they’re good and they hit the spot. I mean in graphics visualization it’s really hard to beat d3.js as a low level graphics library and charting the library. And many people in the JavaScript world have built some fantastic stuff on top of it. But that’s all good in the ClojureScript world because if you need to use those things, you can, so I don’t feel cut off from that world at all.
CRAIG: Right. In fact, the thing about Flash that reminded me of Node was that I feel like Clojure lets me decouple the language from the runtime, you know?
MIKE: Yeah.
CRAIG: I can still – I’ve written some fairly involved simulation of things like weather and, you know, it’s computation heavy.
MIKE: Yeah.
CRAIG: I can use that from the JVM. I can run it at a command line if I need to do that via Node, like this idea that the runtime is a feature that’s separate from the language, I think, is a really powerful one, and we’re seeing that all over the place.
MIKE: Yes. I happened upon your name recently. You’ve done something running ClojureScript making ClojureScript executables in Node, haven’t you?
CRAIG: Yeah.
MIKE: (Indiscernible)
CRAIG: Yeah, I mean it wasn’t anything I invented, but I did happen to see that other people had. I was interested in turning my Clojure code into a native executable because the users for this particular thing are on Windows, and so that’s a familiar packaging mechanism for them. I’m like, well, I have this code. It seems like one ought to be able to do that. I could certainly package it with the various JVM packagers. But if I can not have them install a Java, that’s better than making them do it.
MIKE: Yes. Yes.
CRAIG: And so there–
MIKE: Yes, there’s certainly a certain resistance to Java in certain quarters still.
CRAIG: Yeah, not a big deal, but again any requirements that you can remove is only making things easier. I’m like, well, what would it take to produce a native executable? It turns out there’s this thing in the Node world called Nexe, which is rather clever.
MIKE: Yep.
CRAIG: It compiles the V8 engine and your source code into a single, standalone thing that you can then say, well, here’s a Nexe, and the startup characteristics are actually quite good, I think. I forget the exact numbers, but it’s significantly faster to start a Clojure program written in ClojureScript compiled to JavaScript and then embedded in one of these executables than it is to say, “Run the equivalent program,” where you’re firing up Java. Certainly far faster than when you’re launching it through Leinegen.
MIKE: Yeah, for things like D3, what I found myself doing quite a lot is looking at D3 and thinking, “Wow, that’s good. It does almost all I want, but I really don’t want this binding between. I don’t want to keep data in the DOM. I want to keep it in my closing atom.” I’m finding that the parts of D3 I want to rewrite because of those or I want to code myself using Realm or whatever, and then you do that. You find that actually most of this code that you’re looking at in D3 is collapsing into just one little run component, and that’s an easy way of doing it.
CRAIG: Mm-hmm.
MIKE: Yeah, so it’s been an interesting process.
CRAIG: Cool. Well, I see that we are coming up on an hour, and a very, very interesting hour it has been indeed. But I think it might be an excellent time. The conversation seemed to at least have reached a great pause point. I certainly am looking forward to my next conversation with you, whether it’s on the show or off. We would certainly love to have you back on again some time.
MIKE: Okay.
CRAIG: I don’t want to cut you–
MIKE: Next time it’s breast cancer.
CRAIG: Yeah, no, I mean this is – I really do love to hear stories of people applying technology to truly important problems. It just makes me happy that we are able to make the world a better place, in addition to producing games and search engines and things like that.
MIKE: Yeah. It’s cool.
CRAIG: I mean those are great things too, right? They’re definitely useful, but I love it that a child with a heart problem may in the future have a greater chance of survival due to something that we did with computers. That just makes me happy. Cool stuff. Certainly appreciate your contribution on that front.
MIKE: You’re welcome.
CRAIG: Well, cool. It sounds like that’s a – I didn’t cut you off? Was there anything else that you wanted to talk about before we–?
MIKE: No, no. That’s fine.
CRAIG: Okay. Great. Well, awesome. Well, I do have one more question for you then, as we always do. This is the question about advice. We always ask our guest to provide our audience and me, for that matter, with a piece of advice, whether that’s advice that they have received or advice they like to give, or really any sort of advice. What advice do you have for us?
MIKE: Okay. Well, a very quick one, and I think it’s something that you all agree with. When you develop, when you’re developing, iterate. Never stay very far away from running code. I mean that’s just a useful piece of advice that I often give to anybody who comes in. We often have summer students here, and somebody who starts programming in the user interface will very often write too much code before they try it and then make too many changes before the last iteration, so they get lost. And so all I’d say to them is make small changes, keep testing, go run the loop, and make sure that you’re always on top of it. Will that do?
CRAIG: That’s excellent advice, and not at all the worst for being something that we’ve said before because I think it’s the sort of thing that I at least could use frequent reminders on since I know I tend to drift away on that. Thanks very much for that. I think it’s fantastic. Thanks a ton for taking the time to come on and talk to us today.
MIKE: You’re very welcome. It’s been a pleasure and a bit scary. It’s the first podcast I’ve done, so my apologies if I was a little bit hesitant about the whole thing, but yeah, it was okay.
CRAIG: Oh, not at all. No, we were really glad to have you. I found the conversation to be absolutely fascinating. I’m sure our listeners will agree.
But we will go ahead and wrap it up there. This has been an awesome conversation. I’ll thank you again, and I’ll thank our listeners. This has been The Cognicast.
[Music: "Thumbs Up (for Rock N' Roll)" by Kill the Noise and Feed Me]
RUSS: You have been listening to The Cognicast. The Cognicast is a production of Cognitect, Inc. Cognitect are the makers of Datomic, and we provide consulting services around it, Clojure, and a host of other technologies to businesses ranging from the smallest startups to the Fortune 50. You can find us on the Web at cognitect.com and on Twitter at @Cognitect. You can subscribe to The Cognicast, listen to past episodes, and view cover art, show notes, and episode transcripts at our home on the Web, cognitect.com/cognicast. You can contact the show by tweeting @Cognicast or by emailing us at podcast@cognitect.com.
Our guest today Mike Pearson, on Twitter at @grumplet. Our host today was the magnificent Greg Andera. Cover art is by Michael Parenteau, audio production by Russ Olsen and Daemian Mack. The Cognicast is produced by Kim Foster. Our theme music is Thumbs Up (for Rock N' Roll) by Kill the Noise with Feed Me. I'm Russ Olsen. Thanks for listening.