Generic Intranet Mark Ii Project Proposal

Generic Intranet Mark II Project Proposal Contact Information Mayo County Council Pat Carroll, HIS Rick Love, IS Project Leader

[email protected] [email protected]

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 2007version of their application for easy plug and play, but need to supply an iFrameable 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 ). 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.