ASIS Chapter Website Development Issues
By: Steve Duell
Website Committee Chairman - Columbia River Chapter #064
Website Committee Member - San Francisco Bay Area Chapter #006
Introduction
This information is a general discussion and suggested set of guidelines for the development of ASIS Chapter web sites. Please consult the ASIS Chapter Website General Guidelines for more information.
General Discussion
With today's wide variety of web browsers, web development software tools, and web servers, developing an ASIS Chapter web site that can be seen by everyone and that also uses standardized technologies is a challenge that can only be met by exempting at least some of the technologies that are available. Inevitably some members will be forced to use different methods than they are accustomed to using in order to accommodate the widest possible audience.
Of no lesser importance are the issues of administration and developmental procedures. These two issues are intimately intertwined since it will take a close coordination between the administration and an understanding of the web page development process timelines to ensure timely and appropriate web site content. Web development processes and costs will more than likely complicate the administration of maintenance and expansion of the web site. However, with carefully selected and planned web development processes, the administration of the web site should become an easily followed schedule of events that basically only requires a review of the actual content before its release.
Security in the web development process as opposed to the actual security methods that are used to ensure the safe collection and disbursal of web site content is an issue that is certain to instigate much contention since everyone will want their favorites to be used. The issues of paying for professional development as opposed to volunteer development will need to be weighed by the assets of the individual Chapter. Of primary concern should be the safeguarding of password data, tools, and methods used in, and for, the web site. Of secondary concern should be the ability to continue the smooth operation of the web site during transitions in administration and web developers. In essence, security applies to both the web site content and the web site development/maintenance.
Finally, although each Chapter should be allowed to express the personality of its membership and the individuality of the Chapter, there should also be a relative amount of consistent look and feel across all Chapter web sites. Enough, so that members from other Chapters will be able to use another Chapter's web site with a certain amount of confidence in knowing that they will be able to find standardized content and participation processes. A member from any Chapter should be able to quickly register for events on other Chapter web sites as easily as they do on their own "home" Chapter web site. There should be similar methods of navigation and certain basic content that should always be easily recognized and used.
Setting the Ground Rules
In this section, I will discuss where I believe we need to standardize certain ground rules before beginning further discussion involving the web site's actual development.
Domain Names
Because ASIS is a not-for-profit organization, all ASIS Chapter domain names should follow the following conventions:
Domain name should use the .org suffix. (ex., asischapter.ORG)
Domain name should include "asis" as part of the name. (ex., sfasis.org or asismn.org)
An additional or parked domain name can also be used with the .com suffix but the primary domain name should have the .org suffix.
This option is offered as a convenience for members who are unfamiliar with using the .org suffix while browsing the Internet.
Web Browsers
Although there are over 30 different forms of web browsers ranging from cell phones to computer desktops, the two most widely used are MS Internet Explorer and Netscape Navigator/Communicator. But to further complicate matters, many of today's web browsers have released multiple versions that are not compatible with their predecessors. And, as a final twist to this dilemma, some of these web browsers can only use the most basic of HTML while others can take advantage of the power provided by additional programming languages.
It is not economically feasible to design an ASIS Chapter web site that can be seen by all versions of all web browsers and it would certainly not be possible to provide all of the different versions with the same capabilities and security. It would also not be possible to maintain a web site of this complexity with any sort of reliability when it came to being able to produce timely or even urgent updates. The testing and debugging of such an immense project would probably drive most volunteer ASIS members into an early retirement.
Of the two most popular web browsers, their version 4.0 and newer versions offer the greatest measure of security protection methods although Netscape has had a history of serious security breaches of its core coding. Both web browsers now offer online updates for their software however Microsoft appears to have won the race for being able to provide the most secure Internet protection methods.
From a web developer's viewpoint, coding for a Netscape web browser presents the greater challenge since this web browser is unable to perform many of the integration features that MS Internet Explorer offers. Of particular note is that while Netscape cannot understand VB Script (created for MS Internet Explorer) MS Internet Explorer can understand both VB Script and JavaScript (originally created for Netscape). Of equal disappointment is Netscape's inability to provide a consistent display of web content especially in the display of table contents.
We should standardize the ASIS Chapter websites to be displayed properly on MS Internet Explorer 4.0 and newer web browsers for the following reasons:
MSIE is more stable than Netscape.
MSIE offers better integration to MS databases like MS Access (for future expansion.)
MSIE provides better online support.
MSIE is more widely used than Netscape.
MSIE uses an interface that is intuitive to most Microsoft users.
MSIE uses less computer resources than Netscape.
MSIE offers integration with the MS SharePoint services (for future expansion)
Web Development Tools
There are a wide variety of web development software tools and although they all perform many of the same functions, they also frequently take vastly different approaches as to how the software is to be used, how web pages will be produced, how sites will be structured, security procedures, flexibility, and other similar aspects. It should also be noted that there is a significant range in price for these software tools and their update versions.
Since an ASIS Chapter web site is expected to be operated continuously for many years, it is reasonable to expect to continue using software tools that are economical and which will not present an overwhelming challenge to learn for future web developers having to take over the web site's development. Of equal importance is the support for these tools including user groups, manuals, tutorials, training seminars, and online technical support. Finally, the choice of software tool vendors should include companies who are respected and who are major players in the web development software industry.
While it may be reasonably argued that using an off-brand of web development software might prevent some forms of tampering because of its unfamiliarity to potential troublemakers, I would counter by saying that using an off-brand would present more problems than it would solve. First and foremost because of the loss of widespread technical support and secondly because it would make web developer transitions and troubleshooting considerably more challenging than they should reasonably be. It should also be noted that should this vendor fail to keep its market and quit unexpectedly, the ASIS Chapter web sites could find themselves facing substantial costs in transitioning their web site to accommodate different software tools.
It is this author's opinion that MS FrontPage offers the best solution as a standardized web site development software platform for the following reasons:
Stable company history
Very well supported
Available in a light version as part of the MS Office Professional suites
Relatively low cost
Extremely powerful
Well developed security methods and methodologies
Widespread use (#1 web development software tool in the world)
Easy integration with other Microsoft products
Administration
The administration of the Chapter website should always be overseen by a duly elected representative of the Chapter in the form of a Website Committee Chair. This committee should be responsible for approving the web site's content, choosing to add or remove web site features, determining a schedule for the presentation of web content, gathering and supplying the webmaster with the web content, authorizing responsible content providers, and working with the webmaster to ensure that the web site security does not become compromised.
It is recommended that Website Committee members be actively involved members who are well informed about the Chapter's activities and vision for the future. They should work closely with the Chapter council to make sure that all web content conforms to ASIS policies and procedures. These committee members should also have a firm understanding that the Chapter web site needs to always present a professional appearance and that it should never become a platform for content that is controversial or inaccurate.
Not all of the web site's administration will be telling the webmaster how to change the web site. Other administration duties should also include:
Sending out group email messages/announcements.
Overseeing who is authorized to update the web site.
If the web site has password protected member only areas:
Making sure that only legitimate ASIS members are granted access.
Making sure that all expired or security risk authorizations are removed.
Deciding which non-Chapter members will be granted access and how long that access will be permitted.
ASIS Regional Officers
Web developers
Guests
Visiting Chapter Officers
Deciding which content should be placed in the members only area.
Notifying new or transferred members about when they have been granted access to the members only area.
Standardizing Website Features
This section is not intended to be a list of the required features of a typical Chapter website; but rather it is intended to assist in establishing guidelines for navigation methods, legal obligations, and similar aspects of the website that will not interfere with a Chapter's self-expression. Controlling Chapter websites in this manner should allow ASIS members to find all Chapter websites equally accessible and navigable.
NOTE: The following discussion is based on the precept that the version 4.0+ web browser will become the standard as discussed previously in this document.
Navigation
We will begin by presuming that there will be at least several types of web pages that will become required by all Chapter websites. The most common of these will probably be; the homepage, a calendar of events, and the Chapter officer contact information. Therefore, these 3 pages should be accessible by a hyperlink at all times while a visitor is at the Chapter website.
Naturally, in larger sites it will be unreasonable to make dozens or even hundreds of hyperlinks to all of the website's web pages available to the visitor at all times. There will undoubtedly be submenus and pre-sorted menus that will need to be developed in order to make navigation of the website easier. Although these ancillary menus may be necessarily complex in certain cases, they should still maintain a certain level of conformity with ASIS established navigation methods.
Beyond the methods used to navigate, is the ability for visitors to be able to recognize the names used for various website features. For instance, imagine the confusion for a visitor if the following terms were used by different Chapter websites to refer to the same type of content; Talk to Us, Contact Us, Officers, Members, Who We Are, or Contacts. It should quickly become evident that determining what primary web features are known by should also be standardized.
Non-Framed Architecture
In a non-framed architecture, the navigation to major website features will need to be included on every page. Ideally, this navigation structure would allow a visitor to instantly navigate to any other page in the web site however this would probably not be possible for extensive websites. Therefore we will concentrate on being able to navigate to the three example website features.
Access to these features should be immediately visible whenever a web page is loaded. This can be accomplished by placing the menu within the first 100 pixels of page length. By keeping the menu in the top 100 pixels, it is possible to display the menu without scrolling for the majority of web browser display dimensions. If the website will be using a 'side menu', then the menu should be on the leftmost side and should not extend more than 150 pixels wide.
Displaying this navigation menu can be accomplished using a variety of methods. It is recommended that, unless there are special circumstances, menu navigation methods should be limited to:
Textual Hyperlinks
Banner-sized Image Maps
Labeled form buttons
DHTML or JavaScripted image layover buttons
Sitemaps are web pages that allow a visitor to go directly to virtually every feature on the website. A sitemap is a very efficient way for a website to give its visitors quick access to their website and, with some clever use of graphics, even show some of the Chapter's creativity. For extensive Chapter websites, it is recommended that a sitemap be created and added to the global menu.
As an optional form of navigation assistance, Chapter web pages may wish to include a hierarchy label. For instance, the following hierarchy label could be used:
Home|Newsletter|Archives|1998|September|
This would help the visitor to keep track of where they had navigated to within the Chapter website. Clicking on an item in the hierarchy label would take the visitor back to that previous level or menu.
Submenus, when they are necessary, should always accompany but never replace the global menu. If you will imagine the global menu as a "comfort zone" for visitors, then it is easy to see why this global menu needs to remain visible. We do not want to ever give visitors the impression that they have wandered into somewhere and that they have now become lost with no way back. In most cases, submenus should only be visible when they are necessary for navigation within a specific area and then remain hidden until needed again.
Framed Architecture
In a framed architecture, presenting a global menu of the three example web site features becomes a much less time-consuming task. The global menu only needs to be created once and then placed into one of the parent frames as opposed to placing a copy on every web page. This type of global menu also reduces maintenance and new web page development time.
As any frameset web developer already knows, it is essential to make sure that all hyperlinks within the website contain a target= tag to make sure that the destination web page is displayed in the correct frameset frame. When regarding the menu items, care should always be taken to ensure that the menu is never accidentally replaced by a destination web page. Likewise, care should always be taken to ensure that visitors exiting the Chapter website will never find themselves "trapped" with the Chapter's frameset.
Submenus, when they are necessary, should always accompany, but never replace, the global menu within its frame. If a group of web pages needs to be accompanied by a submenu for navigation, a new frameset should be nested within the parent "target" frame and the submenu should be displayed within the nested frameset. This way when the visitor leaves that area by choosing an item in the global menu, the nested frameset will disappear without affecting the visitor's ability to continue navigating the website as before.
On the topic of target frames, please use the following standards:
_self Used for hyperlink destinations that will replace the currently framed web page.
Recommended for: Normal Chapter web pages
_top Used for hyperlink destinations that will cause the visitor to completely exit the Chapter web site.
Recommended for: External websites, framed external websites
_blank Used for hyperlink destinations that will provide additional information but opens in a separate browser window so that the visitor will not have to re-navigate back to the Chapter website.
Recommended for: Reference content from external sources, pop-up FYI windows, some password protected Chapter website features
Transitioning from non-framed to framed architecture
If a Chapter website has complied with the non-framed architecture guidelines suggested above, then transitioning to a framed architecture should not present any major problems. In short, the web developer should only need to create a framed menu structure and then remove the old individual menus from the web pages.
Perhaps the most time consuming part of this process will be making sure that all pre-existing hyperlinks continue to display the destination in the correct frameset or window as the case may be. In particular, hyperlinks that point to other websites should be sure to use the _blank target as described above. We will want to be sure that we do not inadvertently end up displaying other websites within the structure of the Chapter website frameset. This latter item being commonly known as "trapped within frames".
The main advantage of using a frameset is that it reduces the website overhead from both a web developer's perspective as well as from a web browser perspective. The web developer will not need to worry about updating the menu on all individual web pages each time there is a change. And the web browser will be able to load the individual web pages faster because the amount of individual web page coding will have been reduced.
Legal Obligations
Since ASIS is a volunteer organization, it is reasonable to assume that much, if not all, of the content will be the intellectual property of local Chapter members who deserve to be recognized for their contributions by using either a by-line or copyright notice as needed. The same applies to external or other copyrighted content that is used on Chapter web pages. The basic premise should be, "give credit where credit is due."
This author suggests that the following legal guidelines be followed:
If it is copyrighted material, visibly include the copyright on the web page.
If it is member contributed original material, include a by-line unless a copyright has been requested by the contributing member.
If it is reprinted material, visibly include the source and any copyright notices.
If it is custom artwork, visibly mention the artist credit somewhere on the page and/or as the ALTERNATE text for the image.
If the Chapter does not have permission to display the copyrighted content, then it should not be anywhere on the Chapter web site, visible or otherwise.
The web page creator should be visibly acknowledged.
This information may also be hidden as a comment within the unseen page code.
Member contributed content should become the property of the local ASIS Chapter and copyrighted as such.
Web Development Procedures
The actual development of the web site should be a carefully orchestrated event with considerable testing performed before it is ever released to the general public. There needs to be a balance struck for opening up the beta web site for the Chapter to review and for making changes to it while being careful to not make public any confidential security procedures. This careful scrutiny also needs to be applied when developing additions to the web site at a later date.
This document is not intended to produce an action plan for developing an actual Chapter web site; it is more for making sure that reasonable development procedures are put into place that will protect the content, the security procedures, the legal rights, and the continuity of the web site.
Suggested procedures would include:
Creating multiple off-site backups of all files
Ideally there should be three different off-site backups made of the web site's files. The first should be provided and stored by the web developer. The second should be provided and stored by the ISP. And a third copy should be sent to and stored by the Website Committee.
Creating a password protected beta version for review purposes
During the development of the beta web site, an online version of the web site that is hidden behind password protection should be made available and frequently updated. It is recommended that this beta site be maintained for two purposes; first, for review purposes by the Website Committee, and secondly for testing and refining the web site when use of a local web server would not be useful.
Granting access to the beta web site
It is recommended that very few people have access to the beta website and that web development privileges be strictly monitored. A recommended group of authorized personnel would include no more than:
Chapter Website Committee Members
Chapter Council Officers
Regional Council Officers
Required Web Developer(s)
No more than 3 other authorized people
There are several reasons for severely limiting the access with security being the foremost reason. Due to the unavoidable conflicts in opinion that will occur when there are multiple decision makers, reducing the number of involved personnel will greatly aid in speeding the development of the web site and the time taken to reach final decisions. Finally, initially establishing a limited number of authorized personnel will reduce the amount of hurt feelings by members who will lose their access once the web site is published and will help "set the tone" for future interaction in the web development process.
Creating and maintaining relevant documentation
Documentation of the web site should be a required component of any Chapter web site. The documentation ensures that in a "continuity environment", like an ASIS Chapter is, needs to have this documentation to ensure a smooth transition between future Website Committees and Website Developers. It is the form and complexity of this documentation that should be discussed in this forum.
Three types of documentation should be developed for all Chapter websites:
Website Owner's Manual
The Website Owner's Manual should always be a living document that describes the Chapter's website features, non-technical explanations of website methodologies, Website Committee policies and explanations, future expansion plans, and other content as needed.
Web Developer's Notes
The Web Developer's Notes is documentation that is necessary for the web developer to take care of the Chapter website. This includes ISP data, custom scripts, unusual development procedures, website architecture, file-naming schema, and similar relevant information. This information will include the technical information necessary for a new web developer to continue the web site's operation with this complete disclosure.
Security Documentation
The Security Documentation is information that is shared between the Web Developer and the Chapter Website Committee as pertains to authorized access to the website, e-commerce transactions/reconciliation, security clearance levels, and other confidential information that may be selectively shared as needed. This information should be released on a "need to know" basis.
Preparing a Post-Publication Activity Checklist
A Post-Publication Activity Checklist should be created and used for final configuration activities and procedures that can only be performed after final publishing of the website. This activity list should be confirmed by both the web developer and the Website Committee chair. As a part of this checklist, it is recommended that the website receive a final review to be sure that it complies with the policies and procedures that come out of this Chapter Website Task Force.
Examples of items that may need to be configured after the website is officially published include, but are not limited to:
Password access
PICS label for web site content rating
Updating script pointers, copying scripts, etc.
Folder Structure
In order to keep the web site files organized, it is recommended that files be sorted into the following folders using standardized folder names. The folder names should reflect the type of content contained within them. The folders should be organized as follows:
<Root>
Used for the majority of the required Chapter web pages
Images
Used for storing clip art and other widely used artwork for the website
Downloads
Used for files that need to be downloaded, i.e. PDF files, Zip files, other types of non-web page files that are specifically intended to be downloaded and reviewed separately from the Chapter website.
Archives
Used for the storage of newsletters and other standardized reference web pages. This folder could be further organized into sub-folders for each year's worth of newsletters.
When naming folders, it is recommended that uppercase characters not be used. Some web servers will not correctly convert or recognize filenames that use mixed case. For instance, an NT server will recognize 'images' & 'Images' as being the same folder name, whereas a UNIX server would recognize 'images' & 'Images' as being two separate folders. To prevent potential conflicts always use lowercase folder names.
File-Naming Standards
It should be noted right from the beginning that different web hosts will require that a web site's root web page be named something that is specifically recognized by their web server. In some cases, the root web page will need to be index.html but it might alternatively be required to be named index.htm, home.html, home.htm, etc. Therefore, naming the root web page will need to depend on the web server's requirements.
Aside from the naming of the root web page, the following list provides naming standards that should be used:
All lowercase names
No embedded spaces
No special characters
No excessively long names
No cryptic and/or deceptive names
File naming standards can be determined using a guideline for webpages that are similar in content. For instance, when naming newsletter article web pages, the following convention is suggested:
vXiXaX.htm [v(olume)Xi(ssue)Xa(rticle)X.htm] Where X is equal to a numeric value that represents that portion of the filename. Ex. v9i7a4.htm would be decoded as: Volume 9 Issue 7 Article 4.
Another advantage to restricting and complying with naming standards is that if a Chapter website should desire to convert to different software tools, ISP, or a new webmaster at a later date, this preplanning will help considerably in reducing problems. It is also useful in reducing problems that might occur should the pages need to be referenced from within custom scripts.
Summary
This document has outlined many of the concerns and considerations that everyone should review in order to build a solid foundation and framework for chapter website development.
