I'd like to see if I can gather and organize the requirements for the overall web site. I think we are on a good start with forums but I think other areas could use more defining.
As I do this I would like to make my work in progress available to everyone to contribute, comment, etc...
What is the best format? Word, Open Office Doc, RTF, text? It would be nice to use something that has tables.
Where can I put it that people can get to it?
Actually a Wiki can be ideal for this kind of thing because people can contribute to the process, but I don't think we have that capability yet.
Information I would like to gather:
I think that this information will make it much easier to determine how the web site should be organized and how we will need to manage the data related to each of the goals.
The web site for the YUI-EXT js toolkit uses a very nice system for managing comments related to text material. There is a slim bar along the left side of the text. If you click on it next to a paragraph it brings up a dialog that shows any comments about that paragraph. Once a comment exists there is a small balloon icon next to the paragraph with a number showing how many comments there. Also in the dialog are tabs for viewing all page comments, as well as an editor to create a new comment and help on how to use the commenting feature.
This link is to a blog entry that shows it in action:
<a href="http://www.jackslocum.com/blog/2006/12/17/how-to-create-a-reusable-ajax-driven-web-dialog-a-working-example/">Example Page</a>
Something to think about anyway...
Charlie, I could be terribly wrong, but my guess is you're greatly overestimating the degree to which other people are going to contribute their thoughts (ahead of time, anyway) on the design of the web site. By all means ask, but don't take lack of response as lack of enthusiasm for the project.
I personally loathe and despise the use of Word documents as a communications medium. I believe that if it can be presented in plain text, it should; if it can't, and doesn't need to be edited by others, use PDF; if it needs to be edited by others, fall back on, well, probably RTF, though there's plenty of software around (such as Apple's TextEdit) that will cheerfully mangle RTF into unreadability for you. Or use a wiki.
But the main thing I think about the web site is, it doesn't exist (in any but rudimentary form) and it should. Soon! This is why I asked about the system requirements for the old wiki; if we could find a web server that could meet those requirements, or coerce a fit between the wiki and Jake's web server, then we could have the old site back on the air almost instantaneously.
If we can't do that, then perhaps we could without too much trouble convert the old web material to some other wiki's markup, and put it up quickly that way. For instance, convert to MediaWiki markup and put it up on something like editthis.info. Or maybe some other wiki software -- Dag is, or was, partial to TiddlyWiki -- that could run on Jake's web server. Whatever, at least there would be something out there. And then we could move to a new web site design for the long term.
Actually I agree with you completely. I wasn't really figuring people would put in too much but I figure if I throw out the questions perhaps I can elicit the info over time. For the questions I posed I don't think we need huge amounts of details. But I do think they would help guide the design of the new site.
I also agree that it would be ideal to just get something functional to start right away. We have the content and even if it when into a system and it was somewhat mangled (with regard to links and such), I bet we could go through by hand and fix it fairly quickly. We have all of the text content extracted out to text documents with the simple markup codes. I am happy to spend time recreating links.
If there is a wiki system that we could start with that would be fine. In the long run we may run into the problem that we had before of needing to convert to something better, but perhaps we could do that without killing the original version. I think a beta.interrobangcartel.com domain would probably allow such an approach.
Sorry about the multiple posts. I posted and after hitting reply it didn't show my response. So I went back and tried again same thing. Finally I clicked entire thread and all of the posts were there. Something like that happened before as well. After posting it is not refreshing properly.
Using Firefox? Dag says that's a browser bug.
Yep Firefox. Now I know to refresh after replying.
I was surveying wikis, and this one looked interesting in that it is pretty full featured and may actually do much of what we are looking for:
http://tikiwiki.org/tiki-index.php?page=Home
Uses PHP, MySQL (or other database).
It seems to support a bunch of different functions as server-side plug ins.
Ugh, PHP.
I've looked at a bunch of Perl ones, but didn't find exactly what I was looking for. I concentrate on the ones that use flat files instead of MySQL or other databases, because of the problems with conversion and because of paranoia. Also, database wikis seem a bit slow. We also need a wiki that operates directly in the web directory or its subdirectories. I'd also prefer Markdown, so I was checking this page a couple months ago:
... But I couldn't find anything that fit right.
TiddlyWiki is also kind of difficult to convert to, but I'm thinking about it a little, because at least it could be embedded in a PerlHP script, which would take care of making the formatting look the way we want it to. One problem, though, is that we may have too much data. I'll think about how it can be converted, though. Maybe some temporary pages for each album, plus "unrecorded songs" and "artists"?
I setup and instance of TikiWiki on my site:
http://ibcwiki.spaceroom.org/index.php
You should be able to register. I can then grant rights to you to do admin stuff to fully explore its features.
Looks like it has some useful features (if they work), e.g. forums and articles.
On the down side, it has (of course) yet another completely different markup syntax. If you only use one wiki system, that's not such a big deal... but I spend a good deal of time on MediaWiki systems too.
Also, smileys. :(
I have updated the prototype. In the songs page there is now a button called search. It brings up a dialog with a list of the songs. The search options could be refined but in general I think it is a nice way to find what you are looking for without having to leave the page. The dialog does not have to be modal either interaction with the page itself can continue while the search windows is visible.
I have been thinking about the data related to the web site.
First I know that many of the elements could be represented in a number of way physically, (wiki pages, attachments, in files, in database tables, etc). I could see some advantages by using things like tables. I think it would allow easier linking of the different elements. However it can be done in flat files too if needed.
Ideally from the web UI point of view it will not care. There should just be web functions to call to get the information. I know in past the scripts were tightly coupled to the production of UI and the data. I would like to suggest we change that a bit. I have found that separation of content and presentation makes it much easier to change one or the other independently.
I know I can make it so the UI justs requests data and formats things properly.
Also I think it is useful to have a clear conceptual model of the data elements as well. I took a first shot at creating a picture: (UML)
http://www.spaceroom.org/images/DataModel.png
Let me know if it makes any sense or needs explanation.
I'm not familiar with the graphical notation being used; one minor thing I noticed, though, is it looks as though you provide for only one artist associated with lyrics. There's at least one song ("She's a Geek Freak") whose lyrics were a collaboration of two people.
I updated the diagram. The notation is the Unified Modeling Language (UML) a recent standard defined particularly of Object Oriented Modeling.
More than you ever wanted to know about UML: (Really)
http://www.uml.org/
Doctroid's right, there can be multiple lyricists, composers, arrangers, and performers. Plus, we need to note graphic artists for album artwork and "concept" people who came up with album or song titles.
My concept is that each data page (song page, album page, whatever) should contain several named lists that contain multiple key/data pairs. The lists would have names like Artists, Images, MP3s, and Videos. The Artists list would contain key/data pairs like Concept, Lyrics, and Arrangement that could each appear more than once. As the script read in key/data pairs, if it encounters Concept more than once, it appends a comma and the next data element to that key. All of these keys would be stored in a list that is itself a named key in a hash.
The UI doesn't care too much what the names actually are. There would be named divs or spans in the page markup; as the script hits each special span or div, if that name is the name of a list in the hash, it prints the keys and data in the list. It doesn't need to know the names of every possible role people could play, so one page might display just Lyrics and Arrangement, another might display Composer, Guitars, Keyboard, and Nose Flute.
Even the page layout can be handled in this data neutral way. I want one of the lists to be named Tabs; it would contain keys that would be used as names for tabs on the page. The data in each key is the name of the text file to read and display in each tab. Thus, the UI doesn't know whether the page will be an album page (and display Liner Notes and Track Listing tabs) or a song page (and display Liner Notes and Lyrics tabs) or an artist page (and display Bio and Contributions tabs.)
Regarding the model I am happy to keep working on revising until it is accurate. I will try to introduce more of these elements into the picture.
One of the problems I see with hash lists is that once the data becomes deeper that two levels it becomes hard to manage, and you can easily start to get a high level of redundancy of the data.
I have no problem with looking at hash lists but I think we need to introduce a reference based system. Everything should have a unique id which can be resolved into the desired content. There are a lot of ways of creating unique ids including URLs or from a sequence generator or even just an unique name (much like wiki page names).
The rendering can be different in different contexts, for example a "Page," or XML or another Hash list.
I think I was shooting to have some more basic data organization that did not necessary bind the information directly to a page. (A page could have references to the information).
Lets talk about songs:
Is a song a top level single entity? What uniquely identifies it? I am guessing the name.
A song can have a number of versions.
What is a version though? Is a different set of lyrics a new version? Assuming yes...
Is the concept for the song at the version level or the song level? At the moment the new diagram assumes song level.
A version is based on a set of lyrics.
A version may have a set of images.
A version may have a number of arrangements.
An arrangement may have a number of recorded versions.
Each of the artifacts will have properties related to the people involved in creating the artifact.
For easier location of the diagram:
http://www.spaceroom.org/images/DataModel.png
But what is the distinction between "two versions of a song" and "two songs"?
There are two different sets of lyrics corresponding to the title "Kiss Me, Cruel Fortran" -- are they different songs or different versions?
I could hardly have come up with a worse torture test for database design if I had tried than I did with "Hedgerow Hypothesis (Slightly Less Unlike King Crimson)". It has two titles, the other being "Let's Hypothesize Again". It's one of several versions of "Hedgerow Hypothesis". But it's also one of several versions, if that's the right word, of "Open Source Jam". And, I've forgotten, did Chuma or someone write a different set of "Hedgerow Hypothesis" lyrics?
(Oh, duh, I didn't read all of >>22 before posting.)
Going by what we have actually done:
... and so on, for other songs with multiple versions, like "Hedgerow Hypothesis" or "Kiss Me, Cruel Fortran".
Now think of it from the user perspective: the top of the page, which identifies which song we're looking at, has to have the song name, some quick links to writer and composer (for those looking for songs by the same person,) and a couple MP3s.
And, from our perspective, I think it's funnier to present ourselves as if we were just like any band. I've seen track listings that identified songwriters and composers like this: "Pumpkin, Mrs. Farnsworth" (Bennetto/Haller), "Zebra Races" (Laviolette/Bennetto), "Interests Are For Jerks" (Haller), "Kiss Me, Cruel Fortran" (Holmes/Tanner). This is a very compact, recognizable citation format and also a good way to distinguish versions: it's a different version if one or more of the names changes.
Now, whether we want to do last names only, full names, or first initial plus last name, I don't know. I think in terms of the songinfo file, it should be full name, and we can let the UI decide how to display that info.
Doctroid, by coincidence, I mentioned "Hedgerow Hypothesis" in my long post, without knowing you were already posting about it. Chuma did an alternate version of "Hedgehog Houses", which is probably why you (and I, for a moment) thought he did one for "Hedgerow Hypothesis", too.
I think the alternate title for that version of "Hedgerow Hypothesis" should be mentioned in the liner notes and a search for the song title "Let's Hypothesize Again" (or translating the title into an URL) should redirect to the "Hedgerow Hypothesis (version 1)" page. There should also be a link to it from the Open Source Jam page... which is a unique problem by itself; I think the Open Source Jam is neither an album nor a song, but a project.
I had some other point I was going to make today, but I have to remember what it was.
Oh, I remember:
Regarding hashlists: I think they're just fine, at least in terms of the way they are used in XML::Simple:
http://search.cpan.org/dist/XML-Simple/lib/XML/Simple/FAQ.pod
I think this will fill our needs quite nicely. PerlHP to provide the basic layout and functionality, XML::Simple to read data files, XML::Writer to write them, Yahoo! UI for some UI elements like the pop-up dialogs. It's starting to congeal in my brane!
I think I am also in agreement. But that would be based on using the keyattr stuff as described in the link. I am kind of fanatical about data redundancy because it can screw you. (Experience talking here...)
Again, though, in concept I think we are getting closer.
I was wondering whether or not a direct conference in teh MOO would be useful. The non-realtime discussion is a bit challenging medium at times.
I'm on the MOO most weekdays (9ish to 5ish Eastern time, actual availability sporadic). Other times by appointment.
