Generic Intranet Mark II Project Proposal

Contact Information

Mayo County Council

Pat Carroll, HIS pcarroll@mayococo.ie
Rick Love, IS Project Leader rlove@mayococo.ie

Local Government Services Board

?????

Executive Summary

Virtually all local authorities in Ireland have some form of intranet. Since all
local authorities have similar needs, there is an excellent opportunity to share in the
development of intranet-based tools and reports. Mayo County Council therefore
proposes that interested local authorities come together in cooperation with the LGSB to
develop a number of agreed small intranet-based applications which would be shared out
among participating local authorities. It is intended that each participating local authority
spend no more than 2 full development weeks in building applications (this might mean
that the number of applications developed by each authority may vary between 1 and 5).

The project will allow all participating authorities to greatly leverage their effort.
For example, if 15 local authorities were to participate, then a total of 30-60 applications
would be available to each local authority (depending upon the number of applications
each authority agrees to build). This will prove to be extremely cost-effective and will
help to eliminate duplication of effort between authorities. If the project is successful and
there is interest among participating authorities, then a second development round can be
considered.

Mayo County Council has volunteered to coordinate the project at a high-level

with codebase hosting and other support to be provided by the LGSB. However, it will
be up to each local authority to manage its development efforts locally.

Distribution to Non-Participating Local Authorities

It is likely that local authorities who cannot participate in this project may be
interested in acquiring these applications. This issue must be decided by the HIS group
and may involve some form of one-off payment which could be distributed between
group members and/or used to purchase graphic design work, etc. to improve the web
part suite.

Proposed Process

The following process is suggested for this project:

 1. Each interested local authority will submit a list of up to 10 mini-applications they
would like built for their intranet.
2. All interested local authorities will give weighted votes to the complete list of
proposed applications and the highest weighted applications will be prioritised.
3. Each local authority will volunteer to build applications/reports totalling an
estimated 2 weeks development time. Each local authority will also be assigned
applications from another local authority to test the installation and provide QA.
4. Each local authority will create a short specification document for each of their
applications/reports and circulate them to the rest of the group for comment (other
local authorities will have 1 week to comment on each specification).
5. After reviewing comments from other local authorities in the group, the local
authority will then build its application(s).
6. Completed applications will be documented in two ways: developer notes and an
installation guide.
7. Completed applications will be provided to the assigned partner local authority
for QA.
8. When QA is completed (and the product is declared both functional and that its
installation and other documentation is signed off on by the partner local
authority), the final code and documentation will be uploaded to a central location
for distribution to the group (LGSB extranet area).
9. Each local authority will have access to all other applications developed by the
group when they upload their final codebase and documentation to the central
store. This will serve as an incentive to complete the agreed work.

Project Plan

It is proposed that steps 1-3 will be completed by the end of 2008, steps 4 and 5
by mid-Feb 2009 and steps 6-9 by the end of April 2009.

Design Guidelines/Development Standards

To make all developed applications as universal as possible, each web part should
be built as follows:

• Each application should be designed to sit either within an iFrame or to open in a

new window (as a popup). Local authorities can also develop a Sharepoint 2007-
version of their application for easy plug and play, but need to supply an iFrame-
able version for local authorities not using Sharepoint 2007.
o iFrames should allow applications to be no larger than EITHER:
 200 pixels
 600 pixels
• ASP.NET 2.0 or above (C# or VB.NET) with code-behinds, if needed
o Code must use functions/subs/classes appropriately.
o All code must be commented.
 o Web.config variables should be named similar to Tables and Views (see
below). Ex. a SQL connection string created by Leitrim might be called
SqlCon_LM21_Phonebook.
• SQL 2005 back-end
o All connection strings to be stored in the web.config
o All Tables should use either impersonate permissions for staff access or
the custom user GenericIntranetVII with password to be set in the
web.config file.
o Stand alone applications can use their own tables with the following
naming convention: 2 letter local authority code per car registration tags
(Dublin Area local authorities can use 1-2 letters not in use by other
counties and cities can add a ‘C’ after their county designation) followed
by the application id number assigned by the group, then an underscore
and a descriptive name. For example: Mayo might create
MO23_Colours, Fingal might create F23_Colours and Limerick City
might create LC23_Colours.
o Applications that need to be linked to user data (e.g. the staff phone book
or the new Core HR system) will use Views whose names are configurable
in the web.config. This will allow each local authority to connect this to
their localised phonebook, etc.
o Applications that need to insert/update user data should use the LGSB’s
phone book table structure and/or should allow their stored procedure
names to be set in the web.config file.
o All tables/Views/stored procedures must be documented in application’s
documentation and SQL scripts for creating the tables/views/etc. and/or an
MSI should be created to aid installation.
• Each application should be as Accessible as possible. Some basic rules:
o Font faces, sizes, colours, etc. should be set in the linked CSS ONLY (not
inline or using .NET settings or deprecated tags such as <b></b>).
o Label tags must be used for all form fields.
o Applications using AJAX or other JavaScript should function with
JavaScript turned off or have a non-JavaScript version.
o Tables should include proper markup (th, captions, etc.)
o Include language meta data tag, proper document type, title tags, etc.
o Use proper headers and subheaders (all Applications for iFrames should
have an H1 tag; Sharepoint parts should begin with an H2).
o Full rules at: NDA guide
• Style
o All applications should link to a CSS sheet which can be set in the
web.config file.
o Default HTML should be styled the same unless there is a compelling
reason to create a custom class (ex. allow H2s to be styled the same across
all web parts rather than creating a custom class for your H2 tag).
o It is envisioned that a generic CSS will be created for use by all web parts.
However, if you use custom classes, you will need to build a CSS to
 distribute with your application—if you do this, then link to both the
generic CSS and your custom CSS and put only your classes in your
custom CSS.

Documentation Guidelines

Specification templates and documentation/installation templates will be provided

later in the project and these can be modified by each local authority, as needed. A QA
template will also be provided so that local authorities performing QA can record
bugs/comments/etc. in a semi-standard format.