You'll never know unless you try...? I'm sure you can get someone to help you - I mean, once they understand your reasoning behind how you designed the page you should be able to explain how to integrate the new material.

If you need anyhelp btw, I'm sure there's plenty of people who are willing to do just that. = 3

Hey, don't let yourself get overwhelmed, Mr. Initial Man. I'm the only one in the FBA allowed to do that.

The trick is to just take things one at a time. Figure out what it is you want to concentrate on and work on that thing. Then don't think about the rest until you're done with it. If you had to choose only one thing to work on, what would it be?

Well... right now, I think it should be the Stats input page. The pages to enter in all players and the schedule are in place; and I guess I can ask JT or you to do those. BTW, scoring is ready, too.

Awesome! Think you could give me a refresher on how I edit it?

The scores, the schedule, or the players?

The scores are pretty much self-explanitory: you select the date that you want to record the scores for. If scores have already been entered, they show up (handy when you want to edit them). For example, say the Bikers played the Royals

You would see:


DAK @ RMY: Bikers ______ Royals ______ __ OT

"_____" means an input field, so you enter the scores into each. You also enter how many overtimes they had (if there was no overtime, leave it blank).

Score all teams and hit the submit button. You're done, the database is updated. Yep, I'm cutting out me as the middlefur.




Schedule, well, you select which team is hosting whom. The textboxes below the selections are read-only; they show if a team is being hosted elsewhere.


Entering players should be self-explanitory.



These forms have been set up to get rid of any fooling around with XML files or other kinds of code.

You might be surprised hun. While i cannot speak for myself, as i really do not understand the inner workings of my own site, but I do know [thank god] a good friend that does, he's a wizz at these things. My point is, there is someone out there, someone you Can trust, that would be able to understand what you've created. [I don't mean my friend mind you.]

But I also understand all to well how hard it is to allow yourself to place trust in someone over something that you've spent so much time and energy in creating.

There's always someone out there that can, even if it might take time, be accustomed to your way of scripting this.

It's time to push out a little, don't be overwhelmed. ^^

A specification and a design before getting to code would help.

Could you expand on that?

First, you have to make the blueprints or "mock" for every "mask" or interface. Then you design the database parting from those schemas.

Erf... I kinda did things backwards: I designed the database around the website that most people see, THEN designed the admin pages (which updates the database) around the database itself.

Well, that's a logic way of doing it. Interfaces (in this case, pages) are always pain in the neck and, regrettably, there is no design to help it.

When you say "Interfaces", do you mean the specific webpages that control the database?

In short term, yes. Although if the page is too complex, you can divide it in sections and use those sections as separated interfaces in the design, this will help a lot. One more thing, try not to think of the database as the final aim. A good database is not useful if the user cannot interact with it properly, so it would help if you give the same priority to both interfaces and database.

I already do split it up: So far, the interfaces are:

Scheduling
Scoring
Box Scores
Player information
Team Information (includes position of team title on the map)
Colors

Sounds good.

Actually, to e precise, I designed the database largely using the old XML files as a template (Oh, were those a mistake). Then I refined the database according to how the data I was presenting would be updated.

That was actually what it has to be done: part from the data presentation to design the database.

Question for you: If I was to bring someone else on board to help with the site, what kind of information should I put together to bring that person on board?

I would have everything defined as you like to become, prepared in a way that anyone can understand it. It would help to have it compartimentalized, so the whole thing can be solved little by little. There isn't any procedures defined for that. It's more a sort of agreemens inside the team work.

My biggest problem is I suck at explaining.

I always think that if you can't explain something, it is probably because you don't have it yourself clear.

By the way, being so disciplined with , I'm sure you'll have some laughs seeing this page: http://enterprise-html.com/ I did

...I'll have to admit I didn't get the humour.

I guess I just have a very odd sense of humour. :p

Is this "showcasing" what is done on business websites?

Yes. It is supposed to be "la crème de la crème", but in the end is the most chaotic thing.

I guess my problem is that I can't really imagine coding like that.

I couldn't either, but pressure can make you do very nasty things