[ZWeb] Not another ___Nuke site, please

Ausum Studio ausum_studio@hotmail.com
Mon, 13 Jan 2003 19:18:27 -0500

----- Original Message -----
From: "Jeffrey P Shell" <jeffrey@cuemedia.com>
> > going on with the community? Isn't it better to make nzo to show me
> > relevant external content by means of advanced syndication?  If I was a
> > seasoned Zope developer, do I really need to see the "Zope is this",
> > "Download Zope here"  pieces of content, every time I open nzo?
> Yes.  Should you have to log in every time you open NZO just to avoid a
> "Download Zope Here" piece of content?  Personalization is not worth
> it, unless it's basically a way of allowing you to track product
> releases that are of interest to you.  But at this point, we start
> getting into the large-volume-of-user-data issue again.  I'd like to
> keep that issue at bay for as long as possible in hopes that it will
> make NZO easier to migrate to Zope 3.


> Finally - you shouldn't have to log in in order to use the site, and
> the site shouldn't go through dramatic changes when you do log in.  And
> personalization shouldn't happen based on browser identification,
> because you shouldn't have a different Zope.org experience if you're at
> home or at work or at a coffee shop.

Personalization is all about personal options and tracking content
preferences. Is it a bad idea to allow a user to avoid bogus content just
by letting him to choose it or not? I don't think so. On the other hand I
know we have time limitations, but I'm not proposing a full-blown CRM,
tracking transparently my behaviour at the site, but a minimun set of
features to make more productive a user's visit to the portal,
including -for example- the case of samaritanian people willing to help
everybody else to get the Zen of Zope, and who'd like to cut to the chase
without diving into a large pile of links. Moreover, if we want to
accomplish 10X we need to show off what it can be done -at at reasonable
level within the timeframe- and not just autolimit ourselves.

> If a site is simple and effectively well organized, you should be able
> to move through it quickly without needing DHTML menus.  They're a nice
> bonus, but they shouldn't be necessary.

That's true. Anyway, now I couldn't work without them anymore. I'm used to
them and they have boosted my productivity by many times.  (I'm planning to
release the code as soon as I finish to wrap it as a product):

> > To Plone or not to Plone
> >
> > -1 to Plone. This is out of the scope of this message but you can read
> > my
> > statement on the subject as a reply to the following thread:
> > http://www.zopezen.org/Members/huima/News_Item.2002-11-19.0150
> I've made some comments here before.  Plone, like the CMFDefault,
> doesn't have to *look* like Plone.  Plone rounds out some of the CMF's
> potential by filling in holes (that are intentionally left open,
> thankfully for those of us who have to build other types of content
> sites that are not community oriented) and providing extra services
> that the base CMF implementation doesn't provide.
> <http://www.zope.ch/> says it is powered by Plone, but I think it's a
> much better looking site than most Plone sites tend to look.  I'm not
> sure if it switches skins to look more Plone-ish for those who prepare
> the content, but the public side looks nice.  ZopeZen is a similar
> story - it looks somewhat Plone-ish, but not too much.  And ZopeZen is
> more than just some replaced page-templates in the skins layer, it adds
> and modifies some policies and services to better fit the type of site
> that ZopeZen wants to be.  (I'm not saying Plone is ugly, but it
> certainly doesn't fit all situations).
I'll answer to this on my reply to Robert.