Building a photo history for the department is an exciting but daunting project. One way is to have members send you the photos, and then add them to the album. Getting the photos is probably the easiest part. The hard part is getting the story behind the photo. For a whole department, this could be an overwhelming task.
We love to look at photos, and share our photos. Sharing is the key word. It is the basis of such sites as Google's Picasa, or Yahoo's Flickr. What these sites lack is an easy means for creating a community album, and for that community album to be a part of the Department's Web site.
While I had the idea for awhile, I wasn't sure how to implement it. At our son's wedding last December, I floated the idea of creating a domain name for the kids wedding album and providing one place for everyone to share their pictures. Within a week after the wedding, there were almost 1,000 photos in the album. If it works for a wedding, why not a department's history?
The software is Gallery 2, and available at my price - free. Installing the software is easy, configuring all the options takes awhile. After doing the wedding album, it was much easier. If you are doing it the first time, it takes a few days of experimenting to find out how the options work.
It really helps to have a few photos to get started. Once I created the basic structure for albums, the next step is to get more people involved. For example, the Department Historian has an account, the Department Commander has an account. They have their own albums for which they are the owner and for which they are responsibile for adding photos and building their part of the history. The initial photo album is not big, but it is a start.
The next step is to get other officers, program chairmen, and posts involved. This is the part that takes more time. A project takes time and effort to build. It takes promotion, and more promotion. As it builds critical mass, it gets easier. At least, the fantasy is that it gets easier. At this point my job is to promote, administer, mentor, and more promotion.
Community projects like the photo album allow others to be involved in the Web site. It gets more visitors to the site. It becomes a community project, and not an individual project. Only time will tell how this works.
Bill Anderson
Webmaster
American Legion of Montana
Tuesday, January 27, 2009
Tuesday, January 20, 2009
Static versus Dynamic Pages
Occasionally, you hear that a Website is static, while a Web Application is dynamic. This distinction refers to how the pages are generated versus the content. Nor, does it refer to the timeliness of the information.
Anyone who works with the Web knows that the content must be current and it must offer something new to have repeat visitors. If a visitor sees an entry whose data has long passed, it is an immediate clue that the information on the site is not current. The side could is static, in one sense of the term, in that it is not timely.
The content of the site can be timely, and it can change, and still use static Web pages. If the content of a page is a fixed document, it is a static page. It does not make any difference whether it is written in HTML, DHTML, XHTML, because the content of the page is static. For many pages, this is the best solution. There are pages whose only change occurs when the information on the page is no longer timely.
A dynamic page is a generated page, using a language such as Perl, PHP, Java, or Ruby on Rails. The content of these pages change depending on the information requested. When delivering dynamic content, you often have a back-end database that provides the content.
On the mtlegion.org Website, dynamic content appears in a number of different Web Applications. I call them Web Applications because the number of PHP pages is small compared to the number of different pages delivered. For example, the Posts page only invokes two scripts. One for district information and one for post information. The district script only invokes the post script or the officer information script. The post script can inoke the officer information script. The entire department roster runs off of three scripts that invoke the same officer information script. When any change is made, it is made to the database, and every script automatically generates the new information. With dynamically generated pages, I can now add links to the chairpersons on the program pages, and not worry about changing those pages if the chairperson changes. Only the database changes.
The membership services section follows the same rules. Every post goes through the same scripts. What is offered as a service is defined in a database. If a post wants a dffierent level of service, it only takes one change to the database, and all generated pages change.
If any contact information changes for a post. It only requires a change to the database, and all pages change.
The visitor never sees the underlying code. It just makes maintenace and integration of the Web pages a lot easier.
Bill Anderson
Webmaster
American Legion of Montana
Anyone who works with the Web knows that the content must be current and it must offer something new to have repeat visitors. If a visitor sees an entry whose data has long passed, it is an immediate clue that the information on the site is not current. The side could is static, in one sense of the term, in that it is not timely.
The content of the site can be timely, and it can change, and still use static Web pages. If the content of a page is a fixed document, it is a static page. It does not make any difference whether it is written in HTML, DHTML, XHTML, because the content of the page is static. For many pages, this is the best solution. There are pages whose only change occurs when the information on the page is no longer timely.
A dynamic page is a generated page, using a language such as Perl, PHP, Java, or Ruby on Rails. The content of these pages change depending on the information requested. When delivering dynamic content, you often have a back-end database that provides the content.
On the mtlegion.org Website, dynamic content appears in a number of different Web Applications. I call them Web Applications because the number of PHP pages is small compared to the number of different pages delivered. For example, the Posts page only invokes two scripts. One for district information and one for post information. The district script only invokes the post script or the officer information script. The post script can inoke the officer information script. The entire department roster runs off of three scripts that invoke the same officer information script. When any change is made, it is made to the database, and every script automatically generates the new information. With dynamically generated pages, I can now add links to the chairpersons on the program pages, and not worry about changing those pages if the chairperson changes. Only the database changes.
The membership services section follows the same rules. Every post goes through the same scripts. What is offered as a service is defined in a database. If a post wants a dffierent level of service, it only takes one change to the database, and all generated pages change.
If any contact information changes for a post. It only requires a change to the database, and all pages change.
The visitor never sees the underlying code. It just makes maintenace and integration of the Web pages a lot easier.
Bill Anderson
Webmaster
American Legion of Montana
Sunday, January 11, 2009
Forms and More Forms
I just finished adding all the forms required by Posts and Legion Members to out Web site. It was a challenging project, as I have yet to find a source of National forms in PDF or Microsoft Word format. Without the source documents for many forms, I simply had to scan the forms. The PDF files resulting from scanned forms are much larger than those generated from source documents.
Making the forms available on the Web site makes them more quickly available, and reduces the postage cost for sending out forms. However, it is a long way from the ideal solution.
When we talk about using technology, we often forget the more mundane topics. Yet,, for everyday functioning of an organization, forms just as important, if not more so, than social networking. While computers do a great job of generating paper, they can also be used to save trees and reduce costs.
When available, I also made the Microsoft Word version of the form available. Yet, both the Word document and the PDF document can be improved. With both formats, a form can be designed to fill-in fields. For example, PDF has the capability to have fill-in fields. The resulting PDF file can then be send back to the Department without ever have to print and mail the form. Email could replace the FAX, saving paper in the process.
Ideally, every form would be a fill-in the fields type of document, which is electronically submitted. If we get real fancy, we can even complete the form on-line. All this is possible with today's technology. It would be both environmentally friendly and cost effective. In the meantime, it sure would be nice to have the source documents of National forms, and not just printed forms.
Bill Anderson
Webmaster
American Legion of Montana
Making the forms available on the Web site makes them more quickly available, and reduces the postage cost for sending out forms. However, it is a long way from the ideal solution.
When we talk about using technology, we often forget the more mundane topics. Yet,, for everyday functioning of an organization, forms just as important, if not more so, than social networking. While computers do a great job of generating paper, they can also be used to save trees and reduce costs.
When available, I also made the Microsoft Word version of the form available. Yet, both the Word document and the PDF document can be improved. With both formats, a form can be designed to fill-in fields. For example, PDF has the capability to have fill-in fields. The resulting PDF file can then be send back to the Department without ever have to print and mail the form. Email could replace the FAX, saving paper in the process.
Ideally, every form would be a fill-in the fields type of document, which is electronically submitted. If we get real fancy, we can even complete the form on-line. All this is possible with today's technology. It would be both environmentally friendly and cost effective. In the meantime, it sure would be nice to have the source documents of National forms, and not just printed forms.
Bill Anderson
Webmaster
American Legion of Montana
Subscribe to:
Posts (Atom)
