Daniel:

Hi, Jeff. Welcome to the podcast. So you are the director of user experience at a company called Element 84, and you’ve got this amazingly rich background in design, and now you’re working in geospatial. For the sake of context, could you just take a couple of minutes to introduce yourself to the audience and perhaps explain to us how you got involved with design, your background in it, and how that led you to work with a geospatial company?

Jeff Siarto:

Absolutely. I’m Jeff Siarto. I’m the director of user experience (UX) at Element 84. E84 is a small software engineering company that specializes in geospatial and science systems. I got here through a sort of roundabout way. My educational background is not in geospatial, or science. I studied general design and user experience in college. After that, I did freelance web design for a while. During that time, I wrote a couple of books for O’Reilly and their Head First series. In that time, I met Dan and Tracey Pilone who run Element 84. They were co-authors in that same series so I was able to get to know them early on in my career.

Before I came to E84, I started a small social media analytics company, which I ran for about five or six years. We did early social media analytics for consumer product brands.  I worked with companies like Wrigley, and New Balance, and Radio Flyer, and we essentially monitored their social media traffic, and then helped their marketing teams kind of figure out messaging and how to engage on early social media channels. That was sort of my initial background. I worked on the software there, and I worked on the design of those projects. After I was done with that, Element 84 reached out to me and asked if I’d be interested in working on this NASA project. I said, “I don’t actually have anything going on right now. That sounds really interesting.” That’s sort of how I got here. I came onto that project knowing very little about remote sensing and earth observation, but bringing my design background to bear on their problems. They had never actually worked with any designers before, so I was kind of new to them as well. I sort of just learned as I went through some of their early projects.

Design and Earth Observation

D:

So we’re going to talk a lot more about design and earth observation in just a second here. I’m curious, when you think back to when you started at Element 84, you said that they’d never worked with a designer before. What was it like for you coming in? Were they doing the right things? I guess a lot of the semantics around earth observation was new to you. When you looked at the products that they were making, the things that they were doing, was it all brand new, or could you see a lot of the design elements that you were used to working with, or was it something totally different?

J:

They were getting there. I was actually the first designer at Element 84, and then I was also the first designer to come onto this NASA program, so they had some foundational pieces there. They had great backend systems. They were working in the right direction, and I was able to come in and sort of help them improve the interface, or get their interfaces to the point where they were in the same league as some of the backend systems that they had. They were kind of getting to that point where they had solved a lot of the early problems, but now more of those user experience problems were starting to surface. That has ended up being a trend throughout my career here is once those early problems get solved, those user experience problems sort of creep up and become the major players.

D:

Now that you’ve been working in the industry for a while, when you think about earth observation and design, do you think a lot of the companies that are doing similar work to what you are doing are facing the same problems? I mean, does it surprise you in any way that we weren’t thinking about design earlier?

J:

I do think that more companies are starting to look at that. As we start to solve those kind of middleware early problems, the piping, and the user interface problems start to creep up. I don’t necessarily think that it’s surprising. If you step back and look at the timeline of the early internet and where all of that went, design became more important as the web matured. A lot of people sort of moved from that graphic design discipline onto the web. They brought those skill sets to bear in an area that was highly technical before it was a focused design medium.

I think we’re seeing that in geospatial, particularly as the tooling gets more web-based and cloud-based, or you’re interacting with these applications and APIs through the internet, you’re going to encounter more user interfaces. I think the importance of those user interfaces is in making the job of whoever that end-user is easier.

Reducing the Time to Science

D:

In one of your tweets, I saw this great catchphrase, and it was reducing the time to science. My first question is, how is design going to reduce the time to science? I think design could mean a lot of different things for a lot of different people, depending on what it is that we are working on. If we think about the geospatial stack, we could divide it up broadly into the backend and the frontend. I’d like to start with the backend. You’ve been talking about it as pipes and infrastructure up until this point. How do we bring design to bear on that? What bits can you come in and design to make it better?

J:

Time to science is super important. To define it a little bit, it is the amount of time that a particular scientist or researcher will spend getting to the answer of the question they initially posed. In the past, scientists have spent 50, 60% of their time doing data wrangling, or data processing- getting all of the bits together so that they can answer the question.

The first part of there in reducing time to science, is sort of smoothing out that backend process. Maybe that’s going from having to deal with level zero data, or level one data, up to a more refined data product that is properly subsetted or properly re-projected, and taking care of that for the scientists. Now they don’t have to do all of that specialty work on the data, and that gets them one step closer. If you sort of continue on with that, particularly as we move into a cloud data paradigm, maybe we go even further. Maybe we take it and we put these data products into a format that can be easily visualized, or easily manipulated in a way that does require programming. So we’ve sort of eliminated some of the lower level tasks from the workflow and we sort of shorten that time to science. As a result, now maybe they only have to spend 30% of their time getting the data in the right place.

If you go back even further, some 60% of data wrangling time was just literally waiting for data to download. I would hear stories when I first started where we would go out and talk to scientists, and we’d watch them work on their projects. We’d look at their workflow and see how they interact with the data. Oftentimes, they’d just have to set up a download, and just let it go, and come back a couple days later when all their files were downloaded. Some of that time to science was literally just kind of sitting around and waiting.

Even just improving how you interact with the data, and just generally improving the speed of the internet that people have access to is user experience as well. The speed of the internet access, the way in which they have to get the data onto their machine, and what formats that data is in. They all are related to the overall user experience.

Data Science Infrastructure as a Commodity

D:

When I think about the backend, apart from the data manipulation to get it to that analysis ready-state, I think about infrastructure like blob storage and the cloud. I think about infrastructure like cloud optimized GeoTIFFs and other cloud optimized data formats so that we can stream data directly to a client without having to run a database somewhere in the background. I think about things like the stack interface. It seems to me that these pieces are sort of slowly coming together, and that at some stage, they’re going to be a commodity. It’s going to be “of course you’re running with these types of standard components”. I’m wondering how you see that and think about that in terms of being a commodity. Do you think it is at the moment? Are we there yet? Of course you’re using these things. What else would you be using?

J:

Yeah, I think we’re moving in that direction. I would not say we’re quite at a commodity yet, but I think we’re getting there. I think you can tell that we’re getting there in a couple of different ways. You’re starting to see the major cloud players building these systems up. I’m speaking specifically of the AWS public data sets and the Microsoft Planetary Computer. You have these big cloud players that are kind of investing in these open geospatial systems. They are building this backend, this foundational layer of data products and APIs that then can be built on top of in a standardized way. 

I think we are in the building stage for that layer. I would say I don’t really know where we are in that building stage, maybe halfway through. I think in the decade-ish that I’ve been working in this, over the last three to four years, you’ve really seen an uptick in cloud data adoption, and seeing investment in those platforms that are going to maybe become a commodity in the short term. I don’t think we’re quite there yet, we’re still in the building phase.

D:

It sounds like you are thinking in perhaps the same sort of lines as I am- that this will be a commodity at some stage. When I think about earth observation, and I think about software companies that are looking to build a business around it, I think it’s going to be pretty hard for them to create the data themselves. There will be satellite platforms which are going to create the data. It’s going to come down to earth. It’s going to go through a commoditized system, and it’s going to end up in the frontend. I think the place where a lot of value would be created, would be in the frontend. Do you think that I’m on the right track there?

J:

Yeah, absolutely. Part of the issue that we’re facing right now is that Earth observation and geospatial data is fairly complex to use. We’re taking a step in the right direction by moving that to the cloud and creating standardized systems on top of that, and now we’ve sort of eliminated that initial barrier. Once we have that, now the companies, and the startups, and the government agencies that want to start spending more time answering specific questions can do that. If we’ve got a commercial interest or issue that we want to answer a question about, now, you have the foundational pieces in line to be able to answer those questions, and focus on taking the data that is in the standardized format and manipulating it in a way to answer a specific question for a specific customer.

All you have to do is sort of focus on what that question is and how to build or manipulate the system to answer it. But you no longer have to worry about “Okay, where am I going to get this data? What data set do I need to use?”. You won’t even really need to worry about what the sensor is or what the platform is. You’ll have the normalized data ready to go. So I feel like that allows you to really focus on the customer problem.

I think a good example of this is a company like Twilio, which is sort of like a communication and SMS/voice API over a bunch of lower level technologies. If I want to then build a product that utilizes some sort of SMS messaging, or some sort of voice system, I don’t have to then go interact with the SMS layer, or figure out how I’m going to do voice over the internet. I can just build on top of Twilio’s system. They’ve sort of standardized out that lower level tech for me. I can focus on my AI chat bot, or my SMS messaging tool or something like that, without having to worry about that slightly lower level. It frees you to think about the higher level problem, as opposed to where you’re going to acquire the data, and how you’re going to get it into the right format. 

The Future of Frontend Design in Geospatial Data Science

D:

When I think about the frontend opportunity, we have these great platforms we can build on. I think about the brand-ability of a frontend. The way you can dress something up, you can change the look and feel of it. You can add an identity to it, and that can become a selling point in itself. It doesn’t feel like those in the geospatial industry are that interested in changing the way we do frontends, and designs. It seems to me that we are pretty committed to using the tools we’ve always used. Firstly, I’d like to know what you think about that statement. And then secondly, I’d like to say do you see any opportunities to change things here? Any things that could be done differently?

J:

Yeah, I do agree with that. There’s a pretty consistent set of tooling that’s been used forever. I think there’s a lot of standardized patterns that we’ve seen used quite frequently. I’m kind of talking about a map interface where you can drag around a map,  you can create a bounding box, and you can sort of interact with a Google Maps style interface, which has become fairly ubiquitous. Ubiquitous both on the sort of geospatial earth observation side, but then also the consumer side as well. From a geospatial perspective, when you’re looking at a map with a bounding box and a sidebar of layers, you’re still thinking- “I need to pull data from around this area. Give me all the stuff inside of my bounding box.” I think there are parts of that that are going to carry over. I do think that we’re going to need to move into a direction where we are building interfaces that are answering specific questions as opposed to just building interfaces that are allowing me to grab a bunch of stuff inside of a bounding box.

There’s always going to be that. In geospatial and earth observation, you’re always going to have to tell the system where on earth you want to get data from. I’m not necessarily convinced that it always has to be on a map. I’m also not convinced, after spending many, many years watching folks interact with map products, particularly in the earth observation and earth science world, that that’s really the best thing. I think people still struggle with it. I think they’re still a little inconsistent, and I think we could do better.

Yes, these tools are ubiquitous. But we still have not ironed out all the UX issues of the map-based interface, let alone moving into a new paradigm.  I’m not convinced that it’s the best interface once we get into that higher level “what question do you want answered?” phase.

D:

Every time I see a new data portal, it feels like it’s a total one-size-fits-all without too much thought that’s gone into it. It’s a map. It’s the panel on the left hand side of the screen. It’s all the usual things. Part of me thinks seeing standard products, like standard design, things that I know and have used before makes it easy for me. I don’t have to learn something new, so I get that side of it. It just feels like this one-size-fits-all product where no one has really come along and thought- Can we do it differently? Is there something else? We even see Google Maps doing the same thing. It feels like maybe it’s not a technical problem. Maybe it’s more of a cultural problem.

J:

Yeah, absolutely. I don’t think it’s a technical problem. There have been great strides on the technical side of internet map making. There are all sorts of great tools to make creating layers and getting the map in your browser easier. I certainly would rather be building map interfaces now than map interfaces a decade ago. We’ve come very, very far in the developer experience with how easy it is for a software engineer to put a map interface together, but I think that’s where we’ve been iterating. We’ve been iterating on- How can we make this map interface a little bit easier to use? or a little bit easier to develop? or easier to serve information on top of? But I don’t think we’ve ever really stopped and thought, is a map really the right interface for this particular application?  

I think that’s sort of where I see us going- Maybe a map’s not the best interface for this particular piece of software. And if not a map, then what?

D:

I’ve often heard people get really excited about having an output they can put directly into a spreadsheet, because that’s what they are used to working with. Something that’s going to go directly into a database, or talk nicely with other spreadsheets, and they didn’t actually want a visual output at all.

J:

I think that’s true. You’re kind of always thinking look, I can give you this picture of the land area. We always want to put things into a visualization. Doing visualizations is an important part of this., but not all science users want their output in that format. Sometimes they want it output in code. Sometimes they want it output in a spreadsheet. The flexibility in that output is important. Not assuming that your user wants it in any particular format, but making things sort of extensible in a way that they can pull it into whatever format they’re most comfortable with is the way to go. Whether that’s a statistical programming language or, like you said, just a standard spreadsheet.

Going back to what we were talking about earlier, with having that middle piece built out and matured, that lets us think about those interface problems. We can spend more mental energy and man hours on those types of problems, because we’re not having to sort through the lower level building blocks.

UI/UX Standardization in Geospatial 

D:

MapScaping used to be an eCommerce website. We ran on a platform called Shopify. Are you familiar with Shopify?

J:

Yes, absolutely.

D:

So Shopify showed up and made it incredibly easy for people like me to start an eCommerce website. There is an app environment, so you can just add these plugins, these apps to your Shopify store from a standardized box. You can quickly make a custom thing, and it’s absolutely amazing. It’s interesting with eCommerce. Their whole thing is to get someone into the shop and out of the shop as quickly as possible. If the checkout takes more than five seconds, it’s too long. There’s this real focus on “get the customer what they want as quickly as they can”. I don’t feel like we’ve got there yet with geospatial. I’m wondering if there’s any lessons that you can see in eCommerce, perhaps from Shopify that we could take over to the products that we build in the geospatial world?

J:

Shopify is a great example, because they’ve done a handful of things  really well. One of the things that I love about Shopify is that they’ve sort of standardized the user experience patterns around the checkout experience. When you’re checking out on a Shopify site, you know that it’s a Shopify site. A lot of people probably don’t know it’s a Shopify site, but they know that they’ve seen this pattern before. They know they’ve seen this particular way the credit card has to be entered into the form. They expect when they start to type their address, that a dropdown is going to appear, and they’re going to be able to select their address, and it’s going to autofill. They don’t have to do all that. That experience is seamless and it’s sort of expected. The end user knows what they’re going to get. I think one of the problems I see with geospatial interfaces now is that you’re not always sure what you’re going to get. 

My one example of this is the way that an area of interest selector, or a bounding box selector on a map interface behaves. Sometimes, you have to click and drag it. Sometimes, you have to click and add points like a polygon. Once you have the area selected, the way in which you perform actions on that selection are also different. I think there are ways that we can standardize that. I think the group, or company, or people that figure out the best user experience will have standardized it in a way that makes it kind of crazy to not use that. That’s one thing that Shopify’s done really well is you really have to convince someone to not use the Shopify platform for their store. The people that are using Shopify, they’re using it because they don’t want to deal with the eCommerce aspect. They want to sell their T-shirts. They want to sell their eBooks. They want to sell their information products. They don’t want to have to learn a new system to do that, or put anything out there that is going to make it difficult for their customers to buy their product.

I think with geospatial interfaces we need to move to that point. We need to make it so that there’s an obvious choice for some subset of these user actions, but not everything. There are certainly people who choose to roll their own eCommerce site for various reasons, and that’s always going to exist. I would love to see some of these patterns mature in geospatial user interfaces so that our science users and our municipal users who are trying to get questions answered for their county or state don’t have to wonder what they’re going to get when they try to pull data to answer a question. They know there’s going to be some standard level of interaction there. 

There are two sides here. It’s great for the developers because they don’t have to reinvent that wheel. They don’t have to come up with a new way to do a bounding box, or a new way to do a map interface. On the customer side, they don’t have to wonder, “Oh my gosh, this is a new geospatial system. What am I going to get here? What is this going to be like?”. I think right now, there’s still some of that. 

A lot of the science users that I talk to, they’re certainly apprehensive about new systems, because oftentimes it takes them a long time to become proficient in the one that they’re already using. They do not like to have a new system designed by these new designers that just came in. I’m totally putting myself into those shoes. At one point, I was the new designer that came in and I was like, “You guys are doing all this wrong. You need to do this, and this, and this.” That kind of freaks people out, especially people whose entire career is based around doing this type of science work. That specific data is very important to them, both to their career and whatever agency they’re working for. There’s a lot of uncomfortableness with that change. I think some of that is growing pains, and we’ve got to get through that.

D:

So we talked about Shopify, and one of the beautiful things about it is that establishment of a standard set of patterns. We know what a checkout looks like. We understand this. Three steps, there’s autofill forms, there’s this, there’s that. Then lastly, we push our credit card numbers in. We get that. Do you think the lack of standard patterns in geospatial speaks to how niche it still is?

J:

There’s not as many designers working on specific geospatial problems. I think that’s certainly changing. I think a lot of the new interfaces that we see coming out from a lot of the new commercial companies that are appearing, they’re taking design a lot more seriously. There just hasn’t been a lot of people working on these problems.

There obviously have been great designers working on mapping problems for quite a while. Look at Google Maps, or Apple Maps, or Mapbox. I think on the earth science side specifically it gets pretty niche, especially because of the complex science that’s going on there. I think the consumer side is a little more mature, but I’m not entirely convinced that the patterns developed on the consumer side necessarily fit the scientific model or even the municipal GIS worker model. Those are different people that need to navigate in a car or look at an aerial imagery of their house versus a user who’s trying to work out land use patterns, or monitor sea surface temperature, or things like that. There are different requirements.

Breaking the Status Quo with New UI/UX Functionality in Geospatial 

D:

I think this gets back to the idea that one size doesn’t fit everyone. We need specialized maps or specialized interfaces, depending on what problems we’re trying to solve. I want to stay with the Shopify example just for a second here. In our store, we had this option to install a plugin. That plugin was going to provide a little mini recommendation engine- People that like this also like that.  I think in the past, a big argument for having the map was, “We can see the data to decide if that’s the data we want.” It’s an incredibly quick way of filtering a massive amount of data visually.  I would love to see some sort of recommendation engines come into these portals to help us filter through it. I would like to see some voice interfaces built into these things. From a design perspective, can you see anything that’s stopping us from integrating some of these ideas?

J:

I don’t think there’s anything specifically stopping us from integrating these ideas.  I think we are moving towards that in some areas. We have this notion on the earth science side of “usage based discovery”. This is finding data sets based on what you’re trying to do. What is the end goal of the data set, and categorizing things in that way.

I think as the metadata systems, that middle piece that we’re in the building phase of now, I think as that gets improved we can expand the metadata available for these data products. Then those alternate discovery mechanisms become easier to build.

Part of the problem is that, in order to build those higher level discovery systems, you still have to have the information about the data. You still have to have the metadata about the products. As we’re building this middle piece out, those metadata are becoming more refined, more detailed. Again, because we’re not dealing with the lower level problems, people have more time to refine and incorporate more specific metadata into these programs. We can start to build smarter systems that sit on top of that data and allow us to have some sort of AI, or machine learning algorithm make recommendations for data that we may not have thought about. Maybe we have an interface that isn’t a map, and you’re just sort of asking the system a question based on a region of the globe. Then it can suggest other questions related to that. Or it can say, “Hey, these other researchers have posed a similar question. Here are their results.” I think there’s a ton of space for those types of interfaces once we have the sort of data infrastructure there, but we aren’t quite there yet.

D:

Is there anybody out there at the moment that’s doing inspirational work in this space that you can point to and say, “Well, if you want some examples of great design, great interfaces, look over there”?

J:

Yeah. So a couple examples off the top of my head. I think the folks at UP42 are doing some really great design and user experience work, from a product perspective as well. They’re sort of an example of the higher level system that’s sort of interfacing with a bunch of these other data providers and then providing an interface or a system on top of that to streamline a workflow to get a faster answer to a question. I really like what they’re doing.

I also love this little project called Placemark by Tom MacWright. He’s doing some really interesting user interface work in a niche space. Unfolded.ai is another really great one. Their mapping and general design interfaces are really, really good. They’re built up on top of Uber’s H3 geospatial library, which is a hexagon-based geospatial library. This is being pulled out of the consumer, commercial side, and adopted now into more of the data analytics and geospatial side of the house. 

Obviously Mapbox, I’m sure everybody knows about Mapbox. They’re doing really, really wonderful stuff. They have fantastic designers. Their 3D rendering and map rendering is really amazing. They are importing consumer and commercial tech into the data analytics and geospatial side. Those are all great examples of fantastic design and user experience.

I’m excited because all of these new companies and projects that are cropping up look great. They’re all seeing design as a first class citizen.  I think we can just continue to build on that momentum and raise that bar a little bit. Then those expectations for where design and user experience need to be for these systems are just going to keep getting better. We’re going to see the same trajectory that we’ve seen on the consumer and commercial internet side. Pick your industry. All of those systems have been improved with designers having a seat at the table.

Design and/or User Experience?

D:

You mentioned design and user experience a few different times there. Do you see them as being two different things?

J:

Yeah. This is like an endless debate. I feel like I was just having a conversation on Twitter with somebody about the difference between design, user experience, and user interfaces. If you’re a user experience designer, does that mean you also design user interfaces? And if you’re only a user interface designer, are you also a user experience designer? I’m not sure if that’s exactly the right argument. 

I think I see design as the whole of everything. I consider myself a designer. There are a multitude of practices under ‘designer’. I think a designer could be a pure art illustrator. I would call architects designers. I think industrial designers sort of run the gamut.

User experience for me is the entire end-to-end workflow of engaging with a product. Oftentimes that is not necessarily the way the buttons look, or the way the map looks, or the way the interface looks. It’s the process by which a user gets through the system. What are the steps that they have to take to get there? What is the language that you’re using in the system? What words did you pick to describe different things? What icons did you choose to represent particular things within the interface? It even goes even further than that. What is it like to engage with your company? So if you’re selling geospatial data and you have to send an email to a salesman and then jump through a bunch of hoops to get any information on a data product, well that’s part of the user experience too. That’s the early, early interactions.

Oftentimes at Element 84, when I’m looking at the user experience, I’m not only focused on the UX of the products that we’re developing, or the tools that we’re building for customers. I’m looking at the user experience of the company itself. What is it like to interact with Element 84 on social media? What is it like to interact with Element 84 when you’re engaging as a new customer? Is the contracting goofy, or is it really hard to get a response from someone? Does the person you had to deal with from a project management standpoint, are they treating you well?

Specifically for geospatial and earth observation stuff, the user experience sort of starts at the engagement with the organization that is brokering the data. What’s the UX of going to NASA for earth observation data? It starts pretty early on in the cycle, and our user interfaces are only one tiny part of that overall experience.

D:

So it sounds like what you’re talking about is the promise. What is the promise here? When I interact with a company, when I interact with a piece of software, what’s the promise that is made? And is the promise kept throughout the interaction?

J:

Part of that promise is that you’re setting some level of expectation. You need to be careful. It’s easy to talk about a particular feature, process, whatever, and set that high expectation. Then you’ve got to deliver on that throughout the entire user experience of that individual interacting with your system. That system could just be a little piece of software, or a website, or an entire company. I think keeping that promise is important. When you get into complex systems, particularly in earth science, it is very hard to keep that promise all the way through. There are so many places in that process where you can sort of lose your promise. It’s really important to be vigilant about that. It’s the hardest part of the job. Making the interface look good and polished honestly is the easy part. The really hard problem that we have to tackle, is really how do we keep that promise from the initial interaction all the way through to I’ve got the answer to the question I had.

The Future of UX/UI Design in GIS

D:

I feel like we’ve covered a lot of this already during the conversation. When we look out into the future, if you had to sum up things into some bullet points, what do you think we can expect from user interfaces when we think about geospatial?

J:

First and foremost, there’s going to be kind of a layering over geospatial. I think we’re going to worry less and less about the sensor technology, the resolution, all the tech specs of the geospatial data itself. I think we’re going to get to a point where we’re not going to have to worry about the low level earth observation data. So there’s going to be a pretty good obfuscation of that. I think you’re going to get to a point where you’re going to get transparent sub-setting and re-projection. It’s just going to be like having to understand the intricacies of SMS messaging or any of the HTTP layers on the web.

I really think we’re going to be done with downloading data. I think the future data sets are going to be enormous, like terabytes, petabytes. Huge, huge data sets. It’s not going to make sense to pull that down over even your best gigabit ethernet pipe. Everything is going to be an API layer. Everything is likely going to be sitting with major cloud providers. You could have a whole other discussion on how you feel about centralization of the cloud providers. That’s beyond the topic of this conversation, but I think that’s where we’re headed, at least from what I can see.

I also think particularly on the earth science side, you’re going to get into these low code or no code science tools. There are a lot of really great projects going on right now. Pangeo is one of them where they’re building a lot of standardized Python tool sets and libraries to sort of deal with earth observation and geospatial data at a code level. Now we don’t have to write this low level code anymore. We can write this higher level elegant Python to do some of the data processing. As we move into the future, I think we’re even going to get a step above that. We’re going to get to the point where I could be a data scientist or an earth scientist and not have to deal with spinning up AWS instances, or making sure I have a particular Python library. Looking 10, 20 years into the future, I think the low code, no code science tools are going to be the big step there.

D:

Do you think the community is going to push for this? Do you think the pull is going to come from outside of the geospatial community? Do you think scientists and geospatial users are wanting this today, is this going to make their lives easier? Or do you think that it’s going to be people from outside the community saying, “We would love to use that, but you’re going to have to do these five things first”?

J:

I don’t think we’re quite there yet. I think the pull right now is “Give me better code tools. Give me better Python libraries. Make this whole spinning up cloud instances go away. Get me out of that.” I think we’re moving in the right direction with things like Jupyter Notebooks and JupyterHub standardizing and making it much easier to do data processing at scale in the cloud. So I think we’re getting there, and I think we are answering the call to improve developer tools, but we aren’t there yet. 

I think that the push is going to come from the other end though. A good example of this, the future scientists, think people that are maybe in high school or middle school now that in 15 years, they’re going to be taking over desks at NASA, and NOAA, and USGS. They’re going to have grown up on low code and no code tools. They’re going to have expectations that the science tools are as easy to use or of a similar capacity as what they’ve seen in other parts of their digital life. I think the push is going to come from that direction.

In order to get the low code or no code science tools, first you’ve got to have really great coding tools. The developer experience has to be really, really good, then the developers can stop worrying about the lower level code. Then they can start thinking about, “How can I write this piece of software where my scientist doesn’t really have to do any coding at all, and they can just be an expert at land use, or they can be an expert oceanographer without also having to be a software engineer Python expert?”

You could think of other commercial interests full of people that don’t have any desire to do code. They’re going to be pushing for this too. You see this in commercial web products, like website builders, and even low code or no code tools for building mobile apps and all sorts of complex web interfaces. We’re getting to the point now where the infrastructure for writing code on the web has gotten so good, that we are thinking one level higher now. We’re able to think about how we can build tools that’ll grant that same power to an end user that the developer has without them having to be a software developer.

Daniel:

I think this is a really, really great place to round off the conversation. I want to say thank you very much for walking us through this. I’ve never talked to a designer before on the podcast. I’ve really enjoyed the discussion. It’s opened my eyes to a lot of things.

Before I let you go, if people want to reach out to you, if they want to ask more questions about any of the things we’ve talked about today, where can they go to do that?

Jeff Siarto:

The best place to get in touch with me is probably Twitter. They can get me @jsiarto. So first initial, last name on Twitter. Or you can also find me @Element84, which is our company’s handle. Both of those places are great. DMs are open as they say.