Forum OpenACS Development: Send me your home page

I'd like to get a bunch of people's site root index pages  (/web/service0/www/index.adp, .tcl, .html - whatever you use to power your home page) so that I can look for common elements and modify the current Congratulations page into something closer to what people need.  The idea being that new users can just adjust the home page, instead of basically needing to throw it out or gut it and learn to write a new one.
Of course, the medium-term solution is to make the home page an ETP page, so that it can be configured without touching code, but even then we'll probably want default content, so I don't think this is wasted effort.
Thanks
(email to mailto:joel@aufrecht.org)

Another thing, if you want to read up on home page useability i recommend reading:

http://www.useit.com/homepageusability/studyguide.html

though it mentions things like having a search box on your home page, which we can't make standard because not all usesrs will want to use search... though for those that have it installed this is a good idea.

Ben, although the blogger is great i don't think it should be the "default" application on openacs. I think the front page should only depend on ACS-CORE applications, and not on any non-mandatory apps.

Although blogger is a great app it is really primarily useful for private sites run by individual people and not for companies, non-profits, schools, intranets, etc... it certainly shouldn't be part of the core.

The way to do what Chris and Ben are after is to provide different variants in install.xml (the file that automagically installs .LRN) to make it simple to build custom installs of various packages and to override the default index file with a custom one.

My personal secret plan is to bundle up the blog package, photo album, and similar things into something I've been calling .VANITY (as in the "vanity press", i.e. pay-to-publish press for the vain)

A one-person stand-on-your-soapbox preconfigured install.

Anyway eventually we should be able to allow people to choose between some common configurations if they want.  The installer could even provide a select box with options to choose from based on the different default configs provided by install.xml.  Currently only one "application" tag is allowed inside install.xml but there's no reason we couldn't provide different "application" tags with configuration data inside the file and ask the user to choose.  If only one application is defined it would get autoinstalled without querying the user as is done today for .LRN.

This would support both bundling of single vertical-app tarballs that autoinstall and the choice of several default configurations for the general case.

But we do want to have available a vanilla index page not much different in philosophy from the current one because we still have the developer as a primary target and "real site" builders will be heavily customizing everything.

As far as using ETP ... Lars and I and a couple of others talked at Copenhagen about rewriting acs-subsite to optionally return a portal page or an ETP page instead of the index template.  That would leave folks with the possibility per-subsite of

1. return default index template
2. return custom index template (for the main site that's what's done now, the custom index template at /www)
3. return ETP page
4. return portal

One problem with using ETP right now as our default is that it is still be worked on and rewritten to better fit with content repository paradigms among other things.

This will require upgrade scripts.  This could present a bit of a chicken-and-egg problem when it comes time to upgrade a running OpenACS site if it is still using ETP as its index page.

I'm not sure we want to introduce that potential complexity right now ...

Maybe even make the path to that include an acs-kernel parameter which would ignore it if blank, making it easy to rip out, say, in install.xml if someone builds a custom bundle?

Going along the same path, but maybe a different fork in the road I think it might be helpful to have a few people work on creating serveral type of packaegs (as Don suggested) but in the 'we are copy a popular website because we can' area.  Many of the popular slashdot type software (Post/PHPNuke, etc) were create to copy slashdot.  Why not create an out of the box OpenACS 'Slash' package (which would be simular to the dotVANITY package) or a OpenACS 'Fark' package or pick your favorite site.  Maybe writing a 'how I copied http://xxxxxx'; doc.

I think it could go a long way to showing people what OpenACS can do and be helpful for information on HOW to build sites with OpenACS.  It also could help people that want to learn about OpenACS but specifically about building with OpenACS and not as much building OpenACS.