 I'm going to introduce myself and Ed, but he stole that, which messes up my whole rhythm. So where was I going to start? So we want to talk a little bit about how we're using some open source tools to solve a few big content problems that our company is facing using structured authoring. So content wants to be free. I think this is probably an accurate representation of what our content used to be like. Total free for all, chaos unstructured, you never know where things are going to land. So when we talk about what content wants to be free, we have a certain, a different way of thinking about that. So what we realized before is that our content might have been free flowing, but it wasn't free. We were able to use it the way we want, and freedom for us took on a different meaning. If we wanted our content to be free, we really needed to impose structure on it so that our content could be used, so that it could be not just limited to consumption, but that it could be brought in by different groups of people, used in different ways. We have a wide variety of user groups that it needs to be applicable for. So for us, our idea of freedom now is to impose some structure that's going to allow this different approach to content use. And I'm just going to make a note that we'll be sending the slides out later. Some of them are a little text heavy. I know that. And hopefully, if you look at them later, you'll be able to go through and reference and tie back to some of the things we're talking about. So to kind of accomplish this, we all love to talk about tools. Well, not everyone does, but I'm a tool guy, and I love to talk about tools, so you guys are going to have to listen to me for just a minute or two. So what we're working with for our set of tools is Enterprise Media Wiki. Some of you probably know what Media Wiki is. Some probably don't. It's an open source tool. It allows you to create a really nice editing interface. Oh, we're already moving ahead. It allows you to create an interesting interface where you can edit content or you can display it for your users. So it serves two purposes. It stores all of your content in a database. That's what Media Wiki is. It's popularly known because of Wikipedia, which everyone's heard of. Huge. You know, this is the background platform running it. When you change to Enterprise Media Wiki, what that really means is you're adding in a couple of different extensions that add some functionality to Media Wiki and are going to allow you to do different things. And these are the extensions that we are using that we consider key for our data. We have cargo. Cargo is an extension that allows us to be really specific. It lets us slice up our content and store it in a database in ways that we can query later and reuse in different ways. We have page forms. Page forms is a way for us to hammer into our writers that when you're creating content, there's a certain type of structure we want to impose and we want you to really follow some guidelines that we're presenting for our writers. I talked before that we have a lot of different content creators. Not everyone who creates content for us is a technical writer. We have a lot of marketing people. We have a lot of people who are maybe managers or other content experts we want to contribute. And so visual editor is something that's going to kind of cut through the difficulty in creating content. It provides a way for them to have a really nice visual interface when they're creating content. MintyDocs is key for us. Like a lot of other writers, I assume, we have to work on some different factors, some different, we have to have access control for some of our content. We have to have the ability to version content, to manage content, to group content in different ways. And MintyDocs is what kind of lets us assemble things, bring them together in different ways. So this is a really useful tool for us. And above it all is a nice coat of paint. We have a tweaky skin that changes media wiki so that it doesn't look like what you might have seen on other sites, which can be quite honestly pretty rough. This is a nice way to visualize and to make it very dynamic in the display of how we're putting all this content together. So when you take media wiki and then you add all of these other tools, that's what really enterprise media wiki is kind of about. And it's about making media wiki more useful for technical writers, I think, for other enterprises who might want to display content in different ways. Some of these pieces will come back up. This is our tool kit, but we don't want to think about it just like a tool kit. We also kind of think about it as a set of ingredients. And that might seem weird, a set of ingredients, a recipe. What are you going to do with it? That leaves to the next question. And Barry, what can you do with it? So with the different media wiki projects, we've been integrating the content with different groups around the company, which is great. We're expanding a footprint, we're trying to shift our group to become not just a content authoring group, but a service provider for content that other groups author. We don't directly author it, but we just build the pipelines that we understand the content, and we understand the top-level metadata, we make it all work together. And when you're talking to other people, what does media wiki do? It's a little difficult sometimes, because it does whatever, kind of whatever you want it to do, it's a set of ingredients you use to then make something. So I've been using the metaphor of a bag of flour, and that seems to help people understand. Like you've got to build something to fit the needs of the content, not the other way around. You don't fit the content to fit the tool, you just build the tool around your content. So you've got to, defining your data structure, something that's going to hit through the whole presentation. It's sort of key, understanding what you want from your content. So the software doesn't really do anything for you out of the box, right? It doesn't solve your content problems. You have to. I think probably everyone has seen that, not necessarily in tech-com tools, but just in information technology in general, there's a lot of, buy a software solution, spend a lot of money, and then hope it just does all the work for you, and you don't have headcount dedicated to managing that content, or structuring it, or whatever. The software doesn't really do anything. You need human beings to involve, or it doesn't really, in our opinion, it doesn't really work. So anyways, the challenge is deciding what you want from your content. And we're going to talk a little bit later about a couple of our major use cases, and you'll see the difference between when you know what you want versus when you don't know what you want, and how projects can be successful, depending on that, your answer to that question. I guess this is a layout of how we're using Enterprise MediaWiki in Genesis right now. So we have a mix of content sites that we directly own. So our public technical documentation sites, as well as the Genesis use cases portal. It's one of our case studies we'll talk about later. So on one side we have content sites that we do own, and we sort of manage and offer that content directly in MediaWiki. But then there's content sites that we don't own. And this is an aspect of Enterprise MediaWiki that I think has a lot of potential for the future, for content management in organizations. So there's websites owned by other groups that they query Enterprise MediaWiki to pull in content at runtime based on basically content as a web service. Or headless CMS is another metaphor people use. But the point is that we can control some content as a single source of truth repository, but other parts of the organization can own their own websites. They have their own tools that they love. But they can pull in certain values, certain paragraphs, whatever, certain chunks that they need in their content, the rest of it they own, but we don't have to own it. So instead of having a site that we have to own the entire publishing tool chain up to the variety of publishing outputs, we just have a hub they can go to query the content. It works. Then there's also a lot of our API documentation is Docsis Code. I think the WTT organization has a lot of experience with that. So we have a lot of contents already stored in the source code, but we can pull that into Enterprise MediaWiki so you can add that database layer to the content that with a lot of the Docsis Code pipelines go up to static sites, there's no database. So it's kind of a limit what you can do with the content. So if you want to take it to the next level and start doing some things you can't do with the static site, you can use the same source code in the repository but you can pull that into cargo basically and then have that available for any of the other websites in your company, in your system. So we're in a nutshell with the content, I guess we're trying to think of ways to describe it. Content is data or content in a database way. So it's basically all your content is stored as structured fields and database tables. There's key value pairs. I don't know, there's so many metaphors you can use for it but all stored in a database so that you can then query that database. So all the content is built via query, not maps, that makes sense. The two key aspects I think of a content as a database approach to content is you have centralized control of the data structure. There's different user roles in this kind of a system and you can think on that later slide we'll break that down a little bit but that centralized control of the data structure means you can you can impose a lot of sanity on your content. We'll hopefully we'll show some examples of that after. And then there's dynamic automated content publishing. Everything is query driven so you you make a small change somewhere to your canonical data and the data structure and it propagates automatically through the entire system through the authoring portal through the displays through any website that pulls the content in via REST API you have true control and single source of truth of content where it makes sense to do that. So I guess we're gonna talk quickly about two case studies because in theory some of this sounds good and in theory some of this probably sounds familiar from other tools and platforms but I guess for us what really is illustrated is we had two different case studies that were kind of opposites. The first one is our Genesis docs our own technical documentation where we had been using MediaWiki but we didn't have a lot of freedom we didn't have free content it was difficult to really reuse it to move it around to share it because we had a lot of content we had tools we even had some of the tools and tool chains that we needed but we hadn't structured our content and until we were able to impose some structure on our content that made it really difficult for us to reuse. So we knew our requirements because this is our own content we knew it really well we knew what some of the problems were we wanted but we just hadn't gotten to the place where we were able to use it. Our other case study that we want to talk about afterwards is the Genesis use cases portal that Barry's mentioned earlier and a use case for us is essentially a kind of a sellable item is something that is put together and you know they had the opposite problem from us where they have really well defined data structures available to them but they've been enforcing them through processes through the tools that we're using and so there were a lot of challenges for us to see if you know their challenges that they were having to work through these processes that weren't really sustainable that were difficult to kind of impose on their writers we found it was a really a good match for the tool set that we had and really a good way for us to combine our knowledge of what they had for understanding data structures what we had for understanding some of the tools and I think when we go over them Barry will show you in more detail how that kind of worked out so I guess we'll start on the next slide with the Genesis docs this case study and I'm gonna go over this quickly and I think I'm gonna pass the presentation over to Barry for the second case study so what you see here is kind of a screenshot and this is showing where we need to be because previously we had content that we would write and it would look like this but it wasn't really structured we weren't able to break out and understand what we wanted to do and so what we decided is that we need to really we wanna build an epo-based documentation every page is page one we wanna have certain elements that are defined on every article every single page that we create and so that was really our starting point it's defining an article defining the key pieces of content that we need and trying to understand how those key pieces of content will be reused not just on the pages here but in other locations so this is one thing that we wanted to understand the second part is underneath once we've established what our page is we have sections of content and they tend to follow the same types of patterns there are a couple of different patterns but they would often follow the same patterns these structured sections underneath and so this is an example of what we wanted our content to look like for an end user for someone coming to our portal and being able to read it I'm just gonna mention over here we also have a note this is even though the content is structured this is a part of Mindy Docs here where we are kind of imposing structure over a set of articles and so this isn't directly related to the structure we impose on the specific content but it's helping us to also create some structure at a larger level so that's what the table of content section is here is a series of articles if we go to the next slide so this is actually the same content but what you can see is earlier on that previous page you know the user sees that there is just a nice little Epo heading explaining where they are and what content they have but this is what the writer sees when the writer comes in and they go to edit the page they would get a nice form and again back to the tools this is using page forms this is creating these forms where we create some very specific fields we define how content can be entered and so all of the specific pieces of information were broken out and defined and there's various pieces of information some of them get translated and they turn into images some of them are key contextual statements that we want to apply to the page so that people know where they are some of them are just maybe in the table of contents you want it to appear differently then you want it to appear when you're actually viewing the page so all of this content at the start this is where we really want it to begin we want all of the writer to understand this is one article and then underneath there's additional information so when we go to the next slide we're actually going to just kind of compress that so that we can get to the real meat of the content that the writer is providing at this point really we're again creating sets of sections that are repeatable so you can have multiple different sections you can choose when you want to create new sections you can move them around dragging and dropping and within each section there's specific types of information you want about the alignment the headings the actual content and supporting text which was really in a lot of cases of the bulk all of this information is being stored when you save the page in individual fields that are all tied together based on the forms that we enter so this is really the authoring view and for us this is understanding how we could break our content up and this effort to really define the structure that's what we're missing and that's what we're working towards now we're really trying to make sure that when we have these sections that we're able to create structures that are reusable that are efficient and that makes sense for our content so if we go to the next slide so we showed you first what it looks like for an end user then I showed you what it looks like for someone who's actually writing the content this is what it looks like behind the scenes so we said with cargo when we store content it just all gets thrown into a database and this is basically how the content is stored you're seeing it all of this is going to be queryable later so that top section where we define the article and the EPO information all of that is right here and it's available to be queried you can use that to bring back sets of pages to arrange pages in different ways you can do whatever you want just like any database query with the information here and then underneath here's an example of one of the sections it's got the type, it's got the alignment it's got all the same information that we saw earlier but this is how it's stored and this is what makes it so powerful for us is that even though it's a really easy to use editing editing interface even though we try to make it so that anyone can work with our content this is what's going to allow the architects to really pull together content in interesting ways afterwards then reuse it so skip ahead one more slide now I mentioned earlier there was a table of contents on the side and so we've talked a little bit about how content is stored and how it's edited this is really kind of a tool for us that stitches a lot of things together it was our screwdriver in the image because it helps me piece together different things and what Minty Docs provides for us as part of our tool chain it gives a lot of value to how we make our content accessible who we make it accessible to it gives us content management tools that allows us to quickly publish content to copy from one version to another to work with content in different ways it allows us to define multiple versions we can work with and it also works here with the table of contents that are dynamically built in some cases or in some cases you can define them yourself and you can adjust how content is being entered in view and so this is another piece of our tool and if we go to the next slide Docs' code has a lot of really great forward progress and we really like Docs' code but we found that the output is not depending on your tool chain the output that we were getting wasn't as flexible and as reusable as we want so we built a pipeline like many people our tools are stored and you can see our tool chain and what we expect, how we have our content work the key thing that I want to point out here is that it's very easy for us to bring this content into Media Wiki so previously it might have gone to a different output it might have gone to a different format type but all of the tools that we have in Media Wiki and in Cargo as well both have APIs we can use to bring content directly in so once we have a Docs' code process established getting our content from here into structured content that's queryable is not a difficult process you can see an example based on that tool chain that we have this would be another table of contents where we have different types of articles and this is the API that we're working with we have some content that is generated the markdown file from our Docs' code we have all of this way of output that brings content back in but for us the other key thing is that using this tool chain it makes it very easy for us to add articles wherever we need to to improve our content to add custom value that wouldn't be gotten easily just with a simple Docs' code approach so I think that's probably some of the key points for us about what we really want it yeah if we go to the next slide I think that we go to the next slide I would just say just something about the Docs' code so our company split across a few product lines so some of our underlying APIs get manifested in different actually different documentation sets so one of the issues one of the things we want to be able to support is the stuff that belongs in the source code can live in the source code you can publish it up to that one particular implementation of using that API but there may be differences in how a given platform uses the API so the supporting material, the tutorials and all that it would be difficult to get that in the common source which needs to live in like three completely separate platforms so you can add a layer of information directly in MediaWiki or MintyDocs whatever on top of it but it's in the same table of content so for the user, for the information experience they just go to their book and they have a mix of content coming from different sources some of it is written online by the author the writers that are dedicated to that particular platform but the underlying contents may be coming from the source code, right? so that flexibility is useful and that's a key point about the view like the view for the user because it's really about trying to provide them with the best view into our content everything on one spot so for us we looked at that whole set of tool chains and we said this is really what did provide a lot of value for us we took Docs's code that we were working with and we really turned it into content as data and then that allowed us to just provide a lot more flexibility in how that's presented and I think that's probably the last slide for this portion oh no, ha ha sorry my apologies it changes it to content as data but I think the key point was once the content that we've pulled in is available to us as data there are many different ways we can slice and dice there's many different ways we can display that in some cases we add pop-ups that you can quickly get we can do a quick call, we can see where they need content from the API and we can pull that out so there's little snippets of information available to them we were able to convert very quickly entire sections of code into standalone FAQs that could be provided to customers for different reasons because it's easy for us once the content is in a data format it's easy to restructure it and it also allowed us a lot of flexibility about creating different portal pages automating how our content was generated because again you can decide how you want to break it up where you want to break it up you can report on it in different ways this way so once we have the structure defined once we have the content into that structure and it's available to us to query as data that just gave us all of the flexibility that we really wanted so we'll see if this is the last slide oh it is all right all right so the other case study is the Genesis use cases it's really difficult to talk about the use cases use case without sort of circular language but so Genesis use cases are I guess they're solutions really so there are things that's that there's about a hundred of them or so and they're pretty beefy pieces of content that the field so the sales organization uses to try to tell so Genesis software by the way it's very customizable very flexible fairly complicated sort of try to streamline everything again because Genesis itself is kind of a bag of flour in some respects right so try to streamline that they try to be able to like this is what this is what the software can do there's about a hundred or so things that boiled down this is what the software can do so there's the team that was put together to build all that content and we don't offer that content as a writing group we don't offer that content what we have set ourselves up as is a service organization to help that team manage their content and I think one of the the key reasons the project's successful is they had a really clear understanding of their data structure so they they already had a data structure they were trying to manage their data structure in tools that don't support structured data we had unstructured data in tools that do support structured data it was great to actually cut our teeth on a project that they already had the the data structure so we could just oh awesome we can make it work now we know exactly how the hard work was already done in my opinion that's the hard work is defining the data structure the rest is work but it's more fun I guess right um yeah so there's a description of some of that there um this is sort of a layout of this this project so we built a uh a portal that everyone goes to um all I guess it's mostly product managers and professional services are mostly the author sometimes the offer management team that's who handles the use case information they'll have you know they'll convene key stakeholders in a in an office somewhere for a week and they bang out the use cases there's a lot of business decisions that go into the content there right so they're they're the they're the subject matter experts and they do the authoring and we build the pipelines for them to to do that authoring um uh it's something I want to show uh a demo of so yeah it's okay I got it right here so the uh an individual use case uh has about 50 different fields say right and I'm going to try to show how how the life cycle of one of these fields so I'm going to talk about the benefits so the benefits were unstructured loosely structured data in their old system which they tried to uh impose some order on using process but once the offer management team understood the uh you know the power of the software they realized we could you know the business can if we get the right people together that can decide what are the benefits the benefits are you know um for any every use case has you know four or five benefits say so those are like business outcomes that you know a a use case is going to help you improve your customer experience what they realize is that working with working with marketing if they set if they decided what the benefit like a canonical set of what the benefits are they can define that and then that can cascade through the whole system so this is where an administrator at the administrative level uh they decide what the benefits are that can then be applied to a use case and then cascade to the system so our role was to set up the this is a a page that only administrators can get to that they use to define the top level meta data right so we don't define this data we provide the tools to let the team that owns this data define that data and that's uh sales and marketing and whoever else so um so this is where you would go to so they set a uh they set a code for a benefit which is which can't be changed and then they set a title for the benefit which can't be changed and this is now available to the system so when an author goes to their form view for you know filling the information for the use case they select their benefit from a pre-existing list if an administrator decides they want to change the the wording for uh improve conversion rates or something else they do it here it'll cascade through the whole system through the authoring view through all the displays and through all the external sites that are pulling this data so this is an administrator view that's a user role and then this would be the author view so somebody is they're working on a particular use case ceo one they can only select the business approved list of use case but then they can add you know a little bit of custom information that goes along with it both of those are stored in uh cargo fields that can then be queried for anybody else who needs that information this is a view with the author see to actually this is you know how they actually change their as you can see it printed here again this will uh you know if you change the wording for improved customer experience at the at that first administrator form it'll change here as well and once that content is stored in cargo that way you can query it and you can do things like build this kind of a portal page that allows a customer to find a use case that they need based on a benefit right so if they want to look for improve customer experience they can do a query behind the scenes all the content that you see is query generated some of it is like it shows statically on a page so it looks like just regular content you read but actually behind the scenes there's a query that's pulling whatever field it wants just we whatever field we want to display on the page we choose those this is a portal page that just lets you interact with that queries you pass a parameter to the query and then it will spit out the content so in this case it lets you drill down into the use cases by selecting a benefit I think when as this project matures there isn't going to be a way to go to a master list of all use cases and then customers will select a particular use case it's not how the business wants to present use cases they want to control how people find information so you have to you have to kind of go through a few steps first what do you want to do and you have to answer a few you have to go through a few layers before sort of narrow it down because they don't really want people necessarily choosing a lot of card we want to guide that experience which we can do so we don't have to have a minty docs book with all use cases we could we could hide that but in any case this is that this is the same view and again this text here is that's the you know approved business language and this is the specific language to support that benefit that authors have added so that's one field like I said the use cases have about 50 fields and once the content is built in this way requests come up so just a few weeks ago there was a request come up the maturity level of a use case this means I guess how business ready that use case is for for selling I'm being wrong on that but I think that's what it is they wanted to set up a bunch of books so we've set up some minty docs books that give you a view into the available mature the maturity level for all of the use cases so there's we built four books this is for one of our our platforms pure engage and you know it's really just tables that give you the results from one field that exists in the use case but this field is important enough that the business wants to have like a full doc that has these tables that are static they can create a PDF of it they can use that to disseminate the field and so on and just to understand like once the content it takes about it took a less than an afternoon to build these four or five books right so once the content's in there and you have to you have to build a new view into your 50 fields or so it's pretty straightforward right you just build a new doc set up your queries and you just select which ones you want if somebody wanted to add a new field to this page we just change the underlying query add a new field put it in a div or whatever a table and then we we can alter the the view so that's sort of covering a little bit what we've already talked about there alternate displays so this is an example of one oh what happened so this example of integration with our sales marketing group was building a new web portal for all their sales collateral so this is where salespeople to go to basically download their beautiful brochures and pdfs and whatnot that they use to go into the field and and make sales and there's a large part of that content is supports the genesis use cases right and the what you know how they've been managing this is somebody's job was to go to these old single source of truth for use cases copy the information paste in the pdf upload it into their tool I can't remember what the tool was but they would basically basically they just uploaded documents to a tool and it was always at a date and it was really business people whose job is to generate revenue we're spending a lot of their a lot of their days I think this is not unique to genesis or information technology in general a lot of people spend their time managing documents massaging documents copying content from one silo to another so this is a tool called seismic that has a they have a concept called live doc which is basically a PowerPoint generation tool that they can hook into different data sources and pull in uh content at runtime to build a pdf that so a salesperson wants pdf for a particular use case they have to go to their their portal click a button and then the pdf is generated but it pulls from our cargo data store on the fly right this is sort of an example I mean I don't have access to their tool so I had to take screenshots during the demo as much as I could show because that's another problem right as every team owns their own tools and getting licensing and access across the organization is is difficult but some of these other tools have you know they all have their everyone has their own api so you can you that single source of truth model it doesn't necessarily mean that our team has to own the single source of truth for all content there's sellable items for example which are stored in Salesforce and that's where they need to stay so we need to build api connector to Salesforce to pull that there's different kinds of single source of truth and we want you know I guess it's the web application to web application communication of content is what we think is really interesting in it seems like that's where things are going so the old you know publishing tool chain that publishes to a variety for an outputs that does not seem to be where the where where things are going when we're communicating with other groups when you start talking about rest api and web services for content they know exactly what you're talking about right when you start talking about can we take over your portal so we can publish have a single source of truth it's a non-starter it doesn't go anywhere right so the thing we really want to hit I mean there's you know we've been using media wiki for quite a few years and we're still learning a lot of detail about how you can how you can leverage it and there's you know there's business and political things we've learned but I think the key thing is the key takeaway is define your data structure the more you can define your data structure the more the more you can do with your content right I think that's it thanks so do we do a actually does anybody have any questions and if so we'll give you the mic so that it can go in the recording so question yeah you mentioned you built this tool that's used by sales people and you said they used to spend a lot of time doing this manually so did they love that tool or did you have to sell them on it what's been their response so the offer management team that owns the use case project is the one driving that integration so we're the service organization for them that they bring us into calls and so we're sort of like the technical backup that they do most of the the pushing and the selling of that right yeah they're pretty happy about it because they spend their time massaging documents right and anybody who gets that they can oh we it'll all just automatically pop up leave the whole thing they like that right it's it can make their life easier yeah up front there's work but this what's a big payout well the automation always has that theoretical payoff but apparently it's working yeah and I just want to expand on that by saying that you know I think it's a really big deal for us when we have content there are a lot of users who are helping us to create content and there's a lot of different roles like we we kind of outlined in some slides and glossed over a little bit but there are a lot of different roles about how how that content is created and so you know well you might have some people that are really defining the structures and other people that are you know filling in the the high level idea of how you want your content to be built and then there's other writers who are adding content um you know like there's a lot of different people all the way down the chain and for us it was really valuable we found within enterprise media what we we could accommodate people at a lot of different levels and so you know some of the sales people you know they needed assistance with defining data structures sorry not with defining because they already had a good definition they had they needed some assistance and like kind of implementing those data structures into the the content but once that was set up then it was really them off and running because you know all of those lower level of the content creation was that and yeah it's been a big time saver and I haven't heard anything but praise basically from if you years ago I had switched to did-up would this have all been possible through did-up or is there some reason why you're doing this in a in this particular way I don't I don't know every once in a while it looks we've never I've never really used when I used it a little bit like 10 plus years ago so I'm sure it's matured a lot since then but I've been looking to see if there so that's more like you build maps but I don't know if it's that same kind of query-based tools and I don't know if you can have that full flexibility of you know your you know your tiny little piece of data could be a content structure but a whole page could also be a content structure or a paragraph like you just you set up the way you want so I don't know and another aspect of it is there's some content in the system that is fine just let it be free text we don't need to structure it so you can build heavily structured content automation projects within your content and only for that content so it's like you avoid CMS overkill or something where you know if you have to put all your content into you know into something like dita because you you think you may have some reuse possibilities but it turns out that it's only 5% of your content that actually needs that reuse you kind of it's just too much you know so you can leave things be unstructured for some areas and then you can structure some areas so it's just you're very flexible right you know I just want to you had almost all the points I want to mention but I do want to say that as well I feel like with enterprise media wiki we we get a really good combination of tools that that work together very well and you know it's kind of like one package does does almost everything we need where and forgive me my like I haven't used dita for a while but my understanding is that if you're working in dita that's really one piece of your solution because you haven't dealt with presentation you haven't dealt with a lot of other really significant portions of how you're going to work with documentation and and for us this came together really nicely as a parcel that you know supported us in ways that that that you know there's a lot of different ways to do things I wouldn't fault anyone for for using dita but if you asked me you know a few years ago if we knew about this if we knew about dita you know how can we didn't how can we choose one over the other I think that the convenience of the the whole package makes us really appealing for us so is that fair yeah I yeah and uh headless cms tools like content folders there's a bunch now that are getting a lot of play that's that seems more appealing to me because it's about it's about apis and it's about web application to web application communication and sharing of content between web applications so that's where I would think is more that seems more interesting to me is the headless cms approach so we're going to switch tools it would probably be more towards that but that's also a bag of flour right I mean the headless cms they're really they're a developer tool right so if you're a developer and you want to build a website and you just you don't want to have to build it on top of a cms you build your website and you pull in the content by reference from content for whatever else which is similar so with this system you kind of have your cms but it also can act as a headless cms for other sites to pull from so it's kind of mixing the two is is what was what's happening yeah that scares me because it's a bag of flour that you don't even own so you're kind of I get a little nervous sometimes with these ones but all right that's yeah it would be very good other questions do you translate what's that do you translate content yes well not what I don't but we we we have vendors that translate our content yeah and does this make their lives better does it make your costs lower they don't like it very much they don't like a wiki markup essentially a lot of wiki markup is the way we and we didn't set up what we're supposed to so I mean wikipedia is like the largest the most translated content on the planet right and it's gone so but we're not really using the tools and I don't know where we set up the way that we should so the the the vendors are doing some you know they have some custom scripts to deal with the mix of wiki markup and and html and inline css and stuff like that but they work around that we've been using we've been using them for you know a number of years so we do translate yeah okay and the second question if you were to do this again what would you do just top one or two what would you do differently I would define my data structure absolutely you would spend like a month with key stakeholders figuring out what you want from your content before the horse leaves the barn because once it's gone it's hard to impose that structure afterwards yeah so we're out of position right now for various reasons the way the company's moving that we can we kind of have to start fresh and we want to take advantage and define our data structure which I think is no matter what tool chain you're using that's still the key probably what do you want to do with your content you know like if you're using data whatever a lot of folks don't have a data model they put on top of it you know that's just the plumbing what do you want your content to do and then maybe don't they maybe just take the default output for a bunch of tools and and think that's doing something for people and it really isn't right how long did it take for you to build this infrastructure and how many people do you have working on the tooling side of things well I mean we've got it extended in so many directions so we got a lot of people working on on media wiki but a lot of them are like ed who is an API writer who you know does it sort of part time we have a couple like full time people we have some other parts of our we didn't talk about here we have a contextual help system that has heavy development costs we have search applications that are customized yeah so the use case content structure probably six months 50% one person to build the data structure for that project it's important no use cases they had already defined the data structure before thank you so you know they had a good portion of the work done but the actual implementation I don't think is that costly I think it's more the preparation and understanding you know the buy-in that you're going to need from from the company when you move in the direction which is always challenging I'm interested in two things first of all can you just talk about the impact that this approach had on your writing team people that are actually writing the content and how they felt about it when it happened versus how that changed over time and then two if you looked at how the impact any kind of study on the impact this had on your user experience it's how how is it helping your readers or your your key audiences so studies now we don't we don't we don't have like statistics to show you know is the user experience better we have various feedback mechanisms built into the content I think that tends to be focused on the actual content right so we have I don't know that's a hard question to answer yeah you kind of have to make some assumptions right yeah yeah so speaking to the use case project in particular it's it's pretty successful because they had it was just a free for all for their content so having having their authors be guided in a friendly manner is very useful then for users it's hard to tell the appetite for reading the content the use case content is really high because it's it's a key description of how how Genesis operates from a content point of view the use case content is is like solution level documentation that spans across product silos so it's the kind of documentation that we've had a really hard time writing because our writers are embedded on product teams so we have a very narrow product focus and getting that subject matter expertise which is not from your development team but it's from a higher level from professional service and product management since they're the authors it's a huge improvement in our content because it gives us that layer now what we're doing is we're building automatic tagging of articles to connect to that use case content so that one of the every page is paid to one principle so you hit a page there's going to be a little marker to let you know what use cases does this article support which will take you link to that bump you up to that top level solution level you know description of what the software actually does which helps ground people in that layer of information that otherwise gets a little bit lost you know what either doesn't exist or it's just a link in a search result or so that like using that tagging right and using using the metadata of the data structure to drive users to those high value pages right that's what we're we're setting up so now that we have those pages we want like every single piece of content should should really clearly list what what use cases it belongs to and then bump them up because those use cases have really nice business flow diagrams explaining how it works from a business flow in our regular technical content we have a lot of flow diagrams that describe you know how a software method pings through the system it's always from the it's more it's very technical you know what I mean yeah I'm just I'm just going to mention that for us as well like you question the impact on the writers and for us this has been a process we we didn't arrive here we we got here sometimes stumbling a little bit sometimes making really good choices and not understanding how good they were when we made them I guess it's a mix of of different methods and so if we were to do things over again I think we would do things differently in some cases that would try to impact the writers less for us specifically like the transition from media wiki alone and then pushing into structured content with several new tools I mean that that did introduce and you know we are in the process of doing that we we only have a few writers that are still you know actively doing that for our content for who are you know kind of beta testing this as we're moving forward and so there is there definitely is an impact I think most of what I've seen is positive but I mean we like any process we're still working through that what I will say is part of what convinced us to move in this direction is we had a number of smaller projects initially that treated data as treated content as data for different reasons and so we had you know a huge configuration options guides that were just massive tomes that were very difficult to dig through that are all automated because we're treating that data as we're treating that content as data and we're making it very easy to access and we've had very positive feedback and results from that and we've had a couple of other like smaller scale examples of moving in this direction and they've always been very positive it was received so I don't know if that's something that's that's like what you're looking for but it's I think it's a very positive direction I think that you know learn from our mistakes and do better than us and define your data first and then move forward from there that's that's what I'm going to say so I think we have time for one more question from the floor and then Jessica Parsons is going to give a couple of announcements from Right to Docs and then we're good we have we have the room for another half hour so please after these couple of things feel free to mingle and ask your questions in more depth Michael you had a question or somebody else have a question did somebody else have a question out here okay you showed that screenshot of the alto cloud page how did that writer receive this new system per Paul's question is one of your first did we I don't know if we had alto cloud in there she was our very patient alpha tester right this page yeah so that's one thing though I think I get a challenge right where it's so flexible so you get feedback on things that don't work you just change it super great flexible somebody doesn't like how the form works you just change it but it also means that it's always changing and for some people they're like what do I do how do I do my job and they want it to just be exactly how it always was and where we're changing it all the time so for some folks they love that because they like to be on the edge and some people we got a lot of writers we got like 60 60 plus writers so some people it's it's too much change their head spinning that sounds really scary it doesn't you know the change is decreasing the rate of change is decreasing I think though as we stabilize but the ability to change has not decreased and our ability to adapt has not been effective so but yeah Dana's been a real champ to work through the struggles that we had initially when we're moving in this direction so yeah I think she likes it she loves it yeah I'm saying for the video hope I don't get in trouble all right well thank you everybody all right so yeah thank you