incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [WWW] rebranding...
Date Wed, 04 Jan 2012 16:07:09 GMT

On Jan 4, 2012, at 7:51 AM, Rob Weir wrote:

> 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?

It is controlled from ooo-site/trunk/templates/

These files apply to the whole website.
./brand.mdtext
./topnav.mdtext
./html_page.html
./single_narrative.html
./skeleton.html

These files apply to all of the content in ooo-site/trunk/content/api/
./api/brand.mdtext
./api/leftnav.mdtext

If the following files were present then they are applied to ooo-site/trunk/content/foo

./foo/brand.mdtext
./foo/leftnav.mdtext
./foo/leftnav.mdtext

It only goes to foo. ooo-site/trunk/templates/foo/bar/brand.mdtxt is NOT supported. It could
be if that becomes needed but I would want to solve the override issue - each brand.mdtext
 completely overrides the lower levels.

> 
> 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/

Sure that whole tree is historical.

> 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.

Sure - feel free to remove templates/api/brand.mdtext and create a templates/dev_docs/brand.mdtext

Regards,
Dave

> 
> 
>> 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