As anyone might guess from looking at the magazine’s last date of issue, my time as editor has been done for a while, but there’s been no announcement about it, and only recently have I come up with an exit plan that might help Textpattern decide what to do with the domain. I’d like to present the plan to the Textpattern community for consideration.
But first you need an explanation about why we (as a community) have come to this juncture with the magazine. It will concern those who have been in the Textpattern community since at least 2011, when the magazine was re-launched. Newer community arrivals may appreciate the lessons learned.
To be sure, I’m not exiting the role of editor-in-chief because I didn’t enjoy it, or because I got burnt out from the time (plenty of it) I invested into it. Nor is it because I didn’t believe the new magazine initiative had potential to bring visibility to the Textpattern project—it certainly did. After just two issues, for example, we had the attention of this writer at Smashing Magazine, who advocated to Smashing’s huge readership to keep an eye on our publication:
[T]his publication aims at providing the best publishing system conceived, discusses topics with the community, and features experts in the field. [It] also features topics that aren’t directly related to Textpattern, so even if you aren’t using the CMS, you might want to check the magazine as well.
That person clearly understood my vision regarding TXP Magazine’s purpose, and the article is proof that audience reach was happening. That made me happy. Despite not attaining our goals, I’m proud of what our “media team” accomplished. When I look at TXP Magazine now, sitting idle for two years, I’m still impressed by what I see and read. The presentation alone is better than that of most websites launched today. It’s not a cookie-cut repeat of the trendy pattern du jour, then or now. It’s a unique representation of exactly what we set out to create, right down to the advertisement art by Stephan Simonis—all-in-all a classy and professional reading experience. I might be biased.
No, the reason I’m exiting is due to something entirely different, something out of my control. It’s because despite my hope and ideas for the publication, they were misplaced in such a small community. My role as magazine editor was unnecessary, evident by the few article contributions I could get the Textpattern community to make.
I don’t blame you one bit. As everyone in the writing business will tell you, writing is hard. Good writing is harder. Having the patience, courage, and understanding to let someone edit your copy is harder still, especially if English isn’t your native language. I get it. You don’t want to go down that difficult road. But as the trite saying goes, therein lies the rub. There’s nothing to read and talk about if nobody is writing.
Maybe you’re wondering why I didn’t write more myself. After all, I am/was the editor, right? I could have written more. I’m full of ideas and opinion. I could have filled in all the columns of each issue on my own sweet time. But not only would that bore the crap out of you, it’s not the editor’s role to do all the writing. If I did all the writing, it wouldn’t be a magazine—nor a community effort—it would be a personal a blog. Destry’s Textpattern Diary.
The editor-in-chief of a magazine has many responsibilities, all geared to making sure the business of publishing happens. Wikipedia summarizes it nicely: “An editor-in-chief is a publication’s editorial leader, having final responsibility for all operations and policies.” That includes decisions with presentation and advertising as they pertain to the strategy of the publication. I lost some of that decisional power along the way (the first sign of trouble), which only compounded the contributions issue. Presentation and advertising mean absolutely nothing if magazine content is not published regularly.
Editors often write dedicated Editor’s columns too, which I did with TXP Magazine each issue. My quota was filled. It was a column I partly used to try and rally the troops—you—to no avail. But I pressed beyond the call of duty and wrote a number of other column articles too with the hope of getting the balls rolling, your ball bearings. Priming the inkwell, if you will. I also recruited column editors, like Ralitza Dilovska, Marie Poulin, and Kevin Potts; respected members in the community that had genuine concern for the project or a history of producing good content. I knew the extra keyboards would be essential.
By the fourth magazine issue, however, trouble in paradise was clear. Aside from the tremendous contributions from Stef Dawson, on top of his busy agenda as a Textpattern developer, and the initial efforts from column editors, the burden of writing was falling on me. I couldn’t let that happen. You wouldn’t want that to happen. So we stopped publishing until more contributions came in. They never came. I begged. I pleaded. I poked, prodded, and pushed. We made real-time adjustments with each magazine issue to scale the scope down, but it didn’t matter; we lost our momentum, column editors dropped away like flies, and article contributions dried up. And here we are today.
Correction, I did get offers from ghost writers; people with no knowledge of Textpattern whatsoever who were willing to come out of secrecy (perhaps with pseudonyms) and write any old fluff I told them to in exchange for link-backs and other self-serving requests. But I don’t deal with that crowd. As an editor, I have more scruples, and have higher hopes for the publications I’m responsible for. I wasn’t going to let the magazine become a content farm of listicles about nothing useful from nobodies. I stand by that.
I realise it’s hard to expect high quality and timeliness when you can’t pay writers for their efforts. But there was no budget for that, and I wasn’t paying writers out of my own pocket for Textpattern’s benefit. I wasn’t getting paid either. This was a community project as every Textpattern initiative is, despite not being a horse-by-committee affair. As such, I had hoped community folk—many of you quite knowledgeable of Textpattern’s nuances and capabilities from years of building Textpattern websites—would have come forward for the love of tool and clan, especially as I was providing free editing services to make your copy shine.
Frankly, a lot of designers could improve their writing. Developers, who often write for themselves, could too. Good writing is important for everyone in the digital age, and TXP Magazine was a great way for the designers and developers in this community to share what they know while brushing up on literary skills.
Alas, the editing team gave it a good shot, and I hope we had fun and learned from it.
In the time since the magazine has sat neglected, and my pride as an editor bruised along with it, I’ve come to realise that despite the promise of a magazine, the Textpattern community isn’t suited for one, certainly not the kind I had in mind. There are no writers, as of yet, to sustain a magazine, and the consuming audience isn’t big enough to turn that around. Original ideas like the Textpattern sites showcase, with accompanying interviews and tech profiles, and the theme design contests I hoped the magazine could sponsor, were off the charts of reality. Even the “issues” publishing model, which gave TXP Magazine a true magazine feel, was a challenge, unfortunately. It’s nobody’s fault. It’s just the way it is.
Reality demands something different. The community, if it needs anything at all (and maybe not), might benefit from something simpler. Something with less overhead, fewer editorial hoops, and a different audience scope. Something without need of a chief whip carrier too, though you can’t get rid of governance entirely, it’s important for quality control. Something back to the casual, open nature the magazine used to have, sharing a hodgepodge of information about Textpattern’s functional bits and bobs with no particular agenda, or whatever. And if we can broaden the magazine’s reach within the community by including non-English speakers instead of extending it outward from the community, then all the better.
My exit proposal, which assumes the domain won’t be retired, takes all of that into account and transitions TXP Magazine toward a new publishing direction. Let’s walk through it.
TXP Magazine International: A proposal
The plan began to emerge after a recent forum discussion with two people in Textpattern’s community who are not native-English speakers. Maybe you know them, their nicks are Sacripant and Milosevic. The idea began with the notion of relaxing the English-only publishing rule, which logically came from Textpattern’s policy of using English for official communication. Contributions from Textpattern’s many regional users could be cultivated by opening up the magazine to other languages. Apparently those segments of the Textpattern community are collectively greater in number than the English language segment alone, and are more interested in writing than their English-speaking counterparts too, according to the feedback I was getting, but the latter remains to be seen. Yet it’s a fair idea to consider, particularly as the non-English user segment lost a voice in the community when the forum and user documentation platforms stopped accommodating non-English dialogue. (Unfortunate, but sensible for overhead reasons). The magazine can be the new exception, giving non-English users an official channel to come together and share in a visible way.
The idea didn’t make sense at first because suggestions seemed to rely on translation efforts from one language to another. That would have made the editorial process more complicated, not easier. But then we recognized that by leaving translation out of it entirely, with a few exceptions for the static parts, the magazine would be a melting pot of regional languages for as many groups of readers. Such a model might succeed at achieving many things at once:
- Improve audience reach and Textpattern brand recognition (an original magazine objective)
- Encourage more article contributions (from the unrepresented segments of the community)
- Provide a means for international user interaction (since that element was removed elsewhere)
- Be more relaxed in workflow and writing quality, thus perhaps easier for people
- Make use of the txpmag.com domain in a satisfactory way (otherwise what happens?)
- Allows for my clean exit as editor-in-chief (which is happening anyway)
That’s a tidy sum of benefits, assuming the platform can be refactored to work, and the wave of contributing authors actually materialise. The former is probably doable; it’s software after all, just fix it. The latter is less certain, because as learned in this community many times before, building it doesn’t mean they will come. You’re expected to give feedback on this idea when you’re done reading.
An overview of the nuts and bolts will help set the stage, beginning with the most important part: content and audience.
Adjustments to magazine content and audience scope
The current incarnation of the magazine strived to reach people beyond (and including) the existing user community, offering vetted English articles that would attract web users in general, not just users of Textpattern alone. Some of the bigger ideas like the showcase and themes competitions were part of that thinking (which you may only now about if you read early issues of the magazine), but the main idea was that TXP Magazine could be a valuable web publication by itself, albeit with a Textpattern slant to some of the articles.
For the international transition, I propose we reel back on the audience reach, returning to the existing community of users, but specifically users in any language except English. That’s right, TXP Magazine would no longer publish English content, and no translations to English would be made for that platform. There are two good reasons for this.
First, which I’ve already mentioned, eliminating a translation step keeps editorial overhead down—way down—and this project needs to keep human resource demands as far down as it can because good human help is hard to come by (though it would be nice to have that help).
Second, plans are afoot to revamp the main Textpattern blog as a more open publishing system for English contributions from the community. It’s a great idea. So there’s no need to spread English writing efforts between two platforms. The magazine would serve international audiences, making them feel welcome and appreciated (because they are), and the blog will serve English language content specifically. A double win for Textpattern.
Content in the current magazine was designed as topics within subject columns. They had specific names, but essentially accounted for Textpattern tech, spotlights on noteworthy community people, opinions, and a wild card column for topic flexibility. Multiple articles—one per column or two max with some column variability—made up a given magazine issue. Within these columns, and notably the wild card, different topics could be addressed. From an IA standpoint, it worked well. From an article contribution standpoint against a reasonable publishing timeline, not so good. It relied on having several articles ready before an issue could go out, because a minimum number of articles in this case was needed for the ‘issues’ model to work.
Contributors to the international version of the magazine may like to adapt the issues architecture, or simplify it to a more linear, blog-like flow. Developers will appreciate the path of least resistance, of course.
That said, here’s one interesting idea for adapting the columns/issues model to make refactoring the architecture easier: Instead of columns representing different types of information, as they would with a single language, each might effectively be a wild card column (any topic goes), but dedicated to a given language that exists. A magazine issue would represent however many available articles there were at time of scheduled publication (a quarterly schedule might still be okay), but there should be no minimum (though at least one) or maximum limits per number of languages in a given issue. Odds that any maximum would be a huge amount are unlikely, thus not a concern.
Adjustments to editorial workflow
The current magazine operated by a typical editorial process. A spreadsheet was used to schedule article assignments, and I used Asana to dole out other team tasks. Then it was the usual: authoring, editorial review, revising, publishing. A round of technical review was in there too when engineering topics were involved, as well as final image embeds and so forth once the draft was ported to the CMS.
Article drafting took place in Google Drive because it made collaborative editing easy-peasy compared to such work in Textpattern (not one of its highlights, but few CMS systems do collaborative editing right anyway). Google Docs have since added many new editing features, such as “tracking” changes, which is standard in Numbers and Word, so it’s great for even the non-techy types familiar with corporate options. Plus there’s no need to email anything around. (Draft is another collaborative editing option with nearly the same abilities, though the UI is less intuitive by comparison.) Workflow is supported by draft templates and writing guidelines, as expected.
Altogether the process is not hard, but it does take a willingness by the team to adapt to the chosen way of doing things. It’s the Editor’s thankless role to see that everyone does, as much as possible. This all works fine for classic publishing scenarios, where a team is involved and the content quality aims high, but it’s probably overkill for the new idea I’m proposing.
The scenario for the international magazine would be different by necessity. There won’t be an editor-in-chief at the top coordinating everyone’s tasks and scheduling what gets written. Instead, there would be a simpler review process (recommended for quality control), or no copy review at all, which probably isn’t possible.
In the latter case, the most basic, a hopeful contributing author would simply create an account, thereby agreeing to the established terms of service (to be written), and draft away as a freelancer, or some other named role in the CMS with similar rights. Even in this base situation, someone or something with higher system rights would conduct a technical check of the draft for any missing meta fields and whatnot, then hit the “Let’s do this!” button against a sensible date, whether ‘now’ or in the future. And who would be responsible for the post edits that always need to be done? Somebody has to be, or the quality of the whole platform will quickly go from abbreviated to lazy to another utter embarrassment. You can see the potential problems in this approach.
A level up on quality control would be better. A “Staff Editor” for each language might work, someone who stewards the publishing for that language alone. Language editors would establish their respective editing/collaboration workflows, however they thought best. They might like a typical routine with bells and whistles to produce the best copy they can, or pass drafts back and forth as email novellas. Whatever.
Because quality control is important, editors should be candidates from the Textpattern community, or at least vouched for by someone who is. A recognized language editor should exist before any articles are submitted for that language since someone needs to be in place to receive contributions, verify their structure against required CMS fields, and publish articles live when the time comes. In fact, that might be the mechanism for creating new languages in the UI; it’s only done when a language editor steps up for the role, and they should produce the first article for their language at the same time, even if it’s the only one they ever write. That’s their ticket in.
While quality articles in a given language are encouraged—and should be a sense of accomplishment and pride for authors and language editors alike—only readers of that particular language would ever know if grammar and such was shoddy. Nobody outside of a given language, including Textpattern leadership, will be keeping an eye on that language’s articles, or tapping the brand’s English style guide. The whole thing is largely an editorial trust system policed by the readership of a given language.
Adjustments to magazine architecture
Developers would likely appreciate if the existing architecture could be reused as much as possible. Likewise, English content needs to be dealt with too.
So the first step would be to audit the magazine’s existing content—a relatively simple task since I thoroughly audited it once already and it’s now nice and tidy. Another quick once-over for this new initiative would be needed to cherry pick articles for potential re-publishing at the Textpattern blog. The rest would go on ice for another day, and redirects for everything would point to the magazine’s homepage. The end result is that no articles in English remain. No confusion for future non-English writers. A clean slate for new content.
Static docs, like terms of use, homepage blurbs, and so forth will need to be revised or written too, and perhaps that’s the only English content until those pieces can be translated. I’ll leave the specifics of that to developers. Any translation needs for static content would fall on the shoulders of the dedicated language editors.
Each language would have its own section where articles in that language stream. A standard presentation for all sections would be provided by default once the brand look and feel is completed by Textpattern’s designer, Phil Wareham. Depending on how fast things move along, the magazine’s current design is still lovely, and a few visual props like language flags or something may be all that’s needed to make it work. Ideas for custom presentations unique to a language are a discussion for later, maybe, when theme development has progressed further.
Each language would have its own RSS feed. The use of categories are variable, but taxonomic tags could be used to archive, filter, and search articles by topics, respective to a given language. Tags would require a single taxonomic tree against which all languages would be translated for their topics. Again, translation efforts here would fall on the shoulders of the language editor. The taxonomy tree is probably an early developmental need, so a community-generated list of terms might kickstart what determines the initial taxonomic.
The front-end will enable visitors to choose the language they prefer, provided the language exists in the system yet. No language option is shown until there is. Again, the establishment of a language editor, contributing the first article for that language and doing all needed translations of static content and taxonomy, is what gets a language started in the CMS.
For the admin-side and contributing authors, a language preference in the account creation process might handle what UI language they see. Each contributing author would have a freelance account, for example, to set up draft articles accordingly, and a front-end profile page to pimp their article contributions, much like the People section of the magazine provides for now.
Taking everything so far, you can imagine how this might look on the current homepage of the magazine. Internationalization conversions would need to be done, but mostly elements are removed, simplify the UI:
- The issue numbers would start over, reflecting the new international content.
- Navigation is the same, but adjusts to language.
- There will be no editor-in-chief to manage “business”, so the Editor’s column is removed from UI; implications for layout adjustments.
- Ad unit blocks could also be removed, but that’s up to Textpattern leadership. Nothing wrong with the current artwork.
- The homepage Table of Contents would reflect each language article for that issue. Teasers were hand-written by me, so that would need to be simplified and automated; probably just using article titles, author names, and a thumbnail of some flavour.
- The random quotations are cool and recommended, but unless they can be harnessed with language specificity, they may need to be dropped, meaning more free space.
- Contributor button labels might adjust to language, but the link itself might be the same for everyone—pointing to a single page with a table serving as a language editors’ directory. Each row providing language (ISO notation, maybe?), editor name (link to profile), and a “How to contribute” link in their language, which pulls from the editor’s bio data where they have added an URL for where their respective contribution instructions reside online.
- Footer links all adjust accordingly. Business as usual.
Sketches and technical briefs of all this stuff can be developed when the time comes, naturally.
To you
You now have a reasonable idea of what the new concept would be. I do not presume to think everything I’ve laid out so far is the final word, and I’ve surely overlooked critical details. This proposal is meant to get conversation going, for your sake and that of the Textpattern project.
Textpattern needs you to indicate whether you like the idea or not, first of all, and then offer any additional thoughts toward other aspects of the proposal— notably on the user experience and overhead as it impacts workflow and system architecture. Come forth and speak. Otherwise this proposal will see no move on development, and the magazine as is will continue to grow mushrooms.
If you are a bilingual speaker, try and reach out to your language community and let them know what’s going on here. Start a new thread on the topic in your own language in the forum’s General discussion section and point people there to begin talking. Speak on their behalf, and give some indication back to the English thread about how much support there is from your hive. Consider being a starting editor for your language.
Go!
