"Python Redesign" (fwd)

Discussion in 'Python' started by David Mertz, Sep 8, 2003.

  1. David Mertz

    David Mertz Guest

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

    |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...
    David Mertz, Sep 8, 2003
    #1
    1. Advertising

  2. David Mertz

    John J. Lee Guest

    (David Mertz) writes:

    > <> 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
    John J. Lee, Sep 8, 2003
    #2
    1. Advertising

  3. David Mertz

    Terry Reedy Guest

    "John J. Lee" <> wrote in message
    news:...
    > 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
    Terry Reedy, Sep 8, 2003
    #3
  4. David Mertz

    Peter Hansen Guest

    Terry Reedy wrote:
    >
    > "John J. Lee" <> wrote in message
    > news:...
    > > 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.


    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
    Peter Hansen, Sep 8, 2003
    #4
  5. David Mertz

    David Mertz Guest

    |> <> wrote:
    |> 1) it's an image

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

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

    --
    ---[ to our friends at TLAs (spread the word) ]--------------------------
    Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
    White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
    ---[ Postmodern Enterprises <> ]--------------------------
    David Mertz, Sep 8, 2003
    #5
  6. David Mertz

    Aahz Guest

    In article <>,
    Terry Reedy <> wrote:
    >"John J. Lee" <> wrote in message
    >news:...
    >>
    >> 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.


    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.
    --
    Aahz () <*> http://www.pythoncraft.com/

    This is Python. We don't care much about theory, except where it intersects
    with useful practice. --Aahz
    Aahz, Sep 8, 2003
    #6
  7. David Mertz

    Terry Reedy Guest

    "Aahz" <> wrote in message
    news:bjif13$ou8$...
    > In article <>,
    > Terry Reedy <> wrote:
    > >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.

    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
    Terry Reedy, Sep 8, 2003
    #7
  8. David Mertz

    Aahz Guest

    Making mock (was Re: "Python Redesign" (fwd))

    In article <>,
    Terry Reedy <> wrote:
    >"Aahz" <> wrote in message
    >news:bjif13$ou8$...
    >> In article <>,
    >> Terry Reedy <> wrote:
    >>>
    >>>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.

    >
    >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.
    --
    Aahz () <*> http://www.pythoncraft.com/

    This is Python. We don't care much about theory, except where it intersects
    with useful practice. --Aahz
    Aahz, Sep 8, 2003
    #8
  9. David Mertz

    Tayss Guest

    Re: Making mock (was Re: "Python Redesign" (fwd))

    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
    Tayss, Sep 9, 2003
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Davide Carboni
    Replies:
    0
    Views:
    350
    Davide Carboni
    Dec 18, 2003
  2. Tim Parkin

    Comments on Python Redesign

    Tim Parkin, Sep 7, 2003, in forum: Python
    Replies:
    24
    Views:
    754
    Anton Vredegoor
    Sep 8, 2003
  3. Tim Parkin

    Comments on Python Redesign

    Tim Parkin, Sep 7, 2003, in forum: Python
    Replies:
    0
    Views:
    288
    Tim Parkin
    Sep 7, 2003
  4. James P. Rutledge

    Re: Comments on Python Redesign

    James P. Rutledge, Sep 7, 2003, in forum: Python
    Replies:
    3
    Views:
    259
    John J. Lee
    Sep 7, 2003
  5. Tim Parkin

    RE: "Python Redesign" (fwd)

    Tim Parkin, Sep 8, 2003, in forum: Python
    Replies:
    1
    Views:
    310
    Terry Reedy
    Sep 8, 2003
Loading...

Share This Page