[Zope-PTK] hats off

Chip Vanek chip@upcast.com
Sat, 12 Feb 2000 12:35:46 -0800


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
>