Web Development

Back to My Resume Index | Back to My Resume

At UMPH, the Web development had started , prior to my arrival in May 1997, with some static pages hosted at an outside Internet Service Provider. There were sites for Cokesbury, Abingdon Press, and UMPH. The Cokesbury site was the one that was to receive the bulk of the effort, since Cokesbury is the retail outlet run by the Publishing House.

UMPH had a group within the Publishing House out together a Website plan and used an outside Web development firm to carry out the design and hosting. Abingdon Press, a wholesale unit, after some exploration with the same outside group, finally used UMPH's IT department Applicatioin Development Group, newly staffed with Web developers, to design and build their Web site.

After my arrival in May 1997, I set out on a reworking and redesigning of the Cokesbury Store site. I began the task of building an initial Product database which included a subset of the existing inventory, and built some Subsections for the site to correlate with the major product areas (Books, Bibles, Curriculum, and Files for Download). The outside ISP we were using had various scripts (CGI scripts) available for linking to a text-based database, so the Products in our first online database were tagged to fit the functionality of the database. Discussion board functions were also one of the CGI scripts added. A database was also created to enable the purchase of downloaded files.

We worked with our IT department to decide on an internal platform for an internal Web environment on which to host the Cokesbury Store and any following e-commerce efforts. We decided upon Microsoft Internet Information Server, based upon an existing MS Windows, Office, and Exchange Mail Server. Also key was the emergence of Active Server Pages as an accessible way to program dynamic Web pages, which was considered crucial for allowing a variety of product information to be organized and presented, along with transaction capabilities. Microsoft Site Server was chosen for its variety of components available for resourcing a shopping experience, but only after months of exploring a Web solution offered by the company whose back-end order processing system had just been purchased. It was determined that their Web interface was too server intensive and would require too much re-eengineering to offer an adequate Web shopping experience.

As we began to explore the means of populating a Product database usable by the Web server and IIS, we decided that we needed outside help in building a data entry environment. Our database unit was unable to give us the amount of time we would have needed of them to help us do the Web-to-data integration we needed for this back-end data entry project, so we hired some IIS specialists to help us, knowing that we would also utilize them inthe Web store project as well.

I served as a liason between the sources of Product Data already existing and the consultants building the Interface for its entry (and import). We also had to be planning an integration phase of linking the data held in the new database (Microsoft SQL Server) with the data in the order Processing system (called "MACS", which used a non-standard, "Turbo Database" which was non-relational and not ODBC enabled).

All this time during the develpment of the new system, I was involved in keeping the outside web site's data up to date, as well as oversee the file download functions (which was the major source of revenue for the Website at that time), and make improvements to the email order form and the automatic email generated by the downloads which were processed like phone orders inside our department.

As plans for the Webstore phase began, I was charged with duplicating some of the outside site functioanlity within the new IIS/Site Server environment, so I worked with the consultants to design a userfriendly way to find and download files, and create a "non-shippable" product area (which we called the "Digital Store"). I also was charged with implementing a forum to carry on from the Discussion Board area we had on the outside provider's site. This was to be short lived, as no effort was applied to hosting the discussions, or doing any kind of encouragement of users to join in any discussions. The links to the discussion areas were removed, and I began to be discouraged about the direction we were headed.

I still had quite a bit to look after in terms of watchdogging the Product data, and there was no way of linking together items in a particular set other than by title. We also started building another Web product offering centered around Reference Material such as Commentaries, called initially "Cokesbury Libraries". Sales were based on subscription allowing online viewing of several reference sets and products, one geared to Pastors, another to Teachers. Poor initial sales of subscriptions prompted a name change to "Cokesbury Subscriptions", with the thinking that "Library" implied a larger set of material. My contention was that there was no online community offered as a resource to this. Indeed, it may well be that the content would be a resource to the Community, and not the opposite. Still, no perceptible interest existed within the Publishing House to offer a way for customers to interact with one another on a Website run by a Publisher of resources for Christian ministry. The emphasis seemed to be instead on moving products, rather than trying to find out what their web customers wanted to find, or what their interests really were.

The Libraries (I mean the "Subscriptons") are served up onthe web in "containers" converted to HTML. The system, then called "Live Publish" (and now "NXT"), take the containers, created by a product formerly called "Folio Builder", and described as "nfo-bases", and convert them into a "collection" of html documents and xml files. These are then served up by the NXT application which runs as a Web application under IIS. The Live Publish version relied heavily upon javascript and passing data between framesets, which made it somewhat difficult to customize to the extent that we wanted, with what I knew of NextPage functions and Javascript at the time we began the project in late 1999.

I was able to extend the existing functions of NextPage which allowed us to link to a separate "Bible window" that opened up into one of four translations based on the link in any of the reference materials. I created the Bible application by using the pop-up window function which existed for popup footnotes that came up in a little separate window. I was able to hook this window to the four Bible translation "collections", and build (with lots of help from several people entering lots of data) a Bible database that linked every verse in the Bible to the correct document in the collection. The Bible translations usually differed in the way they broke the Bible into documents. The RSV and KJV were one document per chapter. The NRSV and NIV broke it into "pericopes", which often spanned across chapters. In order to allow a user to "change" from viewing one translation to another, the application had to know exactly which document in the NIV collection contained the same verse or verses being viewed in the KJV, every verse in each of the four translations had to tagged with what document ID held that verse in its scope. A consultant helped us extract the IDs from an XML file into a database, giving us a list of every document in each of the translations. We then linked that data to tables for every book of the Bible which allowed the links information in the href querystring to point us to the correct ID and open that passage in the "Bible Window", in the present "selected translation". The "default" translation opened in the Window is stored as a user preference in a cookie. We will be adding Lectionary Sunday information to these Bible tables as we move on in our presetn project, SermonConnection.com

Sermon Connection is a collection of sermons gathered mostlyfrom users, as a way to collect the content being written and delivered by users, provide relevant resources for worship, and to connect them with each other. It is the first time (since the initial few "user forums" we had at the start of the Cokesbury.com Web project) that we intentionally include this feature (sadly enough).

NXT is also providing ways , through a COM service running within its application framework, to utilize nearly all of the information inthe content collections in an ASP environment, which greatly expands the range of ways all of these content collections can be presented.

Earlier in 2001, I began using Macromedia Dreamwever/Ultradev 4 as my Web editing environment. Ultradev has a variety of "data access" tools that work with ASP, JSP, and ColdFusion scripting environments. I have found it to be a very useful tool to quickly create the functionality that we seek interms of user sessions and data display. Macromedia released Macromedia Studio MX in June 2002. We upgraded our suite to MX, and I have been using Dreamweaver MX and Fireworks MX since then.

SermonConnection is now approaching 1 year since launch (it launced in January 2002). We added User Profiles and Church Profiles to the feature list. We also added an "archive feature" to save versions of pages that feature copy that changes at least monthly. The "Featured Preacher" page uses this functionality, allowing users to see "Featured Preacher of the Month" from earlier months. This feature will be able to be easily applied to any page in the site with the use of some code in the side bar like that on the Featured Preacher Page right sidebar, by simply changing the code for what pageID number was the original pageID number of the page archived.

Back to My Resume Index | Back to My Resume

© Copyright 2003 Dale Lature. Last update: 9/23/2003; 3:37:14 PM.