Okay, good afternoon everybody. So you all just had about train and railways and all that. And are you all awake right now? And since yesterday, you have been hearing a lot about user experience design and kind of thing. And I must thank the UX India team to begin with because they have indeed helped me to choose the title. So I'm kind of stolen the title from UX India itself. What is the theme of UX India conference? Sorry? Impact of design. So I've just added inclusive as a world. So which we are going to talk about the slightly different than from what you've been hearing since yesterday. By the way, before I get started, is there any people with hearing impairment in this room? Can someone say yes or no? No hearing impaired. Any person with a visual impairment? No, great. Because I want to always make sure my presentation is itself as accessible as possible. So in case if anybody cannot see this slide deck all the way to the screen, you can go to the slide share and look for C3 new as well. And actually slide deck is there online as well. And including the full text. Okay. So, okay, let me say, oh, it's working. So what is inclusive design, by the way, right? But before that, let me, this is not the agenda we're going to talk about. We're going to talk about what the inclusive design are all about and then the impact of design from the social perspective, technical perspective and financial perspective and legal perspective. So this is what we're going to cover about. The reason why I've chosen this topic is a lot of times people will keep telling us oh, accessibility is equal to for blind people or people with disabilities, which is not really the case. Though of course it helps people with disabilities a lot, but that's not the only case. Okay, now coming to what is the inclusive design all about. How many of you don't use elevators in your offices? Can you say yes or no? How many of you don't use elevators or use only the stairs? Anybody? Not many, right? Okay, elevators are actually basically meant for my friends like nursing who is sitting here, okay? Who may not be able to climb to the steps, but all of us in this room want to use the elevators, okay? So though the intent needs to build for someone, but it's actually helping, even that thing is that you will see people using elevators going from ground floor to first floor. Am I not right? Yeah. And so are the cases with ramps. If you look at a lot of offices, in one way they have three or four steps, and on the other way you'll have ramps, okay? But most often you see it's actually used by everybody else, and also when it comes to the ramps in shopping malls and all, what is it used for? When you have a big shopping cart, you'll actually take it through the ramp and put it into your cart. So it's actually using beyond disabilities. Ideally, that's again meant for people who use the wheelchairs, are pregnant women, okay, are elderly, but everybody, all of us take the benefit out of it, right? All right, now coming to subtitles. How many of you do watch subtitles on the television's cinemas? Most of us do, especially if you are looking like a Telugu movie sitting in Hyderabad, and you don't know Telugu, you'll say, oh, it would've been nice if there is a subtitle, right? And it's actually meant for hard of hearing people, right? But we all of us look for the subtitles, for sure. And just now our friend talked about the Rael Yathri, right? How many of you go to railway stations, airports and bus stands? Everybody, right? So do you listen to the announcement and board your train? Or do you just look for any visual element, visual information? Mostly not, we all look gossip to the co-passengers and wait for the announcement to happen, right? Can take a break after this, right? Absolutely, yeah, that has happened. And now it is the problem with airports is, in the interest of saying something like silent airports, it's actually dangerous for people, especially with visual disabilities. A lot of times they only display and if we don't pay the attention to the boards and we miss our flight, there can be chances, right? And not only for people with visual disabilities, there can be, this kind of situation will be others as well. Inclusive design is not really rocket science, it's actually building a product which is usable to all users. Nothing but to actually make sure your build, your application or your product is usable to all users. Irrespect, like we all say about, if you look at the job portals today, we are equal opportunity employers. We provide jobs irrespective of gender, caste, disability and elderly or whatnot, right? So it's as simple as that. So, for instance, if you are using Facebook today, okay, you would end up using that when you actually become an elderly person, right? And if at all, Facebook is not accessible due to whatever physical limitations you come up when you grow up towards 60, 70 years, you'll say, what the kind of design it is? And I'm sorry, but I actually have a wish for all the visual designers, actually at least most of the visual designers who love to use the dark background and gray text. You know what is that wish? At least for a day, they should become the people with low vision or elderly person. For a day. If not forever, at least for a day, they should become with a less vision and start looking at their own applications. So when you actually build any product which is actually accessible, like I said, it's not a rocket science. They mostly make building an accessible product, you don't need to oftentimes, at least 70 to 80% trust me, you don't need to do any special things. It's all about keeping the semantics in mind and using our brain in a right way, okay? For a very same, since you are all designers and it's a design conference like our internal event, I'm open to talk about designers themselves because you will relate to your own examples, right? And it's not to hurt you or offend you or anything. Thank you. Okay, it's not to offend you or anything. But what if, if I have made these slides, I have anyway used the black background and if I use the dark blue font color, what will you people tell me? Not readable, right? And this is the same complaint we all will be having. So, and when it comes to developers, you all have to use the semantic and write techniques. Today, thanks to the technology, you can, yeah, checking is over, man. Yeah. So, yeah. So, thanks for the involvement of technology and the hard work will be happening at W3C. You come up with any technology where it may be bootstrap or Angular or jQuery, JavaScript or anything you use. There are techniques to make it accessible. And if any of you have a myth that to make a accessible product, I need to compromise on my design, no. You can build as beautiful design as you want, but make sure that they really look beautiful, okay? Unless if your definition of beauty in us is something like a less contrast ratio, I'm sorry. But as long as it looks beautiful, you don't need to worry about how it looks like. Everything can be made accessible at engineering, right? And if I say that I'm a blind person and I use screen-dating software and your application works great very well on my iOS device or Android device, you'll be happy, right? So, India actually benefits and you know one thing? We say that we are actually, technology is helpful and we are using technology quite a lot, right? For some people, technology is actually required necessary. If you look at our shopping complexes today, a person who is blind, person who is on wheelchair, it's hard for them to go and shop there. But thanks to our e-commerce, we can sit at home and do the shopping as much as we want. Our friend has just talked about Raelia 3, right? Suddenly a blind person or a nursing girl goes to him and say that, you know what? I can't go to your railway inquiry counter in Dilchik Nagar and find the information, but by using your application sitting at my home, I'm able to get all the information. Will you not be proud of? So, once you actually build an accessible product, you're actually creating a social impact, okay? You're also raising awareness among the other product companies, other companies. And as we said, it inspires community. Like, if you go and tell somebody, you know what, my product can be used by you as well as a blind guy. He said, wow, that cool. So you're actually inspiring that other person to actually learn from you. The financial benefit, yes, nursing girl was pointing out, the sales will increase, right? Once your application is actually become accessible, you will have much more users, right? So if your application doesn't work for me, why would I actually use it, right? I will straight away uninstall it. But if it is actually working, we use it, people with disabilities use it, people who are elderly will use it, and people who are actually relaying a low bandwidth connections will actually use it, and so on, right? So you're actually, the increase will, from the financial sector, and also it will reduce your cost. You can actually reduce your investment on accessibility and mobile readiness, okay? Once you actually start thinking from accessibility, right from design stage, and including accessibility right from your engineering and everything, you're actually reducing your cost. Otherwise if you actually think of accessibility at the last minute after the development, you'll actually pay a lot of money to me, okay? Because I'll actually make you to rework on entire application. So you'll also avoid the lawsuits, because in countries like US and Australia, if your application is not accessible, or your building is not accessible, people can actually go and file a lawsuit against you, right? But if you're actually thinking from the practice itself, you will actually get rid of those lawsuits, and legally you'll be more prominent, and this is the kind of benefits you'll have, right? So it's actually impact quite a bit in your business as well. It will save you financially, socially, legally, and so on. So with that, in the interest of time, we'll actually close this presentation here. If you have any questions, any questions? Yeah, so for accessibility, if we passed section 508 and CZ 2.0 Accessibility Guidelines, is that okay? Is there, beyond that, is there anything we need to do for accessibility? Okay, that would be your first step to pass the, see, the section 508 and WCG 2.0. It's a guidance to you, okay? It's not the entire thing. It depends on how you're actually, what kind of application you are, but if you actually, first step would be to actually pass all those requirements, then the second step, based on your audience, okay? Is there anything needed to be done? Okay, but this is the, your guidance part, which will actually help you to at least 80, 85%, but it will still not be complete because they'll be based on your region and based on your requirement and audience, there may be a few additional things you might be needing, but to satisfy the compliance and to say that you are accessibility, okay? But achieving the main, complying with this WCG 2.0, at least double A level, not triple A, would actually help you quite a bit. Ranjith is not allowed, right? Not allowed? Okay. But yeah, you can. So one question, basically. So every company has a lot of accessibility guidelines, sections and WCG, various levels and stuff like that. UK has separate, German has the, German, US has separate. I think India is also. Okay, something. Why, why should we have these very different, different rules for different countries? Why not it's the universal one rule that we need to access? I'm glad, I allowed you to ask the question. It's an interesting question, but what your question, did you finish your question? Yeah. Yeah. It's actually a myth. Okay. You're talking about section 508 in the US, European accessibility standards in the Europe, Australia accessibility standards in Australia, web guidelines for government websites in India. Okay. You are hearing all these different things, but all of these are actually derived from WCAG 2.0, which is by W3C, web content accessibility guidelines 2.0. The accessibility part of all the standards will include only WCAG 2.0, but they will also add the country specific, like if you take the instance of web guidelines for Indian government websites. They will also talk about what is the kind of brand entity needed for Indian government websites? How the Indian government emblem should look like? How is the navigation structure look like for them? What are the colors should be used? So it's actually some of them, they come up with the standards for the country specific, but basic accessibility requirements are taken by WCAG. So all the companies who are here, what we should be doing is that, let's not initially think about the country specific rulesets or guidelines. Comply with WCAG 2.0, and that will help you to fill in the WIPAT documents, which is by section 508 in the US, or any country specific documentation you will be able to fill with. But your basic document and your ground document should be WCAG 2.0. Okay, that is a universal acceptable, accepted and adoptable accessibility standard. And in fact, that is the one which is adopted by United Nations as well. The rule nine of the United Nations Convention on Rights of Persons with Disabilities talks about accessibility and asks users to comply with WCAG 2.0. Okay, as a designers, how many of you will agree if I propose you should make one beautiful looking website and one text based website? How many of you will agree? Yes or no? I need an audible answer. Very good, I appreciate all of you. Okay, and we will not recommend any food supply websites, because one, it is not usable, we are talking about all users. So there should be one product for all users. There are enough techniques available in the technologies, in the technology stack, and the standard, there are enough things available to make the one product accessible. You use any technology you want, but you can make it accessible.  But the reason we highly discourage people to come up with text based website for visual impaired people is that it actually adds the cost to the companies, because you also need to make sure that you will maintain the same content on both websites, right? And why will other people who come to the text based website, even, and if people with low vision like me, or even people with blindness themselves, don't often go to the text based websites, because it will not have the full functionality. You cannot search, okay, you cannot filter, you cannot do anything. Why, they don't even use it, right? I would highly recommend do not go for text based versions. It is again a myth.


Our next presentation is going to be about the OFP reference architecture. So, Surabh is going to review a description of the architecture and provide an overview of the data entry along with reporting. Surabh's background, Surabh Roy is a global director with emphasis energy business unit and is emphasis focal point for the open footprint forum along with the OSDU forum consortium. And in his current role, Surabh is responsible for leading energy transition and digital transformation initiatives for emphasis energy, oil and gas clients. So, there you go Surabh, I'll turn it over to you and just make sure that you just put your sticker on the slide and then you can move the arrow forward or backward. Thank you, Heidi. Thank you for the introduction. It's a privilege to be here. Can you hear me well? Yes, we can hear you. Yes. Okay. All right. Excellent. I'm just trying to move the slide. Thank you everyone for joining in greetings from whichever part of the world you're joining us from. Today's session, we're going to cover the reference architecture, the implementation of it, the data entry aspects of it and the reporting. We absolutely appreciate you joining us and sharing the common vision with us. You know, the way we are moving towards getting a better planet as we move forward with this initiative. All right. So, what we're going to cover is there are two parts to the conversation for particularly this session. One is going to be the technical architecture aspects of it and the other is the default user interface that the group has implemented. And I said, default, because as we go through the architecture, we would kind of communicate to yourselves in terms of what you've heard in the past right now in the morning about the ability for organizations to create their own applications on top of the data platform. And so, therefore, the default aspects of it in terms of the UI, excuse me, but before I move forward, I think a few things that we want to call out. First thing is the key contributions aspects of it. This is more of the credit of the reference implementation and the architecture, you know, while the group and the consortium members have reviewed it, especially want to call out the individuals and the companies that contributed to it. And those are IBM, Infosys, Shell, and Vipro. So, I kind of represent them as I walk you through the reference architecture as well as the user interface aspects of it. So, moving on, before we get into the details of it, and I think through the session today, we kind of worked on as to what exactly has been implemented, but just to kind of do a quick recap so that we can connect the dots in terms of how exactly the objective of open for print has gotten translated into how we have implemented the MVP one. How exactly the reference architecture looks like? What are the scalability and the aspects of it? So, just to call out, I think we all appreciate the challenge. We were looking at, you know, the lack of standards for storing defining accessing and exchanging the G, A, G scope data across the supply chain. And I think we got to highlight the fact and we heard Anna talk about it. We heard the questions that came in today. The scope three aspects of it in exchange of data across the supply chain. I think that's becoming the key challenge. And so, therefore, from a forum perspective, the open for print forum perspective, I think a few things are very important for us to kind of reiterate. One is that this is not a particular industry. This is across all industries because we cannot measure if we are not covering all the industries, you know, because as I think I've read it on the one of the slides. Scope 1 and scope 2 for my organization is scope 3 for another organization. This is about, you know, the definitions and the standards. So, you heard some only talk about the ones that we are referring to at this point of time and the roadmap ahead. Early in the morning, you heard about Gommar and Sammy talk about the, the data definitions aspect of it, the data model aspects of it, but one key thing that I want to call out is that, you know, open for print from our standpoint is just not about the standards. It is, but it equally is about the, you know, the implementation aspects of it, the data platform aspects of it, and which is what we're going to cover here today. So, from a, you know, as we move forward, the 1st part of it is the technology architecture. And as we get into the architecture aspects of it, I think some principles are really important. So there are these 12 principles that you see on the screen right now. And these are the technology principles that we are having to to ensure that the data platform 1st and 4 most and big bowl letters is open source. Anybody can leverage it. Anybody can contribute to it. Anybody can implement it on whatever text tax, you know, you have, as long as you're following the standards provide, you know, that we are that we have identified the other thing. I think is really important for us to highlight that, you know, for us to get a head start on kind of. Creating the, the minimum viable product 1.0 get a head start on that. What we have done is we have referenced back to the OS, do you data platform architecture? And those who do not know is do it's. It's an industry initiative on the subsurface data universe. We created an open source platform across the multiple cloud providers. What we have done is we have, you know, we have tried to leverage that data platform so that we can get a head start about, you know, accelerating the deployment aspects of it for this data platform. So that's, that's what has given us, you know, the, the lead that we could just deploy it real quick using the, the world that has already been done by OS to you. And you can, and again, I think in, hi, these initial note, she talked about the open groups initially. We can read more about it, you know, from open group perspective. I think, you know, the 1 thing that to be called out again important is that you can deploy it on the infrastructure you choose for the MVP 1 for the implementation that we have done. We have implemented this on IBM red hats open shift from a, from a, you know, the cloud standpoint as well as the container platform standpoint. And so that's what you would see. We will talk about it more as we get into the next slides. But just to call out the key principles, you know, you were looking at the availability aspects of it, the scalability aspects of it, the authorization element of it. There should be proper role based access for you to see what data and that kind of has driven the fact that, you know, we have looked at the user interface as aspects of it from a, from a persona standpoint and saying that, you know, oh, if you are more of somebody who was, who was overarching in charge of the data versus somebody who's trying to look at the emissions aspects. Of it versus if you're in the audit organization, which parts of the data, what do you look at it? And so on and so forth. So these principles have guided us to get to that point in the, in our data platform structure. Moving on as we kind of go through it and this is this is 1 of the core aspects of it. You saw this slide that at least the architecture diagram in different shapes today. This is just a simplified way of calling out 2 things. I think the 1st is that there are the blue elements that you've seen here, which is a contribution by the organizations to create the data platform. So the infrastructure element of it, the container platform, as I mentioned about the IBM Red Hat, the data ingestion services, the platform services and the application program interfaces, which was the API. So essentially what we're saying is, and I realize this is more of a technology conversation. I'm going to bring in the business element of it so that we can identify as to how this is, this is actually going to work for your organizations as you adopt the open footprints data platform. But essentially what we're saying is that some of these elements are core to the platform and those are contributions. Those are available that you can download, but there is a competing area and which is what you see in the green box at the top, which says the user interface or the consumption apps. And this is the area where the organizations are free to choose or develop or integrate the applications that they want to be the default user interface. And the other thing that I'm going to talk about a little later in this presentation is just an example of how we can extend the APIs that are provided by the underlying data platform to create an application of sorts, let's just say for data entry or for reporting that kind of a thing. But just an example, there is absolute ability for anybody to kind of plug in if they are using something which is available today in terms of data entry and reporting or they want to build something which is a custom developed application of sorts. But few things to note out, I think this can be deployed on any technology as long as we are compliant to the standards. Again, repeating open source 100% open source. You know, there is a focus on, as you can see from the stack of it, there's a focus on microservices based architecture. The top part provided us the ability to kind of place in the future so that, you know, there is enough healthy competition available and we get the best that we can use in terms of the apps available. And so those are the key elements at this point of time in the data architecture, the platform architecture in here. If you look up the open footprint website, you would also find a link where in we have this mentioned and I have put the link at the bottom of the slide which says, you know, the model.pdf that explains in detail about the various components. Further general review of, you know, the modules that are available and how exactly all of this comes together to offer the data platform. I will, if there was for a moment moving on, I think from a perspective of and this part that you see the next slide, which is the slide number 67 coming up for y'all is essentially the focus is on the user interface and reports architecture and why we are bringing this up is just to let you know how easy it is to kind of get the platform, you know, installing your environment and then kind of link it up to any of the applications that you may have or just consume the API is that you that you see from the underlying platform. So ODI what you see is basically the open data interface platform and that's what we have built on the on the IBM architecture right now, especially from a red have open shift perspective. One thing that I want to call out here is the authentication element of it. So you see the key cloak that is mentioned on the right hand side. Essentially, that's our identity provider. So we're using that IDP tool to authenticate users. And so to my previous point where I mentioned that, you know, we kind of looked at it from a persona based aspects of it as to what role based access would be needed. Key cloak gives us that the authentication and the authorization elements of it on the platform to determine, you know, who gets to access what kind of data how they log in and so on and so forth. What is also going to come up is in tomorrow's session and I think Sammy mentioned that earlier today. What we're going to do is we're going to demo the user interface with us with an example of how exactly this is going to work. So you will actually see this working versus just looking at the block diagram that I'm putting it on the screen right now. If you just look at the diagram, what it essentially means is that their API is extended. You basically consume the API is and then just create forms. If you were doing a custom development to kind of consume the data platform and, you know, either write into it or just export the data and kind of see the data on it. So that's more on the reference architecture in the interest of time. I will move forward into the next part of this thing, or rather I should pause for a moment. Are there any pressing questions at this point of time or do we take questions towards the end? I think we can do the questions at the end. So yeah, keep going. So Rob and I'll we'll pick up some of the questions that are coming through. Okay. All right. Thank you for that. So the next part that we're going to talk about is just a trailer of the user interface design of how things have come together. And so this is what you look at the screen is a default view of the UI that the teams have created. To kind of talk about how we're going to use the data platform. I can't beat myself there. This is just one view of it in terms of, you know, the UI that you can use to access the underlying data platform. You're free to create your own consumer APIs and create your own applications and reporting speeds. But essentially, if we look at the, you know, on this thing and I think this ties back to most of the conversation that happened earlier today in terms of the boundary conditions in terms of creating the organization structure and hierarchy within the platform in terms of capturing the emission data and reporting. So all of those have formed the basis of today, you know, of this platform. So if you just look at it from a perspective of, you know, the the tiles that you're seeing here and this kind of is the workflow that would that would work out as you kind of, you know, start leveraging the open for Prince data platform. There is an ability provided for you to kind of set up your organization hierarchy. And this could be from a, you know, from a field asset perspective. This could be from a equipment perspective. This could be from a corporate office perspective based upon scope on scope to what you're looking at. And then the future in the scope 3 perspective as well. There's an ability for, you know, for the organizations to kind of set up their processes, you know, the facilities, all of that. And each of this is governed by the industry at the bottom line of it. So based upon the industry, the templates kind of show up and say that, you know, what kind of, you know, what kind of data you want to capture in here. So we have provided that flexibility considering the fact that, you know, every industry, whether, whether from aviation to shipping to aluminum to, you know, all in gas. They have their own different ways of reporting some of their emissions data. And you would hear more about the industry aspects of it. And our tomorrow session, which, you know, let's go to talk about about the various industries that we are covering. Now, once we have, you know, the ability of this UI and therefore the underlying platform is that, you know, once you've captured your organization data and the process data, you then kind of can go ahead and start capturing your emissions data. Right now, you know, as part of the MVP 1.0, you can just get the data, you know, from one of the from your existing system so you can just manually enter the data in the system. And again, we're going to show this to you when we kind of give the demo of the platform tomorrow. And once you have the emissions data, then it obviously provides you the ability to generate some, you know, some reports so that you can see in various, you know, slice and dice format of how the data would look like. You know, whether you're tracking it by a process or an equipment or a facility, you would be able to do that. The platform also provides the ability to kind of, as I was talking about the role based access. So, you know, whether you want to set up your own geographies are the admin elements of it and providing members access and all of that stuff. The administrator should be able to do that. So the broader level, that's what we have. We do have a placeholder at the right hand, which you see as the MVP 2. And as we go through today's session and tomorrow's session, you would hear about the open for trends forums plan about the MVP 2, which includes the calculations and the scope 3 elements of it and how that is going to get embedded into the data platform and you would be able to leverage that. So, the broader level, that's the, you know, this is, this is what we wanted to cover a quick. Each of these kind of comes together and I think most of it is what. As you can see, there's an ability to do the organization hierarchy setup. There's an ability to do the boundary condition setup. You can enter data for specific period because that becomes very important from a duration standpoint and the time scale standpoint. Then there are simple tabular reports available to generate data and kind of see the organization hierarchy and the emissions data corresponding to it. And then the administration effort of it. So the ballpark level that kind of covers the reference architecture, how we have leveraged the reference architecture to create the underlying data platform. The MVP 1.0 and then how the default UI right now kind of is a flexibility that allows, you know, the end user to able to kind of put in that data. I'll pause. I'll leave the next few minutes open for any questions that we may have on the reference architecture implementation or any of the user interface elements of it. And Sammy, I'm looking at you right now. I've got a couple of questions already for you all queued up. So, so I think you, I think you spoke to some of the IT folks already. So, but first question I think from to Balt is what are the standards required to be compliant with the architecture? Sorry, I just saw, I just see your hand. Sorry, did you mean to talk. No, you can go ahead. I think so, the, from a standards perspective, I think we talked about the underlying principles. So if you, if you just so that 2 aspects of if you just, you know, the reference implementation is something which is a, which will be a downloadable version of it. So once you download the platform, you know, it comes with all the, the bells and whistles for you to ingest the data to kind of generate the reports and so on and so forth from a broader industry standpoint perspective. I think Somali covered that in the previous session as to what we are. And so we can share that offline with yourself as to which standards we are following. But maybe, maybe can you add something to that? You can hear me. Yes, yes, we can. Okay, thanks. The prime step you need to worry about is really the API is to integrate your applications into the data platform. Those are public standards we come out. What we do inside the data platform course is less relevant because people don't have to access to it. So your prime worry needs to be, I have an application. How does the application get access make use of the standard APIs to access the data platform that really should be focusing at from a standard point of view. Cool. Excellent. And then 1 follow up or 1 additional questions from Ben. Are there any plans to provide a hosted version of the platform beta or otherwise for smaller companies to utilize? Absolutely. Absolutely. And I think we would truly benefit by individuals and companies leveraging the data platform that we have, especially 1.0 version, because that will also give us the ability to consume the data that your organization today has and help us improve. The existing, you know, the data platform that we have and kind of big that into our roadmap aspects of it. So, so I think in the next quarter is what I would say that you should have something available. And, you know, that's what is our goal so that you can download a version and be able to leverage that that would also help us as I mentioned, you know, to kind of see what, what are we missing at this point of time within the consortium members. And the kind of big that into our backlog and the roadmap so that we kind of, you know, ensure that your industry, your company, your data that gets covered into our data platform. Yeah. And if I can build on, so I think there's there's there's sort of a second part to that. So, yes, we'll have the reference implementations that people can download and then, you know, implement in their own landscape, for example. But I think also for some smaller companies, they may not have that infrastructure available. So any views on where there might be, you know, other organizations that are providing that reference implementations to be leveraged by the smaller companies. I guess is more that we expected to have enough time. We clearly send some good idea, good point. We see it also fits with the OGU environment where companies stop finding this as a source of pass capability to other companies. I think the same happening over here. There's just a matter of time. We're very early in the process over here. But if companies come up with that, they're free to do so. So I expect it to happen. Exactly. We just said, in a, in the form of a SaaS type environment. Yes. And just to, and just to build maybe one bit on the standards one coming back to that one as well. I mean, there's a number of software organizations that I know are are attending this as well. So I'm sure that, you know, these standards that were published will also then it's not just in this data platform, but ideally get embedded into other SaaS and, you know, past platforms as well that that'll then get built in and embedded as well. So it's, it's a, it's a full ecosystem of companies, software companies and service providers. I think that are participating. Heidi, there's one question I noticed that we didn't answer previously around governments that Andrew had. Do you want to pick up that one? Sure. Thanks, Sammy. And thank you, Rob. The question is, have any governments or associated agencies endorsed or looking to endorse the OFP? And just to answer that, Andrew, at the moment, we are currently in the beginnings of some discussions with some agencies. We welcome, of course, any collaboration or relationship or an endorsement from the government or any agencies. And so if you'd like to pick that up and continue that discussion, I'm happy to do so afterwards. So at the moment we are welcoming and as Johan pointed out, we're still in the early stages. So any feedback or suggestions or recommendations, you know, that would be very fruitful for us. So thanks for the question. And thank you. I'll put it back to Heidi yourself and, and John back to you on the control. Thank you again. All right. Thank you. Again, really well done. Excellent, excellent presentation. And so thank you. So moving on to. I'm sorry, I just noticed that Sirap has some appendices here to his presentation. Obviously these presentations will be made available. So all the attendees will be able to see these appendices. I'm just running through them now, but there are a lot of embedded links there, a lot more information and these will be distributed after the event folks. So you won't miss those. You will see one of those.


As an emergency medicine physician, one of the most common things I see in the emergency department are sick children, especially children with fevers. Fevers are usually the calling card of simple viruses causing colds. However, a fever may indicate an illness requiring a physician's care. The purpose of this instructional videotape is to provide the basic understanding of how to recognize and treat a fever at home and when to recognize it is time to see a physician. I think she has a fever. What do you want to do? What should we do? What is a fever anyway? How high is too high? And what medicines can you give your child? When should you go see your doctor? Let's take a look. Fever most commonly occurs is a response to an infection. During infections, moderate fever is probably beneficial because it enhances the body's defense reactions. Any high temperature or rapidly rising temperature not well controlled with medicines can be a sign of serious infection. About one fourth of pediatric patients who visit the emergency department have a fever as a sign or symptom. The vast majority of these patients have simple illnesses caused by viruses that go away on their own after a few days. Some result from bacterial infections that can be treated at home.  These antibiotics do not work against viruses. If the fever is caused by a virus such as the flu, chicken pox, or a cold, the best thing to do is to give plenty of fluids, maintain fever control with fever medicines, and let the virus run its course. So, what is the best way to take a child's temperature? There are a variety of ways to measure body temperature.  However, skin temperature from the armpit are easier to do at home with less risk of hurting the child. Oil temperatures are appropriate for children older than four years. Newborn children less than one month old do not get a fever from illness the way older children do. These newborns react to illness with poor feeding, inconsolable crying, difficulty breathing, or just plain do not look well. Any newborn child with these symptoms should be evaluated by a physician immediately. Any temperature greater than 100.4 degrees in a newborn child should be evaluated by a physician. Children between the ages of one and three months with temperatures greater than 100.4 degrees despite giving fever medicines should also be evaluated by a physician. Any child three months to three years old with a temperature greater than 102.2 despite medicines and fluids should be evaluated. And any child with a temperature greater than 105 degrees should be taken to a physician immediately. Now that you've determined your child has a fever, what can you do about it at home? One of the most important things is to ensure your child drinks plenty of fluids. In the newborn, that means breast milk or formula or an electrolyte fluids that is specifically made for infants. In the older child, juice, water, or sports drinks are the best fluids to give. Deluding the juice is important and may ease an upset stomach caused by too much sugar. This will help prevent vomiting.  There are many different brand name fever medicines on the market. There are two basic generic types, acetaminophen and ibuprofen. Look at the ingredients and dosage recommendations on the box or bottle. Read the labels carefully as many different brand names are the same medicines. Acetaminophen is an effective anti-fever medicine. Follow the dosage labels carefully. Ibuprofen is another powerful anti-fever medicine. If one does not work well by itself, then both can be given at the same time and work very well together to bring a fever down. Again, it is important you follow the directions carefully. Another effective way to bring a temperature down is a tepid bath or sponging with cool water. Do not bathe a child in cold water or ice water and never sponge a child with alcohol. Bathing or sponging should be combined with fever medicines. One note about medicines. Never give aspirin to a child with a fever as it is associated with liver and nervous system complications.  First, try to contact your child's pediatrician. As stated earlier, any child less than one month old who appears ill should be taken to a physician immediately. If you are unable to contact a pediatrician right away and your child has a fever, here are some general indications of when to bring your child to the emergency department. A fever that remains high despite fever medications.  Shortness of breath or irregular breathing. A cough and a fever together. If the fever lasts longer than four days. If the child does not want to move his head or if his neck hurts.  Just think how you feel when you get a cold or a flu. Miserable. And that's how your child feels. The important thing is you know how your child acts when he or she gets a cold or a flu. Follow the important steps of giving plenty of fluids and proper fever medicines.  The video you just saw focused upon common medical problems often encountered in an emergency department. Many of these problems can be managed by primary care physicians such as family practitioners, internists and pediatricians and others. As a first step towards managing your healthcare we urge you to contact your primary care physician as they are typically acquainted with your medical history and can maintain continuity in your care. If you do not have a regular physician we strongly encourage you to establish a relationship with one.


Hello, everyone. Welcome to the Horizon deep dive customization session. My name is Ty. This is Matt and Cindy. And I'll be covering the first third of the presentation. So a bit of history before we get started on all of this. The initial plug-in support was we actually added that in Icehouse release. But a lot of the Angular plug-in work didn't actually start until the Kilo release, where we started introducing things like localization, basically Karma and Jasmine for our unit testing, and the initial launch instance work. And in Liberty, we introduced the user's panel. We had auto discovery. We had linting for our code, for code quality. And we had a lot of low-level widgets that we created to help us get along. And in Mitaka, we introduced two new panels, the Angular Swift panels and the Angular Images panel. Along with that, we have two new concepts, which are basically the action registry and the extensibility service. And we'll talk a little bit more about that. And so what's introduced in Newton? So the features that we introduced in Newton were, one, higher directives that basically replace a lot of the boiler plate templates that we used to have. So because we had a lot of lower-level widgets, we had a lot of templating code that also accompanied them. With higher directives, we basically got rid of all of that stuff. And some of the other features introduced in Newton were resource-centric widgets. And later on, Matt will talk a little bit more about that. Essentially, it allows us to define a heat resource type and allow us to use higher directives to then auto-generate a lot of the content that we need. We'll talk a little bit more about that later. Three, we had a lot more extension points. So now you can customize things like columns, search facets, details of you. If you wanted to add more stuff to your details, you can do that easily now. And four, lastly, we introduced the schema forms, which is a third-party library that allows you to essentially generate forms very, very quickly, just using, basically, JSON schema. So what are some of the takeaways we would like you to walk away from this session with? If you can walk away with just one thing out of this four, we would be very, very happy. So four of the things we're going to cover is Angular plug-in architecture, which I'll cover, and then resource action registry, which Matt will cover. And then lastly, three and four, how to write a plug-in and customize different things like actions, columns, details, facets, and so on. Okay, so how do we get here? Angular plug-in architecture, what led us down this road and why do we use it? So this slide will answer the why, and the next two slides will answer the what and how we got to it. So the reason why we use the Angular plug-in architecture is, one, it's extremely modular. So you'll see in this diagram that a lot of the actions are broken up into pieces. A lot of the steps, which you'll see below in the green region, is also broken up into modular little pieces. And because it's modular, we can easily extend and customize these actions and these steps. And as a result of that, we can also make them very flexible. So you can either define them using the schema, such as the schema form, or you can declaratively declare them and say, you know, I want more control. I want to customize my things more. I don't want to use the framework. I want to write out all the HTML and the JavaScript. You can do that too. And because of one, two, and three, these modular pieces make great building blocks, which then allows us to write higher directives that take advantage of these lower directives. And again, Matt will talk a little bit more about some of what some of these higher directives are. So how did we arrive at this Angular plug-in architecture? A couple of mid-cycles ago, we had a problem that was posed to us that we had to solve. Essentially, the problem is you have two independent teams. They both want to work, and they want to introduce their own little step into this workflow, right? In the past, there wasn't actually a way for you to do this.  You have to manually, you know, merge your code. So there's a lot of work just to get two plugins to work together. So we came up with the idea of the extensibility service, and this solves the problem that was proposed. The reason why it works is because it uses a plug-in play model, essentially allowing you to write many plugins, and they can all extend from the same workflow. In this example here, we have a run block that essentially you can then inject an existing workflow from Horizon, and you say, here's what I want to do with it. I can prepend this workflow with another step, or I can append this workflow with another step. I can even inject my own custom step into any arbitrary position, and I can give it even better, I can give it a priority so that I don't run into conflicts. So what's changed since L and N? Well, in L, when you wanted to create custom content, you basically start at the very top, you have a table controller, and then you have some table tabulating code that reads from the controller, and then you have a bunch of actions that the table knows about, and when you click on one of these actions, it launches a wizard model, which then walks you through a number of steps, and once you complete these steps, you then complete the action. In N, we sort of changed that a little bit. If you notice, at the very top, you don't have a table controller anymore. What you have in this place are the images module. So instead of writing your own table code here and your own logic, you essentially now says, hey, I have a resource type, a heat resource type. In this example, we're using images, and we're saying, hey, I have an images resource type. Here are the columns that I would like to see, and here are the properties that are set for this particular resource type. And then you have an actions module, which then is basically an aggregation of all the actions that exist for that particular resource type. And the reason why we have this actions module is that you can now use this across panel. It's no longer restricted to just a single panel. So if you wanted to show, let's say, users along with images, you can now do that, and you can take actions that are specific to that resource type. I'm going to introduce Matt next, and he's going to talk about the action registry a lot more in a lot more detail. Great. Thank you, Ty. All right. A little introduction first. I'm Matt Boylan from HPE. I'm one of the contributors to Horizon, and I also contribute to the Searchlight UI project. Some basic facts about me. I went to space camp. I fly planes, I raise chickens, and you have to trust me, this actually happened. I ran into Tim Allen in a deli. It's true. You could look it up. I'm going to talk about the resource type registry that he was referring to, and then I'm also going to go through and sort of examine and make the anatomy of a web page that's using the registry. So let's take a look at just an overview of Horizon and sort of how it's structured. It can get a little confusing because the word Horizon means several different things, and so I wanted to sort of de-conflict that. Over on the left, you see the Horizon repo contains a Horizon framework and also OpenStack dashboard, which is a directory that contains sort of these core dashboards.  So I just wanted to sort of paint that picture very easily for you. Developers, when they're looking to develop these applications, they want to be able to write features quickly. They want to be able to develop without having to generate a lot of scaffolding and boiler plate, as Ty was mentioning. They want consistency of display. They want things to sort of look consistent from one page to another. And sort of a new thing, at least from my perspective, is the ability to display similar controls and content in different contexts. So for example, right now, using the Images example, you can go into Horizon, drill down into the Images page, and you can see the content there. Well, I would also like to see some of that content in the Searchlight plugin that I'm working on. I want to be able to find images there, click on it, and then see the same content. So we just want to make sure that all these sort of questions are going together. The registry, it's an AngularJS service that allows AngularJS modules to provide or retrieve descriptions of resource types. So volumes, images, those sorts of things. And this is probably the most important aspect, is that the widgets that we're providing in the Horizon framework make use of these descriptions to present information and workflows. So that's what I'm going to try to get across at the end of this talk. As Ty said, it uses heat naming conventions. It's basically a map that just says, you know, OS Nova Server, what's the descriptor object related to that? That's all that it is. And any modules, as Ty also said, can register these things. So just as an overview, if I look at the Images page that exists now in Newton, all of these different aspects are coming from a configuration in the registry. So all the columns and actions and things that I've highlighted here. And similarly, within the details views, all the tabs and headers and actions that you see there are coming from that. So we're going to take a closer look at sort of how this actually comes about. So at runtime, the registry, this is actually an AngularJS thing. When you have a module that's initializing the two important phases it goes through. The first is config and the second is run. And just as a background, the registry initializes itself during config. And the main distinction here is that that makes it available for dependency injection, which is sort of a core feature of AngularJS. So that anything, any module that you write that I write can just receive that as a dependency injection. So that I'll get into exactly when you use that, but it's an important concept. So place your registrations in the run method of your AngularJS module. I'll show you more of that. And just as a highlight as to what the resource types look like, they'll contain some metadata. So like names, things like that, how to load the data. They're going to talk about the actions that you can perform on the data. And also, how can you view the data? I'll go quickly through this. But for example, like OS Nova server would say, well, we're going to call, I don't know why we call instance in Horizon, but instance and instances, well, we're going to keep that in the registry. What API do we use to actually access the data? That's the registry. And then what are all the different views and things. And the other thing I really wanted to point out on this slide is the fact that you don't have to register everything for every resource that you're developing for. You may just want to put names and you may not want details view. It's completely flexible as to how you execute that. So when you use this structure, the things you get for free, you get these tabular list pages. So if you're sort of familiar with the current scheme within Horizon, you go to a page and you see a table list. This also gives you client side results searching as part of that. So it just comes free with using this. All the action drop downs that you're familiar with are provided there. And then the basic structure for details page. And this is actually an collaboration on what's already been done in the sort of the Django side of Horizon. So we'll look at that a little bit more closely.  You have to be able to write actions, which are essentially workflows. And we have some tools to help you with that. You have to write your business logic. And then you have to write your basic views, which are essentially templates. And I'll show you some examples of those. So I work on a plugin. I work on Searchlight UI. And I used the registry, again, not necessarily in the core prize. I'm using it in a completely different context. But I'm going to sort of look through the different places where this registry values show up. So here I'm just highlighting the names of the different types of things in my result set. Those come from the registry, the actions. And there are actually three different types of actions that we register. Their row actions or item actions, rather, that show up at the row level. So on a single item. Then you have batch actions, which are things which can be executed on multiple items. And then you have global actions, which can only be executed at any time without any action. So like launching an instance, you could certainly do without having selected a resource. We've introduced drawer views into many of the displays. So the images page is an example of this. And Searchlight is an example of this as well, where you can just click on a row and get expanded information about it. And then on the details pages that we've introduced, all this is generated from the registry as well. So let's just take a quick look at the details page a little bit more. So the names, the actions and the views, multiple views that you can tab through those are coming from the registry. So let's take a look at the code a little bit.  I'm just sort of pseudo code here. The run method here is having the registry injected into it. And then we are going to call the get resource type method, which is sort of the most critical method in the registry. And it just looks up the string that you're passing in. It says, do I have this in the registry? If it does, great, it's going to pass you back the information. If not, actually initialize the registry so that you could either add more information onto it. And that's really how this sort of plug in method works, is that any module can just call this get resource type and either access or provide information to it. And since it's done at run time, that is the run time for the module, it sort of happens before the application has fully started. So how do I make actions, for example? Actions are expressed in AngularJS as JS services that are registered with a resource type. And I don't want to get into the complexity of that because it's difficult to construct workflows. But basically what this means is that if you look at the very top, it might be hard to read. We call get resource type on the registry for instances, I suppose, is what we're using in this example. And you'll notice it says instance resource type.globalActions. So this means we're accessing the extensibility service for this list called global actions. We're going to append onto our global actions a new action, and this is called create instance. And it's using the service of launch instance service, which is this service that we've created, this workflow we've created. And it has an ID only for the purposes of, for the extensibility service, if someone wanted to remove this or prepend something in front of it, in their deployment, they could certainly do that. But either way, the whole point is that you're basically putting this code into your run method and you're modifying these lists as appropriate. So a couple of notes about actions very quickly. Actions have three major methods that you should be aware of. One is called scope, it's optional, and it's basically an init for whatever your feature is. And as a reminder, an action is like launch instance. So this just means that at the beginning of that cycle, is it going, what, is there anything that needs to be initialized? Dot allowed is sort of familiar for those of you that have done Python development or the Django development before, it's the same thing. It's basically saying, is we pass in some user in context information, is this user allowed to perform this action? If they're not, then the action is not shown for them. And then finally, of course, perform is actually performing the action itself, starting the workflow. One sort of advanced note on all of this is that any action that you fire off, it provides a promise back, a JavaScript promise, which is fairly important because this means that we can have fairly intelligent handling of completion of actions that you've performed, rather than just sort of saying, well, we came back from this action, so let's just reload the page. We don't know what to do. This provides mechanisms for us to more intelligently respond to what the user has done. I won't get into the details of that. How do I make details views? It's very similar. Now, let me show that details view. What you're looking at is there are four tabs with different content in them. That's represented by this kind of code where you say resource type dot details views dot append. We do this four times, we have four different views. Really, all you have to do is give it a name, give it an ID, and then point it to an AngularJS template that you're deploying somewhere. It's quite simple. Similarly, with drawer views, these expanded views within a table, you can say set a drawer template URL. It's just saying use this template to describe the content or to present the content that is here. At the very bottom, I don't know if you can read it terribly well, but this is an example of an entire drawer template. You can see that what we're doing is we're using this HZ resource property list. This is one of the widgets that has been developed that facilitates the use of the registry. In this case, it's saying let's use this widget. We're going to be using OS Notice Server, so this is an instance. Fetch some information from the registry about this so that we can display these properties which are then listed and grouped below. The result of that is you get four columns with properly formatted data in them. It's very simple. That's all you'd have to do to make a drawer. File-wise, you end up, this is a suggestion. You can structure your JavaScript however you want, but we found that it's useful to, of course, put most of your configuration in the module, file itself, so my resource.module, and then in actions and detail subdirectories, put your actions and your details in there. In addition to that, with the actions, we actually suggest you put all of your action registrations in the actions.js or module.js file as well, just so that it's sort of easy to reference. Then steps are more for like if you have workflow steps and you want to separate them from other work. I'm not going to do this right now, but how to make a basic panel, just go through steps I talked about. Register your actions, register columns in a list function, along with some filters for your columns, add a panel that routes to the common Angular ngView template, and then you're done, and then you just go to see that work. And then this is just an outline. I'm not going to get into great detail because there's great detail on the widgets and how they're related to one another. I think if you're curious about the widgets, I would look at this chart and start browsing around because for the most part, you can just take the highest level widget and apply whatever it is, the configuration it needs, and it will create all the sub-widgets within it. So best not to get too worried about that right now, and that concludes my portion. Cindy, you will have a demo for us? Great, thanks. Okay, so I'm going to show a demo to help reiterate everything that Ty and Matt have talked about. So let's first take a look at some source code before we start doing our customization. So we're going to take a look at the images panel. So let's look at the code for that. So it's stored under OpenStack dashboard, static folder, app, core, images. This is important to put all your Angular content under the static folder in order for it to be picked up by Django. So we have three files that we're going to look at for the images panel. These three are the key files. So let's take a look at the images module first. So in here, this is where we register all our information, and as Matt said, the registry is the backbone of all your Angular development. It's where you store all the information that you need to build your UIs, and the registry you can inject into any module and access it and make any modifications you want to it. It provides a single point of access, so when you write a plugin, you can grab it and then change whatever you want to it. So if we look at this code, in here we inject the registry on line 56, and then we also inject the resource type, which is the heat name, so it would be OS, glance images, and this is a constant up here. So we defined that up here. And like Matt said, we use the registry to retrieve the heat type and then we get all the information. So in this file, we set all the information that we can retrieve later. So in here, if you scroll down, you can set your name, you can set URL to the detail drawer, and if you scroll down, you can see we've set all our table columns. So here's a list. It makes it very easy to create a new table, and here we have a list of filter facets as well. So let's look at our next file. This is the actions file. And in here, we do the same thing. We inject the registry and the resource type, as well as all these action services, which we will use. These are all in the different files. If you look under images actions, all the service behavior is in here. So we won't look at that. So once again, registry.get resource type, we insert the heat name, and then we can access the item actions object and append all our actions to it. So we have these item actions are the row actions for each item, and we have five actions here. We have launch, create volume, edit image, update metadata. And for global actions, we have one item, create image, and for batch action, we have one item, delete image. So now let's take a look at the UI. So this is what it looks like. We have our columns that we defined that are generated, just based on our schema, as well as we have one global action, one batch action. We have some item actions here. We have our detailed drawer, if we open these up. And also we have details view. If you click on the image name, this is our detail view. We just have one, the overview page. So now let's take a look at our plugin. So take a mental snapshot of what the table looks like now, because we're going to customize it now. So let's stop our server right now and take a look at a script that I wrote to do all this for us. So I already get cloned this plugin repo, which you can find here. We have a link at the end of the presentation. You can download this and try it out in your own environment to see how it works. And it has all the instructions over here. So what we do is we get cloned the repo and then we tar up the plugin and we copy the enabled file into our OpenStack dashboard. This is the point of contact between the dashboard and the outside world. And it'll register the plugin, which is read up at startup. Then on this line, we pip install the package tar and then we start our server. So if things go well, the package tar file will be installed in the virtual environment. So let's open that up first to make sure that it's not already in there because we're doing a live demo. So we don't want that. So the package is called demo. And sure enough, it's not here. So let's fingers crossed everyone. So let's run that. Okay. So if anyone paid close attention, the package is now installed here. So let's open that up. So inside here, we follow the same file structure as we do in OpenStack dashboard. So we have static app core images. And these are new files. So let's open those up first. So we're going to take a look at demo.module. So let's first take a look. Let's step back and kind of cover the things that Matt and Ty talked about. So in here, we inject the things we need. So once again, we inject our registry service here as well as the resource type. And the run method block will execute after all these modules are loaded and the dependencies are resolved. So in the run module, you can think of it as a main method. So we passed in the registry and the image resource type. We access the registry and we print it to the console so we can take a look at it later. And then let's add a new column. So we're going to create a new column and then append it to the registry. So we made our own custom template, which is just a plain text in the color orange to honor Halloween, which is just around the corner. And so we add a new column. We also add a new detail view. So we access the registry's details view and we append another detail view. So we have a template to a new detail file. So let's open that up. So in here, we just have another text in orange, which just says happy Halloween. And we also override the summary drawer template. So let's take a look at that. So the drawer template is the little box that opens up if you click on a row. So in here, we just have peekaboo. Okay. Lastly, we add a new global action. So we call this one surprise service and we also injected this service up here. And we define the service. So I didn't quite follow the proper way, which you should actually put your services in an action folder, but this is just a small demo. So this is our service, which we defined. And we so each service you have to define a allowed function and a perform function. So allowed makes sure all the promises are filled before executing the perform, which was which would just be to open up the modal. So in allowed, you can also do policy and permission checks to make sure that the user is allowed to perform this action. And in perform, it'll just open the modal. And you can also use the schema form that I mentioned to create your form very easily. You just have to define it as a JSON and it'll generate the form for you. Okay. So we've tried this all out. So let's check out our newly applied plugin. Okay. So let's refresh my heart. So we're looking for anything in orange as a confirmation that this works. Yay. So it worked. We added a new table column called it's just a repeat of this column, but it's an orange. We also added new. We overrode the details drawer view. And we also added another detail view. So in addition to overview, we added another view called happy Halloween. And we added another global action. So if we click on surprise, we just have some blank boilerplate code. I was going to put some something crazy in there, but I don't want to scare people. So that is about it for the demo. So let's go back to the presentation. So this is just a small list of a recap and best practices. So the Angular images table is default since this release and it's set to true in the Angular features dictionary object in settings up P Y. And if you want to revert it back to the previous Django images panel, you can, but there's you should have no reason to do that. You should also from from this release on, you should use a registry for defining your panel. It gives you a lot of extension points. However, you can still define it as an HTML template if you want complete control of all the like little things in your table or you want to make it crazy or you don't even want to use a table. You can you can still use the HTML template, but registry makes things very easy to use. And also don't forget to put all your Angular content under the static folder. So looking forward, we would like to add more extension points, including adding it to the schema form so that you can create a form or you can extend an existing form very easily. We'd also like to be able to change the, what was the second? Okay, sorry. Okay, I forgot we were, we also wanted to be able to modify the behavior after we've already never mind. Okay, so this is a list of resources that we covered. So our, the demo for this, this session is here. So if you want to take a look at that downloaded, try it out yourself. This is a good starting point. We also have a lot of plug-in documentation written by Ty. So check that out. And it's very easy to use now. And this is our contact information. You can find us on IRC channel via these IRC handles. And we also have a meeting every week at this. Okay, so thank you for coming, everyone. This concludes our session. If you have any questions, please go to the microphone and ask us.


like, can you see me, Tracy? I think everyone that the woman between us and our drinks today is named Tracy Evans. No pressure here. As the week and the event developed, a slot came free and the organizers asked if we had anything else that we could contribute. I'd already been planning on showing you what I showed you this morning. And Tracy was supposed to be here, but we were practicing operational risk mitigation by sending me to be quarantined with the fish and chips. And she can stay home in the comfort of her lovely home. And so here I am. Tracy said, yes, she did have an idea. And just give me a moment to think about it. And she's actually come up with a completely brand new presentation that I have never seen before. This is an absolute premiere. And she's done it especially for this event. So I think that's pretty exciting. And she's done it in the last two days. So thank you for that, Tracy. And I showed you some really practical aspects of how we approach building strategically relevant, accurate, compelling communication, and how you can use the same thinking to do it yourself. Tracy is going to talk about the other side of how we got to working like we do, which is we have pretty strong feelings about culture and about ethics and about feeding into clarity from a perspective of honesty and transparency. So Tracy, I'm going to let you take it away. You have up to 45 minutes if you need it. So everyone, my business partner and the other partner at Open Strategy Partners, Tracy Evans. Hi, Tracy. I'm partner Jam. We founded Open Strategy Partners about 2 and 1 half years ago together and with patients. Well, I learned how to navigate to systems here. OSP about 2 and 1 half years ago. And OSP was born out of some conversations and strong ideas about communication, which has now become our communication model, which underpins essentially everything that we do. And it's called authentic communication. And it's based on the three omens that you see on the screen, empathy, clarity, and trust. And so naturally, I gravitate towards any material and books and blog posts, any videos written on any of these two topics. And when I was at home over Christmas, I came across a book that ended up inspiring this talk. And that book was written by Canada's former Governor General David Johnson. And it's called Trust, 20 Ways to Build a Better Country. And in this book, he implores us to see that trust is actually gained through our actions and decisions on our doing and not merely saying on the basis that can be observed and measured rationally to quote the book. And he wants us to basically explore the different attitudes, habits, and approaches that make people, businesses, organizations, and countries trustworthy. And so in this talk, I'd like to actually share with you 10 practical tips to mindfully build trust into your communications. And I'd like to make the argument that if we put actions like these at the core of how we communicate, we could build better connections, better businesses, and better communities. So why does trust matter? Well, these days, there's been, especially in the last couple of years, there's a trend towards more and more people making values-based decisions, including and especially around things like where they work, where they contribute their time and their effort and their money, and then definitely to what tools and services they use or support. And when I was doing a little reading and a little research on this subject, you might have in mind that this is just really pertaining only to millennials and the younger generation. But the research shows that this is increasing across all generations, that people are making more values-based decisions in everything that they do and everything that they contribute to. And while there's a lot of easy examples that might come to mind, where people make values-based decisions based on their moral values, I'd like to share an example of one that is close to an example from our work that is based on business values rather than just moral values. And the example that I thought of for us is our use of the project management tool, ASANA. Basically, ASANA evokes a lot of trust for me and for my team members. And I trust the operations of my company, so the operational health of my company, in ASANA. And the design of the user experience that they've put into their product evokes the trust that they've designed for a smooth workflow that my team will feel comfortable and engaged using it, unlike for me, just writing it, unlike Giro, which feels, looks, and acts very clunky to me. And so that gets in the way of me engaging with it and using it, which is a core part of the value of the tool. And in another aspect, the training materials and the content that ASANA puts out there not only enables me to do better project management, but because I have a really very full view of their knowledge and best practices on project management, I can see and trust that they align with my ideas of project management. And I can trust that they've built that into the UX of their product. So that being said, and that example being shared, I'd like to argue that trust is one of the most important or always underlying values that influences people's choice. And for people to engage with your company, your project, or your product, they need to connect with you. And to do that, they need trust. So when we ask ourselves what is trust, the very basic Oxford English Dictionary definition is that it's a firm belief in a reliability truth for ability of someone or something. But it's actually a lot more complex than that. And trust is one of those things that's often overlooked. But it's an extremely important thrown on, and it's one that's worth deeper consideration in your strategic thinking and when you're building all of your communications. And one of the models that I really like that talks about trust, I looked at a few different ones. And there's some great ones out there in terms of trust in personal relationships. But in terms of trust in the business sphere, I'm really glad to see in Kobe's trust model, I think that you can really, I think you can easily see how this might come across in everything that you communicate and everything, all of the assets and the touch points that you have as an organization that you put out there. I think that you could probably take a look at this and see how this really resonates. And I like how he's broken it down to both character and competence. And I think that these things are equally important in terms of the way that people either consciously or unconsciously build trust with your grant. For example, that Asana example, I had never thought about until today until I ended to think of an example of this presentation. It's not something that I consciously thought about, but the transparency that they have with things like their pricing model or transparency around and sharing of their project management practices is definitely something that unconsciously played an impact in my view of that. And so I think we come back to when we think about trust, the things that might go through our mind are things like, you know, can you actually, can you solve my problem? And can you solve it better than any of the alternatives? And this goes to everything that's there under capabilities. And for me, I definitely, when I look at any technologies that we use as an organization, I want to see that their business model is fair, transparent, and competitive. So there's the number of software companies out there that choose not to list their pricing, for example. And it always gives me a very negative feeling. And I assume that it's going to be. And I would rather see that they give me a starting point and that it's transparent, that I know that I'm getting the same pricing as the rest of the market. And the third question that I think that people tend to ask themselves are, do the organization's values align with mine? Moral values, business values, and technical values, which practices that we're using and things like that. So I thought that this model was really helpful to frame our thinking. And I want to talk about just a couple. I just wanted to sort of paint a picture of the different domains where we really need to think about trust. And so for me, there's definitely different cues and different hands that you see in the support and interaction, how accessible you are via Slack or the way that you interact with your clients. Your training, how available it's, well, it's done. And technical documentation, there's a lot of various cues in there. But the two that I really want to focus on today are your product communications and editorial communications. So product being things like product pages on your website, data sheets, demo presentations, and that sort of material.  So those are the two that I'd like to focus on and start sharing my 10 ways to build more trust. So the first one that I want to talk about is accurate always. This was one of the very first conversations I think that I had with Jim about his ideas around authentic communication and how important it is to be technically accurate in everything that we do. And the way that, for example, the way that we go about doing that is to interview the experts, to interview the technical person who knows the topic and to get that information verified. And that's something that, even if you're applying these internally for yourself, this is where you can encourage your marketing team or your marketing person to make sure that they're interviewing or sitting down or having a work review with a technical expert. And on the other side, it's encouraging your technical experts to contribute their time and really connect with the marketing team and support them to make sure that your materials go out there with technical accuracy. So this is probably, it's number one in the list and probably one of the most important tips. The way is to be precise in your language and absolutely avoid hyperbole at all costs in the clients and companies that work with their, often their target, their audience is developers and developers are especially allergic to hyperbuzzwords and hyperbole. And a good practice that actually makes for better communication is just be more precise in the language that you're using. So the way number three is to have tight writing. So making sure that all of the writing that you do is crisp and sharp and focused, making sure that it is clutter-free and it doesn't have any extraneous words or sentences or paragraphs. And this is something that, for me, for myself as a non-technical consumer of technical information, whether I'm thinking about using a piece of software or engaging some of our clients, I get lost very fast when there's extraneous information. Some of the topics are difficult enough to track on their own and so to keep it crisp and sharp and only include the essential information to make your point means that it's going to resonate that much stronger with your audience. And this is one that I feel personally very strongly about when I'm consuming technical information. To have a clear narrative structure, this one is similar to the tight writing principle and it's something that I also feel really strongly about when I'm reading, especially blog posts, this applies particularly well to blog posts. If there is no clear narrative structure, it has a similar impact to the extraneous information. I just get lost. And some of these technical topics are difficult to deal with on their own that if you don't have a clear narrative structure, it can be really difficult for your audience to follow and actually helps to make the point that you're trying to get across. Point number five, similar point, you need easy to navigate informational structure. So this is keeping the number of pages and the flow of pages on your website easy to navigate and easy to understand where people need to go to find information. It also pertains to things like e-books or any other longer material to make sure that it's really easy to navigate the information. Point number six is a strong logical rigor and definitely be wary of those logical fallacies. We have created something that we use internally so far and have shared with a couple of clients called our Rigger's Guide. And we've created an additional special chapter just on this topic of logical rigor because it's something that I think is it can be quite challenging or easy to fall into certain traps. And it's one of the most important points to keep things clear. Hey, Tracy. I was telling people about our intention to share even more of what we do. And so I'm just going to jump in here for one second. We're in the middle of relaunching our website. And we haven't figured out the exact style yet. We think maybe like the GitLab company handbook. These writer's guides and these principles and stuff, we've documented an awful lot of it so that we can onboard new writers and new team members. And we are going to have that all available online in the reasonably near future. Depends on like, especially if somebody's clamoring for it, that would really help me get it out faster. But we consider this something else that will be really important and good to share and enable other people to help us do it better, but also just communicate better in general. Yeah. And I've got here, and I wanted to share a couple of the examples from our writer's guide of some of the logical fallacies that we can easily fall into. And the first one is over-generalization. And that's where the writer faces the argument on insufficient evidence, where the writer draws a larger conclusion than what the evidence supports. So for example, if you're claiming that Drupal is a better CMS, you've actually got to do a fairly exhaustive comparison with very objective standards and unbiased results to be able to make that thing. And you'd have to share your whole process with the reader and be fully transparent about that if you wanted to make a claim like that. What would be better is if you shared the specific use cases where Drupal was a better CMS as a better choice. For you, right? For you, yeah. Exactly. So that's one example. Another example that I kind of like is the non-tech order, where it doesn't follow. And that's where the writer's conclusion is not necessarily a logical result of the facts. So for example, stating that because Drupal has more functions, that it's a better CMS than WordPress. But obviously, more does not equal better. That isn't logical. So that's a trap that I'm sure we can come up with a better example for. But anyways, those are two examples to share for this particular point, moving on to point number seven. I think worth drawing out on make mindful claims. So avoid binary claims. Things like good or bad or absolute claims, which is like best or worst. And actually, just respect the nuance in the situations where your product may not be the best and the competition may not be terrible or bad. Again, it goes back to coming up with specific use cases where your product has a lengthy, very good fit for the user this time. So back up your claims with MMM. And we've got two types of evidence or two main categories of evidence. We've got quantitative evidence, which is things like statistics or any other research. It's things like case studies with quantifiable outcomes. But what can also be valuable is qualitative evidence and things like expert claims or testimonials, even anecdotal stories or examples are great pieces of evidence. And other things like case studies with more qualitative outcomes rather than quantitative ones. And I think even to some degree, referencing your technical documentation can be really great evidence in some circumstances. And what you want to think about when you're choosing what kind of evidence to provide, things that indicate quality or if you can answer, is it valid? Is it relevant? And is it unique like within the article? And ask yourself, does the evidence directly connect with a cause and effect relationship to the claim that you're trying to make? And it's absolutely OK to make claims without evidence, especially when we're quoting somebody else. So for example, it's absolutely OK to say, by working together, we make something greater than the sum of its parts. So that's more of an emotional claim, which is also acceptable. Number nine, speak from or reference an authoritative voice. This, I think that a lot of people do this really well already, especially in the Drupal community. If you're writing a blog post quoting or interviewing or referencing another expert, it helps build a lot of trust. Around a particular topic, and number 10. So recognizing and acknowledging others, they're recognizing their expertise and their knowledge, recognizing their contributions, and recognizing the competitive offerings can also help build a lot of trust. And this point also goes back to one of the original conversations that I had with JANBA authoritative communication and making sure that you're being very intentional about recognizing and acknowledging the expertise and the work of others. So that was point number 10. And I would like to make the argument that if we take all of these types of actions, these add more, that we'll be able to build more trust. And more trust equals more connection. And that will be better for our businesses and better for our communities overall. Pictures that I found on a splash. And so I can share all of the buildings here at the end of the presentation. See, and that's building trust, giving credit where credit is due, right? Exactly. Hey, so nice presentation, Tracy. Thank you. Thank you. I like the contrast between the sort of mechanical pseudo-scientific stuff that I showed this morning and the art and what goes into then turning that into words that are the most effective, right? All of that goes into then choosing how we say the things that we've determined to be relevant and important, right? Yeah, yeah. I'd love to hear. I don't know if it's a great format for this, but I'd love to hear any input examples, feedback, or even just to pose the question, is this something that you think about either when you're creating your own materials or when you're consuming materials from other companies? I'd love to put that out into the room, if it's a format that works. Tim, you wanted to put your hand up? Well, Finn, I have a question for you. You operate within a collective and work for a lot of public bodies and people and organizations who want to make the world a better place. Does this resonate with you? Absolutely. Yeah. Yeah. I mean, it resonates with everything. I find it particularly interesting to think about. Can you hear him? No. OK, hold on. Sorry. Sorry to put you on the spot there. Can you hear me now? Can you hear me now? OK, good. No, I think it definitely resonates. I found it particularly interesting looking at the different domains, thinking through the domains of your communications and where trust comes in. Obviously, you mentioned support and training and then going into the product communications or editorial. But thinking at every level, how is what I'm communicating actually portraying the trust that I need to build? And am I being absolutely true, correct? And I think I'm going to go back over your slides if you'll share them and just think about those 10 things and take it back to the rest of my team and indeed people that we work with. Yeah, I think that's crucial. I love the idea of sharing what we do. We're open source by nature and open sharing and sharing better ways to do things, better ways to communicate, builds us as a community, builds us as individuals and helps our clients. And I think that's great. Cool. Thank you very much. Thank you, Finn. Thank you. All right. Anyone else? It's the end of a long day here. Everyone needs a beer. I'd really be good. Enjoy your beer. So I'm totally happy to share those slides with you, Finn. I have them on my machine. So are you here this weekend as well? Yeah. I'm just going to shoot out a PDF out of the two presentations from today and then anybody who wants them, I'm totally happy to send them. And Tracy, thank you so much. That was really, really awesome that you put that together and it really captures some things that we haven't talked about in public before. So thanks for putting in that effort. It was definitely worth it.