"Python Redesign" (fwd)

[David Mertz]

|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.

|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.

|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.

I don't remember a URL offhand, since those are--almost by definition
--sites I do not visit more than once. But, for example, I find some
pages choose absurdly small font sizes for various elements; which makes
me very happy that I use Mozilla, which has an option for "minimum font
size". It doesn't seem always to work, I still sometimes see tiny fonts
(I dunno how they get by Moz exactly, maybe Javascript or something).
But more often, once the fonts are forced to a readable size, the layout
becomes almost unreadable. Sometimes different texts render on top of
each other (I think because of the <layers> tag, but it could be something
else). Or other times, a text box winds up with one word per line once a
readable font is used.

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.

|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
Andy Kuchling gets widely read with his "What's New in ..." and other
articles, so maybe more read him.

|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.

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
fact your design is an image. I think I'd recommend that even if I
understood why you think the image thing is relevant.

Yours, David...

 

[John J. Lee]

|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

 

[Terry Reedy]

It seems fairly clear by now that the purpose of the mockup was to

What we were directed to was *not* a mockup (model), but an image of a
mockup. That mislabeling was a source of misunderstanding which
generated part of the criticism. Please let us keep the useful
distinction between a thing and an image of the thing.

Terry J. Reedy

 

[Peter Hansen]

What we were directed to was *not* a mockup (model), but an image of a
mockup. That mislabeling was a source of misunderstanding which
generated part of the criticism. Please let us keep the useful
distinction between a thing and an image of the thing.

There is no such hard-and-fast definition of "mockup". You used
one interpretation, and a valid one at that, others have a different one,
equally valid.

I do lots of prototyping and mocking-up of things and I see no
difficulty in calling either approach a "mockup". For those of you
who, perhaps, don't deal with mockups much, please understand that
the term really just means "this is not the real thing, but exists
to encourage and assist discussion", and nothing more.

-Peter

 

[David Mertz]

|> 1) it's an image

|[email protected] (David Mertz) writes:
|> 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.

(e-mail address removed) (John J. Lee) wrote previously:
|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 --

Kinda. I *did* assume it was a real HTML page when I first looked at it
(I tried clicking on the links). But I realized it was an image before
I posted anything.

But I was mistaken about the sort of image it was. I assumed Parkin had
written some HTML (maybe with some tool), then taken a screenshot of
that as rendered in some browser. Specifically, I imagined that the
underlying HTML had fixed pixel-based "width=" attributes for those
boxes/tables. In retrospect, the assumption about pixel-based widths
wouldn't actually follow from the idea it was a screenshot.

However, that's all moot apparently, since the picture seems to have
been drawn directly in some graphics application, without any HTML
having ever been created. It certainly seems like a weird approach to
me; it also makes the question of whether pixel- or percentage-based
widths were used meaningless.

|> I *am* probably the most widely read writer on Python topics

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

No... my point was more that I am already in the business of trying to
"sell" Python, in some sense. I write articles and books (well, one so
far) in part to encourage new developers to select Python, versus some
other language/technology.

Btw. In my remark (which I wrote privately to Parkin, but posted after
he posted a response that quoted mine), I think I failed to give proper
respects to my excellent colleagues Cameron Laird and Uche Ogbuji, both
of whom are also very widely read with similar articles to mine. I only
claim "most" because Cameron and Uche--being smarter than I--are a bit
less narrow in what they cover (i.e. more outside of Python).

Yours, David...

 

[Aahz]

What we were directed to was *not* a mockup (model), but an image of a
mockup. That mislabeling was a source of misunderstanding which
generated part of the criticism. Please let us keep the useful
distinction between a thing and an image of the thing.

And I'll repeat that in addition to Peter's valid point about differing
definitions of mockups, Tim was not the person who pointed "us" at it.
This has been an out-of-context review of a draft.

 

[Terry Reedy]

And I'll repeat that in addition to Peter's valid point about differing
definitions of mockups, Tim was not the person who pointed "us" at

it.

So what? I neither said nor implied so. The identity of the original
pointer is irrelevant to the point I made. And so is repetition of a
correction of an error I did not make.

In any case, Parkin also used (and today defended) the word himself in
his subsequent posts. Leaving dictionaries aside, the use of the
disputable word 'mockup' instead of the accurate word 'image' lead to
unfulfilled expectations and criticisms based thereon. Indeed, Parkin
himself deflected such criticisms several times by saying 'its just an
image' [and not the html mockup some thought it was].

Do you really think inexact words that lead to misunderstanding are as
useful as exact words that do not? Do you really think the
distinction between object and image is useless? These are the
questions I raised and gave my answer to.

Terry J. Reedy

 

[Aahz]

So what? I neither said nor implied so. The identity of the original
pointer is irrelevant to the point I made. And so is repetition of a
correction of an error I did not make.

It's not so much that the identity of the pointer is relevant as that
the context in which "mockup" is used is important. I think it's
certainly appropriate, for example, to use "mockup" to describe the
whiteboard of a proposed design during a brainstorming session. That's
why I made my comment.

In any case, Parkin also used (and today defended) the word himself in
his subsequent posts. Leaving dictionaries aside, the use of the
disputable word 'mockup' instead of the accurate word 'image' lead to
unfulfilled expectations and criticisms based thereon. Indeed, Parkin
himself deflected such criticisms several times by saying 'its just an
image' [and not the html mockup some thought it was].

You yourself are now using the phrase "html mockup" as a specific kind
of mockup. That's an accurate phrasing.

Do you really think inexact words that lead to misunderstanding are as
useful as exact words that do not? Do you really think the
distinction between object and image is useless? These are the
questions I raised and gave my answer to.

The distinction isn't useless, but neither do I think this was an
example of inexact language *in* *context*. If I specifically wanted to
refer to a non-image mockup, I'd say "working mockup" or something like
that, perhaps "HTML mockup" as you did if I were referring to a web
page.

 

[Tayss]

As I understand, people were unhappy he gave us a prototype. However,
some developers even talk about paper prototypes.
http://www.joelonsoftware.com/news/20030516.html

Not everyone gets to use a language where the prototype is the working
implementation.

- Tayssir John Gabbour