Why I Journal But Don't Blog
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.
I'm flattered.
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...
Comments very welcome. [smile]
in the journal itself. Good idea [smile].
I see the same issues w/ blogs. Some amazing jewels are produced here in the GD journal system (and on other blogs etc), but they are quickly pushed into the depths of the system. The only way to find them again are other blogs constantly relinking the jewels (so the search engines pick them up.) or by dumpster diving the archives. (Messy, takes a long time, but sometimes you find the paper dump of everyone's password for the finacial department.)
Ok, so on to what I've been thinking of.
I look at wikinews, I look at gd journals, I look at blogs, I look at cnn.com etc. They all suffer from the same problem. Finding content thats been pushed off the surface is damn near impossible. The solution I've been toying with is to have a larger encapsaliting events/sections/catagories that can be built up as things go along. This involves a few things. The "static" content for that update, then linking these "static" chunks together under the umbrella of an "event". "events" could be parents and children of other "events".
Ok so what that would create is a dyanmic linking system which can overlap (but checking is done to prevent recusive inclusions). Ok, to link these statics/events into events it would be done automatically and explictily. Either by meta data embedded into each static/event, or by a complex system to link static/events together during the authoring portion of the site.
To give a real world example, I'll use Gamedev.net.
Washu submits a new tutorial on type triatis. (bane of my existance still ;). One of the staff proofs it then pushes it into the tutorials under the right catagegory, and puts it up onthe front page.
Under this system the staff submitting the article would fill in some meta data. The static data would be the content of the tutorial. The meta data would be datum and value. So Author:Washu, Date:28-2-2006, Title:"Type Traits for teh win", CPPTutorial:
Now on submission of this information the backend (which is sitting on top of this "statics"/"events" framework) would look for programmed datums. It would see that Author is set, and to washu. Would look washu up in the user list, and then credit washu w/ the article. It would see that CPPTutorial is defined. It would check to see rules of CPPTutorial and see that CPPTutorials articles get linked into a page that is about C++ Programing Tutorials, it would also see that CPPTutorials are linked to events for Tutorials. Data is check, and the system sees the front page displays a filtered view of items by category, and tutorials by the last 5 recent submissions.
Honestly, you can read that, and see that the concept only shines just above what probably currently exists for GDNet.
The next trick is that you can link "statics" together. So that under CPPTutorials one article would evovle from "Enginuity: Start Here" to a sub page that would link all Eginuity related articles as one event.
Hmmmmmm I'm fleshing out the idea as I'm typing, and it would seem that there really is no difference between static and events. Simply that statics can't have children and have static.
So on top of this content tracking system, you would then build filters/manipulations to the data which would either combine events or render a collection of events and statics to html.
I'm still pondering this, I'll write more about it in my journal.