cloudstack-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Mullins <>
Subject Re: Wiki visual guidlines
Date Fri, 01 Mar 2013 17:16:40 GMT

I think you're are both right, and they both have to be done. It's harder, it's longer, but
it's the right and best west way to do it. The two websites that I personally hate the most
are the ones that have great content, and are hard to look at and use; or the ones that are
beautiful and the content is useless.

I've only been working with the project for about 6 months and I can tell you from an outsider's
point of view that when I first came into it, even being a citrix employee, it was extremely

The Quality finally has got there, and Joe is right that MUST be maintained, but if you really
want to grow this and get people to join, Ilya is right, you have to have to something attractive
to lure them in and keep them.

Look at Openstack's page. While the content may not be super flashy or techno-beautiful, every
page has three key compents:
1. Content that matches the stated purpose of the page (Quality is in the eye of the beholder
2. The navigation is easy and user friendly
3. Each page is consistent and high quality standards match on every single page. One logo,
one font, one style sheet.

Isn't this the level that we are really talking about taking this too?

Thank you,

On Mar 1, 2013, at 11:56 AM, "Musayev, Ilya" <<>>

I think the *code* and *quality* of documentation mean a lot more than whether we have consistent
colors and branding. Again - if we have anything that's just hideous to look upon in the wiki,
we should certainly fix it.
I'm all for quality of content and code, but we need to keep in mind that people tend to judge
the book by its cover - especially the new comers. In comparison, the CS layout / usability
is hands down one of the best and pleasant layouts I've worked with. Wiki - needs a little
help - though as you said, should not be a high priority.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message