WebForum

The old pages are generally quite good--they provide easy links to Atlas pages that are difficult to find, and they provide easy
access to specific types of information. Since the group has grown and evolved since the pages were first created, the information
should probably be re-organized a bit with a thoughtful balance between amount of information on individual pages and the depth of the
overall web tree.

I know several of us keep our own "tips and tricks" pages; perhaps these could be merged or linked to.

One nice thing about the old pages is that they are static, and therefore quick and reliable to load. Rather than using
Confluence for everything, perhaps we want to continue maintaining a set of static pages for links and basic information. If the
pages are put into a CVS or SVN repository, then it would be easier for people at CERN to edit and we would have a useful record
of past information, if needed.

Recipes (suck as how to do Atlas computing at SLAC) should probably be moved to Confluence.

I definitely think we should migrate to a Content Management System or
a Wiki. A full-flegded CMS may be too much to ask for, but I think a
Wiki should do for most of what we need. Having maintained some of our
static web space myself, I always found it quite laborious to do and
actually rather anachronistic. I doesn't matter to me whether I edit
html from CERN or from SLAC, it's just more hassle than it needs to
be. Sometimes that has stopped me from making a quick correction or
update. And I'm sure it has stopped other people from doing anything
with our web.

As to finding things, a Wiki can offer much help there, such as a
left-side navigation bar and a search box. We could easily add these
to our main page and I suggest we start experimenting with that.

Confluence may not be the sharpest looking Wiki out there, but there
is a lot we can do to improve on its current look and feel. I suggest
we start by hiding the automatic list of children and rather add some
page content that links to them. (We are really doing this in a very
minimalistic way, even adding a leading space to bump up an item in
the list - if that' what I think it is.) Confluence can be themed, and
we can add style sheets as we have for our static pages. (I don't know
if anyone noticed, but the yellow background and centered title are
actually a style...) There are some example pages on SLAC Confluence
that do look quite acceptable.

I would suggest we start migrating the static pages that are most in
flux, or most fitting for Wiki editing, or would most benefit in other
ways. For the static main page, an perhaps some others, I agree with
Michael, it has served us rather well. My suggestion would be to add a
link to our alternative Wiki main page, begin to populate that, and as
the link starts to get more hits than the static page, swap the links,
and stop editing the static page.

My impression from people's complaint is that the top page is too dense with too much details, making it difficult to find the categories of information. Some specific proposal:

a) drastically reduce the top page to just links to major categories, e.g. move detailed info on ATLAS documentation, computing etc into subpages. However, I do believe we still need the subpages for even some of the ATLAS global documents, as Michael pointed out that they are sometimes very hard to find which originally motivated us providing these links. The reduction will certainly include collapsing the various meeting info to subpages.

b) if there is a simple and convenient way to bubble hot news and recent events on the top page and then automatically expire them, it would be quite useful. However the key is it has to be simple to do and minimal maintenance.

c) In what mode we want to use our confluence home ? This current form started out with the aim of a working page to provide convenient links. Then we also used this as pointers for potential job applicants, students, and the SLAC link in global ATLAS / US ALTAS / DOE pages. This probably needs be `beautified' somewhat with suitable graphics etc. and become the main function of the current static page at slac/exp/atlas/ which is linked to the confluence for anyone interested in the working information.  This part we can consider to have TechPubs looking into a more professional design look to it.  Once made this funcationality separation, we then don't have to worry the conflictory need on the confleunce top page to serve public information and keep graphics to minimal for fast page loading. Michael has an interesting point whether static pages load faster than wiki. For the top page, both public and wiki, it is an important factor for consideration. 

d) Once declared the working page nature of the confleunce top page, we can probably add a left tab item for the internal protected page as well  (but indicates it is protected and for SLAC group only). If we were to migrate this section of our web, how does the protection work in confleunce ? Do we maintain the current protection or just use the confluence login to reduce the cateories of logins (but ATLAS confluence group has non SLAC-ATLAS members ?

Before we go too far with confluence one thing that needs urgent guidelines is the wiki name of the pages. It is a useful covenience to provide automatic links as you construct newpages, but once grew beyond a few people and more than a few pages, the page naming would become completely unsystematic and sometimes one can get spurious accidental links if someone generated a wiki page took out a simple generic name. A completely systematic wiki naming convention unfortunately result in very long names which are also impractical. The static page system with sub directory structures on AFS are still better to me for locating pages. For example, if you completely failed to find where are the links to the rotation student projects we offered a year ago, as long as you know the  AFS root to /slac/exp/atlas/, it should not take you more than a minute to locate it (assuming you know some basic unix). For wikis, my impression is that unless there is a very well organized hierachical linking tree like static pages, you may be doomed in finding something like that. Providing clear guidelines on confluence subject category tree is probably an essential initial step to make this work.         

Su Dong