On Jan 4, 2012, at 7:51 AM, Rob Weir wrote: > On Wed, Jan 4, 2012 at 3:25 AM, Dave Fisher <[email protected]> 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 <[email protected]> wrote: >>>>> >>>>> >>>>> --- Mar 3/1/12, Kay Schenk <[email protected]> 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) | 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. >>> >>
