[Pydotorg-redesign] What are the goals?

Tim Parkin tim.parkin at pollenationinternet.com
Fri Sep 26 08:20:29 EDT 2003


>This isn't particularly good, but it took me less than ten minutes.  It
>also focuses on the user experience; it says nothing about how the site
>is maintained.  Let's keep that as a separate discussion.

I think we have to take best practices for granted unless there is a
situation where a best practice is in conflict with another best
practice. It is at these pointes we *NEED* feedback. Case in point: full
support for Netscape vs. best practices in w3c wai accessibility and
standards/semantic compliance. In this I raised it as a conflict and
looked for feedback but received very little and had to assume that
support for Netscape was less important than good accessibility and
standards/semantic compliance.

Other points that have already been stated as part of the initial pycon
brief, further discussion through irc or on the mailing list itself are
shown here :

. make it look more "professional". 
. make the site more obvious to use, particularly for beginners.
. prioritise links to download and documentation
. introduce an obvious site search facility
. reduce the clutter in commercial exits
. head towards valid markup
. promoting Python, leverage evangelism 
. use existing metrics to focus improvements
. simplify the homepage
. documentation types confusing
. simple search on home page
. Should bear in mind that mirroring is important
. No 3d rotating head of Guido with glowing lights around him (Kevin
Altiss)
. All sections should adhere to new design templates (Kevin Altiss)
. a google site search on python.org is very ineffective right now
(Kevin Altiss)
. make it work in lynx (Aahz)
. we want blue (Aahz)
. reduce the maintenance hassles for the webmasters (Kevin Altiss)
. top global nav and left hand secondary nav (Aahz)
. front page under 60k (Aahz)
. breadcrumb trail across the site (Aahz)
. Steve Krug - Don't Make Me Think (Guido Van Rossum)
. No flash, No dark backgrounds (Guido Van Rossum)
. Don't design by committee (Guido Van Rossum)
. Browsing then searching then sitemap (Guido Van Rossum)
. home page should have a lot more "sell" with convenient links to the
developer resources (Kevin Altiss)
. there should not be two sites. Python.org is *the* homepage (Aahz)

Generally these break down into four overall core requirements

. Usability / Clarity
. Professional Design
. Both Marketing / Informational Purposes
. Best Practices in Web Development

On top of this, there is the marketing document at :

http://wingide.com/pub/misc/pymarket/py-market-plan-0.0.6.rst

Most of these have been available for at least a month. General best
practices have been taken for granted.

Other than the previously stated PWC/PSF guidelines, here's a list of
general best working practices that I typically work to and the books
that go into some more detail about them.

* Page should have a time to first click of less than 8 second on an
average connection. 
(This actually means the time until you can usefully use the navigation
or content. This affects sites that use graphics as navigational
elements. In these site, all of the headers graphics are loading before
it gets around to loading the menu item graphics. This typically means
the time to first click is similar to the time to download the whole
page. If a page uses html text as the menu items, the page will be
usable before even the whole html has loaded. In this way the page may
be usable before even half of all page elements are downloaded. This
increases the 'perceived' speed of a site.)

* All pages should answer : Where am I? Where do I go Next? How do I get
back?

* A preferred vocabulary should be created that is widely understood and
cannot be confused

* The site should sit comfortably in the perceived market space.

* Pictures of people are widely recognized as engaging more than any
other method, use if there is a choice.

* Don't hijack the browser. Leave it alone. Make it do what people
expect.

* Recognise that most people will be deep linking into the site

* Scrolling should only be needed when a user finds the page they want.

* Pages should print clearly

* The site content should be optimised to benefit accurate search
indexing

These are only some of the best practices that are not widely
recognised. If we were to make a list of all of the practices we would
be writing a book and there are already enough books out there. I have
copied and pasted most of this content directly from the web proposal
that's currently being written that will complement the marketing
document mentioned previously. A lot of extra information comes from
developing best practise guidelines for British Airways' Internet
strategy, a document I was co-author of.

Books for Best Practice
-----------------------
* "Building Accessible Website" - Clark
* "Don't Make Me Think" - Krug
* "Homepage Usability" - Nielsen & Tahir
* "Designing Web Usability" - Nielsen
* "Practical Information Architecture" - Reis
* "Information Architecture" - Wadtke
* "Top 100 Internet Mistakes" - Peter Burns
* "CSS - Separating Content From Presentation" - Briggs, Champeon,
Costello, Paterson
* "Collaborative Web Development" - Brudman
* "WWW Layout" - Glenwright
* "WWW Type" - Pring
* "Reality Chec"k - Wieners & Prescovitz
* "Hotwired Style" - Veen
* "Secrets of Successful Websites" - Siegel
* "Click Here" - Pirouz
* "Accessible Websites" - Thatcher, Bohman, et al
* "Web Metrics" - Sterne
* "Submit Now" - Chak
* "Designing with Web Standards" - Zeldman
* "Designing CSS Pages" - Schmidt
* "Usability" - Braun, Gadney, et al
* "Usability for the Web" - Brinck, Gergle, Wood
* "Eric Meyer on CSS" - Meyer
* "Customer Centred Design" - Hyatt

http://pollenation.net/assets/public/python-guideline-books.jpg

What I, personally, believe the PWC should be doing is dictating a
framework within which people who are willing to contribute can work, if
this can't be achieved then at least a date by which a decision will be
made should be proposed and the process by which a choice will be made.

As it is, it shouldn't take a great deal of time or coordination to get
to 'yes we like the look of that' or 'no, perhaps it should be more...'.
As it is there has been no feedback. We can only assume from this that,
because all the work has been available for quite some time, there is
approval and a desire for us to carry on. If there was a negative
opinion or no wish to use what has been created then why would there be
no communication of that?

As the situation lies, the design/marketing/redesign groups have had
numerous discussions and reached a consensus about what is felt to be
the right direction. This is now being documented. I'm not sure what the
advantage of having multiple groups doing the same thing is unless there
is dissent as to the direction that should be taken. I haven't noticed
any constructive dissent so assume we have a certain amount of
consensus.

I am continuing to develop the proposal, of which the material presented
is only a fraction.

Constructively your,

Tim Parkin






More information about the Pydotorg-redesign mailing list