-------
POLL
-------
Poll is closed. (In case you can't figure that from the following discussion.) We have some serious ideas to discuss for the future of the Database.
-------
RESPONSES
-------
Notes on documentation and GUI will be addressed at the end of the post.
Since you instructed me to reply, I am doing so. My answer is no. No, I do not think the file should be compiled into a .zip file. While it would make all of the information more accessible, it would have to be updated every time a new item is added to the database.
I believe that the database should be kept as is, but with one small addition...
I believe that a compilation index should be added. A document, updated when a new item is added, that is on the front of the Database page. This file will include a picture of the item added (3D picture from the pep program), the game/character of the item, name of the creator, name of the unfolder, the page format, the number of pages, size of the file, and vitam information (foam, sliced & thickness, etc.).
That will make it a little easier to find what is being searched for and to make sure that the proper people get the proper credit. But, that's just my suggestion.
Since a post like this
requires a reply, I will. I'm pretty sure a vote like yours almost classifies as two. Why? You have sound logic, and a good explanation.
I'll discuss the document idea after this.
I think a graphical layer would be nice. It would be a bit of work when adding new ones, but I think the biggest issue for finding things is not knowing what you're downloading until you get it. People are gravitated to that awful wikia, and it might be because it is easier to navigate. But this would require one of us being adept at web design and having good webspace to handle the load.
As for the zip, I think periodically zipping it is enough. There is not THAT much new content to the DB's, so if it were updated every couple of months it would still be recent enough.
Just my two cents, I am joining this conversation late!
Just a little late, but not much.
Seriously, I could make the .zip file a "once a year" update. That way we can simply have a [*2012* Edition] of the Database, compiled at the end of each year. Or we could opt for a version with all the previous files compiled into a [*2013* Edition] released at the beginning of the year.
I think a graphical layer would be nice. It would be a bit of work when adding new ones, but I think the biggest issue for finding things is not knowing what you're downloading until you get it. People are gravitated to that awful wikia, and it might be because it is easier to navigate. But this would require one of us being adept at web design and having good webspace to handle the load.
Not at all. It would be a document file. A .pdf or similar file format. Document editing is easier and it can be grouped just as it is in the Database.
As it currently stands, there are over 750 files to go through and document. Personally, I don't really want to do that all on my lonesome. Then
I would be crazy, and
no-one would run the Database.
-------
ON FILE DOCUMENTATION AND GUI'S
-------
Long have I been considering this idea, but I don't have the means or knowledge to implement it.
One of the first rational steps, I think, would be file tags - eg. #reach, #odst, #shoulder
This means that by using a single tag, such as #odst, brings up all the other files tagged as such. It also means that users can search for a specific
type of file, or combine search tags to refine their search.
The next step, and I completely agree with Jason on this, is images. People want to know what they are downloading, before they do so. While file information is also important, it is somewhat secondary, and often included within the file - but not always.
Which leads into my next thought. We need to find a way to make
all files use the same internal formatting. Whether this is just a textbox inside the file, or specific naming conventions - files need to be identifiable that they have come from the Database, and also present all the critical information about its creation and usage.
A compilation/index of all files. It's a lot of work, and probably needs to happen soon - preferably before the influx of H4 files after launch.
GUI/Web design. You have no idea how badly I want this. This would literally take the Database to a whole new level. Unfortunately, I don't have the budget for this, nor the time to learn the skills. Ideally, we would use Adobe Flash, or even get an executable running
scaleform, and/or it would be on its own server. (ie. not 4shared)
To do this requires an
actual database of all the files (not just a folder hierarchy), that can be filtered and search effectively - as well as being user friendly enough for the person(s) that have to maintain it.
Sure, I can design an interface, maybe even set it up ready for Flash - but that's as far as I can get on my own.
@Jason/Katsu - perhaps we can take this discussion further in a gDoc, rather than on the boards. Interested?
CJ
