Design Fixations with Mediawiki Skins
I spent much of last week with my head inside a Mediawiki skin (when I probably should have been working on another project). I'm not entirely sure what it is, but I sometimes get fixated by technical problems I can't seem to solve.
I first customized the FraternalRelief Mediawiki skin to match my organization's home page. My customization wasn't too bad, but I saw a few errors, and when I queried a forum, they told me FraternalRelief was no longer compatible with the current version of Mediawiki. Who would have thought.
Fine. I found a compatible Paul Gu theme and customized it again to match my organization's site. But during a design review meeting with my team, I brought up the fact that the theme was licensed under GPL. I don't understand the finer details of GPL, but the thought crossed my mind that perhaps GPL would require me to make my customization available to the world. A Mediawiki forum moderator said that would only be the case if I were trying to distribute the skin -- then I would have to give it away for free. But still, I wasn't sure.
Then another team member brought up another point. He said my customization should either look exactly like the original site or it should be noticeably different. No cheap knock-offs or it will throw readers off. I had to agree.
So after the meeting I commenced to pull apart the default Mediawiki skin (Monobook) piece by piece in an effort to understand it. I copied over the stylesheets and layout of the page I was trying to match. And then one by one I copied over chunks of Mediawiki PHP code, trying to understand what each code snippet does.
I copied the source code of the organization page I was attempting to clone. I downloaded all the stylesheets. I pulled down about two dozen images referenced in the stylesheet. I then commenced to integrate the code into the Mediaskin. After about a day and a half, I finally cloned it.
The problem is, Mediawiki has tons of additional components that a regular website doesn't. This is what most people don't understand when they want to convert their regular HTML website to WordPress -- wordpress has a lot more components, each with unique styles. And some of the components only appear at certain times, under certain conditions. So while I cloned my organization's page into a Mediawiki skin, I also have many styles that I need to create. (I wish I could show a screenshot here, but I can't since it's behind the firewall.)
I am starting to like working with Mediawiki as much as I like working with WordPress. Last week the world could have disintegrated around me, and I wouldn't have noticed or even pulled myself away to look.
I don't get fixated with writing help topics in the same way. Mostly writing helps topics is a chore. It's not what I wake up dying to do. But to design the skin, the frame around which the content will display, that's the fun part. It's what I'll do despite all obstacles.
This is not to say, however, that I have aspirations to be an interaction designer. I do love to write. It's nearly 1 a.m., and I couldn't sleep because I wanted to write. But to be free to design and configure the publishing platform for my content is something that, at times, mesmerizes me.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.