I am archiving older pieces I have written on other sites, making this the definitive home for all my work. This is one of several I am porting over from my GameDev.Net user journal. Enjoy!
So I mentioned a few days ago that I was working on a project, but I've mentioned nothing about it yet. It's a software project, and I plan to hit initial alpha release this weekend if all goes well, but its roots lie in human/social problems - as with all great software (and, no, I'm not suggesting that it's great software... yet).
Why I Journal But Don't Blog
[As of 2013, this had become "Why I Essay, but Don't Blog." And Metacite had evolved into iterations built on top of Ghost. The ideas here live on, just with less meanness and arrogance.—Ed.]
We're all familiar with blogging by now. A much-hyped phenomenon in the mainstream media these days, there's actually not much spectacular about it. John Q Public posts random comments on his life, or topical comments on his interest or profession. Occasionally, John happens to be an insightful and intelligent persion. Far too often, however, John is a blithering fool.
Blogs allow for reader comment, and the Talkback system allows blogs to link each other (and something funky about "pinging" each other; anyone care to elaborate?), creating this directed graph of interconnected commentary that goes by the popular name the blogosphere. Great.
The challenge, as a blog author, is that you have to post frequently or people will lose interest in your blog. This pressure to perform can lead to posting inanities and half-witted ruminations on nothing of consequence. Congratulations, you've just proved to the general public that you're an idiot! Fortunately, the advent of RSS and its rapid popularization mean that your blog can be updated a lot less frequently without suffering significant reader attrition, because new content is pushed to them whenever it's made available.
I also have an aesthetic objection to blogs, in that the majority of them (I have yet to find any exceptions, but I am open to the possibility) are linear reverse chronological braindumps (most recent posts first). I find the format inelegant, and the pages frequently cluttered by all the link sidebars necessary to inform the casual visitor that there is additional content. In essence, every blog I've seen looks like a personal Slashdot (and we all know how much I love Slashdot!)
But you journal!, you might say. Yes, I maintain this journal on a semi-regular basis, and, yes, it has all the flaws of blogs that I supposedly dislike. However, this journal is an outgrowth of my extensive involvement in this community - I am essentially talking to people who know me - and it covers material that I think is of topical interest to them. I try not to go too far afield from games, technology, software development and (new) media. But I have a lot of other opinions that are not appropriate for this journal, and some people have even asked me why I don't blog as they feel my opinions might actually be worth reading.
So What's the Alternative?
I wanted something that served the purpose of expressing my opinions regularly, that was accessible to a large number of people (meaning it had to be on the web and not require anything else), did not have the constant pressure to produce of an overt chronological record, and wasn't ugly. In short, I wanted a magazine.
For the record, I will discard the terms e-zine and web-zine, as I don't feel that either of them refers to the sort of thing I am trying to do. What I have in mind is more of a traditional magazine, but delivered on the web. Not as PDF or any other "layout file format," but as simple HTML employing the structural conventions of a print magazine.
It will have a cover page, which both presents a pictoral/graphical representation of the issue's theme/subject as well as highlight some of the articles contained in that issue. It will have a "From the Editor's Desk" section, where the editor in chief (me) will give an overview of the issue, framing the larger questions that run through the entire colleciton of articles. It will have a contents page, with little graphical emphases to draw your eye to various articles. Et cetera. It will be, for all intents and purposes, like reading a magazine on the web.
And, then again, it won't. The web is not high-gloss print paper. You aren't bound by physical dimensions, and while both the screen and the printed page are two-dimensional, the web adds a third dimension in the sense of hypertext links. The magazine needs to take advantage of that property, reflect the fact that, rather than being a collection of sequential pages divided into logical "sections," it is more of a bundle of discrete articles, each of which may have a number of logical sections (pages, for readability sake) of its own. It needs to understand that while its primary consumption format is the screen, the articles may also be printed - and provide alternate, appropriate formatting for that purpose.
You Are Not Your User
At this point I could have whipped up a fairly minimal content management system, or even modified one of the many open source CMSes out there, but doing so would have resulted in an application with all the baling wire exposed, so to speak. Even though I am a programmer, software developer and highly technical user, I have an art degree and the intention of going on to study Industrial Design. Put simply, I like elegant solutions that make obvious how to use them and require zero-to-minimal technical expertise. I needed to design a system that would be useful to others trying to do things similar to what I was doing, very often people with no comprehension of - or interest in learning - HTML and CSS, "simple" as they might be to hardened C++/Java/assembly hackers. So I let the idea simmer.
About two weeks ago I met with an old buddy of mine for lunch and coffee (I never drink the stuff, but he does) and just to catch up. We hadn't seen or spoken in years, so there was a lot to talk about. He runs a design and creative services firm and tried to launch a web-delivered magazine a while back, but he's still working out profitability and modalities related to the magazine, which he delivers as a PDF file because of the flexibility and control it affords him. He turned out to be the perfect person to sound my nebulous ideas off of, as his experiences of surviving contact with the real world as well as his insight into the needs of his clients would prove incredibly valuable. He talked about one client who was looking for a platform to design and deploy her own photo gallery, but who didn't want to need to know anything technical and didn't want to be hostage to contractors. Those were my potential audience!
The idea began to coalesce. I wanted a layout and publication management system with WYSIWYG editing and minimal technical overhead. Native look and feel were not necessary, this being a web application, but the roundtrip penalty of a classic web app is too high for a design-oriented app. My friend solved this by suggesting I write the editors in SWF. (SVG or Mozilla Chrome are options, but they have issues with availability and lock-in, respectively.) All the core elements were in place.
The Metacite Publication Management System
And, yes, I do find it funny that the name can be shortened as "Metacite PMS." Maybe I'll change it.
Design is a slow process, especially when usability is a (the?) major concern. At first I tried modeling the application using a variety of CASE-like tools, like UML Sequence and Interaction Diagrams or Flowcharts, but nothing was working. Then it hit me: Dummy, you're designing an app whose functionality must be intuitively expressed by the UI! Use Interface Mock-Ups! All those months of reading OK/Cancel (currently on hiatus) finally paid off.
A hierarchical task-based decomposition of the UI is nearing completion, and HTML pages with no back-end functionality, just static mock data, will be done between today and tomorrow (if I ever stop writing in my journal!) After that I can start wiring UI elements to event handlers, and Alpha Release 0.1 should be this weekend. Release Candidate 1 should be by the end of September.
The software itself is nothing highly complicated. Yet. Some of the more challenging problems such as multiple users, authentication, privileges and ownership have yet to be addressed, as they aren't really interface problems (but the interface either suggests or reflects them). That's what the interval between Alpha and RC is for. Metacite is being written in ASP.NET, with SWF components to be implemented before Release. Being an application (editor) rather than an animation, the SWF component(s) will be written directly in ActionScript, which lets me try out the open source Motion-Twin ActionScript 2 Compiler. The intention is to open source Metacite itself after release.
There are tons more details about what I want to do and put into Metacite, but I need to keep some stuff to write about later! Remember, pressure to produce...