Symphony.

Hey folks,

Since you are all such Very Smart People, I thought you might be able to help me think through something. As some of you know by now, I'm working on a website for a scholarly journal... so the basics are predicatable... Issues, Articles, Authors, etc.

I'm planning (and only planning at this stage, because this will be built in RC1) to have a section for Issues and a section for Articles. Articles will be section-linked to Issues and so when you're creating an article, you can choose the Issue to which it belongs. Simple.

Each Issue's Articles are organized into subsections. Some of these subsections are just descriptive and are consistent across Issues, but most are not. Most are unique to their Issue. So, the Table of Contents might look like this:

Editorials

• Here's a Sample Article
• Why Sample Articles are Stupid

Articles on Symphony

• Symphony Rules
• Why Symphony's the Greatest Thing Since Nandos
• Mesh Chairs are the Symphonies of the Office World

These subsections are not important enough to warrant their own Section in Symphony because they're not used for anything other than organizing the TOC... so they could simply be a text field in Articles, and I don't mind asking our staff to type them in by hand. What's great is that when I'm displaying the TOC, Symphony can even group the XML by the subsection field, so they'll be easy to display as above. But here's the wrinkle:

How do I order the subsections? Or more accurately, how do I order the subsections without having to make them entities in their own right and thus complexify the Issue/Article creation process?

The only idea I've had is to add extra info to that field's content. So when creating an article, for example, I could enter "1-Editorials" into the subsection field and then use XSLT to order the subsections and strip away the number before displaying it. Anyone have any better ideas?

Thanks in advance, craig

We've actually done something similar in RC1: The menu that sections get placed under (in the admin) is now customisable, so on the Sections form you have a text input for "Parent Menu" in which you can enter a new top-level menu name, or an existing one. Using a tag list field with a suggestion list of existing names is helpful for this, so the user can just click a name instead of having to enter it manually.

As for order, I like your prefix idea, but I agree it seems less than optimal. The biggest problem is that you can't change a heading's order once it's set. To get around this, if you want to add an item between 1 and 2, just give it 1.5.

Another option would be to have a static XML DS that contains order information. This would give you ease of reordering at the expense of making it hard to add new headings.

There will be a nicer way to do this in RC1 if we have time to implement orderable sections. Ask me again when it's done. ;)

you can create a faux-filing system with the Date. Say for one issue, you start out each article with the same date, but you change the time by incrementing x minutes, starting from 00:00. so if you have 5 articles for august, you could potentially have the following dates:

• 01 Aug 2008 00:00
• 01 Aug 2008 00:10
• 01 Aug 2008 00:20
• 01 Aug 2008 00:30
• 01 Aug 2008 00:40

and then you can sort by the date at the same time, being able to see which articles are for which issue, in a sense.

I know you may not have a choice, as I didn't with a project I recently did, but do you really have to use the "issue" concept with a Web site?

It seems like creating individual issues just unnecessarily complicates things. Issues are a solution to a limitation of print design: limited page count. On the Web you can have as many pages as you want. Splitting things up into Issues not only complicates things for archiving in the back-end, it makes it harder for a user to navigate the archives.

Often with this set-up the Web version takes a back seat to the print one. Articles are simply copy and pasted into the Web site all at once and it's not updated again until the next issue instead of being re-written for the Web and updated regularly.

I guess it could be worse. I don't know how many times we've had to say "no" to just publishing PDF versions of publications on a site. For some reason academic people love their PDFs and eReaders. Yuck! :-P

"Splitting things up into Issues not only complicates things for archiving in the back-end, it makes it harder for a user to navigate the archives."

I vainly attempted to make that exact argument to my boss about a month ago. It was a square-peg-in-round-hole moment.

Not sure when, but you may very likely need to use keys. Hope that helps.

Thanks all for the suggestions. Very helpful. I'll continue to ponder.

About the question of Issues... The simplest reason for using the Issue as an organizational framework is that the function of the website is, in part, to be an accurate online representation of the journal itself. And it is a print journal. So simply for the sake of presenting information consistently and accurately, we need users to be able to find articles by issue or browse the contents of an issue. If you've ever done academic research and you need to track down an article you've seen cited, the clues you get (aside from title and author) are usually journal name, year, and journal issue. And it's in precisely that order that, more often than not, you drill down to the content, whether you're in the stacks of a library or in an e-journal system.

Another reason is that Issues are often the product of editorial work. The choice of the essays, the way they're organized, etc. are in themselves part of the product. Part of what makes publications good or bad is the vision of their editors, and some of that quality would be lost without the idea of the Issue itself as a product. Just like you can listen to any random jumble of mp3s that you want in any order, there's still a value to the idea of the album as a work in itself, and sometimes you want to hear an album in the way that an artist originally conceived and arranged it...

... But I've gone off on a tangent now. Sorry... Not enough sleep ;)

Thanks again all. Will post if I think of anything else.

Thanks for sharing. I think those are strong arguments for the idea of an Issue.