This is a pretty bare bones message board, but perhaps if we can integrate it into the rest of the site it will work for what we need.

I have commented in the YUKA board about roles and goals and I think that is a discussion that will help define the overall website, but how our conversations are managed may be a different topic. This is very simple but I wonder how many threads will be managed.

Here's the sketch I made of how I thought the website should look.

Look here: http://en.wikipedia.org/wiki/Kibology

Now, I'm not saying this gets everything right for Wikipedia, let alone that the same thing would be right for us. But notice:

• There are no frames. I like that.
• The logo/site name is a square, in a corner, taking up only a small part of the screen real estate.
• Navigation, search, and tools on left.
• More of what I'd call tools as a simple line of links across the top right. Why do they not put these in the toolbox instead? I don't know. I guess because they're separating "user tools" (things that operate on user information) from "article tools" (operate on article information). Anyway, since they're rarely used, they're small and unobtrusive.
• The legal stuff (disclaimer, privacy policy, etc.) is down on the bottom. You have to scroll to see it.
• 90% or so of the screen real estate is then left for one big box displaying whatever the user chooses (via tabs) to look at... and not displaying what the user chooses not to look at. The tabs are a little garbled: some of them select what is shown in the main area of the page, some (move, (un)watch)) really are more tools.

Inspired by that:

• On left, from top to bottom: Logo/band name, navigation box, tool box (including login, prefs, search ... ? I'm not sure what tools we need.) This could be one frame, in a framed design (though I prefer unframed), or two (logo/band name in one, the rest in the other).
• At right, on top, song title, with a small (100x100 px?) version of album cover or other associated artwork at right. (click on art to see it full size; click on left/right arrows under art to cycle through multiple art items.) For songs with multiple versions: version identifier appears below song title, with left/right arrows carrying reader to other versions. This could be a frame.
• Below that, tabs: e.g. Status, Liner notes, Lyrics, Comments, Artists. Tabs select what appears on the rest of the page, which is the lion's share of the screen real estate. This could be a frame.

Or something like that.

Some nice ideas here. Here are my thoughts.

No Frames. I probably hate them more than you do. The site as it exists now doesn't use frames, it uses divs and CSS, which can be a devil arranging, but is the better way to go.

I can see putting the logo/band name in a box in the upper left corner. It's not right now mainly because of positioning issues, but I'll take care of that.

The login box should be below it, and should change to username/status with a logout link once you're logged in. Burying it in a tool box doesn't seem right, especially since I don't want a toolbox on the page at all if the user isn't logged in. Don't confuse the user. If you are visiting the page for the first time, all you really want and need is an ability to navigate, so below the login/username box is a nav box and (maybe) a search tool. I've got the nav box split in that sketch, but that really makes no sense.

(In fact, screw the idea of a toolbox in the left-hand side at all. The only tools there will be user prefs and logout, and maybe a link to your profile in the wiki.)

For the body of the article, I mostly agree with what you say, except I want the image on the left, for a couple reasons:

• It provides further visual cues to the user that the text on the left (sidebar) is separated from the text on the right (page title and so on.)
• The image size will be fixed, but the box for the song title should resize to the remaining browser width. This prevents the horizontal scrollbar from appearing and makes the page easier to use.

Cycling the images in the same box using nav arrows is a good idea. This will probably mainly matter for Album art, but band members might want more than one pic. If there's no associated image, a generic icon will appear.

The right-side of the article header is the page title. If it's a song, it should have a version nav bar below the title (when applicable) and two lines of small-size text below it: an abbreviated artist attribution (like "R Holmes/M Zed" for "Kiss Me, Cruel Fortran") and an album name, if assigned. If a user is logged in, double clicking the page title pops up article tools (this is a good use for the Yahoo! Utils.) Article tools will let you edit song info, connect songs to albums, set the initial image, and delete the article.

Below this article header will be the tabbed article sections, as you describe. Which tabs appear depends on the article type, but there should always be one tab for text, one for comments, and one for attachments (which only appears if you are logged in.) To edit info in a particular tabbed section, double click the content.

There will also be a "text tool bar" at the bottom of each section of text, in case someone has a problem with javascript or for first-time users who don't know the interface; it would be words in brackets in smaller print, like the [Edit] you see on the Wikipedia example.

What I'm shooting for is:

• the page will adapt to fit the browser, instead of the page forcing the user to adapt to the page.
• if you are using javascript, tools will be unobtrusive, tucked out of the way, in the spot where the tools would do stuff.

Any other ideas of what might be needed?

Oh, and an ordinary user who hasn't created an account and possibly has never been to the site before will be asking three main questions:

• what the heck is this Interrobang Cartel thingie?
• where is the mp3?
• who made that song, and did they do anything else?

The first question gets answered on the main page, or links to the answer. The other two questions get answered on the page for that song, and should be as prominent as possible. There's an Artists tab, of course, which provides detailed info, but the abbreviated attributions under the song title should be links to artist pages, and there should be mp3 links underneath, labeled "mp3 1|2|3" to make them obvious. This way, the novice user doesn't have to look anywhere except the very top of the page. And if all they want are some mp3s, there will be an mp3 page (like now) linked on the left... but I'm wondering if it should be in the nav box, or as a link immediately below the logo/band name?

Repeat users will want more detailed song info and will want to talk about the songs. That's what the tabs are for. The Comments tab will allow comments without needing to log in, just like in this forum. You only have to create an account if you want to contribute to the band. This gives you site editing and upload powers.

Just as a note, the prototype did not use any frames either. It was all divs CSS and Javascript as well. It just simulated frames the frames by creating resizable regions.

I am not stuck on any particular method. I do like the ability to easily create tab panels. I think just figuring out the right layout is the trick. Actually I found the sketch image helpful, perhaps talysman could do another based on the ideas so far?

I am happy to create more prototypes for the sake of discussion.

We probably shouldn't use a tabs-in-tabs layout like I depicted here. I think we can get away with more tabs in a row, but I was only able to fit three in, because I didn't vary my text size much. I wanted it to be readable in the sketch.

I like the overall look if we are just talking about song information.

I do have some questions though:

I am assuming that this page layout just for the songs. If so, is it likely that there would be multiple images related to a particular song? Is this just the album cover? If so why would we need to scroll through images?

The song title box has scroll arrows for navigating through the versions of the songs. Does this cause an update to happen in the tab information below? (Different lyrics/and or artists for a performance?).

How did we get to this page to start? Did we navigate here from a main song index page or perhaps an album page?

I know that wikis can have links to other content, but will the linkage be sufficient for the navigational modal you are showing, or will there need to be more explicit structure?

This mostly follows the song information page, but certain elements would pertain more to other pages. Let's take the multiple images example. The image box will display one image at a time and a caption below that image. If there is more than one image, it will display arrows on either end of the caption, to allow scrolling. If there's only one image, the arrows will be hidden.

The version scroll tool would work the same way. If there is more than one version of a song, the text will say "Version 1 | 2 | 3 ..." and there will be scroll arrows on either side. If there's only one version, that line would be blank. And yes, I think the tabs below should update when you switch versions.

There should be a couple different ways of getting to a song info page:

• By direct URL (example: http://www.interrobangcartel.com/wiki.cgi?Beep );
• By clicking a link in an album track listing;
• By clicking a link in an artist's list of accomplishments;
• By clicking a link on the MP3s page;
• (later) By doing a search.

Don't know how to impliment the last one yet, other than that the results page would list links for each page matching the search. There needs to be a couple different pre-defined searches, though: recorded, unrecorded, unwritten, unassigned to an album.

I'm not sure what you mean by the last line. Presumably, there will be a perl app that searches for and interprets the info files, and the info files will tell the app what versions, tabs and images are available for each page. Album pages, for example, will look identical to song pages, but instead of a lyrics tab, there would be a tracks tab. Artist pages would be the same, except that the title box would never display the version scroll tool and the attributions for lyricist/composer/performer would turn into roles.

I updated the prototype:

http://ibc.spaceroom.org/

Check out the Songs tab and the forum tab.
In songs I created the basic block areas for the scrolling parts as well as the tabs for sub content.

In the forums area I can create a tab for each of any forums we create (only one for the moment). I used an iframe to link to the site. Aside from some CSS formating to get rid of the outer scroll bar it works pretty well.

Generally I like the look of the new prototype.

I think the image box should be smaller: a small square, allowing for an image about the size of the IBC logo plus selection arrows. That gives more space for the title box. Clicking on the image would bring up a larger version.

Different versions of a song may have different artwork.

I suggested the possibility of multiple art items because iTunes has it, and because I know of at least a couple of songs -- "Geek Freak" and my version of "Hedgerow Hypothesis" -- that have their own artwork, in addition to the artwork for their album. We could pick song-specific artwork if it exists, album artwork if it doesn't, and leave it at that, but if it's easy to cycle through multiple art items, why not?

The tabbed boxes under the songs tab appears to have fixed height, smaller than the available height in my browser window, with an empty space below it. I assume that will change.

Bug: On the forums tab, if I click on a link in the forums (e.g. one of the threads in the thread list) the tab bars go away and there's a blank space at the bottom of the box.

Is there a way to make the browser "back" button return to the previously viewed tab, and/or to make "reload" reload the tab you were looking at? (Currently, if you click "reload", you get the initial view of the web site again. Given the forum's behavior with respect to what Dag blames on a Firefox bug, one may want to reload the forum page frequently.)

I think once the interior content is worked out we can size the boxes to fit optimally. If you clicked on the image where would you want the larger image to show up? Perhaps in a dialog?

I am still playing with the CSS to get everything to size properly. I have been using Firefox so I will have to eventually go back and add IE specific settings.

I will have to see if I can duplicate the error.

There is a programatic way to reload. I believe there is a way to have it reload when ever the tab is clicked. There are also ways of creating a right click menu as well. I will play with it and see what I can do.

Regarding the bug with the forum. I have seen this before in pages that use CSS and have links that use internal refs to navigate. For some reason when it repositions the page it tends to move more parts than are desired. (Effectively the tabs are being scrolled off the screen. I think it is a bug in the browsers however I have seen this effect in IE as Firefox.

I know that we are working in "quirks" mode rather than strict so the CSS doesn't always behave properly. However strict brings in its own challenges. Iframes are not supported for example, which is what I am using to contain the forum.

The Javascript tabs have methods for getting content from a URL, however due to Javascript (AJAX) security, it will only load content from the same domain. That is fine once we are running everything on the same server, however for my testing it means I can't load anything from the main IBC site.

This actually brings up an interesting question. Talysman has talked about support for non Javascript but this functionality is dependent on it. I don't know how big an issue that is.

One thing is the approach to updating content on the screen. This implementation is geared around loading content in the background through AJAX, rather than refreshing the page everytime. This also requires Javascript support. I think it makes for a more functional site but that is just my opinion.
I am sure that one could achieve the same look without the Javascript, but the toolkit sure makes it easy.