From: David B. Held (dheld_at_[hidden])
Date: 2005-03-08 23:52:33
David Abrahams wrote:
> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>>David Abrahams writes:
>>>Or it doesn't iconify well, just for example.
>>Never understood why it's important. What's the use case for it
>>besides that smallish icon in the browser's address line that hardly
>>anybody cares about? 95% of all the logos out there don't iconify well
>>or at all.
> Okay, you have a point -- sort of. The graphic parts of many of the
> best logos I can think of are iconish in nature. I'm thinking of
> Pepsi, Nike, Sun, Microsoft Windows, BMW, Toyota, Apple...
> Not that I can say much about _why_ I think that's important ;-)
I think it's important because it illustrates a kind of robustness
in the logo's visual qualities. We demand our code to scale, why
not our graphics? Logos that iconify well have an *elegance* to
them that is not fragile and scale-sensitive. That elegance is
what people respond to. It's also about branding. A nicely scalable
logo is more likely to evoke the associated brand without any
Having said all that, I guess I have to wonder if perhaps Boost
really *needs* such a high-powered logo. It's not like a development
tool where end-user applications might contain the logo as a default
icon. It's not like an application that generates data files that
might contain the logo. It's not like a commercial enterprise that
might want to put the logo on various marketing and advertising
products. So at the end of the day, perhaps we should content
ourselves with something that looks good on the website, since that
is probably where the logo will appear 99% of the time.
My own desire for a scalable logo probably derives more from a
demand for excellence than an actual identifiable need of the
Boost "brand". I guess I think of a nice but non-scalable logo as
a finely designed concrete type, and an elegant scalable logo as
a powerful generic type. The scale-bound logo works fine in
prescribed contexts, but the scale-free logo works in nearly
any context. Since Boost aims to provide powerful libraries
that free the user from context-specific solutions as much as
possible, I tend to transfer that expectation to its art, which
may not necessarily be fair.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk