Mailing List Archive

Timothy Wilson wrote:
> Great job. I've just installed my first PTK-based portal, and it looks
> great! This is going to be a lot of fun to work on.

Here's a way you can repay us -- help us make it _really_ easy to use.
For instance, come up with some sample content that we can optionally
include.

I really want PTK to be a LOT more "self-revealing" than Zope has been
to date, so pitch in!

--Paul

Hi,

I have been working with PTK for a while and just love it. I am
new to Zope and Python but making some slight progress. I have
gotten great help from the mail lists and Mike P. has been great
about answering everyone. You guys are onto something great.

I would be happy to give back if I can in any way. Exactly what
kind of content do you have in mind. I am presently reworking
the DemoPortal with a new look & feel but, am learning basic
Zopeisms at the same time so my work is scattered. I have a
600 line stylesheet and CSS classes linked to most UI elements.
It is not complete and somewhat redundant. I am at least a week
away from having a somewhat consistent CSS configuration capability
but, still need to understand were I can write the color, positioning
and element attribute variables. I really do not understand the
best place to store 20-30 variable per user. Still new to your model.

Again let me know what you need and how it should be packaged and
I will try to see if I can do some of it.

Best,

Chip Vanek

>-----Original Message-----
>From: paul@ns2.digicool.com [mailto:paul@ns2.digicool.com]On Behalf Of
>Paul Everitt
>Sent: Friday, February 11, 2000 3:55 PM
>To: Timothy Wilson
>Cc: zope-ptk@zope.org
>Subject: Re: [Zope-PTK] hats off
>
>
>Timothy Wilson wrote:
>> Great job. I've just installed my first PTK-based portal,
>and it looks
>> great! This is going to be a lot of fun to work on.
>
>Here's a way you can repay us -- help us make it _really_ easy to use.
>For instance, come up with some sample content that we can optionally
>include.
>
>I really want PTK to be a LOT more "self-revealing" than Zope has been
>to date, so pitch in!
>
>--Paul
>
>_______________________________________________
>Zope-PTK maillist - Zope-PTK@zope.org
>http://lists.zope.org/mailman/listinfo/zope-ptk
>
>

On Fri, 11 Feb 2000, Paul Everitt wrote:

> Here's a way you can repay us -- help us make it _really_ easy to use.
> For instance, come up with some sample content that we can optionally
> include.

I've been thinking of creating something to diplay current weather
conditions for a given zip code. Is that the kind of think you're talking
about?

-Tim

--
Tim Wilson | Visit Sibley online: | Check out:
Henry Sibley H.S. | http://www.isd197.k12.mn.us/ | http://www.zope.org/
W. St. Paul, MN | | http://slashdot.org/
wilson@visi.com | <dtml-var pithy_quote> | http://linux.com/

Timothy Wilson wrote:
> I've been thinking of creating something to diplay current weather
> conditions for a given zip code. Is that the kind of think you're talking
> about?

That's one way! I was speaking more about sample content, meaning a
working portal.

I don't suppose someone will host and administer a PTK site where we
could all put example content?

Come to think of it, here's another app someone could finish and host:
searchable archive of the mailing lists. We whipped one up as the demo
content for the CD-ROM we gave out. If someone is interested, let me
know.

--Paul

Paul Everitt wrote:
>
> Timothy Wilson wrote:
> > I've been thinking of creating something to diplay current weather
> > conditions for a given zip code. Is that the kind of think you're talking
> > about?
>
> That's one way! I was speaking more about sample content, meaning a
> working portal.
>
> I don't suppose someone will host and administer a PTK site where we
> could all put example content?
>
> Come to think of it, here's another app someone could finish and host:
> searchable archive of the mailing lists. We whipped one up as the demo
> content for the CD-ROM we gave out. If someone is interested, let me
> know.

I have Mailbag product which is partway along -- I have been refactoring it to
use Python base classes, with ZClasses layered on top to plug them into Zope.
The Python is "Zope agnostic": it just uses the 'rfc822' and 'mailbox' modules
to parse messages and mailboxes. I went this route to make it possible to run
unit tests at the command line, which I see as an important element of a robust
design (the "power-on self test" kind of thing.) This bit is mostly done.

I haven't looked yet at the demo CD -- perhaps my stuff is redundant. Anyway, I
can't host it under the PTK until CodeIt upgrades their Zopes to 2.1.x (and I'd
have to buy more space from them, no doubt). ;) Somebody needs to work on a
program, using ZClient and callable from procmail, to invoke the
manage_addMessage on the appropriate folder when mail comes in, too.
--
=========================================================
Tres Seaver tseaver@palladion.com 713-523-6582
Palladion Software http://www.palladion.com

Chip Vanek wrote:
> I have been working with PTK for a while and just love it. I am

I'd like you to say a little more here, not just out of vanity, but for
a real reason. :^) Specifically, do you love it because it is:

A. More usable and self-revealing than Zope, or

B. Powerful, or

C. ??

> new to Zope and Python but making some slight progress. I have
> gotten great help from the mail lists and Mike P. has been great
> about answering everyone. You guys are onto something great.

Mike is great. His employer loves him, though, so stay back! :^)

> I would be happy to give back if I can in any way. Exactly what

I have a particular interest in making the PTK "self-revealing", to
borrow a phrase from Rand Pausch (head of the Alice project). What are
some ways to make the PTK self-revealing?

o Include sample content, so people can see some exciting things
already working

- A small Gadfly app to show relational data

- Healthy amount of searchable content

- A bunch of members with various roles, with content in
various states, such as unreviewed

- A LONG tutorial describing the state of the sample content,
and where people could click to see the various things

o Perfect wizards. The PTK has a wizard facility. It
needs ongoing attention. It also needs documentation, and
might need to be rewritten, but that's a different story. :^)

o Leverage Amos' help system. For those that don't know, Zope
now has a context-sensitive, searchable help facility that
is usable by developers. Amos Latteier has checked it into
Zope, and most of the content is there. Obviously this is an
ideal "panic button" for newbies. It also provides a place
to put top-level things like "tours".

o A glossary, perhaps as part of the help system. Guns don't
kill newbies, jargon does.

o Some "tours", similar to the tour on the Zope.org homepage.

> kind of content do you have in mind. I am presently reworking
> the DemoPortal with a new look & feel but, am learning basic
> Zopeisms at the same time so my work is scattered. I have a
> 600 line stylesheet and CSS classes linked to most UI elements.

I'd _love_ to see a CSS-aware sample portal. I love CSS. I'd love to
see nearly every discrete piece of the portal (the toolbar box, the
toolbar items, the desktop, the desktop items, the portal title,
margins, etc.) exposed to CSS selectors, then let people do "chrome" by
editing a style sheet in their home folder.

Go Chip!!

> It is not complete and somewhat redundant. I am at least a week
> away from having a somewhat consistent CSS configuration capability
> but, still need to understand were I can write the color, positioning
> and element attribute variables. I really do not understand the
> best place to store 20-30 variable per user. Still new to your model.

Don't. Instead, do the following:

a. Edit the standard_html_header to link to an external style sheet
whose URL is a property of the Member folder. Note that this means
you'll need to extend the ZClass for Members to include a styleSheetURL,
with a default value set to the "master" style sheet you create for the
sample portal.

b. People can use preferences to change the stylesheet to point to their
own stylesheet. Perhaps they point to one in their Member folder on
that portal. Perhaps they point to an existing one they've created on
another PTK portal.

Once you get this working (this weekend, right :^), we could make this
model part of the standard PTK.

> Again let me know what you need and how it should be packaged and
> I will try to see if I can do some of it.

Hopefully that's a good start.

--Paul

Tres Seaver wrote:
> I haven't looked yet at the demo CD -- perhaps my stuff is redundant. Anyway, I
> can't host it under the PTK until CodeIt upgrades their Zopes to 2.1.x (and I'd
> have to buy more space from them, no doubt). ;) Somebody needs to work on a
> program, using ZClient and callable from procmail, to invoke the
> manage_addMessage on the appropriate folder when mail comes in, too.

Here are a couple of things that I'd like to see most:

1) Recovery. Quite often the procmail xml-rpc client or the Zope server
will have some interruption in service. There needs to be some kind of
logic for each side to discover the gaps/overlaps in service and make
_absolutely_ certain there is a one-one correspondence in message ids
between client and server.

2) A published interface for xml-rpc. We could then just setup a
"network service" for mailing lists, both for loading and performing
searches.

3) Scalability. When Jens did the CD app, he loaded over 17,000
messages from 1999's Zope list. When you clicked on the folder and Zope
tried to send the contents of 17,000 items back, the HTML was enormous
(and the DTML took forever to render). He solved this by arbitrarily
spreading the items over 100 subfolders. However, there needs to be
some better subfoldering scheme (perhaps to the day?).

As for a hosting site, if this thing _really_ does work correctly in a
hands-off way, and has a number of management features to find things
that are wrong and correct them, then we'll gladly host it on zope.org.

--Paul

hi,

as a little explanation of what exactly happened: with all 18,500 Email
objects in one folder the opening of the folder in the management
interface would trigger a 5MB download. while zope did its job and sent
all the data across just fine, netscape crashed while trying to render
this undoubtedly mile-long page.

the workaround of creating 100 subfolders and spreading all Email
objects between them was used because people might think zope was at
fault had they ever tried to open that massive folder. with the way it
is on the CD there is about 200 objects per mail folder and it opens in
the normal fashion.

jens

-----Original Message-----
From: Paul Everitt [mailto:paul@digicool.com]
Sent: Saturday, February 12, 2000 11:38
To: zope-ptk@zope.org
Subject: Re: [Zope-PTK] hats off


3) Scalability. When Jens did the CD app, he loaded over 17,000
messages from 1999's Zope list. When you clicked on the folder and Zope
tried to send the contents of 17,000 items back, the HTML was enormous
(and the DTML took forever to render). He solved this by arbitrarily
spreading the items over 100 subfolders. However, there needs to be
some better subfoldering scheme (perhaps to the day?).

Well fill my plate...

>-----Original Message-----
>From: paul@digicool.com [mailto:paul@digicool.com]
>Sent: Saturday, February 12, 2000 8:17 AM
>To: Chip Vanek
>Cc: zope-ptk@zope.org
>Subject: Re: [Zope-PTK] hats off
>
>
>Chip Vanek wrote:
>> I have been working with PTK for a while and just love it. I am
>
>I'd like you to say a little more here, not just out of vanity, but for
>a real reason. :^) Specifically, do you love it because it is:
>
>A. More usable and self-revealing than Zope, or
>
>B. Powerful, or
>
>C. ??
I would have to saw more self revealing. It is clear to me that Zope
is very powerful. For a newbie it is like giving a gun to a child.
The standard Zope interface is fairly easy but introduces some new
interaction models that are just too different. Seeing a list of
items, clicking a checkbox and pressing a button doesn't feel quite
right. The Wizards are a good start but all of the checkbox/button
UI needs to be hidden. I can see were the PTK can support a number
of different types of context sensitive actions per object and will
try to move my implementation in that direction.

I have looked at numerous different development platforms for
collaborative web apps over the last 6 months and Zope is a clear winner.
The combination of an extensible foundation built on Python, an active
development community, and now the Portal ToolKit make Zope the opensource
web platform of choice. The PTK extends Zope to allow new developers to
quickly create a solid first application and exposes some of the power of
the platform. Secure user personalization with cookie support is standard.
Developers can add new functionality, edit one file and provide this cool
new feature to all users or to a subset. Integrated versioning and undo
functionality allow developers to work on a production system without
inflicting partially complete functionality on their users. As PTK
matures it is clear that a new wave of feature rich collaborative
applications will move users away from the monolithic environments offered
by Amazon, AOL, and the other giants. The trick will be to ensure that
these new portals act as a cooperative community, sharing member
credentials,
interest profiles, rich content, and development experiences.

>
>> new to Zope and Python but making some slight progress. I have
>> gotten great help from the mail lists and Mike P. has been great
>> about answering everyone. You guys are onto something great.
>
>Mike is great. His employer loves him, though, so stay back! :^)
>

OK ;( But if you know of any Zopester in need of some California sun...

>> I would be happy to give back if I can in any way. Exactly what
>
>I have a particular interest in making the PTK "self-revealing", to
>borrow a phrase from Rand Pausch (head of the Alice project). What are
>some ways to make the PTK self-revealing?
>
> o Include sample content, so people can see some exciting things
>already working
>

After this project is done we do plan to host a public portal based
on the PTK with some preloaded content. Stay tuned.

> - A small Gadfly app to show relational data
>
> - Healthy amount of searchable content
>
> - A bunch of members with various roles, with content in
> various states, such as unreviewed
>
> - A LONG tutorial describing the state of the sample content,
> and where people could click to see the various things

Yes, we are concerned that we only reveal to users what they can
do along with clear example. I would like to see a user maturity
model built into the PTK. New user would be offered rich tutorials
and have access to a subset of the features. As the user has successfully
added some simple content, seen most of the tours, more functionality
would be revealed. I assume that can be done with roles but, the whole
roles base security model in Zope is still unclear to me.

>
> o Perfect wizards. The PTK has a wizard facility. It
> needs ongoing attention. It also needs documentation, and
> might need to be rewritten, but that's a different story. :^)
>
I created a couple of wizards and like the step by step interaction
but, still am not sure how to create the item in the same step by
step fashion. After the first step the item should be initially
created to check for initial errors. Then other steps could provide
the user with alternatives based on the initial errors found. This
would ensure that a unique ID is chosen and allow prefilled checklists
to be offered to the user based on prior steps.

> o Leverage Amos' help system. For those that don't know, Zope
> now has a context-sensitive, searchable help facility that
> is usable by developers. Amos Latteier has checked it into
> Zope, and most of the content is there. Obviously this is an
> ideal "panic button" for newbies. It also provides a place
> to put top-level things like "tours".
>

What? This sounds like magic. Can't it just be included as a
standard part of the PTK?

> o A glossary, perhaps as part of the help system. Guns don't
> kill newbies, jargon does.
>
> o Some "tours", similar to the tour on the Zope.org homepage.
>
>> kind of content do you have in mind. I am presently reworking
>> the DemoPortal with a new look & feel but, am learning basic
>> Zopeisms at the same time so my work is scattered. I have a
>> 600 line stylesheet and CSS classes linked to most UI elements.
>
>I'd _love_ to see a CSS-aware sample portal. I love CSS. I'd love to
>see nearly every discrete piece of the portal (the toolbar box, the
>toolbar items, the desktop, the desktop items, the portal title,
>margins, etc.) exposed to CSS selectors, then let people do "chrome" by
>editing a style sheet in their home folder.
>
>Go Chip!!

I do have all of the components linked to a separate CSS class. The
stylesheet does not allow Navigator to render the pages yet. I seemed
to do some IE specific things. I do not plan to make it Navigator
compatible in my first release so it may not be fully useful to you.

>
>> It is not complete and somewhat redundant. I am at least a week
>> away from having a somewhat consistent CSS configuration capability
>> but, still need to understand were I can write the color, positioning
>> and element attribute variables. I really do not understand the
>> best place to store 20-30 variable per user. Still new to
>your model.
>
>Don't. Instead, do the following:
>
>a. Edit the standard_html_header to link to an external style sheet
>whose URL is a property of the Member folder. Note that this means
>you'll need to extend the ZClass for Members to include a
>styleSheetURL,
>with a default value set to the "master" style sheet you create for the
>sample portal.
>
I still have the inheritance of a users local stylesheet in the
code. I just do not see users wanting to edit this file, it is
ugly. The stylesheet uses DTML variables for majot colors so a
users can pick a global portal style and just customize their colors.
They could still copy the stylesheet into their home folder and edit
like crazy to override the global sheets. I wanted to provide some
DTML pages at the top of the Member folder that would provide a
safe interface to copying a stylesheet local and making changes.

>b. People can use preferences to change the stylesheet to
>point to their
>own stylesheet. Perhaps they point to one in their Member folder on
>that portal. Perhaps they point to an existing one they've created on
>another PTK portal.
>
>Once you get this working (this weekend, right :^), we could make this
>model part of the standard PTK.
>
>> Again let me know what you need and how it should be packaged and
>> I will try to see if I can do some of it.
>
>Hopefully that's a good start.
>
>--Paul
>

----- Original Message -----
From: "Chip Vanek" <chip@upcast.com>
To: <paul@digicool.com>
Cc: <zope-ptk@zope.org>
Sent: Saturday, February 12, 2000 3:35 PM
Subject: RE: [Zope-PTK] hats off


> Yes, we are concerned that we only reveal to users what they can
> do along with clear example. I would like to see a user maturity
> model built into the PTK. New user would be offered rich tutorials
> and have access to a subset of the features. As the user has successfully
> added some simple content, seen most of the tours, more functionality
> would be revealed. I assume that can be done with roles but, the whole
> roles base security model in Zope is still unclear to me.

I would think that this is not necessarily an application for the Zope
security machinery. The intention may be to configure the display based upon
a user's familiarity with the system, but you may not actually be trying to
fully restrict that person from other features.

The PTK is going to be an excellent framework, and you'll be able to build
all sorts of things on top of it that don't need to be in the core. It will
be quite an easy thing to add a property to the users that sets the maturity
level or something similar. After they've finished a tutorial, the tutorial
can set that property up a notch, and the other methods can automatically
start displaying the appropriate links/content for the new level.

Kevin