[ZDP] DISCUSS: Zope Front Door mockup

[Patrick Phalen]

[Paul Everitt, on Fri, 17 Dec 1999]

:: To stay "on message", the home page should be very terse, but link to
:: very useful pages that organize the most important site content.  Thus
:: newcomers are one click away from the list of links that will answer
:: most questions.

I agree with this wholeheartedly. Newcomers need to be able to quickly
fiind the next step, without filtering too much noise.

:: I think all three (and perhaps the site as a whole) should use a
:: consistent, simple idiom of "More..." as a hyperlink to get the "big
:: page" version of that block.

Yes!

:: I agree that we need to remove a LOT of the overload.  Perhaps move the
:: branding to the "big page" version of the About Zope.org block.  Perhaps
:: Exits should be moved into the "big page" version of the "Where do I
:: start?" block.

<snip>

:: You're right, we don't push the community enough on the front door.  The
:: community has become one of the big, big attractions for going with
:: Zope.

I think the strength here -- and this is different from just about any
other Open Source project -- is the combined resources of Digital
Creations and the Zope community. Zope users get that advantage.

==========

One thing I'm still not seeing is a key positioning statement. While it
is true that Zope is the "leading open source application server," that
doesn't go to the heart of "what's in it for me?" -- the question on
every prospect's lips. It doesn't address the idea that someone had the
notion to take this application space seriously and design it well from
the ground up, with an eye to future growth and flexibility, and to put
all the tools and toys right in the hands of the developers.

Seems like a bulleted list of What You Get with Zope might be good,
showing Features next to their Benefits.

Here's something from John Udell I've been saving for awhile. It
appeared on cmpnet.byte.programming in Oct. See how it merchandises
the load of *STUFF* (TOOLS, FEATURES, BENEFITS!!) you get with Zope:

==========================================================
I see it as an industrial-strength version of my dhttp idea. That is,
for starters, it's a 100% scripted long-running HTTP daemon, which
maps HTTP requests directly into scripted method calls. Then, it's an
ASP/JSP/ColdFusion-style template processor, where the template tag
language is augmented by native method calls in the same script
language (Python), and this is pretty quick because the engine itself
is the aforementioned long-running Python daemon. The tag language
also interpolates SQL calls and results very much as in
ASP/JSP/ColdFusion. Then, it's an object database whose structure maps
to your site's structure, and which is also a persistent
representation of a Python-ish class hierarchy. This makes it great
for "factoring" the functionality of a site. Then, it's a vehicle for
the deployment of packaged "products" that plug into this architecture
-- for example, there's a slashdot-alike called SquishDot which you
install, very simply and cleanly, into Zope to add a slashdot-like
component to a Zope site. Then it's a GUI admin interface on top of
all this, so the site is fully Web-managed, and this includes advanced
features like "sessions" in which you can explore alternate paths of
development, which you can then commit or roll back. Finally, since
the whole thing is Web-driven, it is automatically scriptable from the
outside -- a huge point in its favor in my book.