David Abrahams wrote:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> 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 accompanying text. 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. Dave