Forum OpenACS Q&A: Sizzle vs. Steak

From an article in Fortune magazine on-line about HP's struggles:

In the early 1990s, Motorola revamped its most popular pager. The new model had lots of new features, but it looked the same as the old one. "I was really irritated that these things were black for no good reason," recalls Morris, who was in charge of the project. So he and a buddy bought some green plastic and injected it into the pager molds. The result was a new line of pagers that came in an array of brightly colored, transparent covers, years before Steve Jobs introduced his fruit-flavored iMacs. "The moral of the story, which I repeat many, many times to engineers, is that all the fancy-ass technological engineering in the world couldn't get us a nickel more for the product," says Morris. "But squirt-gun green plastic, which actually cost us nothing, could get us 15 bucks extra per unit, which definitely helps the margin."

I think there's a lesson here--the ACS has the steak but not enough of the sizzle. And as any marketing person will tell you, the idea is that you sell the sizzle and not the steak. Even with software, you want to capture people's attention and imagination.

In my previous comment I mentioned how the Zope toolkit has had "Squishdot" for a while, a Slashdot clone, which gives techies a sense that Zope is cool (since Slashdot is cool and you can do Slashdot with Zope) and that they could use Zope to do cool stuff, like run their own Slashdot-like site, etc.

Oh, and Squishdot is an app that comes with Zope, so users get a good OOTB (out-of-the-box) experience.

Anyway, the point of *this* thread is to continue talking about things that could be added to the OpenACS and/or openacs.org that might draw people in.

In the thread where I posted my initial comment, there were some replies that might be worth looking at, suggesting that a.) weblogs might be a worthwhile addition and b.) that being able to switch the ACS to different modes on installation, so that you could tell your installation to configure itself in different ways, as Yon Derek put it there:

Imagine: after initial setup users sees a page with a few links. One liks says: "make it a Slashdot-type site". Other says "make it a wiki", "make it a weblog", "make it a bug-tracking site" etc. The architecture to support this would be easy to do: main index.tcl is just a dispatch that will redirect to some other page that implements a give "site" based on field in a db. There would have to be some plugin/registration mechanism so that different "sites" can register themselves with the "site dispatcher". When a site gets started for the first time, it would probably have to execute some code (initalized itself). One could even switch between "sites" on the fly. Think of it as "skins" over ACS capabilities.

Ben Adida suggested that this sort of "vertical-specific" configuration "is the way to go":

OpenACS needs to be a "back-end technology," meaning where you can 
have: 

- BITS, the powerful bug tracking system (powered by OpenACS) 

- OpenACES, the easiest online education management system (powered 
by OpenACS) 

- OpenCommerce, the simplest online store system (powered by OpenACS) 

- ... you get the picture 

So much for my recaps--let the thread continue.

Ignore the actual feature set (which is pretty decent), my point is to
look at process.  ACES is a bunch of changes and additions to the base
ACS, and the result is a different toolkit.  It can't be distributed, as implemented in 3.4.x, as an alternative install or a "glue" package
on top of standard ACS 3.4.

This is not the right approach.  I think we can start by stating that vertical packages that are built on OpenACS 4.x should be layered on the stock acs core.  Modified packages (say a customized bboard) can be offered as replacements for the standard packages, but in the package scheme there's no reason why customized versions of non-core packages can't be released as (say) "aces-bboard" etc.  The "glue" package would automatically install the blend of standard and customized non-core packages that are required.

ACES will provide us an interesting test case.  There will be an OpenACS 4.x version of ACES at some point.  Since this code base exists in 3.x and since ACES is really useful, it will undoubtably be our first vertical application package built on 4.x.

It is also a fairly well-defined space so we can concentrate more on central issues like how to structure such packages, how to ensure we can install them on top of vanilla OpenACS 4.x releases rather than see the core fork, etc rather than the feature set it offers.

I really like Don's idea of a "configuration wizard" although I
suspect building a generic-does-it-all-OpenACS-configuration-tool is
more complex than just building 2-3
you-get-what-you-see-and-better-like-it-OpenACS-configuration
solutions (i.e. the new openacs.org), no?

Perhaps we could agree on 1 basic (highly useful) OpenACS
configuration model and work toward building the config scripts for
it, to start; is this the new openacs.org model, Talli?

4.0 presents another issue to consider... how much effort do we put
forth on building a "configuration wizard" or scripts for 3.x that
will be of value? Should I, instead, focus my time learning the 4.0
architechture, so that my efforts (on config scripts) have a more long
term impact?

Don, I will be happy to transcribe my ultra-mini-howtos to the
computer (from napkins and BK whopper wrappers) and forward them to
the community, or rather their links, no? Their purpose is to guide
the somewhat-initiated OpenACS site-manager through the absolute
minimum steps required to setup key OpenACS modules. Despite the great
efforts of those who created web-forms (and all the config options),
my users (my clients) find them too confusing, so I had to create
something more simple. I am not sure how helpful they will be, but I
will let the community decide this for themselves.

I look forward to your feedback! -nate