[Peninsula] "Structured Authoring to Set Your Content Free" at Genesys

introduce myself and and but he stole that which messes up my whole rhythm so where was it gonna 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 are companies facing using structured structured authoring so content wants to be free I think this is probably an accurate representation of where a content used to be like you know 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 that we have a certain way a different way of thinking about that so what we realized before is that you know our content might have been free flowing but it wasn't free we weren't able to use it the way we want and you know freedom for us took on a different meaning if we wanted our content to be for you we really need to impose structure on it so that our content could be used so it could be you know 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 kind of user groups that it needs to to be applicable for so for us you know our our idea of freedom now is to impose some structure that's gonna allow this different approach to content use and I'm just gonna make a note that we'll be sending the slides out later some of our little text heavy I know that and hopefully that people if you look at them later you'll be able to go through and reference and so to to kind of accomplish this you know 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 gonna have to listen to me for just a minute or two so what we're working with for 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 you know create a really nice your face already 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 sorts all of your content in a database that's what MediaWiki is popularly known because of wikipedia which everyone's heard of huge you know this is the 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 in the media wiki and are gonna 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 you later and reuse in different ways we have page forms you know 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 the difficulty in creating content it provides a way for them to have a really nice visual interface when they're creating content mintee Docs is key for us like a lot of other writers I assume we have to work on some different factors so 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 minty Docs 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 TWiki skin that changes MediaWiki so that doesn't look like what you might have seen on other sites which can be you know quite honestly pretty Ralph's 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 MediaWiki and then you add all of these other tools that's what really Enterprise MediaWiki is kind of a boat and it's about you know making MediaWiki more useful for technical writers I think for other enterprises who might want to display content indicators some of these pieces will come back up this is our toolkit but we don't want to think about it just like a toolkit we also kind of think about it as a set of ingredients and you know that might seem weird a set of ingredients of a recipe what are you gonna do with it you know and that that leads to the next question and Barry you know 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 while you were expanding a footprint were expand we're kind of 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 if 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 MediaWiki 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 bag of flour and that seems to help people understand like you 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 content so you got a defining your data structure something's gonna hit through the whole presentation it's sort of key understanding what you want from your content 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 techcom tools but just in information technology in general there's a lot of bias software solutions 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 isn't really do anything if you know you need you need human beings to involved or it doesn't really in our opinion doesn't really war right so anyways yeah the challenge is deciding what you want from your content and we're gonna 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 like 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 also our public technical documentation sites as well as the Genesis use cases portal it's one of our case that we'll talk about later so on one side we have content sites that we do own and we sort of manage an off of that content directly in new yorky but then there's content sites that we don't own and this is an aspect of enterprise media wiki that I think has a lot of potential for for the future for content management in organizations right so there's web sites owned by other groups that they query Enterprise media wiki to pull in content at runtime based on you know 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 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 and 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 Doc's is code I think the wtt organization has a lot of experience with that so we have you know a lot of contents already stored in the source code we can pull that into MediaWiki so you can add that database layer to the content that with a lot of the doctors code pipelines go up to static sites there's no database so they're kind of limit what you can do with the content so if you want I take it to the next levels or doing some some things you can't do with a static site you can 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 in your company in your system so in a nutshell with the content that we try to think of ways to describe it content as a data content as data or content in a database way so it's basically all your content is stored structured fields and database tables or there's their key value pairs I don't know whether 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 everything all the content is built via query not maps that make sense the two key aspects they think of a content as a database approach to content is a centralized control the data structure there's different user roles in this kind of a system and you can I think another later slide will break that down a little bit but that centralized control over the data structure means you can you can impose a lot of sanity on your content well hopefully we'll show some examples of that after and then there's a 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 into 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 you know because the in theory someone that sounds good in theory something this probably sounds familiar from other tools and platforms but I I guess for us what really is Illustrated is we had two different case studies there 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 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 you know we knew our requirements because our own content we knew it really well we do with some of the problems where we really want it but we just we 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 the barriers mentioned earlier and a use case for us is essentially a kind of a sellable item it's 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 had been enforcing them through process and so 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 you know our knowledge of what they had for understanding data structures what we had for understanding some of the tools and I think you know 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 Doc's 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 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 we weren't able to break out and understand what we wanted to do and so what we what we decide is that we need to really we want to build a people based documentation every pages page one we want to have certain elements that are defined on every article every single page that we create and so that's that was really our starting point it's defining an article defining the key pieces of content that we need and there's 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 you know once we've established what our pages we have sections of content and they 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 you know 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 going to mention over here we also have a note this is even though the content is structured this is a part of myndy Doc's 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 a just a nice little Ipoh 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 as you know using page forms as 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 there's various and pieces of information some of them get translated and they turn into images some of them are our key contextual statements that we want to apply to the page so that people know where they are some of them are just you know maybe in the table of contents you want it to appear differently than 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 to begin we want all of the writer to understand you know this is 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 where 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 you know the alignment the the headings the actual content and supporting text which you know is really in a lot of cases the bulk all of this information is being stored when you save the page in individual fields that are all tied together based on on the 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 were missing and that's what we're working towards now we're really trying to make sure that when we have these sections that were able to create structures that are reusable that are efficient and that 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 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 will be defined article and Ipoh 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 you can do whatever you want just like any database query with the information and then underneath here's an example of one of the sections it's got the type it's gonna Lyman it's got all the same information that we saw earlier but that's 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 your interface even though we try to make it so that anyone can work with our content this is what's gonna allow the architects to really pull together content in interesting ways afterwards then reuse it so one more slide now I mentioned earlier there was a table of contents on the side and that you know 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 to use a lot of things together you know as our screwdriver in the image because it helps me piece together different things and what minty Docs provides for us as part of you know our tool chain is it gives a lot of a lot of value to add to how we make our content accessible who we make it accessible to it gives us content management tools that allow 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 you know it also works here with the table of contents that are dynamically built in some cases or in some cases that you can be you can define them yourself and you can adjust how content is being entered so this is you know another piece of our tool and the next slide DOCSIS code has a lot of really great forward progress and we really like DOCSIS code but we we found that you know the output is not depending on your tool chain the output that we were getting wasn't as flexible as we usable as we want so we built a pipeline you know are like many people our tools are stored and get and get love and you can see you know 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 you know it's very easy for us to bringing this content into the wiki so you know previously it might have gone to a different output it might have gone to a different format type but all the tools we have in in MediaWiki and in cargo as well both have api's we can use to bring content directly in so once we have you know adaxes 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 code line 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 you know the the API that we're working with we have some content that is generated via you know the markdown file from our Docs is code we have all the spare output that you know 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 with me just so I think that's probably some of the key points for us but what we really want it yeah if we go to the next slide I think that I'll just say there's something about the Duchess code so I a company split a core across a few product lines so some of our underlying API is get manifested in different actually different documentation sets so one of the issues one of things we want to be able to support is you know the stuff that belongs in the source code can live in the source code you can publish it up to that you know 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 mint tea dogs whatever on top of it but it's in the same table of contents so from the user for the information experience they just go to there they just go to their book and they have a mix of content coming from different sources somebody's written online by the author the writers that are dead to that particular platform but the underlying contents may be coming from the source code right so that flexibility is that it's useful yeah and that's a key point about the view you like the view for the user cuz like it's really about trying to provide them with the best view into our content yeah so everything on one spot yeah so you know for us we looked at that whole set of tool chains and we said this is this is really what did provide a lot of value for us we took DOCSIS code that we were working with we really turned it into content as data and then that allowed us to to just provide a lot more flexibility and oh no sorry my apologies it it changes it to content it's data but I think the key point was once it's 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 had you know pop-ups that you can you know 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 you know little snippets of information available available to them we were able to convert very quickly entire sections of code into standalone FAQ so that could be provided to customers for different reasons because it's easy for us once the content is in 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 know 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 all of you know once 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 wanted all right all right so the other case study is the dentists use cases it's really difficult to talk about the use cases a use case without sort of circular language but so Genesis use cases are I guess there's 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 fields the sales organization uses to try to tell a so Genesis software whether it's like it's very customizable very flexible fairly complicated so to try to streamline everything again cuz Genesis itself is kind of a bag of flour in some respects right so streamlined that that try to be able to think this is what this is what the software can do there's about a hundred or so things I balled 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 author that content does a writing group we don't author that content well 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 successful is they had a really clear understanding of their data structure so they they already had a data structure and they were trying to manage their data structure in tools that don't support structured data we had unstructured data and tools that do support structured data it was great to actually cut our teeth on a project that they already have that they already had 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 and the rest is work but it's more final I guess yeah so there's a description of some of that there this is sort of a layout of this this project that we built they a portal that everyone goes to oh I guess it's mostly product managers and professional services are mostly the authors sometimes the author management team that's who handles that use case information they'll 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 there this there's a subject matter experts and they do the authoring and we build pipelines for them to to do that authoring it's something I want to show a demo of so that's okay I got it right here so the an individual use case has about 50 different fields say alright and I'm gonna try to show how the lifecycle of one of these fields so I'm gonna talk about the benefits so the benefits were unstructured loosely structured data in their old system which they tried to impose some order on using process but once the offer management team understood the you know the power of the software they realized we could so the business can if we get the right people together that can decide what are the benefits the benefits are you know friendly every use case has four or five benefits a so those are like business outcomes that you know a a use cases are gonna help you improve your customer experience but they realize is that working with working with marketing if they 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 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 page that only administrators can get to that they use to define the top level metadata right so we don't define this data we provide the tools to let the team that owns this data to find that data and sales and marketing and whoever else so so this is where you would go to so they set a they set a code for a benefit which it which can't be changed and then they set a title for the benefit which can be changed and this is now available to the system so when an author goes to their forum you 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 though the wording for improved conversion rate 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 right so this is an administrator view that's a user role and then this would be the author view so somebody is there 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 cargo fields it can then be queried for anybody else who needs that information this is a view that the authors see to actually this is you know how they actually change their you can see it printed here again this will you know if you change the wording for improved customer experience to get at that in 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 improved customer experience they can do a query behind-the-scenes all the content that you see is 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 fields it wants this 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 a 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 this so you have to kind of go through a few steps first what do you want to do and you have to answer a few cut you have to go through a few layers before sort of narrow it down they don't really want people necessarily choosing a lot card we want guide that experience which we can do so we don't have to have a mintue Doc's book with all use cases we could we could hide that in any case this is 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 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 wrong on that but I think that's what it is they wanted to set up a bunch of books so we set up some into Doc's 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 peer engage and you know it's really just tables that give you the result from one field that exists in the use case but this field is important enough that the business wants to have like a full dock that has these tables that are static they can create a PDF of it they can use that to disseminate to the fields and so on and just to understand like once the content it takes about it took up less than an afternoon to build these four or five books right so once the contents in there and you have to you have to build a new view into your fifty fields or so it's pretty straightforward right you just build a new dock set up your queries and you just select which ones you want if some of you 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 can alter the the view so that's sort of covering a little bit what we've already talked about they're alternate displays so this example of one a hook happen 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 sales people to go to basically download their beautiful brochures and PDFs and whatnot that they use to go to the field and and and make sales and there's a large part of that content is is supports the Genesis use cases right and the with 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 of it into their tool I can't really what the tool was but they would 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 it 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 content at runtime to build a PDF that so a sales person 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 exam and I don't have access to their tool so I had to take screenshots during the demo as much as I could show his that's another problem right is every every team owns their own tools and getting license he can access across an organization is it's difficult but some of these other tools have you know they all have their everyone has their own API so you can view 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 what 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 for web application communication of content is what we think is really interesting and it seems like that's where things are going so the old you know a 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 and when you start talking about REST API and web services for content they know exactly what you're talking about right we start talking about can we take off her you her portal so we can publish have a simple source of truth it's a non-starter doesn't go anywhere right so thing we really want to hit the way this you know we've been using meeting with you 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 the key thing is the key takeaway is to find your data structure the more you can define your data structure the more the more you can do with your content right actually does anybody have any questions and if so we'll give you the mic so that it can go on the recording so questions yeah you mentioned you built this tool that's used by salespeople 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 in 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 but they bring us into calls and so we're sort of like the technical backup that they do those two the the pushing and the selling of that right yeah they're pretty happy about it cuz they spend their time massaging documents right and anybody who gets that they can all it'll all just automatically populate the whole thing they like that right it's Meghan Victor life easier yeah upfront there's work but that's what's a big payout Wow the automation always has that theoretical payoff but apparently it's working yeah 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 kind of outlined in some slides and Gloucester we're a little bit but there are a lot of different rules 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 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 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 with enterprise media wiki 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 it they needed some assistance and like kind of implementing those data structures into the content but once that was set up and it was really them off and running because you know all of those lower levels of the content creation was that yeah it's been a big time saver and I haven't heard anything crazy if you uh years ago I had switched to did up with this have all been possible through did it or is there some reason why you're doing this in a in this particular way I don't I don't know everyone some why I looks we've never I've never really used I used it a little bit like ten plus years ago some shirts matured a lot since then but I've been looking to see if there was so that's more like you build Maps but I don't know if it's the 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 it could be a content structure but a whole page could also be a content structure or a paragraph like you did he 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 somewhere you know if you have to put all your content into you know into something like data because you you think you may have some reuse possibilities but it turns out that it's only 5% your content that actually needs that reuse you kind of old just too much you know so you can leave things be unstructured for some areas and then you constructor some areas it's just you're very flexible right yeah I just want to you get almost all the points I want to mention but I do want to say that as well I feel like with Enterprise MediaWiki we we get a really good combination of tools 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 it for a while but my understanding is that if you're working in did that's really one piece of your solution because you haven't dealt with presentation you haven't dealt with a lot they're really significant portions how you're gonna work with documentation and and for us this came together really nicely as a parcel that you know supported us in ways that that you know there's a lot of different ways to do things I wouldn't fault anyone for using data but if you asked me you know a few years ago if we knew about this we knew about did oh how could we didn't help can we chose one over the other I think feeling for us yeah yeah and headless CMS tools like content full 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 api's 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's something we're interesting to me is the headless CMS approach so we're gonna switch tools it would probably be more toward 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 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 flow whatever else which is similar so with this system you kind of have your CMS but it also can act as a head of the CMS for other sites to pull from so it's kind of mixing it to that scares me because it's a big a flower that you don't even know so you're kind of I get a little nervous sometimes with the other what these ones but all right that's yeah it would be very questions do you translate but that do you translate content yes well now I don't but 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 wiki markup especially a lot of wiki markup is the way we and we didn't set up we were supposed to so I mean Wikipedia is like the largest the most translated content on the planet right and it's got it so but we're not really using the tools and I don't know we've setup the way that we should so the vendors are doing some you know they have some custom scripts to deal with the mix of wiki markup and and that 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 write a 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 doesn't know what tool chain you're using that's still the key product what do you want to do with your content you know like if you're using did or whatever a lot of folks don't have a data model they put on top of it you know that 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 so 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 MediaWiki but a lot of them are like IDI 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 wood here we have a contextual help system that has heavy development cause we have search applications that are customized so yes so the use case content structure probably six months 50% one person to build the data structure for that project 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 gonna 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 study on the impact that's had on your user experience how how is it helping your readers or your your key audiences so studies now we don't we know 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 well that's a hard question to answer yeah you kind of have to make some assumptions right sure yes so speaking to the use case project in particular 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 it's a key description of how how Genesis operates from a Content point of view the use case content is is a solution level documentation that spans across product silos so it's the kind of documentation we've had a really hard time writing because our writers are embedded on product teams so we're very narrow product focus and getting that subject matter expertise which is not from your development team but it's from a higher level professional service of product management since they're the authors it's a huge improvement in our content as 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 that every page is paid to one principal so you hit a page they're gonna be a little marker to let you know what use cases is 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 either doesn't exist or it's just a link in a search result or so that like using that tagging right there using using the metadata 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 so the use cases have a really nice business flow diagrams explaining how it works from a business flow in our regular tech Euler content we have a lot of flow diagrams that describe you know how a software method pings to the system it's always from it's more it's very technical you know what I mean yeah I'm just I'm just gonna mention that for us as well like you question the impact on the writers and for us this has been a process 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 and I guess it's a mix 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 MediaWiki 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 only have a few writers that are still for our content who are you know kind of 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 directions we had a number of smaller projects initially the treated data as treated content as data for different reasons and so we had you know a huge configuration options guides that were just a massive tomes they were very difficult they're all automated because we're treating that data as as good we're treating that content is data and we're making it very easy to access and we've had very positive feedback 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 positively 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 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 write the 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 and more depth Michael you had 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 all the cloud in there she was a very patient alpha tester right yeah so that's one thing though I think I did 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 were if you just change it but it also means that it's always changing and for some people like what do I do how do we do my job and they want it to just be stacked Lee how it always was and what we're changing 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 write it like 60 60 plus writers so some people it's is too much change their heads spinning yeah 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 dan has been a real champ too to work through the struggles that we had initially when we're moving in this direction yeah she loves it yeah I'm saying for the video over like in trouble all right well thank you're ready all right so yeah thank you next days

Channel: Next Day Video

Views: 390

Rating: 5 out of 5

Keywords: wtd_sf, meetup_april_2019, documentation, EdJamer, BarryGrenon

Id: INr38MCQjeM

Length: 56min 15sec (3375 seconds)

Published: Thu Apr 11 2019