[openbeos] Re: the new website
- From: "Jorge G. Mare (a.k.a. Koki)" <koki@xxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 26 Aug 2006 11:44:46 -0700
Hi Waldemar,
Waldemar Kornewald wrote:
On 8/26/06, Jorge G. Mare (a.k.a. Koki) <koki@xxxxxxxxxxxxxx> wrote:
Waldemar Kornewald wrote:
> What is the difference between "Newsletter" and "Developer blog"? My
> intention is to unify both into some kind of "article" which is
> similar to a blog, but more professional and only Haiku-related.
The Development Blogs are like "online diaries" where the devs can post
development stuff/rants/experiences at any time; it is more of a
personal thing, and it is very dynamic. We could well also call this
section "Devs Blogsphere" or "Devs Planet" (which is very much in vogue
these days).
The newsletter is a less dynamic media that would be published
periodically (on the web to start, potentially in print in the future)
with mostly Haiku related articles contributed that can be technical or
otherwise in nature. Think of it more like a magazine.
Why should we separate this and why should our developers mix
interesting blog entries with personal rants? Actually, I think that
we should not have *any* rants on the Haiku website. Personal rants
are for personal websites. The "articles" are intended as a newsletter
replacement, but with a lot more progress reports and Haiku-related
articles.
My fault: by "personal rants" I did not mean to imply that we encourage
the devs to post about their personal life. Yes, all content should be
related to Haiku; but within that context, they can have a personal
touch; that is the nature of blogs.
The newsletter is a different animal. It is a bit more formal, and also
meant to build value. As mentioned in my reply to Axel, I see the
newsletter as a potential incentive for people to write articles (beyond
their blog), a means for promoting the project (and eventually the
product), and potentially a space for our sponsors (both existing and
future) to advertise in, opening the possibility of raising funds for
the project.
The Community Wiki is a place where the community can contribute
content. Your concern that it may create duplication and therefore
confusion is valid, so perhaps we could simply limit the content; this
could be handled by creating workspaces, such as the following:
- How To's
- Code snippets
- Guestbook
- Beta Docs
The "Beta Docs" deserves special mention; this could be like a "draft"
workspace for community-contributed documentation that, after review
(and changes if necessary), can be moved over the to Documentation area.
I don't think we need a guestbook. How To's could be part of Beta Docs
as all documentation should be part of our website. I agree, we should
limit the wiki to "draft content".
Those were ideas of how the wiki could be used in response to the "what
do we want a wiki for?" questions. But really, the point here is that
having a wiki is a good thing, as it gives those outside of the project
an opportunity to show themselves, and potentially contribute with
documentation that could be useful.
I do not want ugly hacks, so we agree on that. :-)
I was thinking something along the lines of this:
http://drupal.org/handbook/modules/blog
I am not concerned about the content; it is a blog, where people can
rant, and others can comment. It is more of a social thing.
I think it would be too unprofessional to have this on our website.
All important content should be part of the official website section
and that doesn't leave much room for interesting Haiku-related
articles in the user section. This will end in too many off-topic
discussions and that's exactly what we should not have on the official
site.
What user section?
I prefer a separate community site which offers much more than just
blogs. It should for example also have email accounts. It should be
done by the community because we don't have the resources for this.
It is not really what you or I prefer, but what is best for Haiku. :-)
The Community area is meant to give the community a place to express
themselves and to nurture a sense of community. There is really no need
to have a separate site for this, as long as it is clearly
distinguishable from the rest of the site.
Please, take a look at www.zeta-zone.net/haiku/forums_mockup.jpg and
note the "Community" co-branding next to the logo, and the navigation
links under the top menu. This is more than enough to convey that while
you are at the Haiku site, this particular area is community driven.
So the question is: is it possible to change the logo for the Community
area to one with the community co-branding signature?
The *Community Forums* (with a special stress on *commnunity*) are
another place for the community to exchange ideas, tips, or to simply
socialize. It is for the community, and will not be confounded with
anything official.
Exactly. Our phpBB forums already do this job.
Does that mean that we will migrate the phpBB forums to the new website?
If that is the case, that should go under the "Community" area.
Haiku is composed of teams (development, marcom, etc.) that work
together for a common goal. The devs focus on the code, we at marcom
will focus on how to market the ideas (and eventually the product) of
Haiku best. Teams communicate, discuss and coordinate (this is what the
admin meetings should be for). We can also disagree. But in the end, we
should trust each other's good judgment in each particular area of
competence. Trying to subordinate any function to the another (which is
what you seem to be implying) will only work for one side, but not the
other, and in the end for nobody.
You talk about "trust", but then you don't even want to give the
developers (the people who *make* Haiku! it's *their* product!)
access. That's a bad solution and I doubt that any of us will accept
it. We trust you if you trust us.
Too bad that you take it that way. :-(
It is not a matter of trust, it is a matter of being practical, and let
each group of people do what they do best. It is also a matter of giving
marcom certain autonomy to exercise its expertise (like the devs have in
the realm of engineering).
It's OK that the core devs have full access; but it would have to be in
a manageable way. The "anybody can post anywhere, anytime" approach does
not work if you want to have a cohesive, compelling message, and that is
what marketing is all about.
The content that would be under the marketing umbrella is the following:
- Front page
- About (which includes FAQ)
- News & Events
- Newsletter
Tell me, which of the above is largely produced and/or initiated by the
devs?
There is news when our developers achieve a new goal. The developers
decide which direction our product takes (About). The newsletters have
always been written by our developers. The front page is just a
summary and starting point for those articles.
While Haiku would admittedly not exist without the devs that create the
code, and I deeply appreciate what the devs do (I really do), Haiku is
more than just devs, and it will be more so as it grows. I would
(gently) ask if you could try to acknowledge that there are people that
can contribute in areas of competence other than yours. Otherwise, there
is no need for a marcom team (or any other non-engineering team for that
matter).
If you think of it, the fact that you have such a narrow view of what
news can be, and clearly underestimate the persuasion power and
usefulness of a well thougthout and designed front page is in itself
proof that Haiku could indeed greatly benefit from a marketing function.
Whether you are willing to acknowledge that or not, is another matter. :-)
> Is the internal team structure really of any interest to end-users?
> We don't have sponsors, yet, but I hope that this will change. :)
It is important that people beyond the small circle of Haiku fans start
knowing who are the individuals behind Haiku. In the long term, it
produces recognition and value. Just to give you a practical example, if
Haiku decided to participate in at conference in, say, Japan, and Axel
were to give a presentation, the attendance that you can expect could
heavily vary depending on whether people know who Axel is or not. Making
the individuals known also open up editorial opportunities, something
that will be very valuable for Haiku being that we do not have the $$$
resources to pay for advertising.
That's not what I meant. The internal team structure is too detailed.
I wanted to have a "The people behind Haiku" page which describes all
main developers:
* name
* location
* year of birth / birthday
* hobbies (apart from Haiku)
* maybe a funny quote
* what the other developers say about him
* real-life identity (web designer, student, etc.)
And maybe a few "funny" questions along the lines of "coffee or tea?".
That would indeed fit into "About".
Makes sense, but it does not have to be limited to developers. However,
what I would like to see are teams that actually perform specific
functions within the Haiku organization (for ex., admin, development,
marcom, QA/Testing, certification, etc.), with their respective members,
and a point of contact.
This has to reflect as faithfully as possible the organizational reality
of Haiku, and not be like
http://haiku-os.org/contribute.php?mode=teams, which looks more like a
development categorization of tasks (instead of an organization of
project functions), and lists many teams that are actually non-operational.
with the public (Haiku fans + the rest of the world). As the number of
news items builds up, it is very convenient to have the news archived by
topic, month, and even years. It makes it extremely to find what you are
looking for. Something along the lines of this:
The news is the conduit for official/formal announcements/communication
Okay, I just want the "latest news" to be part of the front page.
Apart from that I agree that we should have such an archive and I saw
a Drupal plugin somewhere which offers weekly and monthly (and
yearly?) archives.
News needs to be a section on its own, with an entry in the top menu, a
page with the latest (10?) entries and links to the archives. In the
front page we can have a block that lists, say, the 10 most recent
headlines (just the headlines, not the news). I would like to use the
real estate in the front as wisely as possible (mockup coming).
WalterCon DEFINITELY needs its own entry! WalterCon is great opportunity
that we have to exploit more, and the way to do that is to have a place
where you can always find information about the event, present, past and
future. Not only would we use it to inform of future events, but also to
archive information about the events that happened in the past, and
provide some of the content for download (pictures, videos, etc.). In
the future, we may even look into how to automate some of the logistics
to organize the show, such as allowing donations specific to WalterCon,
and having a payment mechanism for the attendants. Last but not least,
WalterCon has sponsors, and this is where they will get the recognition
for supporting the event.
You're right. I just thought it would not be necessary to make this
section extremely visible, but now I agree. I'd just rather call it
"Community Events" or something like that and mention events all over
the world (WalterCon, BeGeister, is there something in Japan?, etc.).
Hopefully, with time, there will be more in more places. :-)
>
> What about end-user documentation?
We are not addressing end users deliberately, as our key targets right
now are developers. Provisions will be made for user documentation for
when Haiku 1.0 is released.
>> - Development (as is + Documentation)
Does this mean that we should not prepare the website for this? That
would be very short-sighted.
Going back to the early conversations about whether marketing was needed
or not, there was the concern among the members of the project (mainly
devs) that it was premature to promote Haiku to end users, and therefore
marketing was not yet needed.
I share those concerns and I think we need to keep the expectations to
manageable levels. In that spirit, I believe that any user-oriented
content that could be interpreted as "Haiku is ready" should be put off
until the release of at least a public beta (if we will have such a
thing) or beyond. While what falls into that category may debatable, but
anything that carries the word "user" is a suspect. :-)
Is there any problem with adding the user-oriented content later from a
logistics point of view?
"Collaborate" sounds more like a community oriented place, but
terminology aside, I have no clue what the plans are for certification
(if any), so I cannot comment intelligently on the subject. If the
certification process has been defined, and whatever guidelines/specs
need to be met have been documented, then you may need a place for this
information; if nothing is defined and there is no documented
guidelines/specs, then I don't see the point to this page.
Well, it's not only this certification (which must still be worked out
and you would be the perfect person for it, I guess). We also should
have a place for official logos ("Haiku", "Get Haiku", "Haiku User"
and "Haiku Developer" and "Haiku Tester" banners, etc.) and other
marketing material. Michael suggested to call it the section
"Marketing", but IMHO it doesn't really fit with the
certification/distribution information.
Certification is not my forte, so I will leave that to someone else. :-)
We indeed need a place for the "marketing stuff" that would include
logos, branding guidelines, etc. I am inclined to think that this needs
a menu entry, but perhaps it is not imperative. Usually, such content is
targeted to the media, which is why many projects put it under an area
called "Media", "Press" or something along those lines.
> This is at least much better than having *nothing* to work with. I
> like progressing in quick steps more than having to wait and doing
> nothing.
Sorry, but my goal is not to keep people busy, but to try to make things
better. But I understand your frustration. :-)
It's just that you can't take every possible problem into account if
you do this alone. It will take *much* more time than discussing it
with us and working on it together. You will never be able to release
the *perfect* proposal.
From all my past experiences, in a collaborative efforts that involve
multiple individuals, all discussions happen during the planning stage,
conceptual mockups are then created to define the
organization/layout/design of each area, and then but only then is the
web developer cut loose to do his work. The problem is not that we are
having discussions, but that we are having the discussions after the fact.
Koki
Other related posts:
