Mike Bostock - Design is a Search Problem

I'd like to actually go ahead and get started and welcome our keynote speaker who really needs no introduction is the author of d3.js which I'm sure changed most of our lives in a graphics editor for the New York Times where he's been really pushing the boundaries of interactive storytelling and so if you if you could give me a hand welcoming Mike Bostock to the stage right so I've always wanted to give a talk about design but I've always hesitated to give that talk and the reason for that is I really don't feel that I'm not good at design which is not say that I'm not proud of some of my work but design has this tendency to feel very capricious which is that some days you feel like you are a master of design and things are going pretty well and then other days most days you tend to feel more like a neophyte where you're not really sure what's going wrong or how to solve your problems or why everything is so hard and I think Paul Ford recently tweeted this I think it's sort of like summarizes my sentiments pretty closely so one commonality between writing and coding is that everything you do is in a nightmarish state of total failure until the moment it is not and he was he wasn't writing about design directly but if you look at this first reply sounds like design I mean this is like exactly the sentiment that I feel and so if you end up talking about your process and talking about design there's this fear that you will discover that there is no method to the madness and that whatever past success that you've had isn't really the result of any underlying reason it's just lightning striking it's happening to be lucky and so when we talk about our own work it's convenient to sort of ignore all that intermediate failure and the mistakes that were made and that uncertainty and just to just look at the polished end result and to brush away those mistakes that were made and and that sort of lets you pretend that you know what you're doing but of course that's not really helpful if you want to learn design I think if you want to learn design it's helpful to understand that everyone struggles with it and makes mistakes so I'm going to talk about design anyway because I know at least one thing about design which is that we collectively do not know many things about design but to phrase that in a less Rumsfeld Ian way I'm going to say that design is hard and it is because design is hard it is challenging to articulate sort of these effective design principles you know they require careful interpretation thoughtful application and ultimately you never even know if the design print schools that you hold dear are the reasons for your success so what I'm going to talk about is not so much these design principles but instead how we can establish a process for design that recognizes the inevitability of failure and the necessity of trial and error so the title of this talk and the thesis of this talk is that design is a search process a search problem which is to say that we have these principles for design and they are necessary to guide us but they're also not sufficient they don't dictate what a successful design will be they're not blueprints there are alternately too many unknowns for the principles to be sufficient to tell us exactly what we need to do and so what we need in a successful design process is to be able to explore as many of these possibilities as efficiently as possible so that in whatever time that we have because we're always facing particular debt lines you know whether it's a daily graphic that we're working on or sort of a longer-term project where we might have a couple weeks or even a month we we need to be able to spend a lot of time exploring things that aren't going to work in order to find the things that do work and that hopefully if you have a robust creative process like this that you can succeed even if you don't know what you're doing like me so first I guess I should clarify like what I mean by hard because there are lots of things that are hard and design is sort of hard in a particular way so other things that are hard are you know like famous theorems in in mathematics or you know efficiently carrying large amounts of data and the thing however that is peculiar or particularly bad design is that you can't really reduce it to a simple logical system that you can make provable assertions about it right so if you think about computer science so I like a particular problem like like sorting there are various optimal like n log n algorithms for sorting an array of numbers and you can choose between those different algorithms based on whatever constraints your problem has whatever performance characteristics you want to optimize for and so in this slide here is a visualization of quicksort which is a probably one of the most common ones and so each of these little lines here the the ones that are leaning left or the smaller numbers the ones that are leaning right are the larger numbers and the way that quicksort works is that it's called it's a partition exchange algorithm so each of these cyan groups are the active partition and then within that there's a magenta or line which represents the pivot and so each step of this process it's finding the numbers that are larger than the pivot and moving those to the right of the pivot so I'll repeat that again so that you can see how it works now there are lots of variations of quicksort as well and lots of other sorting out algorithm looks like for example you have this one is is using a random pivot there's other ones that do like median of three there's even a cool one that does dual pivots at the same time it's amazing but the point is like you know you have all of these different oops sorry different sorting algorithms and they have different characteristics like you know merge sort recursively partitions the array as well but each of those partitions can then be sort of in parallel because it's going to be sorting each of those partitions and then merging them together and each of those partitions can be done separately and then the merge statements are combined so point is there are lots of things that are uncertain in computer science as well opportunities for creative problem solving but at the same time many of these problems can be reduced to these logical systems about which we can make very strong statements and even if we can't you know prove that a particular approach is optimal at the very least it's easy for us to make empirical observations you know where we can measure the performance of this particular approach on data and and decide what is right for us but in design it's a lot harder to do that and so instead we have you know a lot of collective wisdom and we have a lot of principles but things tend to be much more subjective so even the whole concept of you know what is good or what is optimal design is subjective you know something that might work well for one person or for one audience might not work for other people some technique that might work well in one situation might you might think it would work well in another situation but there's some other sort of hidden factor going on that prevents that approach from working which is not to say that there isn't a whole slew of useful information swath of collective wisdom that you have to internalize and apply in your work but it's that you also have to understand the limitations of that and to sort of reinforce this concept I want to take a little blurb from dieter roms who understood this problem all too well so this is from the vit C website back in the early 1980s dieter roms was becoming increasingly concerned by the state of the world around him an impenetrable confusion of forms colours and noises aware that he was a significant contributor to that world he asked himself an important question is my design good design as good design cannot be measured in any finite way he said about expressing the 10 most important principles for what he considered was good design sometimes they are referred to as the 10 commandments I think that maybe is a little strong statement from the marketing team there but I think to me what this says is like if the best designer in the world doesn't know whether his designs are good I mean how is it possible for like schlubs like you and me to to figure out our own designs so but again it's not to say that these principles aren't useful it's just that they're not sufficient so one of the 10 commandments the 10th commandment in fact that I think has been very influential to me and is something that I like to apply to my own work so I want I want to read that to you as well good design is as little design as possible less but better because it concentrates on the essential aspects and the products are not burdened with non-essentials back to purity back to simplicity so this is very important principle but again it's not a recipe for success right we have to take this as sort of a philosophical viewpoint and figure out how to apply it to our own work but it's not really an instruction says you know given the particular problem that we're facing you know this is what you should do I mean all of us want our to be simple the problem is we don't know how to do it right so that that is what makes these principles difficult to apply and so the reality is like no matter how well you master these principles there will always be some exploration and some failure which is required now there are other scientific principles in design as well that are important to know so does anybody recognize this equation I want to yell it out very good yes so this is Fitts law so this is a way that we can estimate the difficulty of a pointing action so such as like moving the mouse towards that clicking on a button or navigating a sequence of drop-down menus so t he R stands for the movement time to perform that action a and B are these empirical constants is sort of like our functions of the device that you're using like how long it takes you to start moving in and how quickly it moves but the ones that are important as far as design are concerned are D which is the distance to the target and W which is the width of the target along the vector of movement and so the intuitive explanation of Fitts law is that targets that are bigger and closer are easier to click on which is fairly obvious but it's still extremely useful to understand objectively that that is true and also to be able to quantify sort of exactly how important that or how exactly changes in our design can influence our ability to perform those actions so to give you an example of how we apply this law this is a graphic done by Shawn Carter Kevin Quayle and Joe Ward for the New York Times about strikeouts over the last 110 years in baseball and so each of the dots here on the screen there's like 2,300 of them are the I think it's leave average number or the number of strikeouts per game on average per team by year so you can see how sort of as a cloud and with also the league average shown and blue there how that's been changing over time and increasing dramatically but if you you can this is an interactive this is just screenshot but you can mouse over this and sort of get detailed statistics about a particular team like you can see in 2005 the Oakland Athletics five about five strikeouts per game but if you were to mouse over each of these things individually each of these dots is a radius of three pixels so there's tiny little things to click on or to mouse over and so what we do instead is we overlay this Voronoi diagram and a Voronoi diagram is simply a way that identifies the closest point to the mouse so that you can simply with you know mouse over and mouse out events identify the closest point and effectively what this does is take all of those tiny little circuit circles and make them much larger targets so that they're easier to interact with so we can quantify that by looking at a histogram of those target sizes so the the Siam or sorry the magenta line here is the the default size of those circles that three pixel radius and the gray bars here show the distribution of target sizes after we've applied the Voronoi overlay you can see that there are some targets that are actually smaller than those three pixel circles but that is because those circles were overlapping and so in it was in fact it's even worse if you don't have the Voronoi diagram because you're not able to click on those or hover over those circles at all and so when you have those tiny little circles together you can still differentiate those with the Voronoi diagram so that's another important way that we can sort of improve the usability of our graphics through these design principles so ultimately designs difficulty or complexity comes from these human factors like the reason we can't reduce it to just the simple logical system is that even the smallest problem in design requires understanding aspects of cognition of psychology of perception it's really like a biological problem rather than just a mathematical problem so we've come a long way from phrenology that's what the background illustration is like this idea that different parts of our discrete regions of our brain are responsible for different emotions or aspects of our psychology use these chronometer x' to like measure head and identify what your particular problems were obviously we know a lot more than that but there's still a lot that we don't know and that is what makes design difficult and so then the reality is a designer you know when you start out a particular project you know the naive approach is that you just proceed linearly from where you are to where you want to be but because there are so much that we don't know even if we have good principles we can't take that approach in practice and therefore our process has to reflect that so the reality for own life is like let me start over okay so the reality of the design spaces is more like this right where we have a maze that we need to explore where there are various we want to proceed to our destination but we ultimately don't know how to get there and the only information that we have is sort of like this local space around us like where we can immediately go next but we don't know sort of where the different approaches will dead-end or what roadblocks will go run into or ultimately how successful any particular approach will be now as an aside I was like making this slide so this is using what's called prims algorithm for making these mazes and these little dots here the magenta dots represent the frontier and so the way that this algorithm works is for each cell that's in the frontier you know you can explore from any existing passageway you can go up down left or right and all of this algorithm does is that it randomly picks a new cell to expand and it does not expand any cell that would then reconnect with an existing passageway and so the result of this mage or the result of this process is a maze which completely fills the space but which is also what's called a minimal spanning tree so none of the different passageways reconnect again so starting at the bottom left corner it's basically a tree that branches out and fills this entire space so what we need then really is an algorithm for exploring this design space efficiently so one possible algorithm for that is called breadth-first search which is similar to how the maze is constructed in the first place and so in this case basically what we're doing is we're just going out exhaustively searching the entire maze picking up a new sort of open point on the frontier and then the magenta line here is just simply keeping track of the best path that we've taken so far and so ultimately this will find a solution you know you will get to the top right corner of the screen but you can see that you need to explore the entire maze in order to get there and in practice obviously we don't have time to consider every possible design before we finally publish something so really then just like we need a better algorithm for exploring this maze we need a better process for exploring our designs so an alternative to this is called best first search and what this does is it keeps track of the frontier again shown in cyan but it only goes down the frontier that currently seems the most likely to succeed so it keeps a queue a priority queue of those different cells and sort of as it explores if it finds that it's now worse than one of the other cells that are in the frontier it switches paths and ghost goes to try the other solution now you can see this definitely goes down some dead ends and doesn't succeed this particular path was pretty successful but if I try it again you can sort of see more or less successful approaches so this is really again this is pretty bad so but it's just a heuristic I mean there are probably more advanced algorithms that we could apply certainly more information that we could use here I'm using very limited information in this particular algorithm but I'm just including this because it kind of looks cool and it's I think a helpful analogy to understand the problem that we face in design so really in terms of our process you know we have two things that we can do we can go faster which is sort of like the brute force approach and we can go smarter which is about sort of like best first search the best first search which is about applying our principles and biasing our explorations so that we pursue those possibilities that seem the most promising and we spend more time exploring those and less time exploring the ones that are more likely to fail now just a little aside as I was making this like you can do another thing which is cool which is that you can fill it but then you color each of the cells with the hue so this is a rainbow color scale but whatever it looks cool so I just like watching that alright okay so I've talked a lot about sort of philosophy but now I want to talk practice and sort of try to show you how I apply this concept or apply this process in our work so I'm going to show you a video of a graphic that I worked on with Hayden park and Jeremy ashkenaz and this is a little video this is going to be pretty fast and might be like epilepsy warning I'm not sure how flashy it will be so watch out yeah you all right so that was every commit in the get repo for this project as a screenshot shown in 38 seconds I think it's like fifth of a second per commit or something like that so this graphic is called taking the battle to the States and it was about looking at sort of how single party control of both the executive branch of the states the governor's office and legislative state legislature affected that state's policy so which policies were passed under that so if you have Republican Party controls both the state legislature and the governor's office you sort of you might think they would be more likely to pass conservative policies and likewise if you have Democrats controlling both of these branches of government you might expect them to be passing more liberal policies so it's fairly complicated because you have these two different dimensions you're trying to look at two different sort of organelle dimensions right you have the policies ranging from liberal to conservative and then you have the control of government being Republican or Democrat and then you have all these different policies area policy areas that you're looking at I mean you're only seeing the top two here but I think there's something like 10 and then you have you know the population of the states because like the states vary greatly in population so you don't necessarily want to wait them all equally when you're looking at the overall behavior and then people also like looking at maps because they want to understand the geography so there's a lot of things going on here I I'm not sure this is necessarily the best graphic that I've worked on but I'm including it because I think it illustrates sort of all these like wild explorations at the beginning that looked nothing like the final graphic and I really like disasters like I don't even know what that was trying to show there is one in here which I liked which we didn't include let me see yeah this one here I think there's a few variations but like I said there are these two dimensions right you're looking at sort of the state control and that's the x-axis and then you're looking at the policies which is the y-axis and so really this is sort of a scatter plot it's just that those two dimensions are ordinal dimensions rather than quantitative dimensions and then you have small multiples by different policy areas but this was still a little bit difficult to understand so that video was created mostly automatically by this tool that we built internally at the New York Times called preview and each of our graphics is backed by a git repository those git repositories exist on a server where preview runs and preview can actually serve any graphic any version of any graphic live for you directly out of the git repo so used to be the case that in order to show somebody else your work you had to walk over show them your laptop or you had to explicitly make what we call it internal shareable preview and so the preview server was just designed to make that process easier and to sort of share everything by default rather than you needing to explicitly do that because particularly if you're working out of San Francisco like Shawn and I and now Jennifer and Josh and Michael so we have five people in San Francisco we're not in New York so obviously we can't walk our laptop over very easily takes a little bit longer so we wanted to sort of make sharing easier to do and you know I've done a lot of open-source work as well I like the github model I like sharing stuff as blocks and so I wanted to bring that and do that in inside as well so the front page of preview is actually this real-time updating list of all of our projects it's infinitely scrollable you can just keep paging down and see you know projects going back well since we've started the preview server and it updates throughout the day so you can sort of see what the department is working on there's a crazy sort of Chrome extension get hook duct tape system going on which takes screenshots of every commit as it comes in which is extremely helpful right it lets you see visually what people are working on because oftentimes these these slugs are not that descriptive and then of course for any project that's in there you can go in and you can click on it and you can see what it looks like so this is a project that Josh strips working on Josh Williams and you can see there's a there's a little toolbar there at the bottom which has a drop-down menu which lets you switch between branches it also has previous and next links so you can click backwards and see previous commits there's another feature which is you can go see the history of that project as a visual summary so it just gives you a screenshot of every commit now with this particular project it's you know it's limited to that small window at the top so you can't really see necessarily what's different there's a lot more that we could do potentially like looking at visual differences between commits or trying to do some aggregation of those to provide better visual summary so this is sort of more of a first pass but it's still you know extremely useful for being able to see what people are working on and the main benefit that this really provides for us is a way to get feedback more quickly because as we're doing this exploration the goal is to really evaluate how successful we've been so far whether we're going in the right direction or whether we should change and one of the difficulties in doing that is that it's really hard for you to evaluate your own work because you're too close to it you understand what it is that you're trying to do and therefore you see the intent of what you've done and that can influence your perception of it if you show your work to somebody else who doesn't understand what you're trying to do it's easier for them to sort of fairly evaluate it and see how successful you are because they don't have all that context that you have they're just evaluating at face value like your readers will be evaluating it so having ways that people can sort of see your project without you asking for their feedback explicitly is very helpful like even if it's not feedback like if you if you think they're working on something cool and you want to get involved you want to help them you want to share an idea you know you want to make that a passive process rather than something that you have to ask for explicitly and as part of this evaluation process I mean you should also do it explicitly like one of the things that's helped me is to to show graphics that I've been working on you know to my wife or to my friends people that are not in the graphics department and might not have the same biases that we do and just to try to understand if the visualization that I'm making or the graphic that I'm making communicates the way I expect it to do because that's really the goal of the graphic is to try to communicate something to show something because these are you know explanatory graphics that we're making and not exploratory generally like we want there's usually a point of the graphic that we're trying to communicate and likewise if we're building an interface for an interactive graphic we want to make sure that that interface is discoverable that people understand how to use it and so as we're doing this exploration it's important to constantly evaluate how well we're doing and to verbalize what aspects of it that are working well and that are not working well so that if we end up changing paths you know we're not throwing everything away and starting over from scratch every time it's really about learning and taking parts of graphics that work well and parts in removing the parts that aren't working well and sort of reformulating it and improving it as we go along so as I mentioned already you know we use git repos for each of our graphics so you should definitely be using git or some source control for anything that you're doing I mean I don't know how like illustrators that just do everything in AI that would and like keep files of different names I mean I would go insane so use git liberally use branches we have a habit of well branches are also nice and sort of from a social perspective because it gives you like a safe place to work on things that are potentially bad ideas like sean has this habit of naming a branch controversy when it's not likely to succeed or whatever where it may be controversial and so we service that also in the preview server right you in the history like those those Shaw's are have bold names and they're also in the drop-down menu I mean you can look at any commits but obviously it's easier you know if you make the branches named so that people can explore them more easily so this is another example this was just daily graphic that we worked on so it's a much shorter history but you can see that you know there were a bunch of different variations that they tried down there at the bottom this was looking at in in Europe a lot of the countries import energy from Russia import oil and gas from Russia and so this was looking at what percentage of their energy imports come from Russia and so this is a discontinuous cartogram where the country is basically scaled around the centroid so it's sort of whatever this didn't work either but it was the first thing we tried so this is a different approach we're using sort of like a dorling cartogram these are donut charts again didn't really work and then this is roughly sort of the approach that we went with which is a rectangular cartogram or DeMars cartogram I think they look a little bit like gas tanks which is sort of funny this one here I think I mean I think it's harder to read certainly like it's just in terms of a visual encoding I mean you're looking at you're comparing two areas or you're comparing the area of France in the orange to the total area in in gray and it's a little bit hard to do those comparisons with irregular shapes and also doing an area comparison versus doing a position encoding which is what this would be so the position encoding is going to be more accurate and also this is just more reductive right like you've got all of this geography here that really isn't communicating the information that you want to show with this graphic great like we don't care exactly about all the little islands that are in the United Kingdom I mean it's it's helpful to understand sort of a little bit of the geographer you obviously you see that those those countries that are right there on the Russian border are going to be importing more energy from Russia because it's easier for them they're closer and as you get farther away it becomes less common and and so really it's sort of like just trying to reduce that and just focus on just the single variable that we want to show all right so I want to show another example here I'll play this video and I won't talk okay so this is a graphic that we did on on the variation in corporate tax rates across different sectors in the US just to show sort of how widely these things vary you know you have some companies which effectively pay no taxes whatsoever you have other companies which pay they're sort of like in the NA category where they if they have negative profits but they in there they have losses but they still end up paying taxes you can't really give that a particular percentage and you have some companies that pay very high tax rates so it's just like sort of all over the scale again this is just a screenshot just for simplicity here in my slides but you can click this button and it expands out into those different sectors so that you can sort of see how the variation is correlated with those different sectors so if I like this example is sort of the exploded view now you saw in this video here sort of even after we kind of stabilized on this idea of using I guess these are called be swarm plots but the idea is you know it's essentially a one-dimensional scatter plot but then you use collision detection to push apart the circle so that they're not overlapping and so it's sort of also forms this rough histogram so you can see how the different corporate tax rates of companies are concentrated in these different bands so even after we've stabilized on this particular design here it's sort of like bouncing back and forth between these two things and that's because this branched like we baked the forced lake the forced layout so there was another branch which was interactive and computed the positions automatically but then for the final graphic there was no real reason to have that dynamic so we just exported those statically and baked it into the final graphic but you can see early on you know we tried all of these things that look nothing like the final graphic like this is just a scatter plot looking at market capitalization versus tax rate and looks like confetti we also had data for individual years so this is a connected scatter plot on to log scales just interesting to try to like explore it right and then and then drawing lines here that they're looking at the corporate tax rates so again this is one of the issues of looking at percentage tax rates is you've got these weird effects when you have negative or when you have losses rather than profits and so what this is doing here is looking at cash taxes paid versus the what does it say like I think profits - unusual items or something sort of financial terms we tried some box plots you know we tried like smaller sectors versus larger sectors this is actually like if you can see in here but there's a little visualization of how much the circles are getting moved away from where they want to be which is trying to evaluate sort of the the error that is introduced by this collision detection because we're sort of biasing the results there and in order to not have the circles overlap and we want to understand how that is affecting the accuracy of the chart so again even though you can see that this is stabilizing here it's a little bit misleading from this video because there are many more changes that are happening at the end more quickly once we've sort of stabilized on the design whereas early on you know there the commits are farther apart but we're trying much much wider variations in our graphic ideas so I guess I'll show one more but just very quickly I'm going to know what this one is no IDs are stopping again all right so now you can see this got the title so this was the sort of Sankey diagram history of NCAA division one football conferences so looking at how schools changed their affiliation over the last sixty years or something like that so early on like the layout changes dramatically but then by this point we basically sort of stabilized on the form and there were two main insights during this exploration one was that we would use the vertical layout so that it starts by reading the current affiliation and then it moves backwards in time which sort of helps in the readability of the graphics starting with a thing that's most relevant and then moving backwards sometimes sort of as long as you want to go where as doing the horizontal layout sort of you're going to start by reading in nineteen fifty or something like that and sort of less relevant to people and the second big insight from this graphic was really about the color encoding so you can see early on you know I'm trying different color encodings like this is coloring by the originating conference this is coloring by the conference which is sort of redundant with the position and then at some point here there's this realization that we should color the switches rather than coloring the conference and this was really Shawn's insight and I think it's interesting because you know we think from visualization you know you have all of these different dimensions of data and so it's just a question of like which dimension am I going to assign to which encoding but in this case you know the swap isn't really an explicit dimension it's a secondary aspect of it but the reason that it's being highlighted here is because that's really the important part of the story which is that more recently and again you're not seeing it because it's a very tall graphic there are many more switches than there have been historically and that is ultimately about these television contracts and really the conferences being less about sort of geographic locality and more about sort of business arrangement ships and whether it's what's most profitable for the different schools and conferences to be successful and how they want to associate themselves all right so as we're doing this exploration the other things you should keep in mind are that your prototype only exists so that you can learn something it's not supposed to be a final graphic so they don't have to look good they don't have to be polished they don't have to be understandable they don't have to be have labels like every time you make a prototype you should know in your head like what is what is the prototype trying to show you what are you trying to learn from that you have a hypothesis as to you have a hypothesis your that you are testing with your prototype and it doesn't really need to do anything more than that and then likewise as you get farther along in your process you kind of have to switch a little bit because obviously we have deadlines at some point we need to publish something and we can't keep exploring wildly as we get closer to that deadline so you need to transition smoothly as you start to identify what is working well and how much time you have left and in a way this process is sort of like simulated annealing and simulated annealing is this algorithm for you know finding the global maximum of some particular system and it has a concept of temperature so the beginning the exploration is very hot so you're willing to take bad ideas more likely you're willing to spend more time sort of exploring and then as you get farther along your system starts cooling down and you do a little bit less exploration because you're sort of committing more to your idea and so part of the art of design here is figuring out sort of at what point you are in your process how much time you have left and whether you should start slowing down or whether you can continue to explore another aspect of it is you know if you want to move quickly you have to delete code as you go along because you're going to be making mistakes they're going to be branches that you're exploring that are not going to work I mean you think about it is like being a chef right if you're going to make a fancy dinner you're going to try 20 recipes to figure out what you want to serve you know do you want to like do all of your kitchen cleanup the night of your dinner or do you want to do it as you go along so this is sort of something that we're still learning this is the so we launched the upshot on Tuesday and I was helping out with the Senate model so we did this visualization of our Senate forecasts so guess when I got involved with this project so okay Green is the number of lines added and red is the number of lines deleted sorry there are no labels I suck at visualization so yeah so and if I just like highlight my involvement I actually still deleted more code from this project than I added so I was in that agate negative to this project but it just shows you like you know how much detritus you accumulate as you do all of this exploration and it helps for my sanity to try to like continue pruning constantly as I'm as I'm going along and then this is a tweet from Kevin may you all have the pleasure of waking up to this wonderful automated message from emboss TOC delete all dead code from our base camp and then another aspect I mean there there are lots of things I have like a minute left I can't sort of give you all of my advice but you know I I have an article about using make or using a build system and that's really about making yourself more efficient as well so that if you have parts that you want to reuse from other projects it's easier for you to go back and make them work again you know you want to keep that library of examples things that you can reuse so you should go read that article on my website if you haven't already that's called why use make and then of course you know you have to try these bad ideas as you're going along and I think that that's particularly true in visualization because you can't really evaluate an idea without applying it to real data right you may have something that you think works well but there are characteristics of that your datasets might make that idea work well or not work well and so you really have to try it in order to evaluate it but at the same time you can't get too attached to whatever you is your current favorite approach you don't to get stuck at that local maximum right you have to be willing to give up that idea and try something else so lastly just don't be afraid to fail because there's there are too many unknowns in the space for you to sort of succeed perfectly on that linear path to your goal and so you should be willing to try things that don't work and don't be afraid or don't get upset when they don't work because they invariably won't work but it will all be okay in the end okay thank you

Channel: BocoupLLC

Views: 45,792

Keywords: Open Web, JavaScript, Programming, Open Source, Bocoup, OpenVisConf, Data Visualization

Id: fThhbt23SGM

Length: 42min 41sec (2561 seconds)

Published: Wed May 28 2014

Reddit Comments

[u/qznc_bot]

Discussion on Hacker News