incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [WWW] rebranding...
Date Wed, 04 Jan 2012 15:51:26 GMT
On Wed, Jan 4, 2012 at 3:25 AM, Dave Fisher <dave2wave@comcast.net> wrote:
>
> On Jan 3, 2012, at 7:47 PM, Dave Fisher wrote:
>
>>
>> On Jan 3, 2012, at 6:45 PM, Rob Weir wrote:
>>
>>> On Tue, Jan 3, 2012 at 9:19 PM, Pedro Giffuni <pfg@apache.org> wrote:
>>>>
>>>>
>>>> --- Mar 3/1/12, Kay Schenk <kay.schenk@gmail.com> ha scritto:
>>>>
>>>> ...
>>>>> OK, we got to see the new logo and a
>>>>> bit of a discussion has ensued re the
>>>>> now Apache hosted http://www.openoffice.org/ and the
>>>>> existing logo on that
>>>>> site.
>>>>>
>>>>> My question concerns the extent of "future" rebranding.
>>>>>
>>>>> yes, it's pretty easy to just change out the logo, but
>>>>> should anticipate
>>>>> changing out ALL occurrences of OpenOffice.org to "Apache
>>>>> OpenOffice" as well?
>>>>>
>>>>> Thoughts on this?
>>>>>
>>>>
>>>> I think it wouldn't hurt to leave some references to the
>>>> old brand. Something like "Apache OpenOffice, formerly
>>>> OpenOffice.org" in the main pages and Apache OpenOffice
>>>> in the rest.
>>>>
>>>
>>> That's an interesting idea.  I wonder whether it would work to have
>>> such a "transition" graphic that we use prominently for the next
>>> couple of months, until 3.4 is released?
>>>
>>> It might be worth thinking about how we could do something like that
>>> on the website.  So keep the main branding logo, but have the ability
>>> to insert another banner ad or similar on each page that could be used
>>> for things like a release announcement, conference promotion, or
>>> similar announcement that we want to make broadly known.
>>
>> I think that most of this differentiation can be done at the first folder level using
the same structure used for leftnav and topnav overrides.
>>
>> Here is how it is done.
>>
>> We add to templates a brand.mdtext which contains parameter definitions.
>>
>> home: Home
>> search: Search
>> name: Apache OpenOffice (incubating)
>> bannercenter: (incubating)&nbsp;|&nbsp;The Free and Open Productivity Suite
>> bannerlogo: ooo-logo.png
>> legacytag: This page is for OpenOffice.org 3.3
>>
>> For NLC folders a file like "templates/de/brand.mdtext" would contain German language
versions of these strings.
>>
>> Then skeleton.html is changed like so:
>>
>>    <div id="bannerleft"><img id="ooo-logo" alt="{{ brand.name }}" src="/images/{{
brand.bannerlogo }}"/></div>
>>
>>            <input name="Button" value="{{ brand.search }}" type="submit"
class="topsrchbutton"/>
>>
>>    <div id="bannercenter"><br/>{{ brand.bannercenter }}</div>
>>
>>  <div id="content">
>>    {% block legacy %}{% if brand.legacytag %}<h1 class="legacy">{{ brand.legacytag
}}</h1>{% endif %}{% endblock %}
>>
>>
>> Add a .legacy tag to css/ooo.css.
>
> I implemented the above this evening. The www.openoffice.org/api/ section now has a "legacy"
message.
>
> The main correction to the above plan is that brand.foo tags needed to be brand.headers.foo.
>
> Here are the brand.mdtext files I created:
>
> templates/api/brand.mdtext
> home:           home
> search:         search
> name:           Apache OpenOffice (incubating)
> tagline:        (incubating) | The Free and Open Productivity Suite
> logo:           ooo-logo.png
> domain:         www.openoffice.org
> legacy:         Content for OpenOffice.org version 3.3.
>
> templates/brand.mdtext
> home:           home
> search:         search
> name:           Apache OpenOffice (incubating)
> tagline:        (incubating) | The Free and Open Productivity Suite
> logo:           ooo-logo.png
> domain:         www.openoffice.org
>
> Any file like templates/foo/brand.mdtext completely replaces templates/brand.mdtext parameters.
Ideally only the needed parameters like legacy would need to be in the "foo" brand.mdtext.
In this case,
>
> templates/api/brand.mdtext
> legacy:         Content for OpenOffice.org version 3.3.
>

OK.  I see it.  The generated HTML comes out like this:

    <div class="legacy">Content for OpenOffice.org version 3.3.</div>

We could style this in many different ways.

How is it determined what pages get this inserted?  Is it the presence
of the brand.mdtext in a given directory that makes this apply to all
other files in the dir?  Or is it centrally managed, like a list of
URL paths that get this applied?

In any case, I like the general approach.  You're introducing order
and structure to the website, which is a good thing, even a necessary
thing at this scale.

But I must also admit that I don't get the point of having such a
notice at all on this page.  The API website applies as well to the
3.4 beta, to the test builds we're doing now, to the eventual released
3.4 AOO, etc.  It is a living focus area and will be organically
evolving to help OpenOffice users and developers of whatever version
is active at the time.

But maybe it is just not a good example page for this,  Let's take a
different example:

http://www.openoffice.org/dev_docs/features/

The above is historical information.  It is not going to change.  You
could make the argument that it requires a notice that this
information pertains to pre-Apache releases, and that we are
preserving continuity of access to this information as a service to
the broader community

So maybe the right distinction is between:

A) Pre-Apache "frozen in time" information that we preserve for
historical reasons, like old release notes, design documents, even old
releases.  We never intend to revise this content, but we do preserve
it.  It should have a disclaimer of some sort.

B) Pre-Apache content that is living, is being updated or we're
planning to update it.  Is not intended to an historical reference,
but to represent the current state of the project whenever it is.
Although today such content might be out-of-date, it is not
intentionally frozen in that state.  A project member could change
that content at any minute, and in fact we should try to encourage
their ability to do that.  No disclaimer needed in that case.


> Suggestions?
>
>>
>> If we want to add a metatag or comment to specific pages then we can extract that
using the technique that Joe used to remove the use of sed today. Thanks Joe!
>
> If and when this distinction is needed changes can be made to view.pm and skeleton.html
>
> Regards,
> Dave
>
>>
>> Regards,
>> Dave
>>
>>>
>>>> Pedro.
>>
>

Mime
View raw message