How to be a writer in a world of structured content
•
1 gefällt mir•524 views
It’s a weird time to be a writer. Titles, paragraphs, pages and chapters are now being taken apart and processed into supposedly meaningful chunks of information, ready to be served in several channels. The industry requires us as content creators and editors to be able to fit our writing prowess into a structured content skeleton, and even to build one entirely from scratch. Fabrizio Ferri Benedetti lived that transition from unstructured to COPE content himself. Let him tell you of his experience and how he came to enjoy it.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (11)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
How to be a writer in a world of structured content
- 1. How to be a writer in a world of structured content Lessons learned at
- 3. How do writers cope with COPE?
- 4. This is me
- 6. 128 million unique users every month
- 8. The Goal
- 9. Mind = Blow
- 10. “Guys, we must de-blob” ©Columbia Pictures (1989)
- 11. “Jesse, we must do strategy” ©High Bridge Entertainment (2008)
- 12. Our quest for structure Yeah, that’s me with a knight hoodie.
- 13. The Heroes
- 14. The WYSIWYG
- 15. The pool of Write n’ Forget
- 16. The hall of standards
- 17. The first steps…
- 20. Hacking through
- 21. Resistance!
- 22. Luckily, we had the “Generator”
- 24. The envy factor
- 26. API as a translator
- 27. A brand new CMS
- 28. What did we learn? ©Village Roadshow Pictures (1999)
- 29. “Show me the money”©TriStar Pictures (1996)
- 30. Empower the writers ©Filmation (1983)
- 31. Alpha tools smooth transition ©MGM (1968)
- 32. Train & test
- 33. Writers can COPE ©Twentieth Century Fox (1986)
- 35. @remoquete
Hinweis der Redaktion
- First of all, I’d like to thank you Noz and Elodie for giving me an opportunity of being here today and share my experiences. I am here to learn. From all of you. I don’t know if this is a first for Spaniards at Congility, but I am pretty sure we are few –despite Noz and Ray live there. Also, I am also here to tell you a story. The story of how the company I work for started its transition from unstructured to structured content. The story of how the writers, the authors of this website, led this change, broke out from their silo and started mingling with developers and other people inside this 400 strong company.
- Do you recognize the movie? Yep. That’s the writer from the movie Her. A guy who writes. Today I am going to talk about writers. The people that produce content that goes online. Not technical writers specifically; just writers… AUTHORS! They could be your customers. They could be your coworkers. It could be you. The kind of writers I am going to talk about are journalists, copywriters, good old editors. These people have been on the Internet for quite a time now. If lucky, they have read Ginny Reddish book, “Writing for the web”, and read about SEO and usability. For most of them, that’s about it. They don’t know about structured content. They don’t know about XML, nor DITA, not even HTML sometimes. Say “reusability” and they’ll think about recycling stuff from a bin. These writers exist. Because writing is a difficult endeavor, and the technical part is not always part of the job.
- So, this is the question I would like to answer today. How does a team of web writers survive the transition from unstructured to structured content? You must pardon the pun here… COPE stands for Create Once, Publish Everywhere. For some, this acronym is the future of content distribution. I believe it is. I believe that’s the way. I think we all share that view. Content created once… and published in several channels. But how? And what do writers have to do with this? Well, a lot.
- Let me introduce myself first. This is me. Yep. The software doctor. I write. I do that for a living. I have been writing on the web since 2003. In blogs, mostly. Now I do it for quite a big media company, Softonic, where I am an editor and content strategist. I also organize a meetup in Barcelona, CSBCN. We are already 130 people strong. Barcelona is a lovely city, so if you ever want to go, text me and I’ll invite you over for a beer.
- Barcelona! Again. This is our current HQ. In 2008 we were 100, and it took one floor only. Now we are 350 in Barcelona alone, on six floors. Six floors. Six silos? No, more. We have more than 50 writers (journalists) on staff, writing articles and reviews in ten languages every day. We don’t do tech comm. We are a media company. We write articles, but also tutorials, and those have structure. Each team used to write independently and have their own standards. When we moved toward a common strategy, that’s when the fun began.
- As you can see, Softonic is a download portal, much like CNET. It’s one of the go-to places to search and download software. 128 million unique users every month. That’s a lot. We are one of the Top 40 Internet properties. We have been a software portal for almost ten years, and in Spanish mostly. Then we started adding languages. The first were DE and EN. Others followed. And we started blogging. Unstructured, too.
- So far, we have been successful thanks to a mix of passion and SEO and knowledge. But we never really stopped and thought about what the reader cared about and in what order. Some reviews lacked essentials parts, other have an overabundance of information. Content wasn’t structured consistently. And for a time we did not worry excessively about that. But then we ought to. Why, you may ask?
- Because of COPE. Because we wanted to go mobile. To go on the desktop. We realized that we could not keep being dependent on organic traffic alone. We needed other channels. So we built an API to be used by our partners. We filled our brains with COPE, structured content and reusability. But we needed structured content first. And that content was to be created by the writers.
- This was our first reaction when we started investigating about structured content in the Editorial department. Remember: Spain. Lovely Mediterranean country. Barcelona, only recently a tech hub. No structured content tradition. Plus: a media company. Guess what? We writers didn’t have the faintest idea about what it was all about. We just knew it was important. That without structured content we could not survive. We did know, however, that our competitors were doing fantastic things on several channels.
- So we had to “deblob” our content, but as Jeff (Eaton) said once, there’s no magic-bullet for it. For de-blogging I mean taking our beautiful unstructured mess and find patterns inside it… and then split into meaningful chunks. You don’t just wake up and tell your writers to write information in chunks, right? You need a plan. And knowledge. And tools.
- Programmers were ready and eager to help, but they needed instructions; we could not provide those instructions without sorting out our content problems first. We immediately realized that the task was ours first, with some of us trying to fill the gap between the technical staff and the editorial staff. In other words, content strategists. Writers in our case. It could have been developers, but then again, they weren’t really into content strategy. I think it takes a special kind of writers and a special kind of developer to break the silo and work together. Or just a different mindset.
- So, as I said, one day we decided it was important to go the structured way. This is when the story begin to unfold. We had a goal. We had more or less an idea of where the dragon was. But we were poorly equipped for the task. Nevertheless, we dashed forward.
- EVERY QUEST HAS A PARTY OF HEROES. We just did not know how to do it. So the first thing we did was to form a team of volunteers composed primarily by writers. Here they are. My fellow writers. We were eager to do it. No technical background. All tech journalists. We wanted the writers to participate in the project from the very beginning. We did have a champion already, but the champion needed a small maniple of valiant soldiers.
- What were the obstacles? Every quest has obstacles… We knew we had THREE BIG TRIALS. THE WYSIWG DRAGON! First of all, we are visual. We care about format. It’s the way we are. We want to see the finished piece online, with its typography and images and animations of panda bears. Our generation of writers can’t do that: we want to see the result immediately and click the magic “Publish” button. Myabe It’s vanity. Even today, AT SOFTONIC we are still struggling with getting formatting out of our heads. In the first drafts of our content types, there were a lot of references concerning how stuff should have looked. When we switched to structured content in Softonic we were constantly struggling with the templates. The 1:1 correspondence of the CMS form with each part of the template was hard to forget. We had to literally rip apart our beloved CMS in our brains before starting to go structured. It’s the 1:1 form-template trap, a love-hate relationship.
- Second: we don’t think about the maintenance and curation of the content. This behavior belongs to the old printer mentality: I print the book and then I throw it away. In a digital world, this WRITE AND FORGET behavior lead to many, many problems. We focus on just one channel at a time and its requirements. The web template becomes our sheet of paper. We say we love freedom, but then we seek the comfort of an HMTL cage in which we pour our words. THE RESULT IS A CURATION HELL In Softonic we have some 300k unique pieces of content that haven’t been touched since their publication. The problem with having them unstructured is that most updates must be done manually to check that everything is still consistent and legible.
- As I said before, we started as a Spanish-only website. It’s still is our main market, albeit by a small margin. Then we added languages. Now we publish content in ten different languages. Until two years ago, each language of our site had a dedicated content team that used the same CMS, but wrote with different styles and using different structures. When we switched to a different, more global workflow, our styles clashed in every conceivable aspect. Fun time.
- How did we tackle all this mess? Well, we started with meetings. With lessons. The first step was to explain what structured content was about. We started reading a lot. Many of the sources were from you guys. There is nothing in Spanish about this. Almost nothing. We resorted to metaphors, like Lego pieces… and cellular components. Cells. This may sound childish to some of you, but picture this SC virgin land… Yeah? It was not easy. Writers tend to think about their work as a flowing mess of words and images, and modularity is not the sort of mental model they expect to use when writing.
- We dabbled with content attributes. We tried to find patterns in our content. How can we decompose the reviews? What types of content did we have? That’s part of our WebCMS. Home-made. Made without Structured Content in mind. In 2009. The CMS influenced our thinking, and made us define attributes that were connected to the forms. Some attributes were too broad, others were desires that weren’t grounded on data. Did we need a “Source code field”? Our efforts were constantly marred by the presence of the CMS and the product in our everyday’s work. So we had to put a lot of emphasis on not taking the current WebCMS as a reference. We blinded ourselves.
- This is how we split work. We decided to work in sprints, like Agile teams. In Softonic all the development teams work like this. We wanted to accelerate, and we thought that the sprints were a good idea. Sprints work through iteration and small improvements… At the same time, we split work. One team was in charge of defining a certain set of attributes. Another had the task to define the new taxonomy. Then the guidelines regarding the voice and tone and stileguide of the content. And the templates, mock-ups, stuff we could show. It was a very indie, horizontal process. We tore the silos *inside* our team first. We broke the conventions that were in place between languages. That part was essentials for us. To work as one, global team.
- After some effort, a unique model began to form, loosely connected to what already existed. It is a very basic system of content attributes in an Excel sheet. Excel for everything. The universal tool for Content Strategy. We did not use DITA nor any other tagging systems, but we did devised our own set of custom tags to be applied to the existing content. Why? I’d say mostly because we did not need the degree of detail and complexity that XML is able to provide. But I say this after we begun. Truth is: we didn’t know much about DITA nor SC done with XML. We looked for a system easy enough to be applied in our current CMS and easy to parse at the same time. It’s not the optimal solution, I reckon, but it has served well so far. We did not have time enough for anything deeper than that. We worked alone. For a number of reasons, ranging from resources issues to silos, we did not receive support from the developers. To be honest, we didn’t even know if this was going to be accepted. Because the idea had to be pitched. But who else but writers? We wanted to achieve the software guide status. We were going to be the superstars, right?
- Then her our heroes PRESENTED THE WORK. We pitched it to Product Owners. People who in charge of each channel, and yet not participating in this process. They understood why were doing what we were doing, though. They just weren’t much enthusiast. They just wanted something that’d work easily with their products. The others writers weren’t thrilled. The idea of writing tags in every piece of new content was received coldly. And it was criticized as a waste of time by some, because it did not lead to any visible advantage, it seemed arbitrary and did not have a single hint of flexibility. Coming from above like a rock, the first modelling draft looked like some sort of table of the law divinely enforced upon us all. Writers don’t like that. They understand style and language conventions, but anything else is like chaining thoughts to a metal grid. WHAT DID WE DO TO DISSOLVE THIS RESISTANCE?
- Tools. Writers love tools. They love their word processors. Their text editors. You name it. Writers want their typewriters. Something they can use to save time, be it a CMS or a pen… or this. This is why I created, with the help of a colleague, a simple offline editor where the editors could write their reviews like in a CMS form. It’s just an HTML page with some JavaScript in it. On the left you can see the new fields of our new content types, structured the way we want. On the left, the tagged code, ready to be pasted in the OLD CMS. This tool saved the project. A ten hour effort saved the project. Because writers weren’t going to add tags to the text manually, nope. On the other hand, we did not have dedicated development resources yet (there was no team in charge of the CMS). So we had to hack this. We wen’t around the silo. And I’d say the writers were happy with that. And yet, it wasn’t the simplest tool to use.
- That tool wasn’t the only thing that helped get through, of course. We had to tell the other writers why we did it, what were the attributes, what was the model. So before anything else, before going online with a new CMS –which was way overdue anyway- we trained the editors. We had training sessions where we presented the models. We provided a cheatsheet with the attributes and their tags, and we presented the tool at the same time. The training consisted in the adaptation of existing content to the new model and in the writing of new content from scratch. Feedback was gathered that allowed us to fix the model before going green. Some didn’t like some of the limitations. Others suggested changes in the order of the attributes. So it was both a training and feedback session. It was way more useful perhaps as a feedback tool.
- Then there’s the envy factor. Another thing that helped was benchmarking competitors. Envy is a powerful driving force for writers, because they want their content look cool, they want a top-notch CMS and they want to have it all ready and easy. When they saw successful examples of modelled and reused content in the competitors websites, they felt much more motivated and compelled when it came to provide feedback and embrace the new model. Seeing the results of competitors doing COPE was a huge incentive. If others did it, then we also ought to do the same. Simple, right?
- One year and a half we finally got a team of developers for the CMS. They faced a lot of initial troubles. The existing CMS is spaghetti code. It was not cost-efficient to refactor such a beast. So the developers had to come up with something new, from scratch, that would have been backward compatible with the old content. Maybe, if we had an XML advocate inside the company, we would have done different. But I’m not so sure about that. So our developers created an API that use JSON to provide data to our channels.
- As you can see, when the API is queried, all the structured data is provided in the form of JSON output. This is what you get when you query the API for a program review. See? Beautiful JSON output, ready to be used in any channel. You don’t have to store XML or any other custom tags in the database. The API acts as a translator in order to provide the content to all the channels. Developers love this approach. They consider JSON to be lighter and easier to manage.
- Toward the end of our quest, we also got our “Grail”… we finally received sufficient technical resources and the developers started to work on a new CMS, which is still under development. This is what the new CMS looks like. Again: writers love tools. As you can see, it is way more advanced than the Generator I made with my colleague… This CMS follows the content type and attributes the writers defined. What we don’t see here is the impressive work that it had to be done in the backend. Another thing we don’t see here is that writers participated in the creation of the CMS. This is the first CMS shaped according to the needs and requirements of the writers. Not on the need of any other particular stakeholder.
- It took two years to get to a point where we have a beta version of a new CMS and a backend ready to manage structured content. All the content modelling work was done by the writers, and I think this is quite a feat. It is an achievement we are proud of to date. We learned some good stuff along the way. Once the quest ended, those were our thoughts.
- First: you should show the benefits of structured content at the very beginning, and keep showing them at all times. It’s a motivational thing, especially when you deal with writers. Show the benefits of structured content to the writers with actual examples, avoid abstractions. APPEAL TO THEIR PRIDE. Writers have to be convinced of the benefits.
- Second: empower the writers. If you have staff that pour content on a WebCMS or any other CMS, make them feel important. Form a small team of champions taken from the pool of writers that will defend the transition to structured content. COS WRITERS CAN BE THE MOST CRITICAL BUNCH OF THE COMPANY, YOU WANT THEM ON YOUR SIDE.
- Third: give them tools. Writers need to get their hands on something they can use, even if they are mockups, even if they are alpha versions. Provide tools for easy migration / editing of the content as soon as possible, make writers feel comfortable with the process. The sooner the writers have something to play with, the smoother will be the transition when the time is ripe.
- Fourth: do a test with a sample of your content. Organize training sessions. Explain. Do talks. Evangelize. Writers must get used to the model and be allowed to suggest tweaks. Get feedback along the whole process, even after. Feedback was another thing that we couldn’t do without.
- The conclusion is this: Writers can cope. Writers can be both the main characters and the best supporters of the content drama. We went from no-structure to a structure, although not a perfect one. Writers were essentials to achieve this. Writers survived. The next step, thanks to JSON, will be to go from structure to an OPEN structure, and get rid of the rigidity of the current model.