"Python Redesign" (fwd)

[John J. Lee]

mertz at gnosis.cx (David Mertz) writes:

> <tim at pollenation.net> wrote:
> |2) as an image created in fireworks, I expected line spacing to honor
> |html spacing. It doesn't however so I've fixed it.
> 
> I don't know what 'fireworks' is, I suppose it must be some kind of design
> application.  But I figured the image was a screenshot of a rendered
> page... if not, it indeed might appear a bit different as rendered in an
> actual browser.
> 
> |1) it's an image
> 
> You keep writing this; not just to me, but on c.l.py too.  I can't quite
> figure out what relevance you perceive this fact to have.

I guess because people, seeing the .html file extension in the URL,
assumed that resizing fonts and sensible scaling to your browser
window should work (obviously, the .html extension is rather
misleading).  In fact, you were one of those people, David, IIRC --
wondering why the mockup only filled a little box inside your browser
window.  Quite a reasonable question for people to ask, but no need to
get grumpy about it when he answers it.


> |2) images don't have font tags
> 
> Nope... but screenshot images can be made of browsers displaying pages
> with font tags.  I was guessing in the negative that your page was
> produced (indirectly) from such an HTML document; but perhaps no HTML was
> ever involved.

It seems fairly clear by now that the purpose of the mockup was to
give a quick feeling of the visual design (and people's violent
reactions to the 'corporateness' of it and to the colour scheme show
is was successful in that).  Equally clearly, that isn't going to tell
people a lot of other important stuff (no point in repeating those
things here).  Does that mean the mockup is valueless?  Far from it!
Visual design is at least somewhat decoupled from HTML now, thanks to
the not-entirely-broken CSS implementations in many (most?) deployed
browsers.  He implies that it's simpler for him to set up the visual
design in some non-HTML app -- fine: he, as the artist, knows best
which media he can work most quickly in.  If using such an app enables
the design in its current form to be quickly eliminated (quite
possibly by evolution to a better design, rather than dropping it
entirely), he has successfully sped up the design process.  In other
words, it's a prototype!

I think you've already made your points about the design and the
choice of an image in the mockup rather than HTML quite clearly.  No
need to repeat any of that.


> |3) haven't got a clue what you mean about it fairing badly with css
> |dropped and fonts and colours changed. Name me a site that would.
[...]
> Your demo looks a lot like one of those types of sites.  It's hard to be
> sure exactly how it might render if no HTML was ever involved in the
> design though.

I think it's pointless to guess this on the basis of an image mockup,
unless you have a very detailed knowledge of CSS and all the relevant
browser bugs (and maybe not even then).  You're right about the lack
of HTML, but I'm right that that's a perfectly valid thing to do.


> |2) The site has to reflect the expectations of commercial customers who
> |are used to the likes of peoplesoft and atg, etc.
> 
> I suppose.  I'm probably not a "commercial customer", whatever that is...
> on the other hand, I *am* probably the most widely read writer on Python
> topics, worldwide (a lot more people read free developerWorks articles
> than buy books; although a good number bought my book too).  I suppose

So, as you say, we're *definitely* not trying to sell Python to *you*,
David.  <wink>

Seriously, I think there's no intrinsic reason why a glitzy
commerce-friendly page should reduce the usability of python.org to
developers.  By all means let's point out conflicts and complain if
they don't get fixed, but let's not complain about the whole idea of a
glitzier site just because there's a correlation between glitziness
and unusability on *other* sites.


> |3) it's an image. Images don't stretch. If I make it any bigger it would
> |not fit in 800 wide browsers.
> 
> Then it should BE an image, not an HTML page that creates framing elements
> but embeds an image in the middle in a way that hides what's an image and
> what's HTML.  If you had taken that more sensible approach, no one on
> c.l.py would have missed that fact they were looking at an image.

True.


> I reckon you'd be a lot better off taking the near unanimous criticism of
> your design seriously than you will be indignantly protesting about the

I don't think it has been anywhere near unanimous.


John