Forum OpenACS Q&A: Sizzle vs. Steak

Collapse
Posted by David Cohen on
This is a continuation of the line of thought of my comment in the thread Talli started about the site map (see it here):

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.

Collapse
Posted by David Geilhufe on
Speaking as one of those folks that is willing to work, but does not have the skills to actually build a "out-of-the-box" solution, I wonder what I can do. This is perhaps the most critical need that I have with the system-- this out of the box functionality.

I understand the ACS architecture and functionality, I can code html and am working up to being comfortable with .adp pages. I'm a product manager for enterprise software by trade, so I deal in product roadmaps, requirements, specifications and QA testing. Is there anything I can do to help put one of these out-of-the-box implementations together?

Since I would like to see if OpenACS can become a platform for some nonprofit/ community technology application development, it will be critical to have immediate utility/ immediate return installations of OpenACS avaliable... preferably as a rpm.

Collapse
Posted by Don Baccus on
I think a good place to begin analysis is to take a look at ACES.

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.

Collapse
Posted by Nathan Bogo on
In addition to "skins," what about a selection of basic "pre-packaged services" such as:

1) an OpenACS install with 1 bboard, 1 calendar, & 1 news module OR

2) an OpenACS install with 2 bboards and 1 news module, etc.

This is how most of my OpenACS installations work, as most of my clients want a minimum of services to start with; and having a script help me setup the basic configuration for a fully working system would be great.

At present, I have a set of ultra-mini-HowTos that remind me of the steps I must take to properly setup a basic set of OpenACS services. This way I can focus my time on customizing the UI instead of re-remembering how to create categories for a bboard.

Question on the "config scripts" used to build a specific OpenACS system:

I assume BITS, the "Open Bug Tracker(TM)" script will walk me through (using a series of web pages) the decisions that need to be made to properly setup OpenACS as a bug tracking system, such that when I am done with the installation I have a fully operational bug tracking system (with all the properly configured parameter/, home.tcl and admin/???.tcl pages), OR are you planning to have a more "recipie" style system that lists the steps that need to be done?

I am thinking of Windows here, in that after the basic install, I get a few "configuration" screens that allow me to setup my services; i.e. timezone.

Whats more, I am thinking that the Installation/Configuration scripts will result in the basic home.tcl, and admin/???.tcl files that offer _only_ the choices that I have selected to install.

I have already started to build a set of "configuration" scripts (.tcl) pages that walk me through the post-installation process, to help my associate admins more quickly build an OpenACS installation with basic services activated. But my requirements for a basic OpenACS system are likely different from those of others.

Can we agree on 2-3 basic configurations (plus any specific "skins" such as the OpenBugTracker), for the out-of-the-box crowd, so the configuration pages I help build can be more focused?

Can we also agree on the page layout and/or structure of these pages so that I what I build will conform with what other people build?

Perhaps we do not limit the number of OpenACS configuration solutions, but we build a library of solutions from which the user can choose; each with their own description, sample screen shots, documentation (where appropriate), and script files that are used to make the appropriate changes. If we could start with one OpenACS Configuration Model and a guideline that helps future config builders... hmmm I like this, but I think we need to define some basic structure and standards before I go nuts building config solutions. Any thoughts? -nate

Collapse
Posted by Don Baccus on
<blockquote><i>Can we agree on 2-3 basic configurations (plus any specific "skins" such as the OpenBugTracker), for the out-of-the-box crowd, so the configuration
    pages I help build can be more focused?

    Can we also agree on the page layout and/or structure of these pages so that I what I build will conform with what other people build? </i></blockquote>
I'm not sure, unfortunately.  However, I bet folks would love to see your "mini-HowTos" and some of your configuration scripts.  Seeing how  one person deals with some of these issues could be helpful.
<p>And this stuff might well make it into the OpenACS 4.x release if you're willing to take the time (and have the time available) to work with Roberto, who is organizing documentation.
<p>We might want to think about an "customization wizard", so to speak, that would simplify the process of mounting packages and assigning URLs for the combinations of packages useful for most OpenACS sites.  Perhaps allow some look-and-feel customization, too.  Such tools are mostly "sizzle"-oriented as serious customization is serious work, but could help to expose the flexibility of various features of the toolkit in an approachable, if simplistic, way.
Collapse
Posted by Talli Somekh on
The other approach is the Slashcode way. I think it would be good just to make the new openacs.org a tarball and let people download the generic setup. That way they get what they see.

So I think it's a good idea to post your thoughts on the new openacs.org thread.

<subliminal>not enough people posting their ideas for openacs.org.</subliminal>

or does no one have any ideas of how to improve the site? do we just know how to piss off don some more? that's not really hard, you know...

talli

Collapse
Posted by Nathan Bogo on
OpenACS 4.0... OpenACS 4.0... I must keep reminding myself of this
vast effort that many have undertaken; but it is hard to do when my
days (and nights) are spent in 3.x code. I did not think to
check into the implementation (installation+configuration) model for
4.0. Have my ideas already been addressed; i.e. "a library/repository
of complete out-of-the-box OpenACS configuration solutions"?

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

Collapse
Posted by Don Baccus on
<blockquote><i>Have my ideas already been
    addressed; i.e. "a library/repository of complete out-of-the-box OpenACS configuration solutions"? </i></blockquote>
Yes and no.  ACES, for instance, can be thought of representing the first entry into such a library/repository, and is getting ported to OpenACS 4.x.  But beyond that example, just the few ideas tossed about  in the beginning of this thread.
<p>Talli ... I look at ACES as being very similar to Slash in the sense you're thinking of, i.e. it rolls out and looks like Sloan Space.  When I mentioned a "configuration wizard" I wasn't really thinking of this as being an idea in competition with the notion of having vertically customized apps built on top of OpenACS ala ACES.
<p> Rather, I was thinking that the acs subsite admin API isn't entirely straightforward and that a newbie wanting to explore the toolkit's flexibility by cobbling together a quick-and-dirty site with a few bboards, groups, maybe some simple portaling could perhaps be led through the process by the hand, without learning very much at all about the structure of the admin pages and UI.
<p>So I think of it as being complementary.
<p>As Nathan points out, putting together a tool that would be even minimally useful might be a big task - I'm just blue-skying.