Live from Orlando, Florida, it's theCUBE. Covering Cisco Live 2018. Brought to you by Cisco, NetApp, and theCUBE's ecosystem partners. Welcome back everyone, we are here in Orlando, Florida, theCUBE for Cisco Live 2018. I'm John Furrier with theCUBE. Stu Miniman's my co-host for the next three days. Our next segment is the Meraki team we have. Joe Hainline who's with WWT, is a product manager in Courtney Batiste who's the Meraki Solutions Architect. Welcome to theCUBE, great to see you. Thanks for coming on. Thanks for having us. So we've got the engineering, we've got the application, we've got the use cases. Meraki's really, really picking up a lot of steam. It's very cloud-scale, very cloud-native, bringing the enterprise perspective to it, which is a really big challenge right now around how do I get enterprise into the cloud?  If you want to really do the hybrid cloud or multi-clouds really complicated, Meraki's been doing really, really well, what is the big takeaway? I mean, why should people care about Meraki's success and what does it mean to them? So I think it's important to understand why has Meraki been leading the way? We started out cloud-based and that's what was important and that's what's been leading for the past couple of years and we look forward to pushing ourselves above and beyond that. So we also work with partners such as WWT that also embrace that same philosophy and technology and you can see that based on the things that WWT has done up to this day. I mean, Joe, if you want. What's the most you guys done with Meraki? Yeah, I mean, what we love about Meraki for enterprise is being able to leverage APIs to be able to do things at scale and quickly. So we've done some of the largest Meraki deployments, I would say, to date in North America. You know, hundreds of Meraki networks, hundreds of site locations a night with leveraging some of the APIs that Meraki's built, obviously, and then some platform innovations we've done on top of that. Expand on that, give us some color on that. So what does that mean? Hundreds of sites. I mean, is it just offices? Is it full networks? What's the density of it? Can you just kind of unpack that a little bit? Yeah, so we had a customer that we were deploying retail locations. So 10 to 15 Meraki devices per site and being able to do that at scale, be able to deploy those really, I think our max was about 200 on one night that we cut over leveraging APIs. So yeah, it's... What's the big walk away from Meraki? Obviously the simplicity is at one, but you're seeing IoT becoming a big thing where you don't want to have to hire someone to go out and actually turn stuff on. These networks need to be self-provision, self-managed, self-healing. That seems to be the trend that everyone wants, right? So that's obviously just getting stuff up and running. But then actually having it operate and connect into the network seems to be the hard part. Is that where the magic is? Courtney, where's the secret sauce? I mean, where's in all of this? So the beauty about Meraki is that you can use that infrastructure to build a solution, and that's the goal. I mean, we've been doing networking for years and there's no doubt about where the future holds. We want you to know that there's different solutions that you can build on top of your Meraki infrastructure, whether you're focusing on provisioning or you're looking at doing any kind of scanning APIs. Those are things that are leading the future. We're also trying to help you find innovative ways to bring other business units into the IT business. So for instance, marketing is huge. They have huge budgets. They want to invest in their IT infrastructure. And if we're able to give value by showing them what they can extract from the network, that's where the APIs are key to tie in. So integration's really critical. Absolutely. Is that you said APIs is where you see the critical advantage for you guys? How are you guys doing the API? Are you just slinging your APIs with Meraki's? Are you connecting them? You're writing code integration? Where's the touch point? Yeah, that's a great question. I would say that the power that Worldwide brings to the table, especially after acquiring Asynchrony Labs three years ago now, which is a software development arm of Worldwide now, is being able to take those conversations, those integration conversations, and say what's the business outcome you're trying to achieve? So if a customer, a marketing or a line of business person says these are the things we're trying to accomplish, a lot of those are going to be enabled by infrastructure and enabled at scale for enterprise customers really only via APIs. But there's more to that conversation too. I mean, it might be what's the marketing campaign we want to do or what digital innovation are we going to try to do that's going to make us competitive in this space where we can take our business innovation practice and our practice around mobile and web development and tie it into the business outcome we're creating for a customer, leveraging the Meraki infrastructure, leveraging the capabilities that Meraki brings to the table, leveraging APIs around who's in your store, traffic analytics and things like that and pulling those all into a solution, whether it's a consumer facing solution or a backend solution for sales associates that helps give them insight about what's happening. It's kind of knowing the business outcome you're trying to achieve and putting the right pieces in place. Joe, I wonder if you can expand a little bit on the transformation that WWT is going through and your customers. We're here in the debit zone. I've known WWT for years and moving up the stack and APIs and things like that isn't the traditional position that I think at WWT. Long time Cisco partner done lots of great solutions over the year, but it was at the infrastructure level, which not to say that's a bad thing. So talk a little bit about more that those transformations for you and your customers and partnering with Cisco even further. Yeah, I think, like I said, we got acquired, I'm part of Asynchrony Labs actually originally and we got acquired by Worldwide three years ago. I think it was a really smart move because Jim Cavanaugh saw the spaces moving toward software to find everything basically and being able to have that capability built in. I think it's really changed the way we go to market. We can have conversations now, conversations that do include infrastructure, like infrastructure is still core to our business, but conversations that can start at the marketing or line of business side or the digital transformation space or really whatever business outcome that a customer is hoping to achieve, we now have the ability to have that conversation at any level. Everything from our skills and expertise traditionally at Worldwide and deploying infrastructure at Worldwide scale and supply chain management, supply chain management and just top notch integration skills and solution delivery. And now with Asynchrony being able to apply our best in class business innovation, digital transformation, mobile development, web development skills into that mix, we can really provide fully customized solutions delivered to a customer. Take us through what that means for the customer and use it as a way to compare five years ago. Let's just go back in time, pretend it was five, roll back five years, no Maraki. What's the road look like? And then what's the road look like with Maraki? If you had to do this five years ago, what would you have to do? Get a project team, have an assessment of the customer? I mean, much different world. Take us through what, in your mind's eye, what that road would look like. So as someone from Asynchrony on the software side, I can tell you what it looked like five years ago before we were acquired by Worldwide. When we had conversations with some of our big retail customers, for example, we would only be able to go so far in the conversation. We could do the app development. We could take a mobile app and bring it up to par, make sure it integrated well with backend systems. But when it came to what does it take to actually deploy a new customer experience at scale across 4,000 retail locations, we would have to have partners. And now with Worldwide, we can have that conversation. We can integrate through our ATC lab space, our Advanced Technology Center labs. We can integrate a retail location in our lab six months before we deploy it in the real world and have it be exactly the same hardware and software that we're going to deploy in the real world. So we can now have conversations where we're working with infrastructure ahead of the game to make sure that there's a seamless rollout rather than there being sort of a line of business versus IT conversation where line of business says, hey, we have this new digital innovation, but it's not working because the network isn't solid. It's a two step process in the old way, which long creates more risk, more a lot of moving parts. Yeah, and now we have someone seamlessly connecting those pieces across the spectrum. And you do it up front, and then you just deploy. And we know what's a good network strategy to make this scale at enterprise scale, and then what's a good digital strategy to say how are we going to integrate with that? What beacon technology are we going to use? What network APIs are we going to connect to? What analytics do we want to achieve through this transformation to measure its success and have that built in to the infrastructure from the beginning, so. Talk about the management side. Obviously, intelligent dashboarding is big, machine learning, they have a lot of that in their products, only going to get better and talking to the lead executives of the group. For you on the front lines with customers, you want to have that awareness of what's happening, the instrumentation. What is, how's that working for you? Good? Is it working out? What's your view on that? Yeah, I'd say that it's been really good working with Meraki because of the APIs, but we've also opened up some new offerings around Meraki lately from a managed service perspective. We now have a, I would say a digital transformation engine called Branch of the Future, which is designed around not just managing Meraki at scale, but it does have that component, but really the whole ecosystem of what does it take to do a digital innovation leveraging Meraki at enterprise scale, and it includes, like I mentioned, our Advanced Technology Center labs, it includes a managed service, it includes branch service capabilities to be able to roll out hundreds of sites a night, at scale, but it also includes platform innovations like Thelios, which is what I'm the product manager for, which is really a platform for digital innovation that leverages Meraki APIs, leverages other technologies that are going to be in a space like a retail space, pulls those together to provide an analytics capability to provide provisioning, to provide other commonly needed capabilities, and really just gives customers a way that they can engage with worldwide and in a continuous manner, that's going to give them an engine for innovation where they can make a network upgrade, for example, rather than taking four years and rolling something out slowly that they're trying to do a transformation and not getting the benefits of that technology for four years, leveraging Branch of the Future, we can do that same thing in four months, and that big investment they've made in infrastructure, they can actually get an ROI on that immediately, but it doesn't stop there, because then we can say, all right, what's working, what's not, based on the analytics we're taking, what's the next step, and build in that continual evolving of the offering for the customer? Four years to four months. Courtney, what are you hearing from customers? How are their needs evolving? What's driving them from the business and from some of the new technologies? Well, so they're looking at what's next, what's the trends, what are customers wanting, what exactly are their guest experience that they're wanting to have? So it varies based on the vertical. They want more intelligence, they want more out of their infrastructure, and that's where I feel like we've definitely filled that void, and creating this partnership with WWT has been amazing to see what customers are taking from it. They see the advantages of more than just a regular infrastructure running. They're getting to the point of truly embracing intelligent networking. On the future of you guys with Maraki, you know, you're doing deployments overnight, massive numbers, we hear anecdotes from Todd Knight and Gale that customers are giving hugs to each other. I mean, things that have never happened before are happening. And this is the cloud scale, and the CEO of Cisco's and Kino talking about a scale is really the new normal. How are you guys, what are some of the projects you're working on that you could share that give an indicator of some of the cool things and relevant things that are going on? What are some of the projects you're working on right now? Yeah, I'm not allowed to talk about specific customer names, but we can, some of the things that we're building are enhanced customer-centric views of network health, for example. So building systems that show network health from the perspective of the business in simple ways that customers can understand, not just at the IT level, but at the CEO level or at the marketing level. So a lot of customization, leveraging APIs and leveraging platform technology. Yeah, for the customers that are out there that might be assistive customers or new to Meraki. What's your takeaway? What would you say to them and they say, you know, what is this Meraki thing? What does it mean to me? What would your advice be to your peers or someone watching? What would you say to them? You kind of sum it up into a bumper sticker. Yeah, I would say that you need to have those APIs for scale. You need to have a cloud-managed platform that can really scale to the solution you're trying to offer, especially if you're an enterprise customer. And you need to have a partner that understands how to manage to the business outcome you're trying to achieve, not just manage at the technology level. You really need a conversation. You need to be able to create a conversation between your business stakeholders and your IT stakeholders and your marketing and other stakeholders, infrastructure stakeholders, and say, what are we trying to achieve as a business? And I think worldwide is uniquely positioned to be able to help have those conversations with those customers through our business innovation practice, through our chief digital advisors and chief technical advisors practice, and just our deep and rich experience with being able to do this at scale. So, yeah. Cordy, same question to you. Say someone bumps into you, a friend sees you on the street. Hey, Cordy, what's this Maraki thing about? What would you say to them? I would tell them it's the way of the future. I had to shift even my mindset when I joined the team and it was a great shift. I finally was able to have that work-life balance that we all dream of as network engineers. So, that's what I would say to someone. They're able to gather so much intelligence from it. Yeah, it's really awesome. And this is CloudScale. Do it right, it's magic. More time on your hands to have more fun and do other things. Secure live coverage here in Orlando, Florida, Francisco, Live 2018. We'll be back with more. Stay with us. Day one is continuing of three days of wall-to-wall live coverage. We'll be right back. Stay with us. Thanks for watching.


Hello and welcome. This is going to be a quick little video. I hope to go over this sort of thing more in depth in the future, but this is a quick demonstration and explanation. So here we have three little boxes, but just consider these as different parts of a page that you want on different tabs. And these buttons will control what tabs are shown at a time. Right now they don't do anything. I can click on each one of these. Nothing happens and you can see all three. So what we want to do is we want to load the page, show only one of these at a time, one of these sections, and then have those buttons flip through those sections depending on which one you click. So real quick, this is the code for this. It's very simple. I threw it together real quick. I am going to be using Bootstrap and jQuery just to make things, Bootstrap to make things look nice and jQuery because that's what I'm used to working with. But of course everything done in jQuery can be done in plain JavaScript if that's what you prefer. It's just not how I'm going to be doing it. So if you look real quick here, here are our sections. I give them each an individual ID of either Sec 1, Sec 2, or Sec 3. Of course you can call them whatever you would like. And then each one has a class. The container class is just part of Bootstrap, but I also gave them a class of Section. So what we can do now, if we go back to our web browser here and open up our console here, I can say in here, dollar sign, parentheses, quotation marks, dot means class. And I can say anything with a class of section, of course you have to spell things properly, section, I can say dot hide. And that will hide all of them. Now again, they each have their own individual IDs, so I can give them the IDs. So again, dollar sign, side, parentheses, or yeah, parentheses and quotation marks here, pound, dollar sign, hashtag, whatever you want to call it means ID. And I'll say like Section 1, I can say dot show. And it will show Section 1. If I say show Section 2, it will show Section 2. And again, hiding anything with a class will hide all of them. So what we can do is we can say hide them all. And then real quick after that, we can say Section 1 dot show. So what's going to happen is it's going to hide all of them real quick and then show whichever one I tell it to. But it's going to happen so quick you're not going to see that. So there we go, we're showing Section 1. Now I can say Section 2. So it's going to hide them all, whatever's visible, and then show Section 2. And so all we have to do now is program our buttons up here to do exactly that. Now we don't want to write a function for each one of the buttons. As a general rule in programming, if you are going to type something, some code, you should never type it more than once. If you're going to use it more than once, then it should be in a function of some short sort that is called. So what we're going to do up here is for each one of these buttons, let's go ahead and give it an attribute. An attribute for these objects or things like href or class or id or name. Those are standard ones, but you can make any attribute you want. So I'm going to create an attribute here. And what I'm going to do is I'm just going to real quick say here, I'm going to say sec equals and for this one I'm going to say sec 1. And I should have put a space in there. But I'm going to call them section 1, section 2, and section 3, which will correspond with, this is section 1, it will correspond with the ID of this. Section 2, ID of this one, section 3, ID of this one. So that way we know when we press a button the function can look at that and correlate it to the tab that we want, or in this case the div tag that we want. So what I'm going to do in here once the document is loaded, we're going to say anytime, anyone, and again these are the ones that have class, I gave them a class of sec bnt for section button. So I can say sec bnt. So anytime one of those is clicked, we're going to run this function. And what are we going to do in here? As we said, we want to first thing we want to do is find everything with a class of section and hide it. So again, if we restart our page now, if I click any one of these, they're all going to disappear. So far so good. Now we want to get this attribute here of sec. So what we can say is we'll create a variable called var sec equals, and then we'll say inside dollar sign parentheses, no quotation marks, this dot for attribute. And in here we'll say sec. So it's saying look at this, which is the button that's being clicked. Look at its attribute of sec and set our variable in this function sec equal to that. We can check that by saying console log and sec with no quotation marks there, because it's a variable, not a string. Well, I guess it's a string variable. But so now when I click one of these, they shall disappear. But we'd also see down in our console here, which button is being clicked. And what section is correlating to we can get rid of our console log now because we've already checked it. And what I can do is just like before, we can say pound for the ID but then outside the quotations plus sec, which is going to be this variable right here, which is the sec attribute for that button. And again, I'm calling it sec short for section, you can call it whatever you want. I can say dot show. So now I save that I rerun this we see all our sections and I can see section one, section two, section three and I have these little boxes, but it can be a whole page worth of stuff. For example, I can come in here, and I'll just copy this twice or three times. How about that? So now we have section one is these three, section two, section three. So again, it could be tables, it could be pictures, it could be cells, it could be whatever you want. But the only thing we have now is that all the sections show up when we refresh the page. We don't necessarily want that was go ahead and close our developers console there. So what we're going to do is up here is we're gonna say when the document's ready, when the document loads, we will say hide all of them. And then we will show whichever one we want by default, which could be section one or it could be section two, whichever section we want. Let's say we want section two by default. So what's going to happen is when the page loads, once the page loads, it's going to hide all those sections. And those are buttons aren't in those sections. So you can have a header and a footer and some other stuff that's always on the page. But anything that has the class of section is being hidden. And then it's going to go okay, what has the ID of section two, which with an ID there should only be one object. We're going to show that. So we'll save that. Oops, I quit out of it. Let's go ahead and go back here and I'll refresh this page. It says is another section. So that's section two. So if I hit section one, there's section one, section three, section two. And again, it's whatever section you want to show at the beginning. I can make section three show if we want. So section three show it first. I go two, three. And that's a simple way to make little tabs to choose what's being displayed. And there's a way to put animations on these. So they slide in and out or maybe accordion style. But what we're doing is just real quick, they're there. And that's it. Again, so just a quick look at this. But I mean, this is all, you know, HTML down here. The only code that we're writing is, you know, these six lines, seven lines right here, saying to hide and show what we want when a button is clicked. So again, quick and easy way to do tabs without any special plugins or anything. Well, I mean, we're using jQuery and bootstrap. But you can do this with pure JavaScript, the same thing, just it's a little bit longer, you have to say document find object or element by ID and give it the ID. I just prefer using jQuery. And I hope you found this useful. Visit filmsbychrist.com. That's Chris Decay. There should be a link in the description. And as always, I hope that you have a great day.


This study identified several key areas where mentors can provide support to diverse trainees navigating the hidden curriculum of academia. These include providing guidance on how to effectively communicate with colleagues, understanding institutional policies and procedures, and developing strategies to manage bias. Additionally, institutions should create policies and programs that foster the success of trainees and faculty from underrepresented backgrounds. This article was authored by Felicity T. Enders, Elisabeth H. Gullimbeski, Minerva Aurelona, and others.


Hello everyone. Welcome to the session OCaml platform in 2022. We are very glad to have Sudha join us today. So without further delay, Sudha, over to you. So, welcome everyone. Thanks for joining my session on OCaml platform in 2022. Just to give you an introduction of the cycle. I'm a software engineer at Daredis. I joined the OCaml team two years ago at IIT Madras, and since then I've moved to Daredis to do the same task. So, in this session today, I hope to give you all a quick tour of the various components of the OCaml platform, which will hopefully enhance your developer experience of using OCaml. And before I begin, I would like to thank all the people who have been involved in such a remarkable work of making the OCaml platform in a way that's very pleasant to use. So, thanks to all the OCaml platform developers and maintenance for the way that's nice. So, just to give a very quick introduction about OCaml to people who might not be familiar with OCaml at all. OCaml is a functional programming language in its core. It is ML summary language, which started with standard ML, and OCaml is a spin-off of it with interactive and object-oriented features, which has been quite useful for a lot of work, to be honest. But in its core, it's still a functional programming language with a lot of purely functional features, and that are the most useful features in OCaml. So, it has a strong static typing. How is it useful? So, when we say strong static typing, it means the compiler is available, sorry, the compiler is aware of your type. So, what that means is the compiler will not allow you to compile unless your typing information is right. And as the saying goes in the FD community, if your program compiles, it works. So, OCaml has strong type, and it also doesn't mandate you to write the type yourself because it uses type instruments to insert whatever type your functions have, which gives you very strong typing features to make your experience of writing OCaml programs easier. It also has algebraic data types, which make representing any data subject very easy. You will see some examples in the subsequent slides of how ADTs are represented in OCaml. It also has pattern matching, quite similar to Haslip's pattern matching, except for the syntax. And pattern matching makes sure that your code is exhaustive. It means that there won't be any oversights in missing out some of the items in what the function is going to cover. So, ADTs and pattern matching are one of the very main features of OCaml in my opinion. And contrary to popular perception that FD languages are not featured for the systems programming, OCaml has very nice features to allow systems programming. It has very good unique findings, and it also helps that OCaml has DC, which is badly tested and it is very performance. And at the same time, it supports the C-SFI, which has a very strong C-SFI, which makes writing C bindings very easy. So, OCaml has been used for a lot of systems programming. Again, contrary to the popular perception that FD languages are not used for systems programming.  So, OCaml uses minor and major collectors. The minor collector is quite fast. So, there isn't much DC overhead from this. We are allocating a lot. So, the DC helps us not having to do the memory management by the programming. And OCaml is going to have multi-core and effect handlers basement. We are really looking forward to the release of OCaml 5, which will bring in multi-core, which has been one of the most anticipated features in OCaml. The work is done, and we can expect the release sometime possibly in the next quarter, maybe during the end of June or so. I don't take my words for it, but that is the current timeline. And I currently need a team that is helping the community move with OCaml 5. And we hope to have more people start with me at OCaml once we release OCaml 5. And this task is making the developer experience more pleasant to people when they start using OCaml. And as much for people who have been using OCaml for a while now, and they would like to try out the new features that have been added to the OCaml platform. So, to get OCaml, it's quite straightforward. All we need is the OCam package manager. And to install OCam package manager, you only need this one line. This batch script is going to install OCaml for you on Linux and Mac. So, procedure is slightly different in Windows. If you are interested in using OCaml on Windows, I would recommend using WSN. It is also possible to use it naturally on Windows, but the procedure is slightly different. And due to the time constraints, I am not able to cover the Windows part. But I would definitely encourage you to look at the nature of Windows support if you are interested in using OCaml on Windows. So, coming back to OCaml, one line is going to install the right version of OCaml first on whatever system they are using on Linux or Mac. And right after we install this, we just have to run OCaml in it which is going to initialize the configuration for us. So, after you init the OCaml, it's going to install the default switch. Default switch is usually the latest release compiler, which is 4.13 right now. But OCaml also allows us to actually install more than one compiler version at the same time which makes it easier to test different versions of packages. So, for example, some packages should support only certain versions of the compiler and will not support newer versions or older versions. So, when you have multiple compilers at the same time, it makes it easier for us to actually use it on different test cases. So, just to show how this works, I can show the different switches that I have right now. These are all the switches I have right now. I have so many, I know. Usually, we don't need these any switches. I had been hacking on the compiler because I have these many switches. So, yes, it's just running this one-line fast-crypto into the OCaml and we are on to a start.  I mean, don't worry if a lot of it is not making sense right now. Hopefully, we'll connect the dots as we go along. So, to talk about the different stages of the OCaml platform, as you can see, there are many different components that work together and the community has been working very hard on all of these packages. The first stage is integrating some of the packages. These are quite new packages, these are quite new packages, but they are very useful. So, folks are working very hard on developing them and making them stable. The first two items in the incubate stage are the OROC and MDX. Both of these are the documentation tools. OROC allows us to write documentation within the code for the files itself, so that you don't have to write documentation separately. MDX allows us to write for the within mark zone files and also execute. We'll be seeing them in detail later. I'm just giving a quick introduction of all this right now. LSD server is the language server protocol. This can be used with your favorite executor to make it work like an IDE. There are many interesting features in the LSD server. I'll be showing some of them in the subsequent space. OCaml formats automatically formats our OCaml code to comply to the accepted standard. It's very useful, especially when there are multiple people working on the same code base to maintain uniformity in the code base. Dune release allows us to release libraries. It's supposed to work with Dune, the package manager, and the libraries that are hosted on github. Opam is the package manager that we talked about earlier. Dune is the build system that's widely used by OCaml developers. Ptx is a useful set of libraries to write Ptx extensions for your OCaml platforms. Utop is Reptile, which has more features than the repels that ship to the compiler. Opam Publish allows us to publish the new versions of libraries on Opam repository. Opam repository is the central source of all the Opam packages. That's where we install the released Opam packages from. Merlin is supposed to work with the LSD server on providing nice, tidy features like auto-complete the plain sites on the file and so on. We'll be seeing it in the next part of the presentation. The tools that fall under sustain have been in the community for a while and I would say they are legacy tools. They're not actively developed anymore and there are no new features being added to the tools under sustain. We do have many packages and libraries that use these tools. They are in sustain mode for a while until they're deprecated. They would still work with the current features but they wouldn't add any new features. OCP indent is an indentation tool. Now that we have OCP formats, we don't need a separate tool for the indentation. It's in sustain mode. OCP builds and OCP signs are the predate doon. The doon has essentially overrides the OCP build and OCP sign. Projects that use OCP build and OCP sign would still work but they are impregnated to doon to make it use more latest features of OCP. These libraries that fall under deprecates are deprecated and they are in the path of being removed from the existing projects that use them. OYAS is in Germany before the libraries that fall under deprecates. OYAS is a bridge manager and again it's a doon overrides OYAS. So it's not needed anymore. Alright, so now that we had a very quick overview of what's the different components of the OCP platform are, I'll move on to giving you all a very quick demo on how these different things work. We will not cover all of this but we will be covering the most useful part used in the day-to-day work of OCP development. Alright, the first thing is the repel. So OCaml top level is the repel that shifts the OCaml compiler. So when you just run OCaml on your terminal, it's going to start the repel for you. It also mentions current version that you are on. If you see that you are on the wrong version, all you have to do is you have to switch to the right compiler version that you want to select. And you have to evaluate the OCaml environment to make sure that you are using the right OCaml version. That's going to give us the repel. And all the instructions to the repel are ended with two semicolons to say that's done with what I want to run. This is a nice way to play around with, especially when you're starting to learn OCaml and also when you're developing something new. It makes it the same with what you're writing with. So this is the OCaml top level that shifts the compiler. We also have new top like I mentioned earlier. OCaml is built on top of the OCaml compiler top level. But it has more added features that make it easier for us to use the repel. For instance, OCaml supports code completion with the tabs. So if you see the code that's running right now, it's using the autocomplete on the list and it's all that's going there. It also displays the type of the function. If you are not sure what the type of function is, just run it on utop. And utop is going to display the type of the function for you, which makes the using the API quite lucrative. And it also has the syntax highlighting and maybe getting yourself quite nice on utop when you compare it with the OCaml top level. So it's recommended for people to use utop if they want to use repel. For example, if they want to execute the previous block, we just prep up like we do on terminal. Unfortunately, that doesn't work on the OCaml top level. The utop has worked around and it's quite nice. I would highly recommend playing with utop to secure using OCaml for the first time. Yeah, and Dune is the build manager. So Dune was initially developed at the GnStreet internally and later we had released it. They had made it open first and now Dune is the default build manager that's used in new OCaml projects. Dune makes working with OCaml projects quite nice. So you can initialize the project, the new project with Dune and initializing the project as you can see in the terminal. Initializing has two modes, project mode and library mode. So once you initialize it with the project mode that couldn't have any executables, when you initialize it with the library mode, it will create your tests and all of the other libraries, the basic ones for you. So that gives you the skeleton of how your project is going to look like and we can go from there. Dune, yeah, of course Dune builds all the libraries and executables. Dune also allows us to run tests to Dune, run test command. And we can also execute the executables to Dune. So this is the complete package in how you can build your OCaml project. Dune also has more features. Dune is in its construction composites. What do we mean by composites here? Let's say we have any different projects and they use Dune. It's quite simple to combine all of them. Let's say we put all of them into one directory and have a top-level Dune project there. Then Dune will certainly be able to recognize all of the projects and compile and run all of them. So that now becomes a single Dune project. So combining and splitting libraries is quite simple with Dune if all of them are in use Dune. Dune also supports cross compilation. So Dune supports having separate targets for Linux, Mac and Windows. Usually it's not mandatory to configure them unless you are using some OS-specific features that are present in the project. So Dune also supports OCaml. Of course it supports OCaml and it makes the workflow of merging with OCaml quite easy. Dune supports FFI also, especially the CSFI is quite widely used in the OCaml community. Having feedback makes it easier to communicate with other projects and some of the low-level stuff. So Dune has sufficient for the specifying FFI within the entire system. There's no need to compile them separately. Dune supports pdx as well. pdx, for instance, are quite useful for many of the OCaml projects. And Dune does have provisions to specify what pdx we are using in the project. And Dune also supports JavaScript, which is a case of OCaml. There's a OCaml that's used to write web applications with OCaml. So yeah, Dune as a Dune is quite versatile. So that's just about the Dune. Now going on to the IDE experience. So there's usually this notion of OCaml lessons have an IDE. So OCaml LSD server comes quite close to it. It's possible to transform your favorite text editor to an IDE. So the IDE can be made with Emacs, Wim and Vfood that I know of. I would personally be using Vfood because that's what I used in my day-to-day work. But it's possible with Emacs and Wim as well. For Emacs, you need the LSD mode of Emacs and OCaml LSD server. For Wim, you would need Wim LSD and OCaml LSD server. And for Vfood, you would need the Vfood OCaml. So this button that you see here is going to let us generate the ML file from the ML file. And we don't have to do it manually. Which is very nice. ML files are usually used to write API documentation. So all you need to do is just write the documentation and not go over this part again. Which is quite useful in my experience. So the next one is hovering for types. So when you see this program and when you just hover over some function or some part of a function or some variable, it's going to show us the type. Which is very useful especially in largest functions to look at parts and see what the sub part of the function is returning for us. And this has also been very useful as and when you write new OCaml programs or even when you are looking at old code business. So this is another part of the IDE experience. The other part is autocomplete. So Merlin has this nice autocomplete feature. You can see in this code the autocomplete feature is being displayed. It's quite nice. It's going to show us the modules and the functions of the modules. And it also displays the types of the functions for us. So it makes writing new functions quite intuitive because you see the type here itself instead of us having to look at the API docs going back and forth between the API docs and between the source files. So this is the other part of the IDE experience. So the next part is formatting code. So like I mentioned earlier, this OCaml format makes the formatting uniform with an agreed upon standard. So as you see here, this is the old formatting that I had used while writing the code without having any standards in mind, coding standards in mind. And once you run it with OCaml format, it's going to give us this nice reordering of the code. This is a quite nice to look at. And it also makes the entire code base uniform for us. So let's say we have multiple people working on a single package or a single code base using OCaml format is going to make all of it uniform. So it's quite useful for both large projects and for small projects. So all we need to do for running OCaml format is it's supported by Doon. So Doon build, just Doon build is going to build the project for us. Doon build at FMP is going to invoke OCaml format. And that's the formatted file is going to be present in the Doons build folder. If you want to use that in your code, we need to run this Doon promote, which is going to copy the formatted code from the Doons folder to our original source file. So it's quite simple. And I would recommend running this OCaml format every time we write something so that it just stays the entire code base stays uniform in the styling. Yes. And okay, coming to the part about documentation. We have two tools that are quite actively being developed right now. So the first one is MDX. MDX, yeah, as you can see from the name, it supports markdown. And it also supports OCaml documentation tool, ODOX documentation format. So this MDX is MDX allows us to write code within markdown file. So let's say we have a readme file, which is going to demonstrate some features and we have some code there. MDX allows us to actually run the code that's present in the markdown files. So this actually helps us in keeping the documentation up to date. So we don't have any stale parts in the documentation. It's very annoying when you have documentation and have code snippets in documentation, but when you actually try to run them, they don't work. So MDX helps us in eliminating that. So MDX was born out of this while writing this book, Real World OCaml. I would highly recommend reading that book if you want to learn OCaml. So MDX was written during writing the book Real World OCaml and it was very useful for writing book. And it's also being used in many other projects right now. So these are just the config things that we need to specify in these files. And Doon Run Test would by default run all the markdown files for any code snippets. And the next one is ODoc. So ODoc is the documentation tool and it generates HTML pages and man pages and Latin documents from the documentation that's embedded in the source itself. So when we have comments of this form, so OCaml comments are usually, they don't need two asterisks here. Just one asterisk is sufficient for the comment. But for ODoc comments, we need this specific format for it to be passed as documentation comment. So it just takes out whatever comments that are present in the source files and it displays it as a HTML file. So this is ODoc generated documentation of one of the modules. So it is quite nice to actually have the documentation embedded in the code base itself rather than having to write documentation separately. So ODoc has a separate format called MLD which we can use for writing long form documentation. So this is just the API docs that you see here. The MLD files allow us to write tutorials and some of the long form documentations of that sort. And they are also clubbed together with the API docs. So you have all the documentation together at one place and you don't have to redirect people to different places for looking at the documentation. ODoc is being actively developed and new features are being added. So I'm quite excited to see how that evolves. So Dune Release is a tool to actually just add the release of your new libraries or new versions of your existing libraries. So all we need to do is create a tag. Dune Release tag is going to parse the tag from the changes file for us and Dune Release would create the release which can then be uploaded to GitHub. Yes, and the release packages should be published in the OPAM repository. So OPAM repository is the single source of truth for OPAM packages. So all the released OPAM packages are present in the OPAM repository. So it's the central source of all OPAM libraries. So this is the default OPAM repository and any and every release is going to go there. OPAM repository also allows us to have custom OPAM repositories. So if you don't want your library to be released in the OPAM repository and you just want to test it out, we can create our own OPAM repository which is going to host the packages for us and set that as one of the sources in OPAM and we can then install packages from the custom repository. So it will not be exposed to people who don't have access to the custom repository. So to release libraries to OPAM repository, we have this tool called OPAM Publish which publishes packages for us. So after all the tagging and release on GitHub is done all we need to do is call this OPAM publish within the package directory and it will take us through some items like it will ask you to enter your GitHub token and it will show us the patch right before it's submitted to OPAM publish. So this is one of the sample PR that was generated with OPAM publish. You can see that being mentioned here and to release the library we need to add the dot OPAM file that's present in the library to the PR and it's going to create a patch for us and once that patch gets merged the library is released. So it's quite simple to create a new package, new versions of packages and even release new libraries. Yes, so before I finish we are hiring for many positions at Canada's. So if you are interested in working with the camera Lord just want to check out what it is. Feel free to ping me. Yeah, and that is all about the presentation. I would be happy to answer any questions if there are any. Thanks to that. You really maintained your calm during the technical over there. So really appreciate your composer in that one. I am sorry about the glitch. No worries at all. We handle it like live demos and recovering this live it's great. So glad we were able to do that. So there is one question that let's get to first. Okay. So Rick is asking what is the difference between do release and publish. Okay, that's a good question. So do release is just going to pack the package for us and put it on GitHub. Under the tag the version releases open publish actually adds it to the open repository and that is when people will be able to install the package. So the first stage is to release and the next stage is open publish. If it makes sense. But Rick, I hope that makes sense.


In this episode, you're going to learn how to design services for contacts and cultures that are quite different from your current environment and then how to successfully scale these services. Here's the guest for this episode. Let the show begin. Hi, this is Priam. You're listening to The Service Design Show and this is episode 113. Hi, I'm Mark and welcome to The Service Design Show. This show is all about empowering you with the most effective skills and strategies so you can design services that win the hearts of people and business. The guest in this episode is an ethnographer who has done countless projects all across the world focused on helping to improve healthcare situations across the globe. Her name is Priam Shadda. If you've listened to the episode two weeks ago where we already explored what it takes to design successful services in low tech and low resource environments, you'll know that simplicity is key. In this episode, we're going to dig even deeper into that topic and we're going to focus on health and healthcare related challenges. You'll learn about why it's crucial to take stakeholders along and how to design in a context where you literally don't speak the language. Again, just like two weeks ago, it might sound quite distant from your current reality, but I really invite you to listen for the patterns and the bigger picture in Priam's story and think about how these examples translate to your own situation. If you're new to this channel, welcome and I'd love to have you to subscribe because we bring a new video that helps to level up your service design skills at least once a week. Don't forget to subscribe button and the bell icon to be notified when new episodes come out. So now it's time to jump into the conversation with Priam and the cheerful background noise that you'll hear is the livelihood of a day in India. Enjoy. Welcome to the show Priam. Hi Mark, thanks. Happy to have you here. We're going to continue on a theme from the last episode, but let's not spoil too much. For the people who don't know you, could you give like a brief introduction? Okay, sure. I'll try. Well, I'm Priam, I am Indian, but I live in Helsinki at the moment. Why Helsinki is a longer answer and maybe we can get into that a little bit later, but I am a trained ethnographer by sort of history and experience, but I currently work as design research lead with Scope Impact, which is a design company in the space of social impact. Okay. Yeah. And that's the topic we'll dive into in a bit. But before we do that, we're going to do the legendary 60 second rapid fire question round. Just answer as quickly as you can. Are you ready? I think so. Okay. Let's do it. Question number one is what's always in your fridge? Yogurt. Yogurt. Okay. Which book are you reading at the moment? Oh, I'm actually reading Jane Eyre. It's from 1857. It's like one of these classics that I had never read and I found it on my childhood bookshelf. So I'm doing it. Awesome. What superpower would you like to have? Oh, I think teleporting. That would be convenient in these days. What did you want to become when you were a kid? I think for the most part an architect. And a final question and in this case, I'm really interested in your answer. What is the first time you learned about service design? I think it was about a couple of years ago at my first, well, technically design sort of environment, job in a design environment. And I guess intuitively I knew of it, but it was I think the first time I saw it. I saw like an article written about it and I saw people speak about it and that sort of piqued my interest. Yeah, because you said you're an anthropologist or an ethnography background, right? And that's not something that's a very useful skill and background to have in a service design context, but it's not per se, not every ethnographic. I'm going to stumble upon that word a lot in this episode. It's not a common thing to get into service design. So yeah. Yeah, no, absolutely. It was sort of certainly not like obvious to most people at first. But I think with the more you talk about it, the more they see applications for it. I think service design uses a lot of principles for anthropology and ethnography. Absolutely. Yeah. Yeah. It's it's it's one of those things where I think where these two fields overlap is where really interesting things happen. So for the topic of our conversation today, like I already mentioned, we're going to continue and build upon the previous episode with Gonzalo and Firaq, where we started talking about designing sustainable solutions in low resource, low tech environments. And with you, I want to dive deeper into a specific topic around that. And that's health, right? Because that's a topic that's dear to your heart. Can you tell a little bit about that? Sure. I guess I did sort of allude to it a bit when I spoke about what I do currently, but I work in the space of health. And what we do at Scope is we try and emerge with creative solutions to really complex challenges in the space of global health and development. So just to name a few sort of health challenges that I've personally worked on are, let's say, and natal care in which also means like care for pregnant women. I've personally worked on adolescents, sexual health. And in general, I think my focus has been a lot on sexual and reproductive health and well-being. And I think it's just to sort of add to that. Currently, with the pandemic, we've had to pivot what the impact of that has been on just even sexual reproductive health in specific, but also health in general. You know, I think people's ideas are changing. So what is the question these days is quite obvious. But I would say what is at stake? Like, why is this a topic that's dear to your heart? And why are you so passionate about this? A few reasons. I mean, obviously, starting out, I think most people we're all driven by something that helps make an improvement in our lives or in the lives of others. And in this case, I think I found a sweet spot where it teaches me a lot. And I see that in small ways, we're at least trying to make things a little bit different or improve things even by little in the areas around us. The other thing, obviously, is that, you know, with the pandemic and I hate to bring the pandemic into this conversation, but we do. We can't ignore it. I think more and more are starting to think a lot more about global health and health systems and what does it mean for one country to have well functioning health systems and what does it mean for another to not? And how do we address that? How do we solve for it? And those are the kinds of things we've thought a lot about in the last three years. And I mean, of course, the company has existed even before I worked here. And, you know, there are lots of people in the world who think about this more and more. And I do think design has a really strong role to play in that. What's interesting about these topics is we'll be talking about some examples that might feel quite distant to, let's say, let's generalize to say, the Western world. But I think the things you learned through working, maybe quite remote areas, a lot of the basic principles and strategies that are behind those solutions could also be very well translated into the Western health care system. So let's dive into that. I'm really interested in, can you give an example of a project that you worked on and what were some of the challenges that you encountered? What were some of the things that you found to be surprisingly effective? Sure. I mean, there are many, but maybe I'll go with a single thread here in terms of this project that's pretty close to my heart that we worked on in rural Tanzania. It's a part of a larger project which was actually cutting across several countries. But in the case of Tanzania, we were interested in finding creative solutions that improve the sexual health and well-being of adolescent girls in specific. And how that started out was that, you know, that's a pretty broad topic because you can improve the quality of life or, you know, care and well-being of adolescents in a million with different ways. So right from the beginning, we had to work really hard to even frame the problem really specifically that what is it that we're trying to improve here? Yeah, so I'm curious, like if we go back one step, where did this question come from? From us, because I think our donor was kind enough to sort of give us a really sort of large and a great brief as that, which allowed for a lot of room for creative interpretation and allowed for a lot of creative sort of processual sort of thinking and room to play with. So we started to think that, hey, as sort of the interdisciplinary team that we are, everyone's sort of shared agenda was to really think that we can't solve for everything. So let's find the one thing that we are sort of heading towards to solve. Bearing in mind the entire time that no problem is often just one, you know, it's connected to many sort of different pieces and it's result of many complex sort of interrelated things, but still, you know, just sort of funneling down to that one thing that we'd like to solve for is, you know, as we all do in part as part of the design process. And in this case, we did that by like reviewing a lot of existing material on teenage and adolescent girls in rural Tanzania and speaking with a lot of local experts and partnering really closely with local partner organizations and the government in really trying to understand, OK, what is it that's currently happening and what is it that needs, you know, some sort of an intervention or which what is the indicator that needs to move a little more than it currently is. And yeah, the question I have here is, and maybe that's applicable to all the examples you're going to give, but you're an organization based in Helsinki and then you're going to work on a project in Tanzania. What's the dynamic there? I can, how do people respond? How do you get buy-in from the local community? Yeah, that's a really tough one, and which is where the owners of building that and maintaining that comes on us, because I think at least in my previous sort of experience working with the creative teams, you know, this is something that like the partner managers do, or, you know, where they build partnerships or, you know, at a client lead level, someone else does. But in our case, we had to really make local partners feel like we were in it and we had brought ourselves up to speed on the complexities that are at play. We were culturally sensitive. We were culturally aware, we were socially sound. What does that mean? So how do you do that? Yeah, so that was always a bit tricky. At times it meant reading up a lot on what that specific behavior means to the local context. So for example, if I'm thinking about again, adolescent girls and let's say, you know, the high incidence of teenage pregnancy, we would try and dive into it from a very sort of local literature point of view and see what does that tell us about it. But it also means really finding the right partners that also educate you as you go along and keeping your assumptions to a very, very, very minimum, where we assume nothing, our tools assume nothing, our hypotheses assume nothing. And then we take that to local experts and local partners and expect the same sort of objectivity from them. So I think to maintain that and to sort of keep that as a design principle almost in the way we work with local organizations and local communities has been really important to our work because I think the ethical boundaries can blur pretty quickly. And quite often you have to remind yourself of like, who are we and why are we here and how much do we know, right? So that has always been a bit challenging, I'll be honest. But personally, this is also where I think I mentioned this in our previous conversation that this is where we're not the only designers in the project. This is what I keep saying. Quite often the girls that we're designing for, we're designing with them and the people that the community members that we meet, they're designing for themselves and we're just facilitating the process. So again, to recognize that, yes, you need to know a lot of the cultural nuances and sensitivities, but you don't need to be a master because there are already people who live it and are masters at it. You just need to know when it's your turn to sort of step in and move it along the process, I mean. Yeah. And if I look at the design challenges that I worked upon, you know, that's a completely different context, but the principles are the same.  So what were some of the things in this project that really stood out for you in terms of things that didn't work, things that did work? Right. So once we did sort of narrow in on wanting to address, you know, the incidence of teenage pregnancies, we also realized that the narratives that we were hearing about adolescent girls were pretty unidimensional, you know, most people in our sort of preliminary fieldwork were telling us so adolescent girls are rude, they are badly behaved, they have no focus, they have no goals for their future, but we wanted to challenge that and unpack that a little because surely there's more to it. So to overcome that like sort of one narrative that we were hearing, we designed tools to facilitate a broader conversation. So and bearing in mind again, that discussing a lot of the things around teenage pregnancies or sexual sort of behavior, or just like, you know, sort of actitudinal things are difficult, they're sensitive topics and they're difficult to discuss. We needed to keep that in mind when designing these tools. So one tool that we designed, for example, was just, I mean, you can take a, you know, persona building sort of as an exercise, right? But we layered that with local objects and artifacts.  And then we wanted them to pin it onto dresses that, well, that girls wear. So it became sort of like a creative building exercise interspersed with a lot of conversation around that choice of those objects and what that means to the girls life, who this girl is, why is she wearing that? What is she using? So it just led to a sort of a more free conversation around who these girls are and why they fill their lives with the people and the objects and the experiences that they do. And because of that, we managed to get a lot of insight into many sort of the different different different kinds of adolescent girls that exist in those communities, which they do as everywhere else, to be honest. But also that when designing for adolescent girls, that's the reality, you know, that's what we're working with and not just one of them or one kind of them. Yeah. And this sounds really like creating the tools to facilitate the process and also going beyond just verbal ways of researching, verbal ways of creating and using tangible things. You can point that and you can have a conversation around, right? That makes it, yeah, much more tangible. How did the people on this project respond to this approach where they used to a more design approach or was this the first time they get in touch with it? What were some of the responses you got? Well, internally, we piloted it a lot based on the people that had traveled to the contexts that we were working with. But we also then leaned on our local partners to really sort of comment on on the sort of the course of the discussion on whether or not these were feasible to carry out. But then again, I want to remind or sort of bring back into the conversation maybe what I said earlier about how it's also the course that the conversation takes. It's also what people share back with us that ends up shaping it. You know, it's as much their design process as it is ours. So what ended up happening was that it wasn't anticipated, but older women responded to these dresses a lot better than younger girls did. Because I think it gave them a chance to really creatively express what they weren't able to express as young girls and creatively express their observations of the girls from around them in a way that didn't make them feel the need to be the judgmental aunties that they were sometimes being or be the doting mothers that they were sometimes being or being the role model grandmas that they were being, you know, it just allowed them to be women to the girls around them. And I think that to me was really powerful. If you look back on this project, what's the thing that you're most proud of? A few things. I think first like how our tools were really able to get us to engage the right way with our sort of community members and our participants and always putting us at unequal footing where of course I'd go in with a discussion guide in hand, but the discussions is very much co-shaped as I said. The second thing is also like one of our other tools that we use for research was again to discuss some even tougher topics to discuss like events that happen in girls' lives that tend to derail them. And these events can be pretty sensitive. You know, they can be the loss of a parent, they can be loss of an income, they can be getting sexually assaulted, they can, you know, a wide range of, you know, sort of life stuff and other stuff. But where we were able to take learning from both of these is that we were able to represent that in the solutions we created. And interestingly enough, the solutions were designed keeping the needs of the girls in mind, but they were actually designed for the local government to use and to roll out as part of like their complex sort of system of governmental sort of players and interventions. And really sort of we, for the second half of the project, basically we work closely with local government members to really work, see how what it is that would aid them in addressing these needs that we were able to find in the first part of the project. Yeah, right. Because that's eventually how we started this conversation. It's a maybe a low tech, low research environment, sensitive topics, and then how do you design solutions in a way that actually get embraced by the people who you're designing for. And what you're saying here is working with the people in government, for instance, who need to provide the environment, who need to create the context and environment that enables these solutions. How was that? How was it? Because working with the local communities and let's say the end users and the context of the end user, that's one thing. But having a stakeholder like a government entity, getting them to understand this way of working and the solution that you're putting forward is a completely different thing, right? How did that work? Absolutely. I couldn't agree more. What I would say is that they actually enjoyed it. I think it's very rare that they come into contact with real sort of like findings which are not in the form of, you know, sort of let's say quantitative data or in the form of reports. So what they were getting from us were narratives. What they were getting from us were, you know, sort of like softer needs. But then again, what we prepped also in order to get their attention was we mapped what it is that they're currently doing and how could the things that we're finding fit into that. So it needed a bit of sort of like laying it out for them. And I will say there was a lot of relationship building that went into it. There were times when at the end of a long field trip to Tanzania, we would go to meet members of the government to give them an update, you know, as tiring because they were often in a different part of the country because I think when you're working with extremely busy sort of establishments like the government and extremely complex and bureaucratic ones, you have to pay respect to that sort of need of communication and sort of expressing your involvement a certain way. And we worked hard at that. And is that maybe a key part of the design process that a lot of people overlook? Like the relationship building maybe doesn't feel like part of the design process. But if your goal is to create impact, it's actually is. It absolutely I couldn't agree with you more. I'm laughing because we had so many discussions amongst like the designers on this project, including me, where we said, but why do I need to go to meet this head of government? You know, surely someone else can do that. I'd much rather continue to be on field, co-designing, testing. But you know, when we heard it directly from the horse's mouth, so to speak, it changed things for us. When we understood the bureaucratic sort of expectations or resource limitations, we think we absorb that information differently because we were working closest with the designs. Yeah. Yeah. And that's the that's a theme that has been coming up on the show quite often where having empathy for in this case, it's not per se the client, but let's say if the government is the one who is going to implement this, they could be declined. Having empathy for them as well, seeing them as people and with their needs, with their pain points, with their things that keep them awake really enables us to that. That's the thing we often overlook when we design solutions. We are so focused on the end user, while the people who need to enable these solutions, they also need to fit into this context. Yeah. And that's what I hear you saying at least. Absolutely. And I would just sort of rephrase that to say that for us, the government folks ended up becoming users as well, because the solutions that we ended up designing were actually like a three part sort of modular toolkit for for local government officials, where the girls were not actually the focus of it. The focus was very much around what it is that they need to run all five of those solutions, which sort of part of the constellation of their world it sits within. And what do they need to keep it sustainable? Because the needs from a girl's point of view, no one argued with that because I think these are long standing challenges, but we realized pretty quickly that the convincing was actually needed or rather the designing was also needed to make it happen. Do you have a different example where maybe where things were even more challenging? Maybe I don't know if challenging is the right word, but I did work on a project where we basically designed like a group pregnancy counseling experience. It's called group antenatal care sessions for three different cultures and countries actually. I wasn't a part of the first one. The first one was in Uganda even before I joined this company, but when I joined our client in which case our donor was interested in taking it to Kenya and then eventually we took it to Guatemala. Now the challenge slash most interesting piece of that work for me was the fact that these cultures are extremely different. When you say something like this, like taking it to Kenya, taking it to Guatemala, I'm like, how? That feels like completely different worlds, right?  But here's when you know, here's when the processor that spoke of earlier, you know, bringing yourself up to speed to a certain extent matter. But then again, I think we adopted a more agile approach in this project where we went in with what we had created in the other countries, even just to sort of prototype and co-design further with people there directly pretty early on, like we spent some time doing design research and understanding some basic sort of differences and made those quick adjustments to our service journey. We made those adjustments to our tools. Like for instance, in Kenya, we used a calendar with, you know, how pregnancy apps use fruits to tell a woman or like the parents about like how the baby is growing. We used sort of metaphors like that to refer to how the fetus is growing in Kenya. But in Guatemala, even while doing our desk research, we realized that that's probably not going to work. We should probably just stick with more realistic sort of illustrations of how a fetus grows. And that worked out perfectly well. But to me, as like a third person who belongs to neither of those cultures, I was just like, how do we make that decision? But again, we don't. The people in those communities do. Yeah, yeah. And the key is to involve them from early on. Maybe that's, I'm curious, sometimes the challenge in the design process is when you're too similar to the end user, you eventually end up imposing your own ideas about what the needs, desires are. Like I think that's one of the challenges we're making personas or user profiles. If I do that in the Netherlands, I already have so many assumptions and biases when the end user is so different from yourself than like the humbleness comes maybe more naturally. And that's a question. Yes, I work a lot in India as well. And I always have. So, but maybe I'll answer that a little differently using actually two things that anthropology taught me. One is you know, sort of this idea of leaning on a balance between an emic and an etic perspective. So one is like the emic is when it comes from within the culture that you're designing for or well in anthropology or other social sciences you're studying. And etic is when you look at it from the outside in. And I think that it's really important in the work we do whether it's in your own culture or community or your country or in the work that I currently do to have a balance between the both because even if you're incapable of doing the emic part of it, get someone else to sort of bring you up to speed. But I think for a cross cultural or comparative point of view, looking at it from the outside is extremely important too. And there are ways to sort of like build that that sort of that objectivity that is the other thing that the social sciences teach you a lot about which is about how are you like objective to the thing that you're studying without letting your subjectivity affect how you're viewing it. Maybe a little bit more background into social science would be a good thing for a lot of service designers including myself. Getting back to Guatemala what happened there? Right. So as I said, like you know some people would view that as a challenge for me that was the most interesting part of the project where we saw a few things that worked out really well in Kenya. For example, we observed in the early sort of simulations of these group sessions that we did that it was really natural for the nurses and the mothers to hold hands and start to pray before they started the session. So we were working with indigenous Mayan communities in Guatemala and Highlands and we weren't entirely sure if praying together or singing together is even a part of their culture but we tried to ask a few people about it but pretty much on like less than half into the first day of field work everyone was just like you want us to sing and we were like we don't want you to do anything so you know we can skip that completely and more than anything for me personally speaking the language was a huge barrier because I don't speak any Spanish and I certainly don't speak the two sort of local languages that were being sort of spoken there which Keeche and Ma I think and our local partners that's when they sort of stepped in and this is when you know I think you were asking me earlier on what uptake of HCD or like you know sort of ease with the processes and why that matters and how people responded I think one thing we want to make sure right from the get go is that our local partners are on board with the things we are suggesting yeah yeah and that's so key because we are not the experts in in usually in the matter that we're talking about in this case you had done the project in two different areas so that you might become a subject expert at some point but usually we're stepping in into an area where we are known we're known with the design process and then we have to sort of extract the knowledge from the local communities and these local partners whether they are an NGO in Guatemala or maybe the finance or HR department in your organization working closely with those people making them not only as a research subject but a true partner I guess that's the key to success maybe what have you found is the thing that helps to make these other organizations feel like a partner in the project yeah I was just thinking that as you were speaking I think what's really helped is to have them be a part of the transformation process so for example if you know someone from the local partner organizations that's something particularly interesting one way of doing it is that sort of like holding on to it going back to our drawing boards and creating something with that but what we have tried to do more and more of is to think of the solution in that moment with them and I think for them to see the transformation of that information into an idea seed and then into a concept if at all and then like being combined with something bigger greater better it's been really really enriching both for us and I think for some of our partners as well and then of course I think like sometimes we've been challenged you know by our partners because they don't see the value of going to field with half concepts for example because let's be sort of let's remember in this moment that the world of global health and international development has a lot of programs running you know they have a lot of interventions running in field these interventions and programs are highly tested they are highly like you know well piloted and then for our sort of design oriented processes appear a bit less robust in comparison but I think to really sort of again this is where partnership building comes in where you want to just get them to take the first few steps with you see the process move forward you know point out the small sort of slivers of ideas or that sort of silver linings that are sitting within like the conversations and then working it out together so I think taking them together is effortful but it's extremely important yeah it's effortful but it is the process like that's that's the work and so just like with what you said relationship building with the people who need to enable the solutions that is the work like we should embrace it and rather than feel that that it's a burden and I think it's been stated quite often but the design process is a is often very experiential process you have to be in it to feel the value as as abstract and as vague and as soft as that might sound but it doesn't help when you sort of take the results close the curtain and come back with an idea like it like you said that the transformation has to happen by going through the process so okay let's let's get back to Guatemala one more time where what I'm hearing you basically describe is how to scale solutions and that's of course a thing that we've been hearing a lot in service design like we have a solution a service that works here but how do we scale it onto more users more areas and we're talking about getting stuff from Kenya to Guatemala it's it's maybe more contrast but the principles are probably the same so again let's get back to Guatemala we're worried right so I think just in terms of if I were to compare both the service journeys you know we had to design for completely different sort of resource constraints we have to design for completely different social dynamics let's just say because the experience of a pregnant woman going for ant natal her ant natal care visit in Kenya is quite different from a local woman in the Guatemalan highlands going for hers just off the top of my head women in Kenya tend to or in the part of Kenya that people working in tend to come on their own but in the Guatemalan highlands they often came with not only their own kids if they have other children already but also with like you know sort of a plus one so it could be their partner it could be their sister-in-law it could be someone so just purely in terms of space making and place making it has serious implications you know so as like you know designers on field we were taking quick notes and we were reorganizing the space okay instead of seven people we have 13 or we have instead of 13 we have 30 so stuff like that would happen and then one of the other things that I found particularly sort of interesting was how you know if a society or a culture have certain sort of conflicts at the heart of it which in this case was that the healthcare workers the nurses were not viewed very well by the women that were coming to the facilities because they've all either had personal bad experiences in the past or they've heard of other women as having had really sort of disrespectful experiences with healthcare workers and that's a sort of a perception that the service journey had to deal with up front and center and I think anyone listening to this would agree that to design for to solve or to correct held perceptions is is an almost like impossible thing but what you can do is acknowledge it which is what we tried to do through certain small measures like just off the top of my head what I can remember is the nurses would normally wear their nurse outfits but what we requested they do is there's a certain fabric that indigenous Mayan women wear as like skirts and it's like a woven like it's a specific weave from that part of the world so we try to infuse that in the outfits that or like the apron we gave them like a service sort of tool of an apron where they could stuff some of the materials into and we made that apron out of the local material just to it's it's a small gesture but just to build some acceptability and some relatability I think and that's what we heard also in the previous episode that the solutions we seek it's not about how complex or how fancy they are it's about how impactful they are and if wearing a different apron does the job then wearing a different apron does the job and I think it's it's good to remind ourselves that sometimes the the best solutions are the most simple solutions the challenge often we face is that we have to deal with an outside world that perceive these solutions as too simple or too easy or might say well I could have come up with that in an afternoon like that's the that's the that's the bias we're fighting against but yeah absolutely and you know and as again designers and creatives and other people that are part of our team at scope we felt that way constantly where we want to be cutting edge you know where you want to try and see how artificial intelligence or something that's great and exciting and can do great things for you know all the causes is available to us but it doesn't it's it's not needed and the problem at hand can be solved by something that the community has come back to us with which is a lot more intuitive yeah which is a lot more acceptable yeah so yeah yeah that's a general thing that we're not going to solve quite uh quickly but it's the value of simplicity that's not valued uh what's that and yeah sorry and just and that's not to say that like you know a lot of uh now certainly especially with 2020 and you know the sort of the leapfrogging that technology and uptake of that has seen in in sort of all regions of the world uh we might have a different sort of solution in canvas next year when if and when we decide to engage with communities again because if phones are more available if you know internet has picked up a lot more than it currently is then I might be speaking a different tune or you know so in all cases it's coming up with solutions that fit the environment and that's the key it's not about coming up with solutions that use a fanciest technology but really fit the environment are and have a realistic chance of being sustainable making an impact what would you say is the biggest lesson you took away from this project um my biggest lesson was to avoid any assumptions uh to to prototype and simulate experiences as early as you can in the process and expose the people that you're co-designing with to that experience quite early on in the process so I don't know if I mentioned this but we never did traditional design research for this project we only started with simulations of these group sessions where we actually trained nurses and while training the nurses the questions that came up that helped us make that training process better while running the uh sort of the antenatal care experiences we learned how to make that better we noticed the things that were awkward we noticed the things that happened on its own and those were like and of course we would supplement it with like more interviews etc but I think seeing people or sorry helping people see the experience early on helped us see how they relate with it and how it fits within their world and how it can be made better um and then thirdly my biggest takeaway was uh excellent local partnerships uh you know you need those I would have we would have never been able to do any of the stuff that we did in this project if it weren't for the ownership and the sort of the support that we got from our local partners what is the thing that you would say um is the is there a general key takeaway that people who are listening and watching to this episode and maybe are in a completely different context can take away from it so I I'm working at a telecom operator in I don't know Croatia and if we would have a conversation which what what lesson would you share with me what do you think I could take away from your experiences um I think the one thing and I I'm not very good at giving like career advice but what I would say it's changed for me personally is it's taught me to think about results in a very different way uh I think in my previous uh experiences I'm used to shorter projects I'm used to seeing the thing that I'm creating whether it's a report or whether it's a solution right at the end of it but uh you know the kinds of topics we work with are sort of long haul you know it takes a while for the for the you know it's for things to even change even a little and I think what that has taught me is the belief in simpler solutions as we discussed of incremental changes versus like big changes and I do think that has a lot of value no matter what sort of work you're doing because I think quite often a source of project frustrations can be not knowing how to do the big thing but uh we often lose sight of the small things that we can do to get to the big thing and that's something that I hold close when I work on the project that we work on and and if I can dig into that for uh one final minute how do you measure progress for yourself how do you know that you're actually creating an impact I well that is another actually topic on its own I know what I would say but what I will say is that uh on a personal level of course you you know create milestones uh as you would just to see a project moving forward if you're like leading a project or if you're in like sort of seeing how it comes together but even at like a higher level I think what at least our organization had tried has tried to do now is put an impact framework in place where we hold ourselves accountable for putting together a sort of it's called a theory of change in the global health and development world and we sort of adapted that to how we approach designing for solutions as well and I know it sounds uh a little too complex for now but as soon as sort of we were all introduced to it it's actually the most intuitive way to think about like how what are we getting towards like what is the big picture vision that we want to achieve which is a big change we want to see in the world let's say and what are the smaller ways to get there who's going to help us get there um and what are some of the assumptions that are at play here so just these are some of the things and I think what that does for us at a project level or you know task level is that everything becomes attached to a certain thing that helps us create that big change so it it makes you want to work on it harder and it makes you want to make sure it gets done so you can move on and and that's maybe a challenge in a lot of uh uh commercial and corporate context that you have no clue why you're actually doing it you're doing it because I don't know three months ago the CEO put it on the agenda but yeah any who uh yeah if people want to continue this conversation with you what's the best way to get in touch um I'm very LinkedIn friendly I am extremely reachable on email um and I can share that uh with you Mark and I mean you have my details yeah yeah the LinkedIn profile will be in the show notes of this episode yeah thank you for for sharing your uh experience your stories I'm always amazed in how much parallels there are in the design process across across the globe no matter which challenge we're trying to solve and I think it's really good to hear uh to hear so thank you again for sharing that I really hope you enjoyed this conversation with Priam and that you were able to translate some of her stories to your own context if you know somebody who needs to hear these stories as well grab the link and share this episode with them that way you'll help to grow the service design show family and that helps me to invite more guests like Priam here on this show for you if you want to continue learning about skills and strategies that help you to design services that win the hearts of people and business make sure to check out this video because we're going to continue over there


Mae'r bwysig yn ddechrau'r rhannu, ac mae'n rhai o blaen. Mae'n dda'r cwm hon o'r ddweud ychydig o'r cyfnodd ar gyfer y cyfnodd, ac mae'n deall.  Felly, we had a cleanup of one of the oldest, most published files in quite a workspace, StarCADE, looking through actual level code as a group and seeing what parts were still relevant and what parts were, from 2005, and still mental. Outdated? Edit that, Kelly, we will leave it. What have we had? What have we had, yes, please? I'm speaking about things like that. ro stimulating really much, shall we discuss that too well'? OK? Is that for me?  We discussed a strategy about how to reach the main user and potential developer to reach both of them. So we gather up some ideas about what to talk about and how to organise this. So that was predictive and we will have a move as well. So how do we handle what kind of device we will show, what kind of application we want to attract people with. So, yeah, and it's happy to be a great event. That's all. Unfortunately, the number of translatering was not too much, so we've probably been in some of the discussion on the main case. There were some updates on some changes, upcoming changes to the infrastructure, hopefully. We have the plans to finally release something related also on the release part. So we will hopefully release in the near future the translation for KD applications in the tariff belt, like it's happening for plasma and frameworks. Hopefully we will change something, there are other internal changes like in the naming of the files. Maybe we will change also, there is a proposal to change the software which powers the website for the translators. And a few other things like that. There is one thing that I am using the time now because there is a lot of time spent by the translation infrastructure to extract messages from applications which are there. If you go in and on SBN, there are still traces of application from the playground and even in extra gear from plasma, from the team and all the other models which are basically there. If you want to help cleaning up the old application from the SBN or within the tournament area, that will save our notes translation also. That said, nothing more. There are some notes which were sent to the translator list and we will go into the discussion there. We also found a bunch of features we can run right away asking or disable any DUI or change the default values. We briefly discussed releasing stuff that I quite bother to tell you with my performance issues, but I think that is why I am using myself. The other thing is that most of that will be used in the survey. For five hours and we began cleaning up our trouble tasks and we made it into a little pitch, which is good. We talked about social issues as we did the technical stuff, so I think we had a really good meeting and we didn't finish, but as our release manager had to wait, we will continue. It was a very good morning. Except tomorrow we have really important neon boffs, so if you are interested in neon eye problems or whatever, come to the neon boff tomorrow. Also tomorrow evening there is going to be a key signing pop at five, so if you haven't signed up yet, do that. I am going to print the list tomorrow. Sign up to sign up. I keep 500, 300 euros, if you do not sign up. Yes, if you do not sign in on the wiki, if you book tomorrow morning and you come anywhere, you have to pay 300 euros penalty. So make sure you are on the wiki. Wasn't it 300,000 euros? Maybe. That's 300,000. That's it for me.  It's tough here, of course. The portal documentation I have done so far, which is basically free portal software today, and it depends through the run times we have and applications. I think we didn't pay much. It was an interesting question, but I think there is a plan for having a CI and a native build for our KDA applications. I guess that's all. We meant to talk about AppFrame. AppFrame is that thing you have to write so that when people look for your application, they know what it's about. So we need to make sure that all of the information is there, that the software we are releasing has the information in it. We have been talking about how to make sure that the software that we are releasing has the actual information, which is something that we have been working on on the last weeks as well. We have been talking about how to make sure that plugins are probably exposed onto this system because it's actually not trivial. But as a conclusion for all of you, you should know that if you have more of your responsibility for any kind of application, you should be writing all of this metadata. If you're not doing that because you don't know how to, you should come to talk to me or Mathias or anyone else because everybody knows how it works, but it's super important. If it's not happening yet, soon you will start to see that the CI won't build for you if you don't have the information and this kind of thing because it's very important. Other than that, we looked into some new developments that are happening upstream that we hope that will have an impact as soon as possible. I'm raising this morning where we discussed the topics like what we can do to create more opinion and stories for our users and donors and what makes people interested in doing that donations. We basically decided about doing again an end-of-year campaign by using those postcards as gifts and also making the plans for Rwanda next year. We still have one user coming and we mostly discussed about how to get new people involved and how to leave donors and also people helping both sides. It was nice. We had the discussion on the presentation I gave on Sunday about the freedom of web services. What does it take to actually give us criteria to decide how we can maintain and retain the freedoms we have. We have fought for free software and getting the freedoms a lot by writing a free desktop and many more. But it turns out that the fact that the service is running free software is not actually a very relevant criteria. We need much better ones and this is something which is extremely important. I know many of you we all probably use Google Docs and GitHub and Treloir and whatnot. So our freedom we have actually gained was writing free software in danger there. The discussion is quite difficult because the problem is quite difficult. So this will go on. We will create a place where we can continue that in a little bit more structured way where they would like to invite all of you to participate about your freedom. For the past 3-4 months on how to structure all the content and data structure. And finally we have our first results and the first working things. And there is some more work on the QML that is a proper bop of all the customers tomorrow in case anybody has. Seriously, update, upgrade, whatever.