form suggestion
Posted: Fri Feb 22, 2013 2:28 am
I was looking at the neat forms for recording sacrament meeting speakers and music on this section and thinking.
Here the lady in charge of the bulletin gathers the information from various sources. The chorister gets her the songs, the bishopric the speakers. So that information is written down once by the provider and again by the lady putting it in the bulletin. She then emails the bulletin to the bishopic and they check it over at the meeting Sun morning. They then copy big chunks of it over to a sacrament meeting agenda form that they use to keep from making mistakes running the meeting. Then if I was ward clerk were using the forms above I would be copying all that information again. The same information is entered 4 or 5 times.
The dream set up would mean it was only entered once and flowed through everyone's hands. I don't see how to accomplish that one but we might be able to come close. What if a data base was put together to do the bulletin, the sacrament meeting agenda and the speaker list and music lists. It might start from the chorister or from the bulletin stage. Most of the information would just be added as it was emailed from each person so everyone was only entered once.
Maybe the spread sheet gurus here will see a way to do it that way but my guess is to work with the minimum of effort on everyones part it would be a database of the information for say a whole year that was just passed repeatedly around the loop as information was added. It should include several standard bulletin forms. Maybe a single page portrait and landscape, a half page doubled for designed to be printed and then cut in 2 and landscape folded in half bulletin. It should probably also include a couple of different sacrament agenda forms. Finally it should provide a list of members and how many times they have spoken in the last calendar year and how many times each song has been used back to the chorister.
As for the data base structure each weeks entry should probably include date, presiding, conducting, chorister, organist, invocation, benediction, 6 song slots, 6 speaker slots and maybe a couple of logic flags for special events. The 6 song slots would be opening, sacrament, intermediate, 2 special music and closing. The 2 special music is to give more room to list people involved if needed without the database size getting too huge. 6 speakers would cover the worst case meeting I have ever seen that wasn't just done as an under the direction of _____(primary, seminary, stake presidency, etc). The special flags might cover things like testimony meeting, primary program and ward conference, stake conference and general conference. This would both allow these to show in the final report easily and allow for easy setups for special bulletins. To make laying the bulletin out easy the speakers and the music maybe should have an integer order flag beside them to make custom orders of operation easy to set. Simple say 1, 2 ,3 4, 5 to set the order for those events. If there were a couple of associated databases so auto completes worked it would save typing time. Likely an auto complete from song number would be wanted, an auto complete for names coming from preferred name from ward list, a presiding/conducting/chorister organist database to limit the chances of mistakes there and finally a database of people not on the ward list like missionaries, HC or stake presidencies who talk. Since who is conducting rotates on a monthly basis here and mostly the chorister and organist is the same if those defaulted to the person who did it last week it would save editing them most weeks. For wards that rotate those faster maybe allow a couple of other default ways of setting things(maybe a 2,3,4 week rotations). If those filled in automatically and even if they needed change came from a very small auto complete data base virtually no time would be taken there. If the songs auto completed from # things would be speeded up there and speakers would be faster to enter with an auto complete.
When printed the table for a single meetings information in the final might be a column for date, a column for the labels(presiding, conducting, chorister, organist, invocation, benediction), a column for those names beside it, a column for the 6 speakers and a column for the musics. If the flags just set color codes on the information they wouldn't even have to be displayed. The order flags would only matter for the bulletin so they wouldn't need to display. This would be nearly narrow enough to fit reasonably on a portrait page. If each week took 6 lines to display and you could keep it narrow enough to fit portrait then it would only take 7 pages to print.
If the database kept a full year worth of entries then the reports would always have a full year to show the person they were going to for music and speakers. Probably the easiest structure would be to use week of the year as the record number. That way you would overwrite the records when they got a year old always maintaining a years worth of history. If it was set up so saving the bulletin for a given week set the date on the next record to the current year and date and wiped that record clean(maybe fill in the defaults at the same time) that would cost you one week but probably would likely make designing the report forms easier. Then each person in the chain would simply email the database to the next person in the chain. If each person also had their copy of the database on their own computer then breaks in the chain of custody wouldn't matter much. If the database was set to default to the current Sun if it was Sun and to the next Sun the rest of the week date mistakes should nearly be eliminated.
As for why you might want to do this I am going to guess it would save 15 to 30 minutes total a week for the various people involved. If it was 30 minutes a week that would mean over the course of a single year you would save a man day of work per ward using the system. As for sharing the file if each of the people involved set up a group email list that they forwarded the file too then everyone could have the latest version in their email. All they would have to do is save it back to their drive edit their piece and attach the same file every week to go to everyone else in the group. Different people might have different forms for interacting with the database. For example the chorister would only need the ability to enter music and to print songs used. This would also provide a little security on the database.
Any thoughts or suggestions? Doable with reasonable effort? 20 years ago hard coding this as a stand alone program in Clipper 5.1 would have only taken me a few evenings. Any more I don't have much familiarity with current database programs. Probably the ideal would be to simply code this as a structure under one of the versions of Open office since that is what the church is encouraging using currently. Then people could adjust it to fit their needs better.
Here the lady in charge of the bulletin gathers the information from various sources. The chorister gets her the songs, the bishopric the speakers. So that information is written down once by the provider and again by the lady putting it in the bulletin. She then emails the bulletin to the bishopic and they check it over at the meeting Sun morning. They then copy big chunks of it over to a sacrament meeting agenda form that they use to keep from making mistakes running the meeting. Then if I was ward clerk were using the forms above I would be copying all that information again. The same information is entered 4 or 5 times.
The dream set up would mean it was only entered once and flowed through everyone's hands. I don't see how to accomplish that one but we might be able to come close. What if a data base was put together to do the bulletin, the sacrament meeting agenda and the speaker list and music lists. It might start from the chorister or from the bulletin stage. Most of the information would just be added as it was emailed from each person so everyone was only entered once.
Maybe the spread sheet gurus here will see a way to do it that way but my guess is to work with the minimum of effort on everyones part it would be a database of the information for say a whole year that was just passed repeatedly around the loop as information was added. It should include several standard bulletin forms. Maybe a single page portrait and landscape, a half page doubled for designed to be printed and then cut in 2 and landscape folded in half bulletin. It should probably also include a couple of different sacrament agenda forms. Finally it should provide a list of members and how many times they have spoken in the last calendar year and how many times each song has been used back to the chorister.
As for the data base structure each weeks entry should probably include date, presiding, conducting, chorister, organist, invocation, benediction, 6 song slots, 6 speaker slots and maybe a couple of logic flags for special events. The 6 song slots would be opening, sacrament, intermediate, 2 special music and closing. The 2 special music is to give more room to list people involved if needed without the database size getting too huge. 6 speakers would cover the worst case meeting I have ever seen that wasn't just done as an under the direction of _____(primary, seminary, stake presidency, etc). The special flags might cover things like testimony meeting, primary program and ward conference, stake conference and general conference. This would both allow these to show in the final report easily and allow for easy setups for special bulletins. To make laying the bulletin out easy the speakers and the music maybe should have an integer order flag beside them to make custom orders of operation easy to set. Simple say 1, 2 ,3 4, 5 to set the order for those events. If there were a couple of associated databases so auto completes worked it would save typing time. Likely an auto complete from song number would be wanted, an auto complete for names coming from preferred name from ward list, a presiding/conducting/chorister organist database to limit the chances of mistakes there and finally a database of people not on the ward list like missionaries, HC or stake presidencies who talk. Since who is conducting rotates on a monthly basis here and mostly the chorister and organist is the same if those defaulted to the person who did it last week it would save editing them most weeks. For wards that rotate those faster maybe allow a couple of other default ways of setting things(maybe a 2,3,4 week rotations). If those filled in automatically and even if they needed change came from a very small auto complete data base virtually no time would be taken there. If the songs auto completed from # things would be speeded up there and speakers would be faster to enter with an auto complete.
When printed the table for a single meetings information in the final might be a column for date, a column for the labels(presiding, conducting, chorister, organist, invocation, benediction), a column for those names beside it, a column for the 6 speakers and a column for the musics. If the flags just set color codes on the information they wouldn't even have to be displayed. The order flags would only matter for the bulletin so they wouldn't need to display. This would be nearly narrow enough to fit reasonably on a portrait page. If each week took 6 lines to display and you could keep it narrow enough to fit portrait then it would only take 7 pages to print.
If the database kept a full year worth of entries then the reports would always have a full year to show the person they were going to for music and speakers. Probably the easiest structure would be to use week of the year as the record number. That way you would overwrite the records when they got a year old always maintaining a years worth of history. If it was set up so saving the bulletin for a given week set the date on the next record to the current year and date and wiped that record clean(maybe fill in the defaults at the same time) that would cost you one week but probably would likely make designing the report forms easier. Then each person in the chain would simply email the database to the next person in the chain. If each person also had their copy of the database on their own computer then breaks in the chain of custody wouldn't matter much. If the database was set to default to the current Sun if it was Sun and to the next Sun the rest of the week date mistakes should nearly be eliminated.
As for why you might want to do this I am going to guess it would save 15 to 30 minutes total a week for the various people involved. If it was 30 minutes a week that would mean over the course of a single year you would save a man day of work per ward using the system. As for sharing the file if each of the people involved set up a group email list that they forwarded the file too then everyone could have the latest version in their email. All they would have to do is save it back to their drive edit their piece and attach the same file every week to go to everyone else in the group. Different people might have different forms for interacting with the database. For example the chorister would only need the ability to enter music and to print songs used. This would also provide a little security on the database.
Any thoughts or suggestions? Doable with reasonable effort? 20 years ago hard coding this as a stand alone program in Clipper 5.1 would have only taken me a few evenings. Any more I don't have much familiarity with current database programs. Probably the ideal would be to simply code this as a structure under one of the versions of Open office since that is what the church is encouraging using currently. Then people could adjust it to fit their needs better.