Hi Nik, all,
Great to have you back officially :)
On Thu, Dec 23, 2010 at 4:43 AM, Nik <nik@tdf.nikashsingh.com> wrote:
Hi Bernhard, Christoph, all,
I know this isn't something on our current to-do list or a priority, but
I've been watching the talk about the soon-to-be-launched Lib/O site;
http://test.libreoffice.org/
I know this is a work-in-progress and I see the hard work that was put into
its realisation. So I don't mean to undermine any efforts so far.
But if the site is going to be live, I'd like to help address the overall
appearance so it doesn't look so "raw". I've uploaded a couple of quick
mock-ups here;
http://wiki.documentfoundation.org/User:Nik#Interim_Website_Design_proposals
Yeah, it is pretty raw. Your mockups, on the other hand, quick or not,
look polished. I like the two tiered navigation design - I don't know
if you saw my mockup(s), but yours is definitely better in this
respect. I'm not sure if the contrast on the second tier is sufficient
though.
They show a potential arrangement for the Homepage and an example of a
two-tiered navigation.
(Past usability concerns about this type of horizontal menu bar can be
addressed using some intelligent JavaScript).
If I've jumped the gun, or contributed unnecessarily on a topic that has
already been finalised, my apologies and no harm done.
I just want to help ensure Lib/O puts its best foot forward.
+1. I agree with Christoph in that we shouldn't rush to get the
website out at all costs (or something near that), but then again I am
a bit of an idealist. The obvious problem is that as the design team,
we'll need time to come up with a finalised design, and from David et
al's perspective, that's time we don't have. We can always improve on
the design, but, as Christoph stated, this is all initial branding.
On a less helpful note, I wrote this Email (below) some time ago in response
to the icons. For some reason it wasn't received by the list.
I've included it below because I still feel that the concern I raised should
be aired while discussion on the branding is still relevant.
I hope you find time to read it even though it is somewhat long, but I'll
understand if you don't get a chance (it *IS* Christmas after all).
Happy Holidays everyone!
-Nik
PS. I know this is probably more relevant to the Website list but I didn't
want to cross-post and I thought it warranted discussion on the Design list
first.
In case I've made a mistake.
UNRECEIVED EMAIL;----------------------------------------
Hi Bernhard, Christoph, all,
Christoph Noack wrote:
Okay, but - at the moment - you might be more interested in the page
I've already mentioned:
http://wiki.documentfoundation.org/User:ChristophNoack/Initial_MIME_Icons
Can a be a real wet sock and just bring up a concern quickly before
everything is set in concrete regarding the file icons?
I noticed that the icons carry on from the current logo design. While the
logo design concept of the dog-eared document is iconic and intuitive, I
think the implementation of the logo needs some work before it looks like a
professional brand. But that may just be my opinion.
We've already had discussions here on improving the initial branding,
and some of that has been implemented (e.g. branding colors). Beyond
that, we were initially caught between creating/adapting/supplying
artwork for a product that needs to ship very soon and creating a
comprehensive branding framework that is done in an open source
manner. We couldn't do both; rushing now to create a comprehensive
identity would have been too chaotic. So, for now, our primary focus
is on the initial branding which requires us to be reasonably
conservative; as time passes we will shift to the latter.
What is more relevant right now is the derived styling of the mime-type
icons and the "reflective surface" in particular.
I'll be bold and get straight to the point: I think there is no need for
those icons to be reflective or "shiny".
Hmm, there was no intention (on my part) to make the icons
shiny/reflective (a la the 3.0 splash screen) - if you're referring to
the lighter patch near the top (which was a transparent segment with a
solid white fill in my proposal), that's intended to denote a document
header rather than a reflection (at least in my mind), and could be
removed if it gives the wrong impression.
[...]
This is just a request. But I hope you'll consider it an important one for
getting our brand right?
I know I'm raising concerns without offering solutions and I know it may not
be practical to do so at this time.
I'm sure I'm being idealistic while you're all being pragmatic, but I just
thought it was worth asking in case it was an oversight.
Fair enough (I, too, have been guilty of reflections in the past, I'm
still guilty of idealism, etc), and it's great to have your feedback -
feel free to take the mockups and make changes if you have a specific
vision in mind. Do you think they'd be better without the white
transparent segment at the top, or are there other changes you think
would make them better? Again, the approach has been reasonably
conservative (e.g. keeping the same symbols as OOo) to ease the
transition process for users (addressing the usability concerns with
the 3.2.1 icons), speed up the design process and secure short term
branding.
Happy holidays everyone!
- Ivan.
--
Unsubscribe instructions: E-mail to design+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.