Go to CERN Home Page
Go to AIS home page
[Home] [Search] [News] [Site map]

AIS Web Site Specifications

Final version

Table Of Contents

Introduction
Objectives and standards
    Objectives
    Standards for development
Contents
    for AIS users
    for AIS members
Navigation
Layout
Searching
Authoring & Publishing
WEB based applications
Site administration
Migration to new site
Next steps

1. Introduction

This paper gives the detailed specifications for an Administrative Information Services  web site.  They are meant to cover all aspects of the design and development of a WEB site,  sized ~500 pages. These specifications were  drawn by the project team  during a series of meetings (02/10/98, 06/10/98,08/10/98,13/10/98 ) .

Throughout the paper, we make reference to AIS users and AIS members:

  • AIS users are people within or outside CERN which need to use one of our AIS applications (~3000). Amongst them we have 'power users' who often are computer people in the other divisions (FI,  SPL, PE ) and who extract and analyse the data which we provide for the needs of their services.
  • AIS members are people in the AS-SU and AS-DB groups, mostly engineers but also the Help Desk staff.
AIS members and their management have reviewed a draft of these specifications, and have approved them during a meeting held on 17/11/1998 (See summary of this meeting).
Some representatives of the AIS user community will be invited to  review the prototype of the WEB site and will have the opportunity to comment and suggest.

Between 03/98 and 09/98 a number of task forces were appointed to study specific areas where co-ordination between the two groups should be emphasized. These task forces were the User Interface Task force, Reusable Tools Task force, Workflow Task force and the Standards Task force
The specifications presented in this paper stop where the recommendations of the task force start.
 
 

Back to TOC

2. Objectives and standards

2.1 Objectives

The broad objectives of the project are described in the Goals section of the project's home page. This section covers them in more details. Note that it is not realistic to try to  reach all of these objectives at once. Intermediary solutions may be provided, while keeping in mind those objectives.
  • Guide the AIS user through the WEB site to the information he needs, which could be anything such as:
    • what is PIE?
    • where are the minutes of the latest meeting I took part in?
    • I need to take a  home leave where do I start?
    • where is the CFU user's guide?
    • I need to extract data from HR for statistics purposes, will it be up this week end?
    • How does a person registered in HR come to be known in GESLOC?
    • etc.

    •  
  • Present this information to AIS users in the best possible coherent and logical way;
  • Provide the AIS users a central point of access to all of the AIS applications;

  •  
  • Interactively guide the AIS users, step by step, to complete the Administrative procedures they are asked to follow. (E.g. I need to attend a course given externally, what do I need to do ..?)

  •  
  • Ultimately reduce the amount of first line support needed from the AIS users, especially those who are occasional users of the AIS applications.,

  •  
  • Provide authors of WEB pages in AIS, and developers  with the tools to:
    • concentrate on contents and forget about layout and underneath file structure;
    • easily find technical information needed to do their job (e.g. server map, machine availability), without loss of time ;
    • ease the transfer of knowledge and avoid loss of information when staff, or non staff, join and leave AIS;
    • avoid duplicate development effort by publishing documentation on reusable software components;

    •  
  • Although the AIS Web site will be, in a first step, used by the Computing support for Administration (AS-DB + AS-SU), it should remain opened to other administrative services  so that it progressively covers all Administrative Information.

  •  
  • The specifications listed in this document only cover the pages which are part of the AIS web site.  However, the authors of these specifications were tempted to submit some recommendations for the pages which are part of the AIS WEB applications (See WEB based applications) . These recommendations are the next step to a complete, coherent environment which we would like to offer to the AIS users.

2.2 Standards for development

This  section covers some principles that must be kept in mind when making decisions for developing the AIS Web site.
     
  • Given the size of the AIS WEB site (currently >500 pages ) , it is important to choose the appropriate tool for site design and maintenance. The criteria for selecting such a tool will be:
    • facilities for professional  publishing/authoring;
    • facilities for invalid link detection, site restructuring;
    • openness versus proprietary system;
    • facilities for deriving navigation tool from a repository (database or other);
    • the possibility to export  the AIS WEB site into another site management tool if needed;.

    •  
  • Maintenance of the site  must be fully taken into account, at the earliest stage of design;

  •  
  • The site must be designed so that it may evolve easily (e.g. it must be possible to add new AIS applications without having to redo all the navigation stuff). In particular, the implementation of reusable components will reduce the development effort and add coherence to the site.

  •  
  • The site will exist in the long term, it must be  independent from re-organizations,  so it must be solely described in terms of activities, without reference to today's organigramme.

  •  
  • It is essential that the AIS WEB  pages work consistently on the recommended browser Netscape and, if possible, on the other widely used browser, Internet Explorer. The use of client specific technology such as Java or specific plug ins,  must be avoided, at least in the parts of the site which will be immediately opened to end users;
  • It is important to keep good performances throughout the WEB site. In particular, one should avoid large .gif files in the Navigation bars, or numerous graphics in pages which are most often accessed.
Back to TOC

3. Contents

This section gives an exhaustive list of  all the information that must be available from the AIS Web site. It does not address the question of how this information will be structured nor how it will be laid out and presented to the user. It does not follow an order of importance or priority.

It is divided into two parts, the contents of interest to the AIS users and the contents of interests to AIS members.
 

3.1 Contents for AIS users

  • 3.1.1 Support page

  • This page must describe how to obtain support from AIS. It must also be the access point for all other information related to support (e.g. introduction to the Help desk, recommendations to make support more efficient, links to questionnaires and statistics etc. ).
     
  • 3.1.2 FAQ  - Frequently Asked Questions

  • FAQ must be organized in such a way that AIS users find  the answer to their questions, 90% of the cases. FAQ for AIS users cannot be simply extracted from REMEDY: they have to be sorted out and phrased in a very user friendly way. When AIS members answer to a Remedy log, they should have a possibility to make a reference to a FAQ number, so as to avoid repeating a frequently given explanation.
    The FAQ page(s) must exist both in English and in French.
    The Help Desk can play an active role in sorting out which are the frequently asked question, phrasing them for AIS users and translating them.
     
  • 3.1.3 Dynamic pages of useful administrative data

  • Examples are:
     
    • list of DPOs and DAOs per division
    • List of persons holding a certain signature profile
    • Members of committees
    • who is who + organigramme (pictures/home pages)
    • machine operations, planned interruptions
    • remedy statistics
    • user specific information (e.g.: contact your DPO)
    These pages could be extracted online from our databases or regenerated once a day.
     
  • 3.1.4 Procedures click able maps

  • The idea is to present for each of the Administrative procedures a page with the procedure diagram turned into a click able map. The user might click on part of the diagram to display dynamic information ( e.g.  who is DPO or DAO?) or to get entry point into the appropriate application (e.g. EDH or AVCL) .  This data would be extracted from our Administrative databases (Foundation). Note that, in order to give user specific information, this would require logging in to the AIS web site. These interactive guide pages through administrative procedures should  be implemented in close collaboration to the AS-DI-OP section (Organization and Procedures).
     
  • 3.1.5 Description of service contracts

  • For each application, the AIS users should find information on the level of services provided (run hours, backup plans) -  Such pages could also describe how AIS resources are used and how they link to maintenance activities or projects, so as to give to AIS users an accurate image of our resources deployment.
    The AIS potential clients should also find there the conditions under which new projects may be started (e.g. at the time, it is planned to inherit the Medical Service application, one should define the conditions which apply such as number of staff involved, quality of specifications, realistic time scales etc. ..)
     
  • 3.1.6 An alert zone

  • This alert zone is used to convey to AIS users or AIS members any piece(s) of information which they need to be aware of urgently.
    Examples are
    • announce that one of the machine is down;
    • reminder of a temporary service interruption;
    • reminder of deadlines for annual leave book closing etc..
    We propose to include, next to the AIS logo, an additional icon which will indicate an alert and will invite the user to click to the alert zone.
    AIS users should evidently  not be aware of alerts for AIS members.

    NB: Whenever critical information needs to be pushed forward to end users, sending e-mail remains the most appropriate medium.

       
  • 3.1.7 A desktop page

  • This page should be the entry point of all AIS applications , with one logo/icon per applications. AIS users should also find on this page reference information that may be found in our databases, without entering in the context of one specific application. Examples are directories of suppliers, persons , budget codes etc. ... Finally there should be an icon to open the Feedback form
     
  • 3.1.8 Link to other pages not part of AIS but related to (Manual of procedures, Staff Rules & Regulations)

  •  
  • 3.1.9 Traditional online application documentation (see CFU example)

  •  
  • 3.1.10 Useful e-mail lists

  • The only available dynamic e-mail lists are provided by the Mowgli service and are  based mostly on the CCDB database (e.g. as-su.listbox@cern.ch).
    Our Foundation databases hold a large amount of potential e-mail lists. Examples are:
    • e-mail to all DPOs
    • e-mail to all DAOs
    • e-mail to all CFU users
    • etc..
    The mechanism for producing such lists has been implemented as part of the Foundation application. We suggest to make it available as a service. We are aware of the potential dangers related to the publication of e-mail lists. It remains to be decided if these should be  kept for internal use.
  • 3.1.11 Tutorials on basic concepts, which could contain  a certain degree of animation  (e.g. Las cookies documentation)

  •  
  • 3.1.12 Projects follow up pages

  • This pages would be mostly aimed at our AIS users who participate to projects users group. At a glance such users should find what the. project status is, when is the next meeting foreseen, what are the actions expected from them if any, minutes of previous meetings etc...
     
  • 3.1.13 A map of administration fields

  • The site should include a click able map of all fields of administrations ( Finances, Purchasing, Logistics, Human Resources, Electronic workflow support, Budget management, Goods inventory --). Clicking on a field should display another map to present the components. For example, clicking on Human Resources should bring the user to all components of Human Resources (Administration, Payroll, Training etc..).
    The aim is to provide a coherent and comprehensive view of administration, not as disparate as the view provided when one starts form the Applications point of view.
    At the latest level of this click able map, the user should see the map of applications, their interfaces and how they support business processes
    (e.g., process 'material'/'information' flow diagram  from contract preparation (CFU), purchase requisitions (EDH), purchase
    orders (SIRIAC), goods reception (SIRIAC), invoice acceptance (SIRIAC), invoice payment (ORIAC), reporting on expenditures (BHT), etc.... )
     
  • 3.1.14 News page

  • The AIS Web site must include a News page. This news page must be divided into two parts:
    • one part which is automatically generated from the Site maintenance tool - e.g. all pages that have been inserted/updated today
    • one part with all applications related news,  service interruptions etc. ...
    There is no need to provide a facility for ticking news items  that have already been read.
    We propose to implement a simple database repository to hold this news, as well as a WEB interface to enter  news (a straightforward matter with Designer 2000).
       
  • 3.1.15 Newsletter

  • It is difficult to position an electronic Newsletter in the overall contents of a WEB site, without making it redundant. However, the newsletter we imagine would be an informal way to push forward some information to AIS users  and improve the contacts we have with them.
    The characteristics of this newsletter would be:
     
    • attractive to read with graphics and animation's;
    • simple, one page on the WEB,  with links to the other pages if the user wants to drill down to a piece of news or  information;
    • contain not so formal information such as arrival, departures of new staff etc. ..

    •  
  • 3.1.16 Feedback page

  • AIS users must be encouraged to provide feedback to us, or raise problems. In order to do this, we think it is useful to provide a feedback page. This page would contain a CGI form for the user to enter his feedback/request.  It is possible to feed Remedy directly from this page, for all feedback of type Problems, or e-mail the contents of the form to the AIS help desk  This page would be accessed from the Contact us button on the top navigation bar.
  • 3.1.17 Site map

  • The site map is a single page where all links appear, under their appropriate heading but without a menu structure. This allows experienced users to have a global and comprehensive view, at a glance, of all the information which the AIS site provides.
    A good example of a site map is the BABAR site newly designed site map.

3.2 Contents for AIS members

This section lists some information which will empower the AIS member to do their job more efficiently, provided they can find it easily on their Web site.
  • 3.2.1 Icon and images sources
  • 3.2.2 Systems maps: which application on which server?
  • 3.2.3 System operations: backups? service interruptions?
  • 3.2.4 Database Map: which database & version on which server?
  • 3.2.5 Internal FAQs

  • REMEDY could be used to store solutions to technical problems which are met internally (e.g. all problems linked to Case*Designer)
  • 3.2.6 Technical notes
  • 3.2.7 Maintenance notes
  • 3.2.8 Tips and instructions on using some tools
  • 3.2.9 Useful links to Technical documentation outside (e.g. links to Javascript documentation)
  • 3.2.10 Guidelines on how to publish on the AIS web site
  • 3.2.11 Tools to facilitate authoring on the AIS site (e.g. templates).
  • 3.2.12 Descriptions of roles and responsibilities (e.g. list of tasks under responsibility of the AIS Web master).
  • 3.2.13 Recommendations for ensuring quality in developments ( e.g. mostly outputs of the task forces)
  • 3.2.14 Clues on internal organization (e.g. who is in charge of HR support this week?)
Back to TOC

4. Navigation

We propose to divide the AIS Web site into two 'sub sites'. The AIS User site and the AIS Internal site, as opposed to mixing public and private documents inside the hierarchical structure.

NB: the sub site to which we refer  here does NOT define an area of the WEB with its own web master, own users and access mechanisms. We think that partitioning the  WEB site too strictly would lead us back to today's difficulties to share information.

Not all pages available to AIS users may be accessed by the world outside CERN, although the criteria for selecting these pages have not yet been clarified and, to some extent, are not with the control of AIS (e.g. pages on CERN internal procedures have been declare CERN only by the CLA). The design of the WEB site must take this into account and allow to protect individual pages from outside access.

Pages visible from the Users will have a URL beginning with http://aiswww, whereas pages visible from AIS members only will have a URL beginning with http://aiswww/internal. A single, different background colour all over the  AIS internal site would be a useful reminder to  AIS members of the part of the site in which they are.

It is important that URLs on the AIS Web site  should be coherent. For example if the user is on http://aiswww/bht/welcome.html he should know that
http://aiswww/bht/Docs would bring him to the User Documentation directory.

In order to protect the contents of the Internal part of the WEB site, we propose to apply URL based security mechanism combined with LAS authentication, as it is done today for some of our applications (e.g. Foundation).
A list of allowed cernids/person_id is extracted from Foundation (members of AS-DB + AS-SU + AS-OP) and kept on the aiswww server. When the user requests a URL of type beginning http://aiswww/internal, it is re-routed for logging (first time only) and then allowed, if in the list of cernids/personids.
It is felt to be safer and more user friendly than the standard account/password restriction.

All pages used for navigation should be available in French as well as in English. Other pages may remain in their author's preferred language.

The User Interface Task force has published very useful recommendations for setting up navigation on the WEB. In addition, we have reviewed a large number of sites where we feel that  navigation is easy and intuitive. This brings us to highlight the following specifications for the AIS Web site navigation:
 

  • A static standard menu should appear at the top of each page and provide access to frequently needed information and utilities
     
     
    Home Contact us User forum FAQ Search News Site map Switch to French
     
     
  • The user should not have to go down more that  three levels in the menu before he reaches 'leave pages'
     
  • A navigation bar on the left side of the page.

  • Ideally , this navigation bar should be generated automatically from a repository, which would reduce the maintenance to a minimum. Whether this is possible or not strongly depends on the site design and management tool which we will choose.
We propose one menu for the Users site and one menu for the internal site. The proposed tree structure of these menus appear below in italics.

4.1 Navigation in the Users sub site

      What is AIS ? .............................................welcome.html  ( with a link to organigramme, service contracts)
      Applications ...............................................desktop.html
        AVCL ...............................................welcome.html (introduction page to the application + links to other info)
          Documentation ......................avcl_doc.html (table of contents of user documentation)
        BHT..................................................welcome.html
          Documentation.......................bht_doc.html
        CFU
        CTA
        EDH
        FOUNDATION
        GESCLE
        GESLOC
        HR
        HRT
        ORIAC
        SIGAGIP
        SIRIAC
        TRITON
        Y2K
        REMEDY
      Ongoing projects
        CFU
        PIE
        CSS
        AISWEB
        CTA
        REMEDY
        PROJECTS Management
      Business areas .......................................admin.html (click able map of administrative fields)
      How to? ................................................howto.html (with links to set by setup administrative procedures guide)
      Newsletter ............................................ NL0398.html (with links to previous editions)
      Utilities
         Login/Logout .............................connect.html (with links to login and logout pages)
        E-mail lists
        Useful  data ................................admindata.html (explanation page with links to dynamic pages)
        Useful sites .................................sites.html (with links to all sites useful for the AIS user)

4.2 Navigation in the Internal sub-site

    Users site ........................................................http://aiswww/welcome.html
    Applications
      AVCL.....................................................avcl.html (no welcome, just links, and search internal FAQs)
        Technical notes
        Internal meetings
      BHT
      CFU
      CTA
      EDH
      FOUNDATION
      GESCLE
      GESLOC
      HR
      HRT
      ORIAC
      SIGAGIP
      SIRIAC
      TRITON
      REMEDY
    Ongoing projects
      CFU
      PIE
      CSS
      AISWEB
      Y2K
      CTA
      REMEDY
      PROJECTS Management
    Internal meetings .......................................welcome.html with a link to all internal meetings (rsm.html )
    Tasks forces ...............................................tasksf.html ( with a link to each of the task force home page)
    Systems .......................................................welcome.html (with a link to machines map and operations timetable)
    Databases ...................................................welcome.html (with a link to database map and backup schedules )
    Development tools
      Standards
      Useful sites & pages
      Resuable software components
    Authoring tools
      Templates .........................................welcome.html (recommendations and links to all available templates)
      Icons/Images sources ....................... index.html
      Guidelines ........................................ guidelines.html (for authoring on the AIS WEB site)
    Management .............................................. welcome.html page (with a link to POW, etc ..)
Back to TOC

5. Layout

5.1 Home page

  • Professional looking graphics are considered worthwhile on the home page, while not so important on lower levels. If we can't reach the required level of quality graphics for the Home page, using artistic skills inside the DB-SU groups, it would be worth considering professional design consultancy.
  • There should be a well defined zone on the Home page that we should update regularly so as to convey an image of dynamic, evolving contents as opposed to static, made once for all page. Note that graphics and texts should be updated, but NOT  navigation.
  • The Home page should contain the usual traditional welcome message plus a few, concise guidelines aimed at the occasional user who does not know where to start (e.g. if you want to know more about services provided click there, if you want to submit a problem or give us feedback click there etc. ..)

5.2 Any page

This section lists pieces of information which must appear on all  page of AIS WEB site:
  • The AIS logo and a discrete CERN banner
  • Keeping a colour scheme per application would quickly reach its limit, so we suggest an application logo, to appear on each application related page. From within these pages, clicking on the application logo would bring the user to the Application welcome page.
  • Date last modified in the ISO standard dd.mm.yyyy
  • Limit date of validity (same format) - to help the WEB master to archive all pages which are no longer relevant.
  • For pages under the responsibility of the WEB master, a reference to ais.webmaster@cern.ch
  • For most pages in the Users site the pages should be signed Ais support . Whenever direct feedback to the author is required (e.g. minutes ), the page should be signed with the author's name (e.g.  Francois Briard ). All pages within the internal site should be signed with the name of their author.
  • a Copyright stamp wherever there is any information to protect (e.g. technical notes, projects etc..)
  • Cascading Style Sheets should be used to impose a common layout for all similar pages (as part of the template for example).

5.3 Authoring style

Equally important as the contents and structure of the WEB site is the style used to write the pages. A large amount of literature may be found on how to best write your Web pages. Amongst them, the useit.com site  provides clear guidelines. An abstract of this information will be available from the internal site, to help  AIS members push information to AIS users efficiently.
     
Back to TOC

6. Searching

Standard recommended search engines must be used such as Infoseek or AltaVista.  A search engine such as Compass would allow indexing of useful database information. Some site design and maintenance tools provide their own search facility.  The evaluation, choice and set up of a search engine for the AIS web constitutes a smaller sub project in itself.

Searching on meta-data (e.g. all pages with Project = CFU ) would require that meta -data is systematically entered on each AIS page. This would be difficult to enforce without implementing a rigid front end tool for publishing.

Rather, we suggest that AIS users take full advantage of the search engines search syntax (e.g. CFU + Project). Since AIS users are not always aware of how to take maximum advantage of the search engine possibilities, it will be necessary to create a help page, with simple examples, covering all search cases.

Back to TOC
 

7. Authoring and publishing

It is not clear what is the level of assistance needed by Web authors for publishing on the WEB.  For some authors, it is important to reduce the publishing task to the minimum (entering text, for technical notes for example), while others want to retain a fair amount of freedom when publishing.

Templates will provide to WEB authors a quick way to get started on their documentation tasks, while leaving them the possibility to add/modify them as needed. General layout imposed by CSS should however not be modified.

Templates should be available in English and in French to suit the WEB author's preferred language.

Templates must propose naming conventions (MinDDMMYYYY for minutes) and enforce the recommended file extension .html

We suggest to implement the following templates:

    • minutes of meetings
    • application user documentation ( automatic table of contents ?)
    • project (status, resources etc. ...)
    • technical note
    • AIS related procedure  (how to register a new WEB AIS user ?)
    • development specifications
    • presentations ( a Powerpoint template)
Back to TOC
 

8. WEB based applications

As far as possible, developers of WEB based applications should follow the User Interface guidelines set up by the User Interface task force.
In addition we suggest to implement,  as part of of the AIS Web site, a thin top page banner containing the AIS logo, which developers are encouraged to systematically place as a header on their application pages. From inside the application, clicking on the application logo must bring the use to the application desktop. On the application desktop page, clicking on the logo should bring the user to the application home page.

On each page of the application must appear a reference to AIS support and a CERN copyright stamp.

Back to TOC

9. Site administration

It is the role of the WEB master to perform all tasks related to WEB site administration and maintenance. These tasks, which do not include all the tasks necessary for the design of the site, are listed below:
  • Maintain lists of people who are allowed to author in the site (all AIS members);
  • Define which pages are under the sole responsibility of the web master and maintain them (home page , navigation bars ..);
  • Ensure that all other pages are owned by and maintained by someone in AIS;
  • Organize regular meetings (once every six months?) with some AIS key users to check that evolving requirements are still met;
  • Organize similar internal meetings;
  • Perform periodical analysis of invalid hyper links and report needed  amendments to WEB authors;
  • Monitor pages usage and propose modifications to the WEB;
  • Perform periodical review of the contents and  feedback to WEB authors when needed;
  • Collect comments from WEB authors who do not  follow publishing recommendations, analyze them and propose improvements;
  • Give brief introduction/recommendations to newcomers on how to use the site;
  • Give advice whenever needed about how to use the site (which template, where to put things etc. ...);
  • Archive pages which have reached their limit date of validity, or which are never accessed, or upon instruction from the author;
  • Help other administrative services to move inside the AIS WEB site (e.g. AS-OP);
  • Evaluate new WEB tools which allow to improve/diminish  maintenance effort, as they become available;
  • Set up and maintain a test environment to prepare and test modifications to the WEB site
  • Backup both production and test environment
  • Edit the AIS newsletter on a regular basis (e.g. collect news and articles, compose Newsletter, advertise and publish, monitor interest);
  • Keep contact with the Divisional Web Master . Agree with him on links that are to be shared between Divisional pages and the AIS web site.
  • Serve as a central point for contacts with the WEB office;
It is essential to choose a tool for the design of the site which will also efficiently support the Web master in these administration and maintenance tasks.
Today, two software appear on the Top list for management of sites between 500 and 1000 pages. They are Microsoft Frontage  and NetObjects  NetObjects Fusion.
We have performed a brief evaluation of both tools, as well as simpler tools such as of Visual Page and have come to the conclusion that Microsoft Frontpage provides, at the moment, most of the functionality needed for design, administration and maintenance. In order to ensure that this software actually is the best match to our requirements, we suggest to use Microsoft Frontpage  to implement the prototype for the AIS web site.

Note that new software appear on the market, such as Oracle WebDB, which claims to provide a complete integration of the Web site and of underlying Oracle databases. These software are not mature yet but might be worth switching to in the future.

In order to to set up a test environment, install Microsoft Front page, evaluate new tools and new versions, we think that a dedicated PC is necessary. In addition, if we confirm this choice, AIS will have to purchase Microsoft Frontpage Web authoring licenses  for all AIS members.

Finally, we estimate that, to cover the design and implementation phases, no less than 50% of a FTE will be needed. In a full production phase, this could be reduced to a 30% of a FTE.

Back to TOC
 

10. Migration to new site

Over the last three years, AIS has produced a large number of pages on the WEB. Migrating to the new AIS site will consist in:
  • selecting pages which must move to the new site, and decide on where they must be moved;
  • delete or archive pages which authors do not  think worthwhile migrating;
  • strip selected pages of everything but contents;
  • insert all mandatory information listed in xxx
  • wrap up the pages with the new layout
  • publish them on the new site
  • for a limited period of time (3 months) re-route old bookmarks to new locations
  • suggest to the WEB office to include a link to the AIS Web page from the CERN Home page.
  • get rid of old DB and SU sites;
Although it is possible to write scripts which could help in these tasks, manual conversion might be a good opportunity of getting rid of worthless information. Also we suggest to involve some of our colleagues as much as possible in these tasks, under close supervision from the WEB authors.

We recommend that the DB-SU management set up a migration schedule where persons responsible for applications put aside the time necessary to migrate their pages. PIE and CFU volunteer to migrate first.

We are concerned that, the more this migration is belated, the more difficult it will become, because important documentation on new strategies , new projects etc. .. are being created now. Ideally the migration to the new AIS web site should be completed my mid 99.

Back to TOC
 

11. Next steps

The project team suggests to prepare an implementation plan, using Microsoft project, in order to break down all tasks  and outline their dependencies.

Then the Project Team, together with DB-SU management will also define priorities amongst the tasks, as well as the minimum required to bring the site to life and start using it.
 
It will also be important to define what can be done immediately so that pages created from now on can be effortlessly migrated to the new site when it is ready. For example, it might be efficient to propose some new templates as soon as possible for new projects.

The project team will proposes to create implementation sheets for sub tasks with the necessary specifications, so that these tasks are worked on as resources become available. As an example, one needs to specify the requirements for the alert zone so that it can be developed as an independent task.

We feel that the effort of designing a new web site will be lost if no strategy for using the site is developed and clearly stated to the AIS members. Elements of such a strategy should be:

  • Appoint a AIS web master as a rotating role, with an appropriate percentage of his time;
  • Inform AIS users about the new WEB site (e-mail, bulletin, open presentation);
  • Give demo and clear instructions to newcomers of how to use the site;
  • Back to TOC