Talk:Search Odds/Fort Data/Storehouse Data

Don't you think you've a bit overcomplicated the process? --~~~~_T^''' 21:09, 20 August 2007 (BST)

I'm not sure if you've seen the final edit. But even so, my purpose is to clearly separate data by condition, which makes it easier to see where data is lacking, or to estimate search rates based on limited data, which is a bit difficult under the current table. You're right, it does look a bit more complicated, but I tried a number of different ways, and this seem the best. Also, I have modified the Guidelines (not in the template itself, but just for this page), to reflect the table's redesign. Do you have any suggestions, other then "toss it out altogether"?

Yes, but i'll suspend implementing them for a while --~~~~_T^''' 09:09, 21 August 2007 (BST)

Ok. Now that i've tried to use it - it's horrible. total pain in the arse to update. Besides the whole "different tables for different conditions" is useless - it only clugs the page and makes it harder for updater to understand where his line goes. With just an another column for "Building State" it was alll clear, but not now --~~~~_T^''' 08:55, 22 August 2007 (BST)

Duke Garland, your last comment made me laugh out loud, seriously. And I particularly like the phrase "clugs the page". I'd agree with that one completely, and I'm thinking that the simpler solution would be to just group several rows of totals at the end of the table, tallying by building condition, so that they're only present when there are actually data points for that specific circumstance, and as the tallying is generally done only by those who take it upon themselves to do so, the typical user adding search data wouldn't be burdened by it in any way. Opinion? --Morgan Blair 23:58, 22 August 2007 (BST)

I meant clogs the page... nevermind. Yes, many rows for "summary" and simple table for data is very good --~~~~_T^''' 07:33, 23 August 2007 (BST)