Re: font preview screenshot

From: Joaquin Cuenca Abela (e98cuenc@yahoo.com)
Date: Wed Aug 28 2002 - 03:43:20 EDT

  • Next message: Hubert Figuiere: "Fwd: Re: AbiWord Font Usability question"

    --- Dom Lachowicz <doml@appligent.com> wrote:
    >
    > On Tuesday, August 27, 2002, at 02:09 AM, Joaquín
    > Cuenca Abela wrote:
    >
    > > It seems that the 2 main criticism against the way
    > Word handles font
    > > preview are:
    > >
    > > 1) Usability. As Karl said "The font size is much
    > > to small to get a useful impression of the font
    > (and often make it
    > > very difficult to read the actual font name)"
    > >
    > > 2) Resources. It takes too much to preview all the
    > fonts.
    >
    > This is not counting my:
    >
    > 3) This approach is not necessarily desirable
    > because it's kind-of ugly
    > and the list is potentially hard to read through
    > (potentially related
    > to how well the human eye scans through many short
    > text strings that
    > are written in a variety of font faces).

    good point. I still prefer the word approach, but
    it's a good point.

    > I can't advocate emulating MSWord without
    > considering that there might
    > be viable alternatives.

    Of course, I agree 100% with you. It's just that in
    this case my opinion is that Word is doing it better
    than us. I'm not in "everything != from MS is bad"
    mode :)

    > Please try to consider my
    > suggestion that
    > Marc's font preview + always previewing the
    > currently used font
    > (inside of the toolbar) might be a *superior*
    > approach to what MSWord
    > does from a usability standpoint.

    I've considered it. It has a very clear advantage
    over MSWord approach, because the font is very
    readable, and you get a very good feeling of what's
    going to the printer (at 10pt hinting has probably
    deformed too much the font from what you get at high
    resolution).

    That's why I said to pick MS approach (because *for
    me* the MS way has other advantages over our way), but
    using larger sizes for the preview.

    > It is interesting
    > to notice that
    > Apple's font selection dialogs don't display each
    > font's name in that
    > particular font's face. They do, however, display
    > the selected font's
    > name in its respective face, though.

    And also did MS in older versions. I don't know if
    apple remained in its position after user testing or
    if MS changed it due to user testing. Probably none
    of them :)

    > We are not usability experts and shouldn't pretend
    > to be.

    Well, my speciality in computer science is 50%
    computer interfaces, 50% speech recognition. I spend
    more than 6 months studying (and implementing)
    computer interfaces, but most of them where quite
    radically different from what we use today.

    IMO these kind of decisions depend mainly of

    1) common sense
    2) user testing
    3) past experience

    And I agree that the GNOME HIG team have more of these
    than me :)

    > I promise to
    > talk to the GNOME HIG and Seth Nickell about this
    > and see what they
    > have to say in this matter. I am not advocating my
    > suggestion or
    > "dissing" yours. I am merely pointing out that there
    > is more than one
    > *good* suggestion on the table here, and we should
    > really get some
    > more-expert opinion here before actually doing
    > anything. Usability
    > features done poorly often are worse than not having
    > those features at
    > all.

    Agreed 100%. Of course I will also accept the final
    decision, whatever it is.

    > Re: performance - For what it's worth, Mariner Write
    > on OSX has this
    > feature. I have a fast (866MHz 512MB RAM) Mac
    > running Jaguar. It takes
    > ~4 seconds to load and display the font menu. It is
    > also sluggish when
    > scrolling. GNOME HIG guidelines state that an
    > operation like this
    > should take about .1 seconds, so this would be about
    > 40x too slow.
    > BBEdit 6,5's font menu has a similar startup
    > problem. Hub pointed out
    > on IRC that some older apps did some hacking/caching
    > to get around this
    > problem. They'd store the font name + the preview
    > image in a cache to
    > get around this slowness.

    Word does it quite fast in my computer. It
    definitively caches it (as first time is a bit slower
    than others).

    I agree (without measuring it) that it will be a
    problem with current code, but I think that it may be
    solved. I don't say that it's something trivial to
    make such a menu at < 0.1s, but we should measure it
    and see where are the bottlenecks before ruling out
    the idea due to "performance issues".

    Cheers,

    =====
    Joaquin Cuenca Abela
    e98cuenc@yahoo.com

    __________________________________________________
    Do You Yahoo!?
    Yahoo! Finance - Get real-time stock quotes
    http://finance.yahoo.com



    This archive was generated by hypermail 2.1.4 : Wed Aug 28 2002 - 03:47:34 EDT