New Python.org website ?

[Tim Parkin]

Fredrik Lundh wrote:
> What puzzles me (and scares me) is that some people seem to think that
> anyone would go to python.org and expect a corporate fluff site.
> 
> It's like when I asked a "suit" friend with long industry experience to check
> the python marketing list; his spontaneous reaction after reading some of
> the "we must do this because non-programmers think like this" discussion
> was one big WTF-are-these-guys-talking-about-why-do-they-hate-python ?
If you'd followed the conversation, we actually asked a sample of
non-programmers and a few company decision makers what there
expectations were.. You may have seen a few ill informed comments on the
python list (but tell me what list you can go on that doesn't).

> The current site needs an incremental style overhaul, a less cluttered front
> page, and some signs that python.org's actually using modern Python tools
> for the site.  And it needs to be more alive, both style-wise and content-
> wise.
Thats what we've done.

> It does not need to treat its target audience (be it developers nor managers)
> as simpletons.  Companies in the Python space don't do that, so why should
> python.org ?

I haven't got a clue what you are on about with the simpleton thing.. Is
this related to another conversation

> it's the kind of tools that people built around then: a bunch of text
> files, and a make-style build templating system.  to use the tools,
> you log in  to the web server via a back channel.

In most circles it is considered a 'good thing' that data is stored in a
format that can be edited by hand. Of course we could have stuffed it
all in a database or stored it as xml.. would this have been more 2006.

> anything that supports edit-though-the-web and does the final
> composition  by composing HTML information sets would be more 2006.
> the easiest way to get there would be to use a MoinMoin instance to
> maintain the content, and a separate renderer to generate static pages
> for the  main site (possibly using Cheetah or Kid as
> templateanguages).

It would be apparent to you if you'd read around (even within this list)
that the website is ultimately intended to have 'through the web'
editing tools. You'd also know that one of the biggest acheivements so
far is the separation of template from data from content so that
'information sets' actually exist in the first place. This also means
that when someone designs a better template (as they may well do) it can
be easily changed in the future.

We also don't really want to have a proliferation of text formats and as
a lot of the website is already written using restructured text, this is
the format thats been recommended. A wiki is not a website and to try to
shoehorn a wiki into a content management system is not a good final
goal. We are adding facilities to use the wiki to manage some pages in
near future as part of migration.

However, the priority was to do certain things first.

1) Separate content from data from presentation is as complete a way as
possible (for which nevow templates, which contain no programmatic
componenets are suitable).

2) Ensure that the system is usable using basic text editing tools

3) Build the website using the latest techniques ensuring accessibility
and usability. The site is XHTML and uses CSS for layout. It also offers
legacy style sheets for netscape and has been tested in speech readers
and text browsers. how quaint..

4) Needed someone to actually do something ....

The last item seems to be the one that has hit the most hurdles. As I
remember you were a member of the marketing list and have had many
opportunities to contribute constructively at planning time.

If you could choose to be constructive in either offering useful changes
that would make sense at this point in time or offereing to provide help
that would be greatly appreciated.

I'm afraid I won't be able to respond at length to any more posts..
There is still a lot of work to be done to get the website live.

Tim Parkin