Forum OpenACS Development: Send me your home page

Collapse
Posted by Joel Aufrecht on
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)
Collapse
2: Re: Send me your home page (response to 1)
Posted by Matthew Geddert on
i think we need to have a basic description of openacs on the home page for normal users, as we do now. it needs to explain what do do next to somebody that doesn't know anything about openacs and the current one does that reasonably well. Homepages will have very little in common with one another on a running site... just take a look at all the openacs sites:

https://openacs.org/community/sites/

they are all very different and these will give you all the examples you could need. i think ETP is the way to go. one thing that i always do is copy the code from that box that tells you what packages are installed (i.e. a small self-generating site map) and put that code on the primary admin page... but i think somebody else is already working on improving the admin pages... there are many people that will want things like news headings on their homepage (as my sites do)... but i think this shouldn't be standard because many people won't want it on their home page and/or may have many instances of news and a generic one won't work then...

Collapse
3: Re: Send me your home page (response to 1)
Posted by Matthew Geddert on
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.

Collapse
4: Re: Send me your home page (response to 1)
Posted by Ben Koot on
Why don't we add larsblogger as default to the index page? it's the only module that offers a simple and universal low tech sollution.
If we would have a simple template with blogger on one section, and the basic ACS functionality (the current quik links)
Site map
Package Manager
Users
Groups
Main site admin
Software Downloads
Developer Community
Report a bug
on the other half of the basic screen that would give newbies with soem basic logic, as well as the power to add thier own information in the blogger.

Just a thought

Ben

Collapse
5: Re: Send me your home page (response to 1)
Posted by Matthew Geddert on
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.

Collapse
6: Re: Send me your home page (response to 1)
Posted by Chris Johnson on
This problem is related to Lars's thread, "Making OpenACS useful out of the box".
https://openacs.org/forums/message-view?message_id=107358

Going along that thread's lines (as I would prefer to do), solving the "default homepage" problem is similar to solving the "Out of Box" experience with OpenACS applications.

Concrete example: I believe that the toolkit should evolve very soon such that a final step of my default install procedure will be to choose between the following (this is before I even see a homepage):

-OpenACS personal portal (blogger-style)
-OpenACS Project Management (sourceforge-style)
-OpenACS dotLRN
-OpenACS dotFamily (subsites for each family member including blogger, photo album, content repository)
-OpenACS dotWRK (work-place portal, including wiki, news, content repository)
-OpenACS barebones ETP subsite

See? This solves the home page problem while unifying all that we have invested in the toolkit...

On a more practical and immediate note, I agree with doing something like ETP or what you're doing for the short term before the above becomes fully feasible (for that we might need to make more packages properly subsite aware...???)

My $0.0187

Collapse
7: Re: Send me your home page (response to 1)
Posted by Don Baccus on
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 ...

Collapse
8: Re: Send me your home page (response to 7)
Posted by Jeff Davis on
Another thing we might do is make most of the "welcome" stuff come from an include rather than be inline in the
index.adp page which would make ripping it out pretty trivial.
Collapse
9: Re: Send me your home page (response to 1)
Posted by Don Baccus on
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?
Collapse
Posted by Talli Somekh on
In the past few months, my personal totally screwy statistical analysis has shown that the community has grown a great deal, including a lot of newbies who are not necessarily related to any institution. This really rocks.

Don's idea of a dotVANITY (shouldn't it be dotVNT?) is a great idea. It would probably be a nice response to the Plone "download and run" challenge.

talli

Collapse
Posted by Mat Kovach on
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.