You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Dave Fisher <da...@comcast.net> on 2011/07/02 21:57:14 UTC
Website Content plus Look and Feel Improvements
Yesterday I got tired of the look of people.mdtext in the project site. It was so 1990s. So, I've improved the look via css and adding defined widths. I guess I am volunteering for the item on https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted
Several of us have been surveying the existing openoffice.org website on several wiki pages mostly linked to from:
https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan
With over 140 "projects" in openoffice.org, it will be important to agree to a mapping which reduces the granularity by more than an order of magnitude. The page http://projects.openoffice.org/ is a good and clear way to start - and pretty much fits the structure on https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning
• Product Development
• Extension Development
• Language Support
• Helping Users
• Distribution
• Promotion
I think that these groupings will help us easily have a rule about which projects end up on http://openoffice.apache.org/ or stay on the successor http://*.openoffice.org/.
Projects have "webcontent" and/or "wiki" content. On openoffice.org there is a generally consistent look. There are exceptions which are marketing sites like http://why.openoffice.org/. The difference is glaring because that is the first big button on the main site.
Webcontent is available via svn - "svn co https://svn.openoffice.org/svn/${project}~webcontent ${project}" (Thanks Marcus Lange)
Some projects are huge and others small. I downloaded several:
wave@minotaur:~/ooo-test$ ls -1
development
documentation
download
projects
www
The size is 2.7GB.
It would be good to come up with a scripted way to convert existing webcontent to either mdtext, an altered html, or specialized javascript and css. It is likely we can adapt the content and use the Apache CMS to wrap a standard skeleton.
Regards,
Dave
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 2, 2011, at 5:26 PM, Raphael Bircher wrote:
> Am 03.07.11 01:30, schrieb Kay Schenk:
>> On Sat, Jul 2, 2011 at 3:41 PM, Raphael Bircher<r....@gmx.ch> wrote:
>>
>>> Am 02.07.11 23:41, schrieb Kay Schenk:
>>>
>>> OUCH! see below...
>>>> On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher<da...@comcast.net>
>>>> wrote:
>>>>
>>>> Yesterday I got tired of the look of people.mdtext in the project site.
>>>>> It
>>>>> was so 1990s. So, I've improved the look via css and adding defined
>>>>> widths.
>>>>> I guess I am volunteering for the item on
>>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Help+Wanted<https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted>
>>>>>
>>>>> Several of us have been surveying the existing openoffice.org website on
>>>>> several wiki pages mostly linked to from:
>>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Site-PPMC-Plan<https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan>
>>>>>
>>>>> With over 140 "projects" in openoffice.org, it will be important to
>>>>> agree
>>>>> to a mapping which reduces the granularity by more than an order of
>>>>> magnitude. The page http://projects.openoffice.**org/<http://projects.openoffice.org/>is a good and clear
>>>>> way to start - and pretty much fits the structure on
>>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>>>> Project+Planning<https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning>
>>>>>
>>>>>
>>>> • Product Development
>>>>> • Extension Development
>>>>> • Language Support
>>>>> • Helping Users
>>>>> • Distribution
>>>>> • Promotion
>>>>>
>>>>> I think that these groupings will help us easily have a rule about which
>>>>> projects end up on http://openoffice.apache.org/ or stay on the
>>>>> successor
>>>>> http://*.openoffice.org/.
>>>>>
>>>>> Projects have "webcontent" and/or "wiki" content. On openoffice.orgthere
>>>>> is a generally consistent look. There are exceptions which are marketing
>>>>> sites like http://why.openoffice.org/. The difference is glaring because
>>>>> that is the first big button on the main site.
>>>>>
>>>>> Webcontent is available via svn - "svn co
>>>>> https://svn.openoffice.org/**svn/${project}~webcontent<https://svn.openoffice.org/svn/$%7Bproject%7D%7Ewebcontent>${project}" (Thanks
>>>>> Marcus Lange)
>>>>>
>>>>>
>>>> Some projects are huge and others small. I downloaded several:
>>>>> I think "infrastructure" which is the project for all aspects dealing
>>>> with
>>>> the development of the old web site itself could be thrown out completely,
>>>> since, ta da, here we are in a new environment. And, much of that is VERY
>>>> old. Ditto for much of the "download" area which goes back to the
>>>> non-mirrors age.
>>>>
>>> The problem is, that we have many dead pages on the SVN. At Collabnet we
>>> haven't the right to delete pages from the CVS. So many many unused site is
>>> still on the SVN but you won't find it over the OOo webpage.
>>>
>>> It might be useful to take the domains list....
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>>> OpenOffice+Domains<https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains>
>>>>
>>>> and see what can be combined into your suggested categories below. Maybe
>>>> we
>>>> could start something like this as a seperate item off the "To Do" list on
>>>> the OOo-sitemap page. Oddly, some of these actual "virtual domains" are
>>>> really part of the main website -- web~webcontent.
>>>>
>>> I have already done a sitemap for all projects. It's only 4 month old. I do
>>> this sitemap for the kenai migration. I will upload the list. It's a line
>>> separated textfile.
>>>
>>> The following page needs more fleshing out:
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**OOo-Sitemap<https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap>
>>>>
>>>>
>>>>
>>>> wave@minotaur:~/ooo-test$ ls -1
>>>>> development
>>>>> documentation
>>>>> download
>>>>> projects
>>>>> www
>>>>>
>>>>> The size is 2.7GB.
>>>>>
>>>>> It would be good to come up with a scripted way to convert existing
>>>>> webcontent to either mdtext, an altered html, or specialized javascript
>>>>> and
>>>>> css. It is likely we can adapt the content and use the Apache CMS to wrap
>>>>> a
>>>>> standard skeleton.
>>>>>
>>>>> Yes we need a script, but I think the Script can only do basic work. The
>>> OOo Page is not so easy as it looks. Ther are many special features on the
>>> kenai framework, and a load of JavaScript. I agree with Kai that we have to
>>> be verry carefull.
>>>
>>> Greatings Raphael
>>>
>>> --
>>> My private Homepage: http://www.raphaelbircher.ch/
>>
>> OK, a totally different thought/approach.
>>
>> I think it might be easier in the long run to migrate the entire current OOo
>> site in total (well except for maybe a few areas/projects) and deal with the
>> revamping/reorg on a longer term basis -- culling out a bit at a time.
>>
>> I think trying to deal with this NOW will considerably slow site migration
>> down, maybe even prevent it altogether and will considerably upset existing
>> users I think.
>>
>> The biggest problem with this alternate approach, well really ANY approach,
>> is that folks that formerly had commit rights to sites, won't, because they
>> aren't committers. And now, with the (somewhat) recent migration to kenai,
>> it's a bit difficult to tell what was going on before that.
>>
>> We should definitely think long term about migrating nearly all project home
>> pages to a wiki for easier maintenance. I think much of this had already
>> happened in actuality. People didn't want to deal with cvs/svn or anything
>> even remotely "techie" to participate.
> Ther is a webbased CMS on Apache at http://cms.apache.org . Well it's not a rich CMS, but you can edit a page without using SVN and Command Line. I think cause the performance, a static page as main page is not a bad idea. Markdown is much easier as html and as I said above, you don't have to deal with svn for normal maintenance.
>
> The problem that not all content developer has access to the Apache CMS is true. The problem is, that the ASF dosn't make a difference between Content Developer and Core Developer. At ASF that's the same status. Become a Commiter it's not a fast proces.
You have to show sustained contribution. Patches and presense are noticed by the PPMC who review and commit the work of non-commiter developers. Often this comes at the point where the reviewing committers would rather have the contributor do it themselves. This is what takes time.
> First you have to fill ICLA, then you have to be voted in by PPMC, and finaly you have to wait for the apache account.
The main purpose of the ooo-private list is for the PPMC to discuss various individuals, vote, and only once a new committer has an account will there be a welcome email on ooo-dev.
> At the OOo Project you have only ask a Project Lead for content defeloper right. Therefor you have access to the whole site at Apache OOo.
Regards,
Dave
>
> Greetings Raphael
>
> --
> My private Homepage: http://www.raphaelbircher.ch/
Re: Website Content plus Look and Feel Improvements
Posted by Raphael Bircher <r....@gmx.ch>.
Am 03.07.11 01:30, schrieb Kay Schenk:
> On Sat, Jul 2, 2011 at 3:41 PM, Raphael Bircher<r....@gmx.ch> wrote:
>
>> Am 02.07.11 23:41, schrieb Kay Schenk:
>>
>> OUCH! see below...
>>> On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher<da...@comcast.net>
>>> wrote:
>>>
>>> Yesterday I got tired of the look of people.mdtext in the project site.
>>>> It
>>>> was so 1990s. So, I've improved the look via css and adding defined
>>>> widths.
>>>> I guess I am volunteering for the item on
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Help+Wanted<https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted>
>>>>
>>>> Several of us have been surveying the existing openoffice.org website on
>>>> several wiki pages mostly linked to from:
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Site-PPMC-Plan<https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan>
>>>>
>>>> With over 140 "projects" in openoffice.org, it will be important to
>>>> agree
>>>> to a mapping which reduces the granularity by more than an order of
>>>> magnitude. The page http://projects.openoffice.**org/<http://projects.openoffice.org/>is a good and clear
>>>> way to start - and pretty much fits the structure on
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>>> Project+Planning<https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning>
>>>>
>>>>
>>> • Product Development
>>>> • Extension Development
>>>> • Language Support
>>>> • Helping Users
>>>> • Distribution
>>>> • Promotion
>>>>
>>>> I think that these groupings will help us easily have a rule about which
>>>> projects end up on http://openoffice.apache.org/ or stay on the
>>>> successor
>>>> http://*.openoffice.org/.
>>>>
>>>> Projects have "webcontent" and/or "wiki" content. On openoffice.orgthere
>>>> is a generally consistent look. There are exceptions which are marketing
>>>> sites like http://why.openoffice.org/. The difference is glaring because
>>>> that is the first big button on the main site.
>>>>
>>>> Webcontent is available via svn - "svn co
>>>> https://svn.openoffice.org/**svn/${project}~webcontent<https://svn.openoffice.org/svn/$%7Bproject%7D%7Ewebcontent>${project}" (Thanks
>>>> Marcus Lange)
>>>>
>>>>
>>> Some projects are huge and others small. I downloaded several:
>>>> I think "infrastructure" which is the project for all aspects dealing
>>> with
>>> the development of the old web site itself could be thrown out completely,
>>> since, ta da, here we are in a new environment. And, much of that is VERY
>>> old. Ditto for much of the "download" area which goes back to the
>>> non-mirrors age.
>>>
>> The problem is, that we have many dead pages on the SVN. At Collabnet we
>> haven't the right to delete pages from the CVS. So many many unused site is
>> still on the SVN but you won't find it over the OOo webpage.
>>
>> It might be useful to take the domains list....
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>> OpenOffice+Domains<https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains>
>>>
>>> and see what can be combined into your suggested categories below. Maybe
>>> we
>>> could start something like this as a seperate item off the "To Do" list on
>>> the OOo-sitemap page. Oddly, some of these actual "virtual domains" are
>>> really part of the main website -- web~webcontent.
>>>
>> I have already done a sitemap for all projects. It's only 4 month old. I do
>> this sitemap for the kenai migration. I will upload the list. It's a line
>> separated textfile.
>>
>> The following page needs more fleshing out:
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**OOo-Sitemap<https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap>
>>>
>>>
>>>
>>> wave@minotaur:~/ooo-test$ ls -1
>>>> development
>>>> documentation
>>>> download
>>>> projects
>>>> www
>>>>
>>>> The size is 2.7GB.
>>>>
>>>> It would be good to come up with a scripted way to convert existing
>>>> webcontent to either mdtext, an altered html, or specialized javascript
>>>> and
>>>> css. It is likely we can adapt the content and use the Apache CMS to wrap
>>>> a
>>>> standard skeleton.
>>>>
>>>> Yes we need a script, but I think the Script can only do basic work. The
>> OOo Page is not so easy as it looks. Ther are many special features on the
>> kenai framework, and a load of JavaScript. I agree with Kai that we have to
>> be verry carefull.
>>
>> Greatings Raphael
>>
>> --
>> My private Homepage: http://www.raphaelbircher.ch/
>
> OK, a totally different thought/approach.
>
> I think it might be easier in the long run to migrate the entire current OOo
> site in total (well except for maybe a few areas/projects) and deal with the
> revamping/reorg on a longer term basis -- culling out a bit at a time.
>
> I think trying to deal with this NOW will considerably slow site migration
> down, maybe even prevent it altogether and will considerably upset existing
> users I think.
>
> The biggest problem with this alternate approach, well really ANY approach,
> is that folks that formerly had commit rights to sites, won't, because they
> aren't committers. And now, with the (somewhat) recent migration to kenai,
> it's a bit difficult to tell what was going on before that.
>
> We should definitely think long term about migrating nearly all project home
> pages to a wiki for easier maintenance. I think much of this had already
> happened in actuality. People didn't want to deal with cvs/svn or anything
> even remotely "techie" to participate.
Ther is a webbased CMS on Apache at http://cms.apache.org . Well it's
not a rich CMS, but you can edit a page without using SVN and Command
Line. I think cause the performance, a static page as main page is not a
bad idea. Markdown is much easier as html and as I said above, you don't
have to deal with svn for normal maintenance.
The problem that not all content developer has access to the Apache CMS
is true. The problem is, that the ASF dosn't make a difference between
Content Developer and Core Developer. At ASF that's the same status.
Become a Commiter it's not a fast proces. First you have to fill ICLA,
then you have to be voted in by PPMC, and finaly you have to wait for
the apache account. At the OOo Project you have only ask a Project Lead
for content defeloper right. Therefor you have access to the whole site
at Apache OOo.
Greetings Raphael
--
My private Homepage: http://www.raphaelbircher.ch/
Re: Website Content plus Look and Feel Improvements
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/03/2011 01:30 AM, schrieb Kay Schenk:
> On Sat, Jul 2, 2011 at 3:41 PM, Raphael Bircher<r....@gmx.ch> wrote:
>
>> Am 02.07.11 23:41, schrieb Kay Schenk:
>>
>> OUCH! see below...
>>>
>>> On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher<da...@comcast.net>
>>> wrote:
>>>
>>> Yesterday I got tired of the look of people.mdtext in the project site.
>>>> It
>>>> was so 1990s. So, I've improved the look via css and adding defined
>>>> widths.
>>>> I guess I am volunteering for the item on
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Help+Wanted<https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted>
>>>>
>>>> Several of us have been surveying the existing openoffice.org website on
>>>> several wiki pages mostly linked to from:
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Site-PPMC-Plan<https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan>
>>>>
>>>> With over 140 "projects" in openoffice.org, it will be important to
>>>> agree
>>>> to a mapping which reduces the granularity by more than an order of
>>>> magnitude. The page http://projects.openoffice.**org/<http://projects.openoffice.org/>is a good and clear
>>>> way to start - and pretty much fits the structure on
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>>> Project+Planning<https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning>
>>>>
>>>>
>>> • Product Development
>>>> • Extension Development
>>>> • Language Support
>>>> • Helping Users
>>>> • Distribution
>>>> • Promotion
>>>>
>>>> I think that these groupings will help us easily have a rule about which
>>>> projects end up on http://openoffice.apache.org/ or stay on the
>>>> successor
>>>> http://*.openoffice.org/.
>>>>
>>>> Projects have "webcontent" and/or "wiki" content. On openoffice.orgthere
>>>> is a generally consistent look. There are exceptions which are marketing
>>>> sites like http://why.openoffice.org/. The difference is glaring because
>>>> that is the first big button on the main site.
>>>>
>>>> Webcontent is available via svn - "svn co
>>>> https://svn.openoffice.org/**svn/${project}~webcontent<https://svn.openoffice.org/svn/$%7Bproject%7D%7Ewebcontent>${project}" (Thanks
>>>> Marcus Lange)
>>>>
>>>>
>>> Some projects are huge and others small. I downloaded several:
>>>>
>>>> I think "infrastructure" which is the project for all aspects dealing
>>> with
>>> the development of the old web site itself could be thrown out completely,
>>> since, ta da, here we are in a new environment. And, much of that is VERY
>>> old. Ditto for much of the "download" area which goes back to the
>>> non-mirrors age.
>>>
>> The problem is, that we have many dead pages on the SVN. At Collabnet we
>> haven't the right to delete pages from the CVS. So many many unused site is
>> still on the SVN but you won't find it over the OOo webpage.
>>
>> It might be useful to take the domains list....
>>>
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>> OpenOffice+Domains<https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains>
>>>
>>> and see what can be combined into your suggested categories below. Maybe
>>> we
>>> could start something like this as a seperate item off the "To Do" list on
>>> the OOo-sitemap page. Oddly, some of these actual "virtual domains" are
>>> really part of the main website -- web~webcontent.
>>>
>> I have already done a sitemap for all projects. It's only 4 month old. I do
>> this sitemap for the kenai migration. I will upload the list. It's a line
>> separated textfile.
>>
>> The following page needs more fleshing out:
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**OOo-Sitemap<https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap>
>>>
>>>
>>>
>>> wave@minotaur:~/ooo-test$ ls -1
>>>> development
>>>> documentation
>>>> download
>>>> projects
>>>> www
>>>>
>>>> The size is 2.7GB.
>>>>
>>>> It would be good to come up with a scripted way to convert existing
>>>> webcontent to either mdtext, an altered html, or specialized javascript
>>>> and
>>>> css. It is likely we can adapt the content and use the Apache CMS to wrap
>>>> a
>>>> standard skeleton.
>>>>
>>>> Yes we need a script, but I think the Script can only do basic work. The
>> OOo Page is not so easy as it looks. Ther are many special features on the
>> kenai framework, and a load of JavaScript. I agree with Kai that we have to
>> be verry carefull.
>>
>> Greatings Raphael
>>
>> --
>> My private Homepage: http://www.raphaelbircher.ch/
>
>
> OK, a totally different thought/approach.
>
> I think it might be easier in the long run to migrate the entire current OOo
> site in total (well except for maybe a few areas/projects) and deal with the
> revamping/reorg on a longer term basis -- culling out a bit at a time.
>
> I think trying to deal with this NOW will considerably slow site migration
> down, maybe even prevent it altogether and will considerably upset existing
> users I think.
>
> The biggest problem with this alternate approach, well really ANY approach,
> is that folks that formerly had commit rights to sites, won't, because they
> aren't committers. And now, with the (somewhat) recent migration to kenai,
> it's a bit difficult to tell what was going on before that.
>
> We should definitely think long term about migrating nearly all project home
> pages to a wiki for easier maintenance. I think much of this had already
> happened in actuality. People didn't want to deal with cvs/svn or anything
> even remotely "techie" to participate.
>
> Obviously the BIGGEST change is what people now see for the projects on the
> site (esp the language areas), but many of those current enhancements just
> recently emerged with kenai. We can scale back this listing.
>
> Thoughts?
+1
I also think that a (nearly) complete migration makes most sense. Then
we can take the time to delete unwanted/unnecessary stuff and take the
reamining into the Wiki if not already done.
Marcus
Re: Website Content plus Look and Feel Improvements
Posted by Kay Schenk <ka...@gmail.com>.
On Sat, Jul 2, 2011 at 3:41 PM, Raphael Bircher <r....@gmx.ch> wrote:
> Am 02.07.11 23:41, schrieb Kay Schenk:
>
> OUCH! see below...
>>
>> On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher<da...@comcast.net>
>> wrote:
>>
>> Yesterday I got tired of the look of people.mdtext in the project site.
>>> It
>>> was so 1990s. So, I've improved the look via css and adding defined
>>> widths.
>>> I guess I am volunteering for the item on
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Help+Wanted<https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted>
>>>
>>> Several of us have been surveying the existing openoffice.org website on
>>> several wiki pages mostly linked to from:
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Site-PPMC-Plan<https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan>
>>>
>>> With over 140 "projects" in openoffice.org, it will be important to
>>> agree
>>> to a mapping which reduces the granularity by more than an order of
>>> magnitude. The page http://projects.openoffice.**org/<http://projects.openoffice.org/>is a good and clear
>>> way to start - and pretty much fits the structure on
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>> Project+Planning<https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning>
>>>
>>>
>> • Product Development
>>> • Extension Development
>>> • Language Support
>>> • Helping Users
>>> • Distribution
>>> • Promotion
>>>
>>> I think that these groupings will help us easily have a rule about which
>>> projects end up on http://openoffice.apache.org/ or stay on the
>>> successor
>>> http://*.openoffice.org/.
>>>
>>> Projects have "webcontent" and/or "wiki" content. On openoffice.orgthere
>>> is a generally consistent look. There are exceptions which are marketing
>>> sites like http://why.openoffice.org/. The difference is glaring because
>>> that is the first big button on the main site.
>>>
>>> Webcontent is available via svn - "svn co
>>> https://svn.openoffice.org/**svn/${project}~webcontent<https://svn.openoffice.org/svn/$%7Bproject%7D%7Ewebcontent>${project}" (Thanks
>>> Marcus Lange)
>>>
>>>
>> Some projects are huge and others small. I downloaded several:
>>>
>>> I think "infrastructure" which is the project for all aspects dealing
>> with
>> the development of the old web site itself could be thrown out completely,
>> since, ta da, here we are in a new environment. And, much of that is VERY
>> old. Ditto for much of the "download" area which goes back to the
>> non-mirrors age.
>>
> The problem is, that we have many dead pages on the SVN. At Collabnet we
> haven't the right to delete pages from the CVS. So many many unused site is
> still on the SVN but you won't find it over the OOo webpage.
>
> It might be useful to take the domains list....
>>
>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>> OpenOffice+Domains<https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains>
>>
>> and see what can be combined into your suggested categories below. Maybe
>> we
>> could start something like this as a seperate item off the "To Do" list on
>> the OOo-sitemap page. Oddly, some of these actual "virtual domains" are
>> really part of the main website -- web~webcontent.
>>
> I have already done a sitemap for all projects. It's only 4 month old. I do
> this sitemap for the kenai migration. I will upload the list. It's a line
> separated textfile.
>
> The following page needs more fleshing out:
>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**OOo-Sitemap<https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap>
>>
>>
>>
>> wave@minotaur:~/ooo-test$ ls -1
>>> development
>>> documentation
>>> download
>>> projects
>>> www
>>>
>>> The size is 2.7GB.
>>>
>>> It would be good to come up with a scripted way to convert existing
>>> webcontent to either mdtext, an altered html, or specialized javascript
>>> and
>>> css. It is likely we can adapt the content and use the Apache CMS to wrap
>>> a
>>> standard skeleton.
>>>
>>> Yes we need a script, but I think the Script can only do basic work. The
> OOo Page is not so easy as it looks. Ther are many special features on the
> kenai framework, and a load of JavaScript. I agree with Kai that we have to
> be verry carefull.
>
> Greatings Raphael
>
> --
> My private Homepage: http://www.raphaelbircher.ch/
OK, a totally different thought/approach.
I think it might be easier in the long run to migrate the entire current OOo
site in total (well except for maybe a few areas/projects) and deal with the
revamping/reorg on a longer term basis -- culling out a bit at a time.
I think trying to deal with this NOW will considerably slow site migration
down, maybe even prevent it altogether and will considerably upset existing
users I think.
The biggest problem with this alternate approach, well really ANY approach,
is that folks that formerly had commit rights to sites, won't, because they
aren't committers. And now, with the (somewhat) recent migration to kenai,
it's a bit difficult to tell what was going on before that.
We should definitely think long term about migrating nearly all project home
pages to a wiki for easier maintenance. I think much of this had already
happened in actuality. People didn't want to deal with cvs/svn or anything
even remotely "techie" to participate.
Obviously the BIGGEST change is what people now see for the projects on the
site (esp the language areas), but many of those current enhancements just
recently emerged with kenai. We can scale back this listing.
Thoughts?
--
---------------------------------------------------------------------------------------
MzK
"He's got that New Orleans thing crawling all over him, that good stuff,
that
'We Are the Champions', to hell with the rest and I'll just start over kind
of attitude."
— "1 Dead in the Attic", Chris Rose
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 2, 2011, at 3:41 PM, Raphael Bircher wrote:
> Am 02.07.11 23:41, schrieb Kay Schenk:
>> OUCH! see below...
>>
>> On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher<da...@comcast.net> wrote:
>>
>>> Yesterday I got tired of the look of people.mdtext in the project site. It
>>> was so 1990s. So, I've improved the look via css and adding defined widths.
>>> I guess I am volunteering for the item on
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted
>>>
>>> Several of us have been surveying the existing openoffice.org website on
>>> several wiki pages mostly linked to from:
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan
>>>
>>> With over 140 "projects" in openoffice.org, it will be important to agree
>>> to a mapping which reduces the granularity by more than an order of
>>> magnitude. The page http://projects.openoffice.org/ is a good and clear
>>> way to start - and pretty much fits the structure on
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning
>>>
>>
>>> • Product Development
>>> • Extension Development
>>> • Language Support
>>> • Helping Users
>>> • Distribution
>>> • Promotion
>>>
>>> I think that these groupings will help us easily have a rule about which
>>> projects end up on http://openoffice.apache.org/ or stay on the successor
>>> http://*.openoffice.org/.
>>>
>>> Projects have "webcontent" and/or "wiki" content. On openoffice.org there
>>> is a generally consistent look. There are exceptions which are marketing
>>> sites like http://why.openoffice.org/. The difference is glaring because
>>> that is the first big button on the main site.
>>>
>>> Webcontent is available via svn - "svn co
>>> https://svn.openoffice.org/svn/${project}~webcontent ${project}" (Thanks
>>> Marcus Lange)
>>>
>>
>>> Some projects are huge and others small. I downloaded several:
>>>
>> I think "infrastructure" which is the project for all aspects dealing with
>> the development of the old web site itself could be thrown out completely,
>> since, ta da, here we are in a new environment. And, much of that is VERY
>> old. Ditto for much of the "download" area which goes back to the
>> non-mirrors age.
> The problem is, that we have many dead pages on the SVN. At Collabnet we haven't the right to delete pages from the CVS. So many many unused site is still on the SVN but you won't find it over the OOo webpage.
>> It might be useful to take the domains list....
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains
>>
>> and see what can be combined into your suggested categories below. Maybe we
>> could start something like this as a seperate item off the "To Do" list on
>> the OOo-sitemap page. Oddly, some of these actual "virtual domains" are
>> really part of the main website -- web~webcontent.
> I have already done a sitemap for all projects. It's only 4 month old. I do this sitemap for the kenai migration. I will upload the list. It's a line separated textfile.
Would you please commit the list to https://svn.apache.org/repos/asf/incubator/ooo/trunk/tools/dev
>> The following page needs more fleshing out:
>> https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap
>>
>>
>>
>>> wave@minotaur:~/ooo-test$ ls -1
>>> development
>>> documentation
>>> download
>>> projects
>>> www
>>>
>>> The size is 2.7GB.
>>>
>>> It would be good to come up with a scripted way to convert existing
>>> webcontent to either mdtext, an altered html, or specialized javascript and
>>> css. It is likely we can adapt the content and use the Apache CMS to wrap a
>>> standard skeleton.
>>>
> Yes we need a script, but I think the Script can only do basic work. The OOo Page is not so easy as it looks. Ther are many special features on the kenai framework, and a load of JavaScript. I agree with Kai that we have to be verry carefull.
On the wiki you mentioned a script for producing downloads from the webcontent in svn - that could also go into ooo/trunk/tools/dev
How much of the webcontent in svn is replaced by wiki content? Is the webcontent maintained in Kenai, or separately?
Also important and part of being very careful is paying attention to the css tags embedded, ids, and classes.
Regards,
Dave
>
> Greatings Raphael
>
> --
> My private Homepage: http://www.raphaelbircher.ch/
Re: Website Content plus Look and Feel Improvements
Posted by Raphael Bircher <r....@gmx.ch>.
Am 02.07.11 23:41, schrieb Kay Schenk:
> OUCH! see below...
>
> On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher<da...@comcast.net> wrote:
>
>> Yesterday I got tired of the look of people.mdtext in the project site. It
>> was so 1990s. So, I've improved the look via css and adding defined widths.
>> I guess I am volunteering for the item on
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted
>>
>> Several of us have been surveying the existing openoffice.org website on
>> several wiki pages mostly linked to from:
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan
>>
>> With over 140 "projects" in openoffice.org, it will be important to agree
>> to a mapping which reduces the granularity by more than an order of
>> magnitude. The page http://projects.openoffice.org/ is a good and clear
>> way to start - and pretty much fits the structure on
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning
>>
>
>> • Product Development
>> • Extension Development
>> • Language Support
>> • Helping Users
>> • Distribution
>> • Promotion
>>
>> I think that these groupings will help us easily have a rule about which
>> projects end up on http://openoffice.apache.org/ or stay on the successor
>> http://*.openoffice.org/.
>>
>> Projects have "webcontent" and/or "wiki" content. On openoffice.org there
>> is a generally consistent look. There are exceptions which are marketing
>> sites like http://why.openoffice.org/. The difference is glaring because
>> that is the first big button on the main site.
>>
>> Webcontent is available via svn - "svn co
>> https://svn.openoffice.org/svn/${project}~webcontent ${project}" (Thanks
>> Marcus Lange)
>>
>
>> Some projects are huge and others small. I downloaded several:
>>
> I think "infrastructure" which is the project for all aspects dealing with
> the development of the old web site itself could be thrown out completely,
> since, ta da, here we are in a new environment. And, much of that is VERY
> old. Ditto for much of the "download" area which goes back to the
> non-mirrors age.
The problem is, that we have many dead pages on the SVN. At Collabnet we
haven't the right to delete pages from the CVS. So many many unused site
is still on the SVN but you won't find it over the OOo webpage.
> It might be useful to take the domains list....
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains
>
> and see what can be combined into your suggested categories below. Maybe we
> could start something like this as a seperate item off the "To Do" list on
> the OOo-sitemap page. Oddly, some of these actual "virtual domains" are
> really part of the main website -- web~webcontent.
I have already done a sitemap for all projects. It's only 4 month old. I
do this sitemap for the kenai migration. I will upload the list. It's a
line separated textfile.
> The following page needs more fleshing out:
> https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap
>
>
>
>> wave@minotaur:~/ooo-test$ ls -1
>> development
>> documentation
>> download
>> projects
>> www
>>
>> The size is 2.7GB.
>>
>> It would be good to come up with a scripted way to convert existing
>> webcontent to either mdtext, an altered html, or specialized javascript and
>> css. It is likely we can adapt the content and use the Apache CMS to wrap a
>> standard skeleton.
>>
Yes we need a script, but I think the Script can only do basic work. The
OOo Page is not so easy as it looks. Ther are many special features on
the kenai framework, and a load of JavaScript. I agree with Kai that we
have to be verry carefull.
Greatings Raphael
--
My private Homepage: http://www.raphaelbircher.ch/
Re: Website Content plus Look and Feel Improvements
Posted by Kay Schenk <ka...@gmail.com>.
OUCH! see below...
On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher <da...@comcast.net> wrote:
> Yesterday I got tired of the look of people.mdtext in the project site. It
> was so 1990s. So, I've improved the look via css and adding defined widths.
> I guess I am volunteering for the item on
> https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted
>
> Several of us have been surveying the existing openoffice.org website on
> several wiki pages mostly linked to from:
> https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan
>
> With over 140 "projects" in openoffice.org, it will be important to agree
> to a mapping which reduces the granularity by more than an order of
> magnitude. The page http://projects.openoffice.org/ is a good and clear
> way to start - and pretty much fits the structure on
> https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning
>
>
> • Product Development
> • Extension Development
> • Language Support
> • Helping Users
> • Distribution
> • Promotion
>
> I think that these groupings will help us easily have a rule about which
> projects end up on http://openoffice.apache.org/ or stay on the successor
> http://*.openoffice.org/.
>
> Projects have "webcontent" and/or "wiki" content. On openoffice.org there
> is a generally consistent look. There are exceptions which are marketing
> sites like http://why.openoffice.org/. The difference is glaring because
> that is the first big button on the main site.
>
> Webcontent is available via svn - "svn co
> https://svn.openoffice.org/svn/${project}~webcontent ${project}" (Thanks
> Marcus Lange)
>
>
> Some projects are huge and others small. I downloaded several:
>
I think "infrastructure" which is the project for all aspects dealing with
the development of the old web site itself could be thrown out completely,
since, ta da, here we are in a new environment. And, much of that is VERY
old. Ditto for much of the "download" area which goes back to the
non-mirrors age.
It might be useful to take the domains list....
https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains
and see what can be combined into your suggested categories below. Maybe we
could start something like this as a seperate item off the "To Do" list on
the OOo-sitemap page. Oddly, some of these actual "virtual domains" are
really part of the main website -- web~webcontent.
The following page needs more fleshing out:
https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap
> wave@minotaur:~/ooo-test$ ls -1
> development
> documentation
> download
> projects
> www
>
> The size is 2.7GB.
>
> It would be good to come up with a scripted way to convert existing
> webcontent to either mdtext, an altered html, or specialized javascript and
> css. It is likely we can adapt the content and use the Apache CMS to wrap a
> standard skeleton.
>
hmmm...this would work fine (maybe) if you wanted to do a 1-to-1 conversion
on the pages. However, I'm pretty sure given your thoughts so far that this
probably isn't what you want. It seems like we've got quite a bit of
analysis and housecleaning to do first -- unfortunately. I would be happy to
work on a "new infrastructure" list or something based on what I know.
take care...
K
>
> Regards,
> Dave
>
>
--
---------------------------------------------------------------------------------------
MzK
"He's got that New Orleans thing crawling all over him, that good stuff,
that
'We Are the Champions', to hell with the rest and I'll just start over kind
of attitude."
— "1 Dead in the Attic", Chris Rose
Re: Website Content plus Look and Feel Improvements
Posted by Kay Schenk <ka...@gmail.com>.
On 07/06/2011 11:00 AM, Dave Fisher wrote:
> Hi Kay,
>
> On Jul 6, 2011, at 8:34 AM, Kay Schenk wrote:
>
>>>>> So, keep the home page as is or find someway to get the CMS
>>>>> to display it, action statements intact at least.
>>>
>>
>> yes...I hope to investigate the Apache CMS capabilities in this
>> regard this week.
>
> I'm looking forward to it and I am here to help you with patches and
> to talk through ideas.
>
> The CMS does look easily extensible, if you know python, I am
> learning.
>
> The current www.apache.org is a good example of how to merge content
> from multiple sources on the main page - this includes watching a
> twitter feed.
Dave--
Thanks for all this. My days are kind of scattered at the moment, but I
hope to have at least a summary of what we've discussed here over the
last few days and some reasonable approaches in the wiki area in about a
few days. We've covered at lot of ground, by, yes, as you point out, a
LOT to do. And, unfortunately, since I did know quite a bit about how
Collabnet was set up, I don't know much about kenai...so more to learn.
>
>>>>> Then to my mind the only subs to the OOo domain that I would
>>>>> think that would be compulsory would be:
>>>>> support.openoffice.org Why.openoffice.org and
>>>>> download.openoffice.org
>>>>>
>>>>> and the NLC subdomains
>>>>>
>>>>> The rest of the website could happily exist under
>>> OpenOffice.apache.org.
>
> I think we have an outline and lots of work to do.
>
> Regards, Dave
--
------------------------------------------------------------------------
MzK
"He's got that New Orleans thing crawling all over him, that good stuff,
that 'We Are the Champions', to hell with the rest and
I'll just start over kind of attitude."
-- "1 Dead in the Attic", Chris Rose
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
Hi Kay,
On Jul 6, 2011, at 8:34 AM, Kay Schenk wrote:
>>>> So, keep the home page as is or find someway to get the CMS to display
>>>> it, action statements intact at least.
>>
>
> yes...I hope to investigate the Apache CMS capabilities in this regard this
> week.
I'm looking forward to it and I am here to help you with patches and to talk through ideas.
The CMS does look easily extensible, if you know python, I am learning.
The current www.apache.org is a good example of how to merge content from multiple sources on the main page - this includes watching a twitter feed.
>>>> Then to my mind the only subs to the OOo domain that I would think that
>>>> would be compulsory would be:
>>>> support.openoffice.org
>>>> Why.openoffice.org and
>>>> download.openoffice.org
>>>>
>>>> and the NLC subdomains
>>>>
>>>> The rest of the website could happily exist under
>> OpenOffice.apache.org.
I think we have an outline and lots of work to do.
Regards,
Dave
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 7, 2011, at 8:24 AM, Kay Schenk wrote:
> On Thu, Jul 7, 2011 at 5:12 AM, Marcus (OOo) <ma...@wtnet.de> wrote:
>
<big snip>
>> I also think that mailing lists are not the best medium to "speak" with
>> marketing and news people outside. A single and easy to reach webpage is
>> much better.
>>
>
> yes...the Blog would be much easier upkeep than the current "News" page on
> the existing site as well. Let's do it! :)
Recent blog entries can appear on any CMS page in the website. See the main www.apache.org and Latest News. These are from the Apache Blog.
Note also the "Latest Activity" section this can be recent svn, twitter feeds, etc.
Once active, if we republish the main openoffice.org page on a schedule then we get an always fresh and relevant page.
Regards,
Dave
>
>
>> Marcus
>>
>
>
>
> --
> ---------------------------------------------------------------------------------------
> MzK
>
> "He's got that New Orleans thing crawling all over him, that good stuff,
> that
> 'We Are the Champions', to hell with the rest and I'll just start over kind
> of attitude."
> — "1 Dead in the Attic", Chris Rose
Re: Website Content plus Look and Feel Improvements
Posted by Rob Weir <ap...@robweir.com>.
On Thu, Jul 7, 2011 at 11:24 AM, Kay Schenk <ka...@gmail.com> wrote:
> On Thu, Jul 7, 2011 at 5:12 AM, Marcus (OOo) <ma...@wtnet.de> wrote:
>
>> Am 07/07/2011 11:25 AM, schrieb Graham Lauder:
>>
>> On Wed, 2011-07-06 at 08:34 -0700, Kay Schenk wrote:
>>>
>>>> On Wed, Jul 6, 2011 at 12:39 AM, Graham Lauder<yo...@openoffice.org>**
>>>> wrote:
>>>>
>>>>
>>>
>>> We had some earlier discussions on this. Personally, I was proposing
>>>>>> that we take the opportunity to simplify. For example, right now
>>>>>> we're doing all the work on ooo-dev. At some point it will be clear,
>>>>>> perhaps soon, that we need an ooo-user list.
>>>>>>
>>>>>
>>>>>
>>>> > From my POV, what would be really helpful right now to the existing
>>>> user
>>>> base, is to somehow migrate over the "Announcement" list and its
>>>> corresponding subscribers. And, have someone designated to be the
>>>> "announcement guru". My feat at the moment is losing supporters/users who
>>>> don't have any interest in direct contribution but who use
>>>> OpenOffice.org.
>>>>
>>>>
>>> We have to be careful about rushing before we have an established
>>> community that is needed to run a users list. At present we have had a
>>> reasonably large migration to LibreOffice but I consider them to still
>>> be part of our greater community. In terms of brand recognition our
>>> brand still has high profile because LO is still seen as a "fork" of
>>> OOo. Possibly not the best scenario for the LO people but until they
>>> break fresh marketing ground that's simply the reality. What this gives
>>> us is breathing space that we would not have but for LO's existence, not
>>> a lot it is true but enough. OOo will not disappear from the LO users
>>> ken for a number of months, possibly even a year.
>>>
>>> In the interim before a release, an active announce list and marketing
>>> blog should be priorities as well as maintaining a profile on User
>>> forums such as OOoForum.org
>>>
>>> And maybe a few others.
>>>>
>>>>> But I'd resist the urge to recreate the byzantine complexity of OOo
>>>>>> until we're sure that we need it. I'm hoping we never do.
>>>>>>
>>>>>
>>>>> Small projects do have the advantage that people can contribute as suits
>>>>> their availability and feel their contribution is meaningful. That's
>>>>> just a function of Human group dynamics, we can get to know about 8
>>>>> people well, 25 we can work with, once the numbers get up however then
>>>>> people are simply in the company of strangers and thus they feel
>>>>> unrecognised and unappreciated.
>>>>>
>>>>>
>>>>>>
>>>>>> The home page as it is now was designed originally with one overriding
>>>>>>> goal: "increase downloads."
>>>>>>>
>>>>>>>
>>>>>> Do you think this should still be the overriding goal of the homepage?
>>>>>>
>>>>>
>>>>> There was reasoning behind this, more downloads = more users, More Users
>>>>> = Greater market share, More market share = more contributors. However
>>>>> the homepage grew from that original precept to become "Make it as easy
>>>>> as possible for someone landing on the homepage to have their OOo needs
>>>>> fulfilled!" Downloads was one of those needs.
>>>>>
>>>>> There was a history to the "More Downloads" thing, in 06 I think it was,
>>>>> Sun decided to spend some money on promoting OOo. Rather than giving it
>>>>> to the marketing project and letting us use it as best we could, they
>>>>> spent it with a promotions company to use on internet marketing (and
>>>>> gave the Marketing team a part of it, with the proviso that it be spent
>>>>> on promo materials, but that's another story.) The promo company spent
>>>>> around 35K USD, IMS, on google keywords and the like on a "Pay on click
>>>>> through" basis. Clicking on a text ad or keyword sent people to
>>>>> download.openoffice.org. The money disappeared fast, so there were
>>>>> lots
>>>>> of clickthroughs.
>>>>>
>>>>
>>>>
>>>> Oh boy...interesting little known facts.
>>>>
>>>>
>>> It was frustrating, we could have run a community driven campaign that
>>> raised brand recognition (always our single biggest problem) and we
>>> would have steered them to the Why.ooo page, build confidence in the
>>> brand and then led them to the download button, but someone in the
>>> corporate space somehow figured that dumping people straight onto the
>>> download page would turn into downloads, if only it was that easy.
>>>
>>>
>>>> However, the rate of download changed not even so
>>>>> much as decimal of a percent. The promo company picked up their check
>>>>> and the value to the project was zero. To me and number of other people
>>>>> in the marketing project, the reason was obvious. The redesign of the
>>>>> homepage was a response to that failure, so that if ever they were that
>>>>> generous again we could say: "Just link to openoffice.org homepage
>>>>> because we have proved that it increases downloads."
>>>>>
>>>>>
>>>> Why wouldn't you design a homepage for "users" that makes it easier for
>>>> them
>>>> to get what they need -- monetary contributions notwithstanding?
>>>> OpenOffice.org is first and foremost a "client" product.
>>>>
>>>
>>> The confusion with the original design was the confusion over the
>>> definition of "User". Our problem is that our User-Base is diverse in
>>> terms of Internet sophistication. The homepage in it's effort to cater
>>> for this huge diversity ended becoming too complex and confusing, a
>>> problem I foresee if we try to simplify everything too much. A maillist
>>> for devs is not the best place to have marketing discussions or users
>>> complaining that their download "doesn't work", or artists considering
>>> the aesthetics of different fontsets.
>>>
>>>
>>>
>>>>> So, keep the home page as is or find someway to get the CMS to display
>>>>>>> it, action statements intact at least.
>>>>>>>
>>>>>>
>>>>>
>>>> yes...I hope to investigate the Apache CMS capabilities in this regard
>>>> this
>>>> week.
>>>>
>>>
>>> I'm still in the committer pending box, as soon as that is actioned I'll
>>> get to grips with the CMS as well. The initial homepage will be
>>> probably more informational than guiding people to downloads. We could
>>> probably go with familiarity and substitute the download button for a
>>> "Countdown to Release" perhaps and link it to a blog, what do you think?
>>>
>>
>> I know the bits behind the download website as I helped to keep it running
>> and have made some improvements. To install a countdown button to show how
>> many days until release is a good idea.
>>
>> It should be clickable to link to a blog, announcement, release schedule,
>> whatever we will define.
>>
>> I always liked the one from Fedora. However, currently there is none.
>>
>> To get an idea here are some older ones:
>> http://fedoraproject.org/wiki/**F13_Artwork#Release_Countdown_**Banner<http://fedoraproject.org/wiki/F13_Artwork#Release_Countdown_Banner>
>> http://fedoraproject.org/en/**counter<http://fedoraproject.org/en/counter>
>>
>>
>> Play a bit of the MS vaporware game. Trickling press releases,
>>> tantalising blog entries and so on! :) A bit difficult on public lists
>>>
>>
>> Normally I would leave them alone in their self-created game. ;-)
>> But yes, for the initial release we need to push the news and press guys to
>> our project.
>>
>>
>> it's true (which is why we had some private lists in the marketing
>>> project) but it's all about keeping the attention simmering.
>>>
>>
>> I also think that mailing lists are not the best medium to "speak" with
>> marketing and news people outside. A single and easy to reach webpage is
>> much better.
>>
>
> yes...the Blog would be much easier upkeep than the current "News" page on
> the existing site as well. Let's do it! :)
>
Does someone want to start a new top level thread, proposing to
request a blog for the project? State that you are assuming lazy
consensus and that you will go forward with an infrastructure request
if no one objects in 72 hours.
Maybe seek author volunteers at the same time?
>
>> Marcus
>>
>
>
>
> --
> ---------------------------------------------------------------------------------------
> MzK
>
> "He's got that New Orleans thing crawling all over him, that good stuff,
> that
> 'We Are the Champions', to hell with the rest and I'll just start over kind
> of attitude."
> — "1 Dead in the Attic", Chris Rose
>
Re: Website Content plus Look and Feel Improvements
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Jul 7, 2011 at 5:12 AM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 07/07/2011 11:25 AM, schrieb Graham Lauder:
>
> On Wed, 2011-07-06 at 08:34 -0700, Kay Schenk wrote:
>>
>>> On Wed, Jul 6, 2011 at 12:39 AM, Graham Lauder<yo...@openoffice.org>**
>>> wrote:
>>>
>>>
>>
>> We had some earlier discussions on this. Personally, I was proposing
>>>>> that we take the opportunity to simplify. For example, right now
>>>>> we're doing all the work on ooo-dev. At some point it will be clear,
>>>>> perhaps soon, that we need an ooo-user list.
>>>>>
>>>>
>>>>
>>> > From my POV, what would be really helpful right now to the existing
>>> user
>>> base, is to somehow migrate over the "Announcement" list and its
>>> corresponding subscribers. And, have someone designated to be the
>>> "announcement guru". My feat at the moment is losing supporters/users who
>>> don't have any interest in direct contribution but who use
>>> OpenOffice.org.
>>>
>>>
>> We have to be careful about rushing before we have an established
>> community that is needed to run a users list. At present we have had a
>> reasonably large migration to LibreOffice but I consider them to still
>> be part of our greater community. In terms of brand recognition our
>> brand still has high profile because LO is still seen as a "fork" of
>> OOo. Possibly not the best scenario for the LO people but until they
>> break fresh marketing ground that's simply the reality. What this gives
>> us is breathing space that we would not have but for LO's existence, not
>> a lot it is true but enough. OOo will not disappear from the LO users
>> ken for a number of months, possibly even a year.
>>
>> In the interim before a release, an active announce list and marketing
>> blog should be priorities as well as maintaining a profile on User
>> forums such as OOoForum.org
>>
>> And maybe a few others.
>>>
>>>> But I'd resist the urge to recreate the byzantine complexity of OOo
>>>>> until we're sure that we need it. I'm hoping we never do.
>>>>>
>>>>
>>>> Small projects do have the advantage that people can contribute as suits
>>>> their availability and feel their contribution is meaningful. That's
>>>> just a function of Human group dynamics, we can get to know about 8
>>>> people well, 25 we can work with, once the numbers get up however then
>>>> people are simply in the company of strangers and thus they feel
>>>> unrecognised and unappreciated.
>>>>
>>>>
>>>>>
>>>>> The home page as it is now was designed originally with one overriding
>>>>>> goal: "increase downloads."
>>>>>>
>>>>>>
>>>>> Do you think this should still be the overriding goal of the homepage?
>>>>>
>>>>
>>>> There was reasoning behind this, more downloads = more users, More Users
>>>> = Greater market share, More market share = more contributors. However
>>>> the homepage grew from that original precept to become "Make it as easy
>>>> as possible for someone landing on the homepage to have their OOo needs
>>>> fulfilled!" Downloads was one of those needs.
>>>>
>>>> There was a history to the "More Downloads" thing, in 06 I think it was,
>>>> Sun decided to spend some money on promoting OOo. Rather than giving it
>>>> to the marketing project and letting us use it as best we could, they
>>>> spent it with a promotions company to use on internet marketing (and
>>>> gave the Marketing team a part of it, with the proviso that it be spent
>>>> on promo materials, but that's another story.) The promo company spent
>>>> around 35K USD, IMS, on google keywords and the like on a "Pay on click
>>>> through" basis. Clicking on a text ad or keyword sent people to
>>>> download.openoffice.org. The money disappeared fast, so there were
>>>> lots
>>>> of clickthroughs.
>>>>
>>>
>>>
>>> Oh boy...interesting little known facts.
>>>
>>>
>> It was frustrating, we could have run a community driven campaign that
>> raised brand recognition (always our single biggest problem) and we
>> would have steered them to the Why.ooo page, build confidence in the
>> brand and then led them to the download button, but someone in the
>> corporate space somehow figured that dumping people straight onto the
>> download page would turn into downloads, if only it was that easy.
>>
>>
>>> However, the rate of download changed not even so
>>>> much as decimal of a percent. The promo company picked up their check
>>>> and the value to the project was zero. To me and number of other people
>>>> in the marketing project, the reason was obvious. The redesign of the
>>>> homepage was a response to that failure, so that if ever they were that
>>>> generous again we could say: "Just link to openoffice.org homepage
>>>> because we have proved that it increases downloads."
>>>>
>>>>
>>> Why wouldn't you design a homepage for "users" that makes it easier for
>>> them
>>> to get what they need -- monetary contributions notwithstanding?
>>> OpenOffice.org is first and foremost a "client" product.
>>>
>>
>> The confusion with the original design was the confusion over the
>> definition of "User". Our problem is that our User-Base is diverse in
>> terms of Internet sophistication. The homepage in it's effort to cater
>> for this huge diversity ended becoming too complex and confusing, a
>> problem I foresee if we try to simplify everything too much. A maillist
>> for devs is not the best place to have marketing discussions or users
>> complaining that their download "doesn't work", or artists considering
>> the aesthetics of different fontsets.
>>
>>
>>
>>>> So, keep the home page as is or find someway to get the CMS to display
>>>>>> it, action statements intact at least.
>>>>>>
>>>>>
>>>>
>>> yes...I hope to investigate the Apache CMS capabilities in this regard
>>> this
>>> week.
>>>
>>
>> I'm still in the committer pending box, as soon as that is actioned I'll
>> get to grips with the CMS as well. The initial homepage will be
>> probably more informational than guiding people to downloads. We could
>> probably go with familiarity and substitute the download button for a
>> "Countdown to Release" perhaps and link it to a blog, what do you think?
>>
>
> I know the bits behind the download website as I helped to keep it running
> and have made some improvements. To install a countdown button to show how
> many days until release is a good idea.
>
> It should be clickable to link to a blog, announcement, release schedule,
> whatever we will define.
>
> I always liked the one from Fedora. However, currently there is none.
>
> To get an idea here are some older ones:
> http://fedoraproject.org/wiki/**F13_Artwork#Release_Countdown_**Banner<http://fedoraproject.org/wiki/F13_Artwork#Release_Countdown_Banner>
> http://fedoraproject.org/en/**counter<http://fedoraproject.org/en/counter>
>
>
> Play a bit of the MS vaporware game. Trickling press releases,
>> tantalising blog entries and so on! :) A bit difficult on public lists
>>
>
> Normally I would leave them alone in their self-created game. ;-)
> But yes, for the initial release we need to push the news and press guys to
> our project.
>
>
> it's true (which is why we had some private lists in the marketing
>> project) but it's all about keeping the attention simmering.
>>
>
> I also think that mailing lists are not the best medium to "speak" with
> marketing and news people outside. A single and easy to reach webpage is
> much better.
>
yes...the Blog would be much easier upkeep than the current "News" page on
the existing site as well. Let's do it! :)
> Marcus
>
--
---------------------------------------------------------------------------------------
MzK
"He's got that New Orleans thing crawling all over him, that good stuff,
that
'We Are the Champions', to hell with the rest and I'll just start over kind
of attitude."
— "1 Dead in the Attic", Chris Rose
Re: Website Content plus Look and Feel Improvements
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/07/2011 11:25 AM, schrieb Graham Lauder:
> On Wed, 2011-07-06 at 08:34 -0700, Kay Schenk wrote:
>> On Wed, Jul 6, 2011 at 12:39 AM, Graham Lauder<yo...@openoffice.org>wrote:
>>
>
>
>>>> We had some earlier discussions on this. Personally, I was proposing
>>>> that we take the opportunity to simplify. For example, right now
>>>> we're doing all the work on ooo-dev. At some point it will be clear,
>>>> perhaps soon, that we need an ooo-user list.
>>>
>>
>> > From my POV, what would be really helpful right now to the existing user
>> base, is to somehow migrate over the "Announcement" list and its
>> corresponding subscribers. And, have someone designated to be the
>> "announcement guru". My feat at the moment is losing supporters/users who
>> don't have any interest in direct contribution but who use OpenOffice.org.
>>
>
> We have to be careful about rushing before we have an established
> community that is needed to run a users list. At present we have had a
> reasonably large migration to LibreOffice but I consider them to still
> be part of our greater community. In terms of brand recognition our
> brand still has high profile because LO is still seen as a "fork" of
> OOo. Possibly not the best scenario for the LO people but until they
> break fresh marketing ground that's simply the reality. What this gives
> us is breathing space that we would not have but for LO's existence, not
> a lot it is true but enough. OOo will not disappear from the LO users
> ken for a number of months, possibly even a year.
>
> In the interim before a release, an active announce list and marketing
> blog should be priorities as well as maintaining a profile on User
> forums such as OOoForum.org
>
>> And maybe a few others.
>>>> But I'd resist the urge to recreate the byzantine complexity of OOo
>>>> until we're sure that we need it. I'm hoping we never do.
>>>
>>> Small projects do have the advantage that people can contribute as suits
>>> their availability and feel their contribution is meaningful. That's
>>> just a function of Human group dynamics, we can get to know about 8
>>> people well, 25 we can work with, once the numbers get up however then
>>> people are simply in the company of strangers and thus they feel
>>> unrecognised and unappreciated.
>>>
>>>>
>>>>
>>>>> The home page as it is now was designed originally with one overriding
>>>>> goal: "increase downloads."
>>>>>
>>>>
>>>> Do you think this should still be the overriding goal of the homepage?
>>>
>>> There was reasoning behind this, more downloads = more users, More Users
>>> = Greater market share, More market share = more contributors. However
>>> the homepage grew from that original precept to become "Make it as easy
>>> as possible for someone landing on the homepage to have their OOo needs
>>> fulfilled!" Downloads was one of those needs.
>>>
>>> There was a history to the "More Downloads" thing, in 06 I think it was,
>>> Sun decided to spend some money on promoting OOo. Rather than giving it
>>> to the marketing project and letting us use it as best we could, they
>>> spent it with a promotions company to use on internet marketing (and
>>> gave the Marketing team a part of it, with the proviso that it be spent
>>> on promo materials, but that's another story.) The promo company spent
>>> around 35K USD, IMS, on google keywords and the like on a "Pay on click
>>> through" basis. Clicking on a text ad or keyword sent people to
>>> download.openoffice.org. The money disappeared fast, so there were lots
>>> of clickthroughs.
>>
>>
>> Oh boy...interesting little known facts.
>>
>
> It was frustrating, we could have run a community driven campaign that
> raised brand recognition (always our single biggest problem) and we
> would have steered them to the Why.ooo page, build confidence in the
> brand and then led them to the download button, but someone in the
> corporate space somehow figured that dumping people straight onto the
> download page would turn into downloads, if only it was that easy.
>
>>
>>> However, the rate of download changed not even so
>>> much as decimal of a percent. The promo company picked up their check
>>> and the value to the project was zero. To me and number of other people
>>> in the marketing project, the reason was obvious. The redesign of the
>>> homepage was a response to that failure, so that if ever they were that
>>> generous again we could say: "Just link to openoffice.org homepage
>>> because we have proved that it increases downloads."
>>>
>>
>> Why wouldn't you design a homepage for "users" that makes it easier for them
>> to get what they need -- monetary contributions notwithstanding?
>> OpenOffice.org is first and foremost a "client" product.
>
> The confusion with the original design was the confusion over the
> definition of "User". Our problem is that our User-Base is diverse in
> terms of Internet sophistication. The homepage in it's effort to cater
> for this huge diversity ended becoming too complex and confusing, a
> problem I foresee if we try to simplify everything too much. A maillist
> for devs is not the best place to have marketing discussions or users
> complaining that their download "doesn't work", or artists considering
> the aesthetics of different fontsets.
>
>
>>>
>>>>> So, keep the home page as is or find someway to get the CMS to display
>>>>> it, action statements intact at least.
>>>
>>
>> yes...I hope to investigate the Apache CMS capabilities in this regard this
>> week.
>
> I'm still in the committer pending box, as soon as that is actioned I'll
> get to grips with the CMS as well. The initial homepage will be
> probably more informational than guiding people to downloads. We could
> probably go with familiarity and substitute the download button for a
> "Countdown to Release" perhaps and link it to a blog, what do you think?
I know the bits behind the download website as I helped to keep it
running and have made some improvements. To install a countdown button
to show how many days until release is a good idea.
It should be clickable to link to a blog, announcement, release
schedule, whatever we will define.
I always liked the one from Fedora. However, currently there is none.
To get an idea here are some older ones:
http://fedoraproject.org/wiki/F13_Artwork#Release_Countdown_Banner
http://fedoraproject.org/en/counter
> Play a bit of the MS vaporware game. Trickling press releases,
> tantalising blog entries and so on! :) A bit difficult on public lists
Normally I would leave them alone in their self-created game. ;-)
But yes, for the initial release we need to push the news and press guys
to our project.
> it's true (which is why we had some private lists in the marketing
> project) but it's all about keeping the attention simmering.
I also think that mailing lists are not the best medium to "speak" with
marketing and news people outside. A single and easy to reach webpage is
much better.
Marcus
Re: Website Content plus Look and Feel Improvements
Posted by Shane Curcuru <as...@shanecurcuru.org>.
http://blogs.apache.org/
Any PPMC member can simply ask infrastructure@ to create a blog for the
podling (I think that's the right list), specifying the preferred name
for the blog. The PPMC should manage a list of PPMC members who have
write access to the blog, and ensure that comments get moderated.
The advantage is that the blogs.a.o namespace is stable, so there's no
need to change the URL when the podling graduates. Note, however, that
any posts should include a clear note that the podling is still
incubating (i.e., don't sell ourselves as a top level project of the ASF
yet).
All committers may be interested in putting their own blogs onto Planet
Apache as well (it has aggregators for both blogs.a.o and any
committer's blogs):
http://planet.apache.org/
- Shane
On 7/7/2011 10:04 AM, Rob Weir wrote:
> On Thu, Jul 7, 2011 at 5:25 AM, Graham Lauder<yo...@openoffice.org> wrote:
>
> <snip>
>
>> I'm still in the committer pending box, as soon as that is actioned I'll
>> get to grips with the CMS as well. The initial homepage will be
>> probably more informational than guiding people to downloads. We could
>> probably go with familiarity and substitute the download button for a
>> "Countdown to Release" perhaps and link it to a blog, what do you think?
>> Play a bit of the MS vaporware game. Trickling press releases,
>> tantalising blog entries and so on! :) A bit difficult on public lists
>> it's true (which is why we had some private lists in the marketing
>> project) but it's all about keeping the attention simmering.
>>
>
> Apache projects, including Podlings, do have the ability to have a
> project blog. I think it uses Apache Roller. This would need to be
> requested from Apache Infrastructure.
>
> -Rob
Re: Website Content plus Look and Feel Improvements
Posted by Rob Weir <ap...@robweir.com>.
On Thu, Jul 7, 2011 at 5:25 AM, Graham Lauder <yo...@openoffice.org> wrote:
<snip>
> I'm still in the committer pending box, as soon as that is actioned I'll
> get to grips with the CMS as well. The initial homepage will be
> probably more informational than guiding people to downloads. We could
> probably go with familiarity and substitute the download button for a
> "Countdown to Release" perhaps and link it to a blog, what do you think?
> Play a bit of the MS vaporware game. Trickling press releases,
> tantalising blog entries and so on! :) A bit difficult on public lists
> it's true (which is why we had some private lists in the marketing
> project) but it's all about keeping the attention simmering.
>
Apache projects, including Podlings, do have the ability to have a
project blog. I think it uses Apache Roller. This would need to be
requested from Apache Infrastructure.
-Rob
Re: Website Content plus Look and Feel Improvements
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Jul 7, 2011 at 2:25 AM, Graham Lauder <yo...@openoffice.org>wrote:
> On Wed, 2011-07-06 at 08:34 -0700, Kay Schenk wrote:
> > On Wed, Jul 6, 2011 at 12:39 AM, Graham Lauder <yorick_@openoffice.org
> >wrote:
> >
>
>
> > > > We had some earlier discussions on this. Personally, I was proposing
> > > > that we take the opportunity to simplify. For example, right now
> > > > we're doing all the work on ooo-dev. At some point it will be clear,
> > > > perhaps soon, that we need an ooo-user list.
> > >
> >
> > >From my POV, what would be really helpful right now to the existing user
> > base, is to somehow migrate over the "Announcement" list and its
> > corresponding subscribers. And, have someone designated to be the
> > "announcement guru". My feat at the moment is losing supporters/users who
> > don't have any interest in direct contribution but who use
> OpenOffice.org.
> >
>
> We have to be careful about rushing before we have an established
> community that is needed to run a users list. At present we have had a
> reasonably large migration to LibreOffice but I consider them to still
> be part of our greater community. In terms of brand recognition our
> brand still has high profile because LO is still seen as a "fork" of
> OOo. Possibly not the best scenario for the LO people but until they
> break fresh marketing ground that's simply the reality. What this gives
> us is breathing space that we would not have but for LO's existence, not
> a lot it is true but enough. OOo will not disappear from the LO users
> ken for a number of months, possibly even a year.
>
> In the interim before a release, an active announce list and marketing
> blog should be priorities as well as maintaining a profile on User
> forums such as OOoForum.org
>
Well you're the marketing guy. ;)
At this point, all I'm suggesting is that "we" somehow keep the e-mail
Announcements current, somehow. I haven't seen an OO.o announcement e-mail
in a long long while, nor do I know how it actually gets constructed and put
out. Yes, this list is still managed the old site, but....?
Setting up a blog and just sending out an announcement with a link to the
blog (maintained by marketing?) would be ideal. A blog would be great!
> > And maybe a few others.
> > > > But I'd resist the urge to recreate the byzantine complexity of OOo
> > > > until we're sure that we need it. I'm hoping we never do.
> > >
> > > Small projects do have the advantage that people can contribute as
> suits
> > > their availability and feel their contribution is meaningful. That's
> > > just a function of Human group dynamics, we can get to know about 8
> > > people well, 25 we can work with, once the numbers get up however then
> > > people are simply in the company of strangers and thus they feel
> > > unrecognised and unappreciated.
> > >
> > > >
> > > >
> > > > > The home page as it is now was designed originally with one
> overriding
> > > > > goal: "increase downloads."
> > > > >
> > > >
> > > > Do you think this should still be the overriding goal of the
> homepage?
> > >
> > > There was reasoning behind this, more downloads = more users, More
> Users
> > > = Greater market share, More market share = more contributors. However
> > > the homepage grew from that original precept to become "Make it as easy
> > > as possible for someone landing on the homepage to have their OOo needs
> > > fulfilled!" Downloads was one of those needs.
> > >
> > > There was a history to the "More Downloads" thing, in 06 I think it
> was,
> > > Sun decided to spend some money on promoting OOo. Rather than giving
> it
> > > to the marketing project and letting us use it as best we could, they
> > > spent it with a promotions company to use on internet marketing (and
> > > gave the Marketing team a part of it, with the proviso that it be spent
> > > on promo materials, but that's another story.) The promo company spent
> > > around 35K USD, IMS, on google keywords and the like on a "Pay on click
> > > through" basis. Clicking on a text ad or keyword sent people to
> > > download.openoffice.org. The money disappeared fast, so there were
> lots
> > > of clickthroughs.
> >
> >
> > Oh boy...interesting little known facts.
> >
>
> It was frustrating, we could have run a community driven campaign that
> raised brand recognition (always our single biggest problem) and we
> would have steered them to the Why.ooo page, build confidence in the
> brand and then led them to the download button, but someone in the
> corporate space somehow figured that dumping people straight onto the
> download page would turn into downloads, if only it was that easy.
>
> >
> > > However, the rate of download changed not even so
> > > much as decimal of a percent. The promo company picked up their check
> > > and the value to the project was zero. To me and number of other
> people
> > > in the marketing project, the reason was obvious. The redesign of the
> > > homepage was a response to that failure, so that if ever they were that
> > > generous again we could say: "Just link to openoffice.org homepage
> > > because we have proved that it increases downloads."
> > >
> >
> > Why wouldn't you design a homepage for "users" that makes it easier for
> them
> > to get what they need -- monetary contributions notwithstanding?
> > OpenOffice.org is first and foremost a "client" product.
>
> The confusion with the original design was the confusion over the
> definition of "User". Our problem is that our User-Base is diverse in
> terms of Internet sophistication. The homepage in it's effort to cater
> for this huge diversity ended becoming too complex and confusing, a
> problem I foresee if we try to simplify everything too much. A maillist
> for devs is not the best place to have marketing discussions or users
> complaining that their download "doesn't work", or artists considering
> the aesthetics of different fontsets.
>
I agree...I suspect this will change in the future. The ASF setup is just
preliminary I think.
>
>
> > >
> > > > > So, keep the home page as is or find someway to get the CMS to
> display
> > > > > it, action statements intact at least.
> > >
> >
> > yes...I hope to investigate the Apache CMS capabilities in this regard
> this
> > week.
>
> I'm still in the committer pending box, as soon as that is actioned I'll
> get to grips with the CMS as well. The initial homepage will be
> probably more informational than guiding people to downloads. We could
> probably go with familiarity and substitute the download button for a
> "Countdown to Release" perhaps and link it to a blog, what do you think?
> Play a bit of the MS vaporware game. Trickling press releases,
> tantalising blog entries and so on! :) A bit difficult on public lists
> it's true (which is why we had some private lists in the marketing
> project) but it's all about keeping the attention simmering.
>
> Cheers
> GL
>
Great that you shared your insights!
>
> --
> Graham Lauder,
> OpenOffice.org MarCon (Marketing Contact) NZ
> http://marketing.openoffice.org/contacts.html
>
> OpenOffice.org Migration and training Consultant.
>
>
>
>
--
---------------------------------------------------------------------------------------
MzK
"He's got that New Orleans thing crawling all over him, that good stuff,
that
'We Are the Champions', to hell with the rest and I'll just start over kind
of attitude."
— "1 Dead in the Attic", Chris Rose
Re: Website Content plus Look and Feel Improvements
Posted by Graham Lauder <yo...@openoffice.org>.
On Wed, 2011-07-06 at 08:34 -0700, Kay Schenk wrote:
> On Wed, Jul 6, 2011 at 12:39 AM, Graham Lauder <yo...@openoffice.org>wrote:
>
> > > We had some earlier discussions on this. Personally, I was proposing
> > > that we take the opportunity to simplify. For example, right now
> > > we're doing all the work on ooo-dev. At some point it will be clear,
> > > perhaps soon, that we need an ooo-user list.
> >
>
> >From my POV, what would be really helpful right now to the existing user
> base, is to somehow migrate over the "Announcement" list and its
> corresponding subscribers. And, have someone designated to be the
> "announcement guru". My feat at the moment is losing supporters/users who
> don't have any interest in direct contribution but who use OpenOffice.org.
>
We have to be careful about rushing before we have an established
community that is needed to run a users list. At present we have had a
reasonably large migration to LibreOffice but I consider them to still
be part of our greater community. In terms of brand recognition our
brand still has high profile because LO is still seen as a "fork" of
OOo. Possibly not the best scenario for the LO people but until they
break fresh marketing ground that's simply the reality. What this gives
us is breathing space that we would not have but for LO's existence, not
a lot it is true but enough. OOo will not disappear from the LO users
ken for a number of months, possibly even a year.
In the interim before a release, an active announce list and marketing
blog should be priorities as well as maintaining a profile on User
forums such as OOoForum.org
> And maybe a few others.
> > > But I'd resist the urge to recreate the byzantine complexity of OOo
> > > until we're sure that we need it. I'm hoping we never do.
> >
> > Small projects do have the advantage that people can contribute as suits
> > their availability and feel their contribution is meaningful. That's
> > just a function of Human group dynamics, we can get to know about 8
> > people well, 25 we can work with, once the numbers get up however then
> > people are simply in the company of strangers and thus they feel
> > unrecognised and unappreciated.
> >
> > >
> > >
> > > > The home page as it is now was designed originally with one overriding
> > > > goal: "increase downloads."
> > > >
> > >
> > > Do you think this should still be the overriding goal of the homepage?
> >
> > There was reasoning behind this, more downloads = more users, More Users
> > = Greater market share, More market share = more contributors. However
> > the homepage grew from that original precept to become "Make it as easy
> > as possible for someone landing on the homepage to have their OOo needs
> > fulfilled!" Downloads was one of those needs.
> >
> > There was a history to the "More Downloads" thing, in 06 I think it was,
> > Sun decided to spend some money on promoting OOo. Rather than giving it
> > to the marketing project and letting us use it as best we could, they
> > spent it with a promotions company to use on internet marketing (and
> > gave the Marketing team a part of it, with the proviso that it be spent
> > on promo materials, but that's another story.) The promo company spent
> > around 35K USD, IMS, on google keywords and the like on a "Pay on click
> > through" basis. Clicking on a text ad or keyword sent people to
> > download.openoffice.org. The money disappeared fast, so there were lots
> > of clickthroughs.
>
>
> Oh boy...interesting little known facts.
>
It was frustrating, we could have run a community driven campaign that
raised brand recognition (always our single biggest problem) and we
would have steered them to the Why.ooo page, build confidence in the
brand and then led them to the download button, but someone in the
corporate space somehow figured that dumping people straight onto the
download page would turn into downloads, if only it was that easy.
>
> > However, the rate of download changed not even so
> > much as decimal of a percent. The promo company picked up their check
> > and the value to the project was zero. To me and number of other people
> > in the marketing project, the reason was obvious. The redesign of the
> > homepage was a response to that failure, so that if ever they were that
> > generous again we could say: "Just link to openoffice.org homepage
> > because we have proved that it increases downloads."
> >
>
> Why wouldn't you design a homepage for "users" that makes it easier for them
> to get what they need -- monetary contributions notwithstanding?
> OpenOffice.org is first and foremost a "client" product.
The confusion with the original design was the confusion over the
definition of "User". Our problem is that our User-Base is diverse in
terms of Internet sophistication. The homepage in it's effort to cater
for this huge diversity ended becoming too complex and confusing, a
problem I foresee if we try to simplify everything too much. A maillist
for devs is not the best place to have marketing discussions or users
complaining that their download "doesn't work", or artists considering
the aesthetics of different fontsets.
> >
> > > > So, keep the home page as is or find someway to get the CMS to display
> > > > it, action statements intact at least.
> >
>
> yes...I hope to investigate the Apache CMS capabilities in this regard this
> week.
I'm still in the committer pending box, as soon as that is actioned I'll
get to grips with the CMS as well. The initial homepage will be
probably more informational than guiding people to downloads. We could
probably go with familiarity and substitute the download button for a
"Countdown to Release" perhaps and link it to a blog, what do you think?
Play a bit of the MS vaporware game. Trickling press releases,
tantalising blog entries and so on! :) A bit difficult on public lists
it's true (which is why we had some private lists in the marketing
project) but it's all about keeping the attention simmering.
Cheers
GL
--
Graham Lauder,
OpenOffice.org MarCon (Marketing Contact) NZ
http://marketing.openoffice.org/contacts.html
OpenOffice.org Migration and training Consultant.
Re: Website Content plus Look and Feel Improvements
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Jul 6, 2011 at 12:39 AM, Graham Lauder <yo...@openoffice.org>wrote:
> On Tue, 2011-07-05 at 13:33 -0400, Rob Weir wrote:
> > On Tue, Jul 5, 2011 at 5:04 AM, Graham Lauder <g....@gmail.com>
> wrote:
> > > On Sun, 2011-07-03 at 10:23 -0700, Dave Fisher wrote:
> > >> On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote:
> > >
> > >
> > >> >
> > >> > Much of what is on there is legacy material that could be seriously
> > >> > pruned. For instance all the old Marketing material that is V2.0
> and
> > >> > earlier could be deleted.
> > >>
> > >> What would you do to the main openoffice.org site if you were
> starting from scratch?
> > >
> > > Big question, moving to Apache has one big advantage from my POV.
> > > (I should point out that my POV is marketing centric and is End User
> > > focussed rather than developer focussed.)
> > >
> > > With the content going onto CMS it makes it a lot easier for marketing
> > > content to be updated and changed as required. The Collabnet setup was
> > > difficult.
> > >
> > > The OOo web presence is huge, not just the website itself but all the
> > > NLC projects, the services part, maillists, forums, downloads and so
> on.
> > > Each fragment is looked after by it's own team. There are overlaps
> (ie:
> > > Distribution and CDROM) and global projects (Renaissance, art, UX)
> each
> > > piece has it's user base and it's client base and so the website as an
> > > entirety, obviously has to reflect that.
> > >
> >
> > Yes, there were a lot of teams. Everyone seemed to have an official
> > project title, often several ;-)
>
> Heh not everyone, but true there were a lot. Each had a Lead and a
> co-lead, then specific roles within each project. You have to remember
> that each section was treated as a project on it's own and this for good
> reason. OOo is a beast as people are discovering, there are very few
> people who could make informed comment about the entire project, maybe
> Mathias and Thorsten and Louis and a few others, but to be up to speed
> on all the code and the marketing and the documentation and the
> Linguacomponent and the NLC and the Renaissance project etc etc
> is ....well you can see what I mean.
>
> You break problems down into manageable chunks, then create the
> infrastructure that pulls all that together into a whole. In a Bazaar
> this size, it seems chaotic to the Cathedral builders. the problem is
> that this bazaar was trying to build a cathedral and so the stalls in
> the bazaar became minicathedrals to a degree, but that was possibly a
> symptom of the corporate ownership. It is true that many people wore
> several hats but I never considered that a huge problem, that's human
> nature, we all wear different hats. The problem was the coordination of
> all of the disparate pieces.
>
> >
> > We had some earlier discussions on this. Personally, I was proposing
> > that we take the opportunity to simplify. For example, right now
> > we're doing all the work on ooo-dev. At some point it will be clear,
> > perhaps soon, that we need an ooo-user list.
>
>From my POV, what would be really helpful right now to the existing user
base, is to somehow migrate over the "Announcement" list and its
corresponding subscribers. And, have someone designated to be the
"announcement guru". My feat at the moment is losing supporters/users who
don't have any interest in direct contribution but who use OpenOffice.org.
And maybe a few others.
> > But I'd resist the urge to recreate the byzantine complexity of OOo
> > until we're sure that we need it. I'm hoping we never do.
>
> Small projects do have the advantage that people can contribute as suits
> their availability and feel their contribution is meaningful. That's
> just a function of Human group dynamics, we can get to know about 8
> people well, 25 we can work with, once the numbers get up however then
> people are simply in the company of strangers and thus they feel
> unrecognised and unappreciated.
>
> >
> >
> > > The home page as it is now was designed originally with one overriding
> > > goal: "increase downloads."
> > >
> >
> > Do you think this should still be the overriding goal of the homepage?
>
> There was reasoning behind this, more downloads = more users, More Users
> = Greater market share, More market share = more contributors. However
> the homepage grew from that original precept to become "Make it as easy
> as possible for someone landing on the homepage to have their OOo needs
> fulfilled!" Downloads was one of those needs.
>
> There was a history to the "More Downloads" thing, in 06 I think it was,
> Sun decided to spend some money on promoting OOo. Rather than giving it
> to the marketing project and letting us use it as best we could, they
> spent it with a promotions company to use on internet marketing (and
> gave the Marketing team a part of it, with the proviso that it be spent
> on promo materials, but that's another story.) The promo company spent
> around 35K USD, IMS, on google keywords and the like on a "Pay on click
> through" basis. Clicking on a text ad or keyword sent people to
> download.openoffice.org. The money disappeared fast, so there were lots
> of clickthroughs.
Oh boy...interesting little known facts.
> However, the rate of download changed not even so
> much as decimal of a percent. The promo company picked up their check
> and the value to the project was zero. To me and number of other people
> in the marketing project, the reason was obvious. The redesign of the
> homepage was a response to that failure, so that if ever they were that
> generous again we could say: "Just link to openoffice.org homepage
> because we have proved that it increases downloads."
>
Why wouldn't you design a homepage for "users" that makes it easier for them
to get what they need -- monetary contributions notwithstanding?
OpenOffice.org is first and foremost a "client" product.
> >
> > > Therefore we had to analyse our catchment, identify our user groups and
> > > their specific needs and patterns of usage of the Website. We then
> > > needed to specifically identify the Home page users and their needs.
> It
> > > should be noted that while there is a crossover, Homepage users are a
> > > different set to Website users. Regular community members tend to
> > > bypass the homepage because they know where they can fulfil their needs
> > > already, they either go straight to the wiki or the forums or docs or
> > > whichever part is specific to their part of the community.
> > >
> > > IMS We identified 5 groups that visit the Homepage.
> > >
> > > Casual arrivals
> > > People seeking a download, either for the first time or to upgrade
> > > Users seeking assistance
> > > People wishing to contribute to the community
> > > Developers
> > >
> >
> > What is a "casual arrival"? Is that someone arriving via a search?
>
> The Casual arrival was someone who clicked a Google ad or keyword out of
> curiosity. Someone who has done a search specifically for OOo is
> generally already informed about OOo, conversely someone who had
> searched say for "Free Office Suites" would fit the Casual arrival
> group
>
> >
> >
> > Have you ever seen any traffic reports for Openoffice.org? Or
> > something like Google Analytics, that would show how the web site is
> > being used currently?
>
> Probably the nearest thing would be
> http://tools.services.openoffice.org/dashboard/
>
> Not all up to date unfortunately, but not unexpected. Obviously the
> marketing teams main concern was the download numbers, the average was
> about 300,000 a day back around 3.2 launch if memory serves
>
>
> > > So, keep the home page as is or find someway to get the CMS to display
> > > it, action statements intact at least.
>
yes...I hope to investigate the Apache CMS capabilities in this regard this
week.
> > >
> > > Then to my mind the only subs to the OOo domain that I would think that
> > > would be compulsory would be:
> > > support.openoffice.org
> > > Why.openoffice.org and
> > > download.openoffice.org
> > >
> > > and the NLC subdomains
> > >
> > > The rest of the website could happily exist under
> OpenOffice.apache.org.
>
> > >
> >
> > This is close to what I was proposing. Move the project-centric
> > services and content, the stuff that project volunteers access most,
> > to the Apache address. But keep OpenOffice.org as the public-facing,
> > user-facing portal for the product.
>
> +1
>
+1, sounds reasonable
>
> Cheers
> GL
> --
> Graham Lauder,
> OpenOffice.org MarCon (Marketing Contact) NZ
> http://marketing.openoffice.org/contacts.html
>
> OpenOffice.org Migration and training Consultant.
>
>
>
>
--
---------------------------------------------------------------------------------------
MzK
"He's got that New Orleans thing crawling all over him, that good stuff,
that
'We Are the Champions', to hell with the rest and I'll just start over kind
of attitude."
— "1 Dead in the Attic", Chris Rose
Re: Website Content plus Look and Feel Improvements
Posted by Graham Lauder <yo...@openoffice.org>.
On Tue, 2011-07-05 at 13:33 -0400, Rob Weir wrote:
> On Tue, Jul 5, 2011 at 5:04 AM, Graham Lauder <g....@gmail.com> wrote:
> > On Sun, 2011-07-03 at 10:23 -0700, Dave Fisher wrote:
> >> On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote:
> >
> >
> >> >
> >> > Much of what is on there is legacy material that could be seriously
> >> > pruned. For instance all the old Marketing material that is V2.0 and
> >> > earlier could be deleted.
> >>
> >> What would you do to the main openoffice.org site if you were starting from scratch?
> >
> > Big question, moving to Apache has one big advantage from my POV.
> > (I should point out that my POV is marketing centric and is End User
> > focussed rather than developer focussed.)
> >
> > With the content going onto CMS it makes it a lot easier for marketing
> > content to be updated and changed as required. The Collabnet setup was
> > difficult.
> >
> > The OOo web presence is huge, not just the website itself but all the
> > NLC projects, the services part, maillists, forums, downloads and so on.
> > Each fragment is looked after by it's own team. There are overlaps (ie:
> > Distribution and CDROM) and global projects (Renaissance, art, UX) each
> > piece has it's user base and it's client base and so the website as an
> > entirety, obviously has to reflect that.
> >
>
> Yes, there were a lot of teams. Everyone seemed to have an official
> project title, often several ;-)
Heh not everyone, but true there were a lot. Each had a Lead and a
co-lead, then specific roles within each project. You have to remember
that each section was treated as a project on it's own and this for good
reason. OOo is a beast as people are discovering, there are very few
people who could make informed comment about the entire project, maybe
Mathias and Thorsten and Louis and a few others, but to be up to speed
on all the code and the marketing and the documentation and the
Linguacomponent and the NLC and the Renaissance project etc etc
is ....well you can see what I mean.
You break problems down into manageable chunks, then create the
infrastructure that pulls all that together into a whole. In a Bazaar
this size, it seems chaotic to the Cathedral builders. the problem is
that this bazaar was trying to build a cathedral and so the stalls in
the bazaar became minicathedrals to a degree, but that was possibly a
symptom of the corporate ownership. It is true that many people wore
several hats but I never considered that a huge problem, that's human
nature, we all wear different hats. The problem was the coordination of
all of the disparate pieces.
>
> We had some earlier discussions on this. Personally, I was proposing
> that we take the opportunity to simplify. For example, right now
> we're doing all the work on ooo-dev. At some point it will be clear,
> perhaps soon, that we need an ooo-user list. And maybe a few others.
> But I'd resist the urge to recreate the byzantine complexity of OOo
> until we're sure that we need it. I'm hoping we never do.
Small projects do have the advantage that people can contribute as suits
their availability and feel their contribution is meaningful. That's
just a function of Human group dynamics, we can get to know about 8
people well, 25 we can work with, once the numbers get up however then
people are simply in the company of strangers and thus they feel
unrecognised and unappreciated.
>
>
> > The home page as it is now was designed originally with one overriding
> > goal: "increase downloads."
> >
>
> Do you think this should still be the overriding goal of the homepage?
There was reasoning behind this, more downloads = more users, More Users
= Greater market share, More market share = more contributors. However
the homepage grew from that original precept to become "Make it as easy
as possible for someone landing on the homepage to have their OOo needs
fulfilled!" Downloads was one of those needs.
There was a history to the "More Downloads" thing, in 06 I think it was,
Sun decided to spend some money on promoting OOo. Rather than giving it
to the marketing project and letting us use it as best we could, they
spent it with a promotions company to use on internet marketing (and
gave the Marketing team a part of it, with the proviso that it be spent
on promo materials, but that's another story.) The promo company spent
around 35K USD, IMS, on google keywords and the like on a "Pay on click
through" basis. Clicking on a text ad or keyword sent people to
download.openoffice.org. The money disappeared fast, so there were lots
of clickthroughs. However, the rate of download changed not even so
much as decimal of a percent. The promo company picked up their check
and the value to the project was zero. To me and number of other people
in the marketing project, the reason was obvious. The redesign of the
homepage was a response to that failure, so that if ever they were that
generous again we could say: "Just link to openoffice.org homepage
because we have proved that it increases downloads."
>
> > Therefore we had to analyse our catchment, identify our user groups and
> > their specific needs and patterns of usage of the Website. We then
> > needed to specifically identify the Home page users and their needs. It
> > should be noted that while there is a crossover, Homepage users are a
> > different set to Website users. Regular community members tend to
> > bypass the homepage because they know where they can fulfil their needs
> > already, they either go straight to the wiki or the forums or docs or
> > whichever part is specific to their part of the community.
> >
> > IMS We identified 5 groups that visit the Homepage.
> >
> > Casual arrivals
> > People seeking a download, either for the first time or to upgrade
> > Users seeking assistance
> > People wishing to contribute to the community
> > Developers
> >
>
> What is a "casual arrival"? Is that someone arriving via a search?
The Casual arrival was someone who clicked a Google ad or keyword out of
curiosity. Someone who has done a search specifically for OOo is
generally already informed about OOo, conversely someone who had
searched say for "Free Office Suites" would fit the Casual arrival
group
>
>
> Have you ever seen any traffic reports for Openoffice.org? Or
> something like Google Analytics, that would show how the web site is
> being used currently?
Probably the nearest thing would be
http://tools.services.openoffice.org/dashboard/
Not all up to date unfortunately, but not unexpected. Obviously the
marketing teams main concern was the download numbers, the average was
about 300,000 a day back around 3.2 launch if memory serves
> > So, keep the home page as is or find someway to get the CMS to display
> > it, action statements intact at least.
> >
> > Then to my mind the only subs to the OOo domain that I would think that
> > would be compulsory would be:
> > support.openoffice.org
> > Why.openoffice.org and
> > download.openoffice.org
> >
> > and the NLC subdomains
> >
> > The rest of the website could happily exist under OpenOffice.apache.org.
> >
>
> This is close to what I was proposing. Move the project-centric
> services and content, the stuff that project volunteers access most,
> to the Apache address. But keep OpenOffice.org as the public-facing,
> user-facing portal for the product.
+1
Cheers
GL
--
Graham Lauder,
OpenOffice.org MarCon (Marketing Contact) NZ
http://marketing.openoffice.org/contacts.html
OpenOffice.org Migration and training Consultant.
Re: Website Content plus Look and Feel Improvements
Posted by Wolf Halton <wo...@gmail.com>.
I am going to do some research into *2odf in python.
On Jul 5, 2011 11:57 PM, "Dave Fisher" <da...@comcast.net> wrote:
>
> On Jul 5, 2011, at 2:53 PM, Wolf Halton wrote:
>
>> As far as preparing literal books, it would help to know if the page
content
>> is stored as records in a database. That would make exporting to the book
>> simpler, using sql to predesigned report templates. In my experience,
almost
>> no web images are of high enough quality for inclusion in professionally
>> published material.
>
> Page content will be files in a hierarchy of some kind stored in an svn
repository.
>
> Many possible transformations are possible using python markdown and the
Apache CMS.
>
>
>> I would like to help with this if possible. I am thinking a off
compressed
>> file could be broken into its 3 parts, export the database as text or xml
>> and resave it as an odf compressed file. This looks relatively simple,
even
>> with placing the images. Thus it is probably full of minefields.
>
> Yes, but it is a good idea to have a *2ODF conversion. If we create an xml
or xhtml of some type using python markdown we should be able to transform
it to ODF somehow.
>
> Images can start with website level and we can worry about publishing
quality later - I wonder how many will actually print.
>
> I am thinking about how to manage the selection of foreign language
content in this web flow and your XML2ODF module would be a critical tool.
>
> I wonder if the ODF Toolkit would be helpful here.
>
> If we do this correctly the ODF option will be available to any Apache
project using the CMS.
>
> Regards,
> Dave
>
>>
>> Cheers
>> Wolf
>>
>> On Jul 5, 2011 1:57 PM, "Dave Fisher" <da...@comcast.net> wrote:
>>>
>>> On Jul 5, 2011, at 10:33 AM, Rob Weir wrote:
>>>
>>>> On Tue, Jul 5, 2011 at 5:04 AM, Graham Lauder <g....@gmail.com>
>> wrote:
>>>>> On Sun, 2011-07-03 at 10:23 -0700, Dave Fisher wrote:
>>>>>> On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote:
>>>>>
>>>>>
>>>>>>>
>>>>>>> Much of what is on there is legacy material that could be seriously
>>>>>>> pruned. For instance all the old Marketing material that is V2.0 and
>>>>>>> earlier could be deleted.
>>>>>>
>>>>>> What would you do to the main openoffice.org site if you were
starting
>> from scratch?
>>>>>
>>>>> Big question, moving to Apache has one big advantage from my POV.
>>>>> (I should point out that my POV is marketing centric and is End User
>>>>> focussed rather than developer focussed.)
>>>>>
>>>>> With the content going onto CMS it makes it a lot easier for marketing
>>>>> content to be updated and changed as required. The Collabnet setup was
>>>>> difficult.
>>>>>
>>>>> The OOo web presence is huge, not just the website itself but all the
>>>>> NLC projects, the services part, maillists, forums, downloads and so
on.
>>>>> Each fragment is looked after by it's own team. There are overlaps
(ie:
>>>>> Distribution and CDROM) and global projects (Renaissance, art, UX)
each
>>>>> piece has it's user base and it's client base and so the website as an
>>>>> entirety, obviously has to reflect that.
>>>>>
>>>>
>>>> Yes, there were a lot of teams. Everyone seemed to have an official
>>>> project title, often several ;-)
>>>>
>>>> We had some earlier discussions on this. Personally, I was proposing
>>>> that we take the opportunity to simplify. For example, right now
>>>> we're doing all the work on ooo-dev. At some point it will be clear,
>>>> perhaps soon, that we need an ooo-user list. And maybe a few others.
>>>> But I'd resist the urge to recreate the byzantine complexity of OOo
>>>> until we're sure that we need it. I'm hoping we never do.
>>>
>>> If you read my initial email in this thread you will know that is where
it
>> started. Keeping the list to the 6 basic categories which I noted
paralleled
>> your Project Plan layout though not exactly.
>>>
>>>>
>>>>
>>>>> The home page as it is now was designed originally with one overriding
>>>>> goal: "increase downloads."
>>>>>
>>>>
>>>> Do you think this should still be the overriding goal of the homepage?
>>>>
>>>>> Therefore we had to analyse our catchment, identify our user groups
and
>>>>> their specific needs and patterns of usage of the Website. We then
>>>>> needed to specifically identify the Home page users and their needs.
It
>>>>> should be noted that while there is a crossover, Homepage users are a
>>>>> different set to Website users. Regular community members tend to
>>>>> bypass the homepage because they know where they can fulfil their
needs
>>>>> already, they either go straight to the wiki or the forums or docs or
>>>>> whichever part is specific to their part of the community.
>>>>>
>>>>> IMS We identified 5 groups that visit the Homepage.
>>>>>
>>>>> Casual arrivals
>>>>> People seeking a download, either for the first time or to upgrade
>>>>> Users seeking assistance
>>>>> People wishing to contribute to the community
>>>>> Developers
>>>
>>> He said they did an analysis. From my own experience the Home page is
the
>> hardest page in the whole site to design.
>>>
>>> For the new openoffice.org I would keep these key - dynamic buttons. The
>> top bar and right news sections are another story - the page frame story
>> which needs to be integrated with the openoffice.apache.org site.
>>>
>>>>>
>>>>
>>>> What is a "casual arrival"? Is that someone arriving via a search?
>>>>
>>>>
>>>> Have you ever seen any traffic reports for Openoffice.org? Or
>>>> something like Google Analytics, that would show how the web site is
>>>> being used currently?
>>>>
>>>>
>>>>> Each of these groups have entirely different needs. The original home
>>>>> page tried to cater for all these different groups and ended up doing
it
>>>>> badly. My intention for the homepage was to have each of these groups
>>>>> headed to wherever they needed to be on the website within 15 seconds.
>>>>> We did that by reducing the number of decisions and introducing the
>>>>> "Action Statements". (There were over 120 links on the original
homepage
>>>>> we reduced them to about 15, not including those in the news column.)
>>>>>
>>>>> Did it achieve More Downloads? as far as I know, yes. Louis would be
>>>>> better informed on this. A lot of debate went on with regard to the
>>>>> concept of the "Action Statements", over many months, but once the web
>>>>> team were onside the results were, to my eyes, spectacular.
>>>>>
>>>>> (Just for amusements sake
>>>>>
>>
http://wiki.services.openoffice.org/mwiki/images/a/a3/Home_page_draft_11-27.jpgwas
>> my first rather amateurish mockup which the website team, Maarten,
>> Kay,
>> Ivan and others turned into http://www.openoffice.org .)
>>>
>>> It is important to note who has contributed to this process.
>>>
>>>>>
>>>>> So the homepage is simply a portal, a signpost that is geared to cater
>>>>> to the Unsophisticated End User. These people require simplicity,
>>>>> continuity and a feeling of security and it is only this group that
the
>>>>> warmth and comfort of http://www.openoffice.org would be significant
or
>>>>> necessary.
>>>>>
>>>>> So, keep the home page as is or find someway to get the CMS to display
>>>>> it, action statements intact at least.
>>>>>
>>>>> Then to my mind the only subs to the OOo domain that I would think
that
>>>>> would be compulsory would be:
>>>>> support.openoffice.org
>>>>> Why.openoffice.org and
>>>>> download.openoffice.org
>>>>>
>>>>> and the NLC subdomains
>>>>>
>>>>> The rest of the website could happily exist under
OpenOffice.apache.org.
>>>>>
>>>>
>>>> This is close to what I was proposing. Move the project-centric
>>>> services and content, the stuff that project volunteers access most,
>>>> to the Apache address. But keep OpenOffice.org as the public-facing,
>>>> user-facing portal for the product.
>>>
>>> This is what I hoped would be proposed.
>>>
>>> If you look in an earlier message I proposed a strategy:
>>>
>>> (1) An initial test could focus on the current main page in English
>> followed by versions in several languages. This will need to script the
>> conversion of existing webcontent from Kenai into format for the Apache
CMS.
>>>
>>> -> This becomes the openoffice.org effort.
>>>
>>> (2) A second focus would be on the Kenai content for one of the product
>> development areas. This script may be substantially different.
>>>
>>> -> This becomes part of the openoffice.apache.org effort.
>>>
>>> (3) A third focus would be building the documentation area. If a wiki is
>> preferred then we should create a website page that provides good links.
>>>
>>> -> Jean and others have expressed wanting to have a reset here.
>>>
>>> (4) A fourth focus for the website migration is how to best integrate
the
>> project's choices for Bugzilla or JIRA, user forums, and mailing lists.
>>>
>>> -> This becomes a focus on the site skeleton and internal navigation.
>>>
>>>
>>> I created a script here - ./trunk/tools/dev/fetch-all-web.sh to download
>> webcontent from the svn. Like the hg to svn work this process must be
>> repeatable by anyone who wants to run it.
>>>
>>> Regards,
>>> Dave
>>>
>>>>
>>>>
>>>>> Cheers
>>>>> for now
>>>>>
>>>>> GL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Dave
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Argument could be made for the marketing material to start from
>> scratch.
>>>>>>> Personally I'd like to see a whole new branding and get shot of the
>> old
>>>>>>> stuff, make the first Apache release: V4.0 (Historically,
significant
>>>>>>> global change has meant a whole number change in the version: V2 new
>>>>>>> codebase, V3 Apple compatibility. I think this is significant
enough:
>>>>>>> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
>>>>>>> gives us a handle to hang a campaign on.
>>>>>>>
>>>>>>> Cheers
>>>>>>> GL
>>>>>>>
>>>>>>> --
>>>>>>> Graham Lauder,
>>>>>>> OpenOffice.org MarCon (Marketing Contact) NZ
>>>>>>> http://marketing.openoffice.org/contacts.html
>>>>>>>
>>>>>>> OpenOffice.org Migration and training Consultant.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 5, 2011, at 2:53 PM, Wolf Halton wrote:
> As far as preparing literal books, it would help to know if the page content
> is stored as records in a database. That would make exporting to the book
> simpler, using sql to predesigned report templates. In my experience, almost
> no web images are of high enough quality for inclusion in professionally
> published material.
Page content will be files in a hierarchy of some kind stored in an svn repository.
Many possible transformations are possible using python markdown and the Apache CMS.
> I would like to help with this if possible. I am thinking a off compressed
> file could be broken into its 3 parts, export the database as text or xml
> and resave it as an odf compressed file. This looks relatively simple, even
> with placing the images. Thus it is probably full of minefields.
Yes, but it is a good idea to have a *2ODF conversion. If we create an xml or xhtml of some type using python markdown we should be able to transform it to ODF somehow.
Images can start with website level and we can worry about publishing quality later - I wonder how many will actually print.
I am thinking about how to manage the selection of foreign language content in this web flow and your XML2ODF module would be a critical tool.
I wonder if the ODF Toolkit would be helpful here.
If we do this correctly the ODF option will be available to any Apache project using the CMS.
Regards,
Dave
>
> Cheers
> Wolf
>
> On Jul 5, 2011 1:57 PM, "Dave Fisher" <da...@comcast.net> wrote:
>>
>> On Jul 5, 2011, at 10:33 AM, Rob Weir wrote:
>>
>>> On Tue, Jul 5, 2011 at 5:04 AM, Graham Lauder <g....@gmail.com>
> wrote:
>>>> On Sun, 2011-07-03 at 10:23 -0700, Dave Fisher wrote:
>>>>> On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote:
>>>>
>>>>
>>>>>>
>>>>>> Much of what is on there is legacy material that could be seriously
>>>>>> pruned. For instance all the old Marketing material that is V2.0 and
>>>>>> earlier could be deleted.
>>>>>
>>>>> What would you do to the main openoffice.org site if you were starting
> from scratch?
>>>>
>>>> Big question, moving to Apache has one big advantage from my POV.
>>>> (I should point out that my POV is marketing centric and is End User
>>>> focussed rather than developer focussed.)
>>>>
>>>> With the content going onto CMS it makes it a lot easier for marketing
>>>> content to be updated and changed as required. The Collabnet setup was
>>>> difficult.
>>>>
>>>> The OOo web presence is huge, not just the website itself but all the
>>>> NLC projects, the services part, maillists, forums, downloads and so on.
>>>> Each fragment is looked after by it's own team. There are overlaps (ie:
>>>> Distribution and CDROM) and global projects (Renaissance, art, UX) each
>>>> piece has it's user base and it's client base and so the website as an
>>>> entirety, obviously has to reflect that.
>>>>
>>>
>>> Yes, there were a lot of teams. Everyone seemed to have an official
>>> project title, often several ;-)
>>>
>>> We had some earlier discussions on this. Personally, I was proposing
>>> that we take the opportunity to simplify. For example, right now
>>> we're doing all the work on ooo-dev. At some point it will be clear,
>>> perhaps soon, that we need an ooo-user list. And maybe a few others.
>>> But I'd resist the urge to recreate the byzantine complexity of OOo
>>> until we're sure that we need it. I'm hoping we never do.
>>
>> If you read my initial email in this thread you will know that is where it
> started. Keeping the list to the 6 basic categories which I noted paralleled
> your Project Plan layout though not exactly.
>>
>>>
>>>
>>>> The home page as it is now was designed originally with one overriding
>>>> goal: "increase downloads."
>>>>
>>>
>>> Do you think this should still be the overriding goal of the homepage?
>>>
>>>> Therefore we had to analyse our catchment, identify our user groups and
>>>> their specific needs and patterns of usage of the Website. We then
>>>> needed to specifically identify the Home page users and their needs. It
>>>> should be noted that while there is a crossover, Homepage users are a
>>>> different set to Website users. Regular community members tend to
>>>> bypass the homepage because they know where they can fulfil their needs
>>>> already, they either go straight to the wiki or the forums or docs or
>>>> whichever part is specific to their part of the community.
>>>>
>>>> IMS We identified 5 groups that visit the Homepage.
>>>>
>>>> Casual arrivals
>>>> People seeking a download, either for the first time or to upgrade
>>>> Users seeking assistance
>>>> People wishing to contribute to the community
>>>> Developers
>>
>> He said they did an analysis. From my own experience the Home page is the
> hardest page in the whole site to design.
>>
>> For the new openoffice.org I would keep these key - dynamic buttons. The
> top bar and right news sections are another story - the page frame story
> which needs to be integrated with the openoffice.apache.org site.
>>
>>>>
>>>
>>> What is a "casual arrival"? Is that someone arriving via a search?
>>>
>>>
>>> Have you ever seen any traffic reports for Openoffice.org? Or
>>> something like Google Analytics, that would show how the web site is
>>> being used currently?
>>>
>>>
>>>> Each of these groups have entirely different needs. The original home
>>>> page tried to cater for all these different groups and ended up doing it
>>>> badly. My intention for the homepage was to have each of these groups
>>>> headed to wherever they needed to be on the website within 15 seconds.
>>>> We did that by reducing the number of decisions and introducing the
>>>> "Action Statements". (There were over 120 links on the original homepage
>>>> we reduced them to about 15, not including those in the news column.)
>>>>
>>>> Did it achieve More Downloads? as far as I know, yes. Louis would be
>>>> better informed on this. A lot of debate went on with regard to the
>>>> concept of the "Action Statements", over many months, but once the web
>>>> team were onside the results were, to my eyes, spectacular.
>>>>
>>>> (Just for amusements sake
>>>>
> http://wiki.services.openoffice.org/mwiki/images/a/a3/Home_page_draft_11-27.jpgwas
> my first rather amateurish mockup which the website team, Maarten,
> Kay,
> Ivan and others turned into http://www.openoffice.org .)
>>
>> It is important to note who has contributed to this process.
>>
>>>>
>>>> So the homepage is simply a portal, a signpost that is geared to cater
>>>> to the Unsophisticated End User. These people require simplicity,
>>>> continuity and a feeling of security and it is only this group that the
>>>> warmth and comfort of http://www.openoffice.org would be significant or
>>>> necessary.
>>>>
>>>> So, keep the home page as is or find someway to get the CMS to display
>>>> it, action statements intact at least.
>>>>
>>>> Then to my mind the only subs to the OOo domain that I would think that
>>>> would be compulsory would be:
>>>> support.openoffice.org
>>>> Why.openoffice.org and
>>>> download.openoffice.org
>>>>
>>>> and the NLC subdomains
>>>>
>>>> The rest of the website could happily exist under OpenOffice.apache.org.
>>>>
>>>
>>> This is close to what I was proposing. Move the project-centric
>>> services and content, the stuff that project volunteers access most,
>>> to the Apache address. But keep OpenOffice.org as the public-facing,
>>> user-facing portal for the product.
>>
>> This is what I hoped would be proposed.
>>
>> If you look in an earlier message I proposed a strategy:
>>
>> (1) An initial test could focus on the current main page in English
> followed by versions in several languages. This will need to script the
> conversion of existing webcontent from Kenai into format for the Apache CMS.
>>
>> -> This becomes the openoffice.org effort.
>>
>> (2) A second focus would be on the Kenai content for one of the product
> development areas. This script may be substantially different.
>>
>> -> This becomes part of the openoffice.apache.org effort.
>>
>> (3) A third focus would be building the documentation area. If a wiki is
> preferred then we should create a website page that provides good links.
>>
>> -> Jean and others have expressed wanting to have a reset here.
>>
>> (4) A fourth focus for the website migration is how to best integrate the
> project's choices for Bugzilla or JIRA, user forums, and mailing lists.
>>
>> -> This becomes a focus on the site skeleton and internal navigation.
>>
>>
>> I created a script here - ./trunk/tools/dev/fetch-all-web.sh to download
> webcontent from the svn. Like the hg to svn work this process must be
> repeatable by anyone who wants to run it.
>>
>> Regards,
>> Dave
>>
>>>
>>>
>>>> Cheers
>>>> for now
>>>>
>>>> GL
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Dave
>>>>>
>>>>>
>>>>>>
>>>>>> Argument could be made for the marketing material to start from
> scratch.
>>>>>> Personally I'd like to see a whole new branding and get shot of the
> old
>>>>>> stuff, make the first Apache release: V4.0 (Historically, significant
>>>>>> global change has meant a whole number change in the version: V2 new
>>>>>> codebase, V3 Apple compatibility. I think this is significant enough:
>>>>>> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
>>>>>> gives us a handle to hang a campaign on.
>>>>>>
>>>>>> Cheers
>>>>>> GL
>>>>>>
>>>>>> --
>>>>>> Graham Lauder,
>>>>>> OpenOffice.org MarCon (Marketing Contact) NZ
>>>>>> http://marketing.openoffice.org/contacts.html
>>>>>>
>>>>>> OpenOffice.org Migration and training Consultant.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
Re: Website Content plus Look and Feel Improvements
Posted by Wolf Halton <wo...@gmail.com>.
As far as preparing literal books, it would help to know if the page content
is stored as records in a database. That would make exporting to the book
simpler, using sql to predesigned report templates. In my experience, almost
no web images are of high enough quality for inclusion in professionally
published material.
I would like to help with this if possible. I am thinking a off compressed
file could be broken into its 3 parts, export the database as text or xml
and resave it as an odf compressed file. This looks relatively simple, even
with placing the images. Thus it is probably full of minefields.
Cheers
Wolf
On Jul 5, 2011 1:57 PM, "Dave Fisher" <da...@comcast.net> wrote:
>
> On Jul 5, 2011, at 10:33 AM, Rob Weir wrote:
>
>> On Tue, Jul 5, 2011 at 5:04 AM, Graham Lauder <g....@gmail.com>
wrote:
>>> On Sun, 2011-07-03 at 10:23 -0700, Dave Fisher wrote:
>>>> On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote:
>>>
>>>
>>>>>
>>>>> Much of what is on there is legacy material that could be seriously
>>>>> pruned. For instance all the old Marketing material that is V2.0 and
>>>>> earlier could be deleted.
>>>>
>>>> What would you do to the main openoffice.org site if you were starting
from scratch?
>>>
>>> Big question, moving to Apache has one big advantage from my POV.
>>> (I should point out that my POV is marketing centric and is End User
>>> focussed rather than developer focussed.)
>>>
>>> With the content going onto CMS it makes it a lot easier for marketing
>>> content to be updated and changed as required. The Collabnet setup was
>>> difficult.
>>>
>>> The OOo web presence is huge, not just the website itself but all the
>>> NLC projects, the services part, maillists, forums, downloads and so on.
>>> Each fragment is looked after by it's own team. There are overlaps (ie:
>>> Distribution and CDROM) and global projects (Renaissance, art, UX) each
>>> piece has it's user base and it's client base and so the website as an
>>> entirety, obviously has to reflect that.
>>>
>>
>> Yes, there were a lot of teams. Everyone seemed to have an official
>> project title, often several ;-)
>>
>> We had some earlier discussions on this. Personally, I was proposing
>> that we take the opportunity to simplify. For example, right now
>> we're doing all the work on ooo-dev. At some point it will be clear,
>> perhaps soon, that we need an ooo-user list. And maybe a few others.
>> But I'd resist the urge to recreate the byzantine complexity of OOo
>> until we're sure that we need it. I'm hoping we never do.
>
> If you read my initial email in this thread you will know that is where it
started. Keeping the list to the 6 basic categories which I noted paralleled
your Project Plan layout though not exactly.
>
>>
>>
>>> The home page as it is now was designed originally with one overriding
>>> goal: "increase downloads."
>>>
>>
>> Do you think this should still be the overriding goal of the homepage?
>>
>>> Therefore we had to analyse our catchment, identify our user groups and
>>> their specific needs and patterns of usage of the Website. We then
>>> needed to specifically identify the Home page users and their needs. It
>>> should be noted that while there is a crossover, Homepage users are a
>>> different set to Website users. Regular community members tend to
>>> bypass the homepage because they know where they can fulfil their needs
>>> already, they either go straight to the wiki or the forums or docs or
>>> whichever part is specific to their part of the community.
>>>
>>> IMS We identified 5 groups that visit the Homepage.
>>>
>>> Casual arrivals
>>> People seeking a download, either for the first time or to upgrade
>>> Users seeking assistance
>>> People wishing to contribute to the community
>>> Developers
>
> He said they did an analysis. From my own experience the Home page is the
hardest page in the whole site to design.
>
> For the new openoffice.org I would keep these key - dynamic buttons. The
top bar and right news sections are another story - the page frame story
which needs to be integrated with the openoffice.apache.org site.
>
>>>
>>
>> What is a "casual arrival"? Is that someone arriving via a search?
>>
>>
>> Have you ever seen any traffic reports for Openoffice.org? Or
>> something like Google Analytics, that would show how the web site is
>> being used currently?
>>
>>
>>> Each of these groups have entirely different needs. The original home
>>> page tried to cater for all these different groups and ended up doing it
>>> badly. My intention for the homepage was to have each of these groups
>>> headed to wherever they needed to be on the website within 15 seconds.
>>> We did that by reducing the number of decisions and introducing the
>>> "Action Statements". (There were over 120 links on the original homepage
>>> we reduced them to about 15, not including those in the news column.)
>>>
>>> Did it achieve More Downloads? as far as I know, yes. Louis would be
>>> better informed on this. A lot of debate went on with regard to the
>>> concept of the "Action Statements", over many months, but once the web
>>> team were onside the results were, to my eyes, spectacular.
>>>
>>> (Just for amusements sake
>>>
http://wiki.services.openoffice.org/mwiki/images/a/a3/Home_page_draft_11-27.jpgwas
my first rather amateurish mockup which the website team, Maarten,
Kay,
Ivan and others turned into http://www.openoffice.org .)
>
> It is important to note who has contributed to this process.
>
>>>
>>> So the homepage is simply a portal, a signpost that is geared to cater
>>> to the Unsophisticated End User. These people require simplicity,
>>> continuity and a feeling of security and it is only this group that the
>>> warmth and comfort of http://www.openoffice.org would be significant or
>>> necessary.
>>>
>>> So, keep the home page as is or find someway to get the CMS to display
>>> it, action statements intact at least.
>>>
>>> Then to my mind the only subs to the OOo domain that I would think that
>>> would be compulsory would be:
>>> support.openoffice.org
>>> Why.openoffice.org and
>>> download.openoffice.org
>>>
>>> and the NLC subdomains
>>>
>>> The rest of the website could happily exist under OpenOffice.apache.org.
>>>
>>
>> This is close to what I was proposing. Move the project-centric
>> services and content, the stuff that project volunteers access most,
>> to the Apache address. But keep OpenOffice.org as the public-facing,
>> user-facing portal for the product.
>
> This is what I hoped would be proposed.
>
> If you look in an earlier message I proposed a strategy:
>
> (1) An initial test could focus on the current main page in English
followed by versions in several languages. This will need to script the
conversion of existing webcontent from Kenai into format for the Apache CMS.
>
> -> This becomes the openoffice.org effort.
>
> (2) A second focus would be on the Kenai content for one of the product
development areas. This script may be substantially different.
>
> -> This becomes part of the openoffice.apache.org effort.
>
> (3) A third focus would be building the documentation area. If a wiki is
preferred then we should create a website page that provides good links.
>
> -> Jean and others have expressed wanting to have a reset here.
>
> (4) A fourth focus for the website migration is how to best integrate the
project's choices for Bugzilla or JIRA, user forums, and mailing lists.
>
> -> This becomes a focus on the site skeleton and internal navigation.
>
>
> I created a script here - ./trunk/tools/dev/fetch-all-web.sh to download
webcontent from the svn. Like the hg to svn work this process must be
repeatable by anyone who wants to run it.
>
> Regards,
> Dave
>
>>
>>
>>> Cheers
>>> for now
>>>
>>> GL
>>>
>>>
>>>
>>>
>>>>
>>>> Regards,
>>>> Dave
>>>>
>>>>
>>>>>
>>>>> Argument could be made for the marketing material to start from
scratch.
>>>>> Personally I'd like to see a whole new branding and get shot of the
old
>>>>> stuff, make the first Apache release: V4.0 (Historically, significant
>>>>> global change has meant a whole number change in the version: V2 new
>>>>> codebase, V3 Apple compatibility. I think this is significant enough:
>>>>> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
>>>>> gives us a handle to hang a campaign on.
>>>>>
>>>>> Cheers
>>>>> GL
>>>>>
>>>>> --
>>>>> Graham Lauder,
>>>>> OpenOffice.org MarCon (Marketing Contact) NZ
>>>>> http://marketing.openoffice.org/contacts.html
>>>>>
>>>>> OpenOffice.org Migration and training Consultant.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 5, 2011, at 10:33 AM, Rob Weir wrote:
> On Tue, Jul 5, 2011 at 5:04 AM, Graham Lauder <g....@gmail.com> wrote:
>> On Sun, 2011-07-03 at 10:23 -0700, Dave Fisher wrote:
>>> On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote:
>>
>>
>>>>
>>>> Much of what is on there is legacy material that could be seriously
>>>> pruned. For instance all the old Marketing material that is V2.0 and
>>>> earlier could be deleted.
>>>
>>> What would you do to the main openoffice.org site if you were starting from scratch?
>>
>> Big question, moving to Apache has one big advantage from my POV.
>> (I should point out that my POV is marketing centric and is End User
>> focussed rather than developer focussed.)
>>
>> With the content going onto CMS it makes it a lot easier for marketing
>> content to be updated and changed as required. The Collabnet setup was
>> difficult.
>>
>> The OOo web presence is huge, not just the website itself but all the
>> NLC projects, the services part, maillists, forums, downloads and so on.
>> Each fragment is looked after by it's own team. There are overlaps (ie:
>> Distribution and CDROM) and global projects (Renaissance, art, UX) each
>> piece has it's user base and it's client base and so the website as an
>> entirety, obviously has to reflect that.
>>
>
> Yes, there were a lot of teams. Everyone seemed to have an official
> project title, often several ;-)
>
> We had some earlier discussions on this. Personally, I was proposing
> that we take the opportunity to simplify. For example, right now
> we're doing all the work on ooo-dev. At some point it will be clear,
> perhaps soon, that we need an ooo-user list. And maybe a few others.
> But I'd resist the urge to recreate the byzantine complexity of OOo
> until we're sure that we need it. I'm hoping we never do.
If you read my initial email in this thread you will know that is where it started. Keeping the list to the 6 basic categories which I noted paralleled your Project Plan layout though not exactly.
>
>
>> The home page as it is now was designed originally with one overriding
>> goal: "increase downloads."
>>
>
> Do you think this should still be the overriding goal of the homepage?
>
>> Therefore we had to analyse our catchment, identify our user groups and
>> their specific needs and patterns of usage of the Website. We then
>> needed to specifically identify the Home page users and their needs. It
>> should be noted that while there is a crossover, Homepage users are a
>> different set to Website users. Regular community members tend to
>> bypass the homepage because they know where they can fulfil their needs
>> already, they either go straight to the wiki or the forums or docs or
>> whichever part is specific to their part of the community.
>>
>> IMS We identified 5 groups that visit the Homepage.
>>
>> Casual arrivals
>> People seeking a download, either for the first time or to upgrade
>> Users seeking assistance
>> People wishing to contribute to the community
>> Developers
He said they did an analysis. From my own experience the Home page is the hardest page in the whole site to design.
For the new openoffice.org I would keep these key - dynamic buttons. The top bar and right news sections are another story - the page frame story which needs to be integrated with the openoffice.apache.org site.
>>
>
> What is a "casual arrival"? Is that someone arriving via a search?
>
>
> Have you ever seen any traffic reports for Openoffice.org? Or
> something like Google Analytics, that would show how the web site is
> being used currently?
>
>
>> Each of these groups have entirely different needs. The original home
>> page tried to cater for all these different groups and ended up doing it
>> badly. My intention for the homepage was to have each of these groups
>> headed to wherever they needed to be on the website within 15 seconds.
>> We did that by reducing the number of decisions and introducing the
>> "Action Statements". (There were over 120 links on the original homepage
>> we reduced them to about 15, not including those in the news column.)
>>
>> Did it achieve More Downloads? as far as I know, yes. Louis would be
>> better informed on this. A lot of debate went on with regard to the
>> concept of the "Action Statements", over many months, but once the web
>> team were onside the results were, to my eyes, spectacular.
>>
>> (Just for amusements sake
>> http://wiki.services.openoffice.org/mwiki/images/a/a3/Home_page_draft_11-27.jpg was my first rather amateurish mockup which the website team, Maarten, Kay, Ivan and others turned into http://www.openoffice.org .)
It is important to note who has contributed to this process.
>>
>> So the homepage is simply a portal, a signpost that is geared to cater
>> to the Unsophisticated End User. These people require simplicity,
>> continuity and a feeling of security and it is only this group that the
>> warmth and comfort of http://www.openoffice.org would be significant or
>> necessary.
>>
>> So, keep the home page as is or find someway to get the CMS to display
>> it, action statements intact at least.
>>
>> Then to my mind the only subs to the OOo domain that I would think that
>> would be compulsory would be:
>> support.openoffice.org
>> Why.openoffice.org and
>> download.openoffice.org
>>
>> and the NLC subdomains
>>
>> The rest of the website could happily exist under OpenOffice.apache.org.
>>
>
> This is close to what I was proposing. Move the project-centric
> services and content, the stuff that project volunteers access most,
> to the Apache address. But keep OpenOffice.org as the public-facing,
> user-facing portal for the product.
This is what I hoped would be proposed.
If you look in an earlier message I proposed a strategy:
(1) An initial test could focus on the current main page in English followed by versions in several languages. This will need to script the conversion of existing webcontent from Kenai into format for the Apache CMS.
-> This becomes the openoffice.org effort.
(2) A second focus would be on the Kenai content for one of the product development areas. This script may be substantially different.
-> This becomes part of the openoffice.apache.org effort.
(3) A third focus would be building the documentation area. If a wiki is preferred then we should create a website page that provides good links.
-> Jean and others have expressed wanting to have a reset here.
(4) A fourth focus for the website migration is how to best integrate the project's choices for Bugzilla or JIRA, user forums, and mailing lists.
-> This becomes a focus on the site skeleton and internal navigation.
I created a script here - ./trunk/tools/dev/fetch-all-web.sh to download webcontent from the svn. Like the hg to svn work this process must be repeatable by anyone who wants to run it.
Regards,
Dave
>
>
>> Cheers
>> for now
>>
>> GL
>>
>>
>>
>>
>>>
>>> Regards,
>>> Dave
>>>
>>>
>>>>
>>>> Argument could be made for the marketing material to start from scratch.
>>>> Personally I'd like to see a whole new branding and get shot of the old
>>>> stuff, make the first Apache release: V4.0 (Historically, significant
>>>> global change has meant a whole number change in the version: V2 new
>>>> codebase, V3 Apple compatibility. I think this is significant enough:
>>>> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
>>>> gives us a handle to hang a campaign on.
>>>>
>>>> Cheers
>>>> GL
>>>>
>>>> --
>>>> Graham Lauder,
>>>> OpenOffice.org MarCon (Marketing Contact) NZ
>>>> http://marketing.openoffice.org/contacts.html
>>>>
>>>> OpenOffice.org Migration and training Consultant.
>>>>
>>>>
>>>>
>>>
>>
>>
>>
Re: Website Content plus Look and Feel Improvements
Posted by Rob Weir <ap...@robweir.com>.
On Tue, Jul 5, 2011 at 5:04 AM, Graham Lauder <g....@gmail.com> wrote:
> On Sun, 2011-07-03 at 10:23 -0700, Dave Fisher wrote:
>> On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote:
>
>
>> >
>> > Much of what is on there is legacy material that could be seriously
>> > pruned. For instance all the old Marketing material that is V2.0 and
>> > earlier could be deleted.
>>
>> What would you do to the main openoffice.org site if you were starting from scratch?
>
> Big question, moving to Apache has one big advantage from my POV.
> (I should point out that my POV is marketing centric and is End User
> focussed rather than developer focussed.)
>
> With the content going onto CMS it makes it a lot easier for marketing
> content to be updated and changed as required. The Collabnet setup was
> difficult.
>
> The OOo web presence is huge, not just the website itself but all the
> NLC projects, the services part, maillists, forums, downloads and so on.
> Each fragment is looked after by it's own team. There are overlaps (ie:
> Distribution and CDROM) and global projects (Renaissance, art, UX) each
> piece has it's user base and it's client base and so the website as an
> entirety, obviously has to reflect that.
>
Yes, there were a lot of teams. Everyone seemed to have an official
project title, often several ;-)
We had some earlier discussions on this. Personally, I was proposing
that we take the opportunity to simplify. For example, right now
we're doing all the work on ooo-dev. At some point it will be clear,
perhaps soon, that we need an ooo-user list. And maybe a few others.
But I'd resist the urge to recreate the byzantine complexity of OOo
until we're sure that we need it. I'm hoping we never do.
> The home page as it is now was designed originally with one overriding
> goal: "increase downloads."
>
Do you think this should still be the overriding goal of the homepage?
> Therefore we had to analyse our catchment, identify our user groups and
> their specific needs and patterns of usage of the Website. We then
> needed to specifically identify the Home page users and their needs. It
> should be noted that while there is a crossover, Homepage users are a
> different set to Website users. Regular community members tend to
> bypass the homepage because they know where they can fulfil their needs
> already, they either go straight to the wiki or the forums or docs or
> whichever part is specific to their part of the community.
>
> IMS We identified 5 groups that visit the Homepage.
>
> Casual arrivals
> People seeking a download, either for the first time or to upgrade
> Users seeking assistance
> People wishing to contribute to the community
> Developers
>
What is a "casual arrival"? Is that someone arriving via a search?
Have you ever seen any traffic reports for Openoffice.org? Or
something like Google Analytics, that would show how the web site is
being used currently?
> Each of these groups have entirely different needs. The original home
> page tried to cater for all these different groups and ended up doing it
> badly. My intention for the homepage was to have each of these groups
> headed to wherever they needed to be on the website within 15 seconds.
> We did that by reducing the number of decisions and introducing the
> "Action Statements". (There were over 120 links on the original homepage
> we reduced them to about 15, not including those in the news column.)
>
> Did it achieve More Downloads? as far as I know, yes. Louis would be
> better informed on this. A lot of debate went on with regard to the
> concept of the "Action Statements", over many months, but once the web
> team were onside the results were, to my eyes, spectacular.
>
> (Just for amusements sake
> http://wiki.services.openoffice.org/mwiki/images/a/a3/Home_page_draft_11-27.jpg was my first rather amateurish mockup which the website team, Maarten, Kay, Ivan and others turned into http://www.openoffice.org .)
>
> So the homepage is simply a portal, a signpost that is geared to cater
> to the Unsophisticated End User. These people require simplicity,
> continuity and a feeling of security and it is only this group that the
> warmth and comfort of http://www.openoffice.org would be significant or
> necessary.
>
> So, keep the home page as is or find someway to get the CMS to display
> it, action statements intact at least.
>
> Then to my mind the only subs to the OOo domain that I would think that
> would be compulsory would be:
> support.openoffice.org
> Why.openoffice.org and
> download.openoffice.org
>
> and the NLC subdomains
>
> The rest of the website could happily exist under OpenOffice.apache.org.
>
This is close to what I was proposing. Move the project-centric
services and content, the stuff that project volunteers access most,
to the Apache address. But keep OpenOffice.org as the public-facing,
user-facing portal for the product.
> Cheers
> for now
>
> GL
>
>
>
>
>>
>> Regards,
>> Dave
>>
>>
>> >
>> > Argument could be made for the marketing material to start from scratch.
>> > Personally I'd like to see a whole new branding and get shot of the old
>> > stuff, make the first Apache release: V4.0 (Historically, significant
>> > global change has meant a whole number change in the version: V2 new
>> > codebase, V3 Apple compatibility. I think this is significant enough:
>> > pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
>> > gives us a handle to hang a campaign on.
>> >
>> > Cheers
>> > GL
>> >
>> > --
>> > Graham Lauder,
>> > OpenOffice.org MarCon (Marketing Contact) NZ
>> > http://marketing.openoffice.org/contacts.html
>> >
>> > OpenOffice.org Migration and training Consultant.
>> >
>> >
>> >
>>
>
>
>
Re: Website Content plus Look and Feel Improvements
Posted by Graham Lauder <g....@gmail.com>.
On Sun, 2011-07-03 at 10:23 -0700, Dave Fisher wrote:
> On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote:
> >
> > Much of what is on there is legacy material that could be seriously
> > pruned. For instance all the old Marketing material that is V2.0 and
> > earlier could be deleted.
>
> What would you do to the main openoffice.org site if you were starting from scratch?
Big question, moving to Apache has one big advantage from my POV.
(I should point out that my POV is marketing centric and is End User
focussed rather than developer focussed.)
With the content going onto CMS it makes it a lot easier for marketing
content to be updated and changed as required. The Collabnet setup was
difficult.
The OOo web presence is huge, not just the website itself but all the
NLC projects, the services part, maillists, forums, downloads and so on.
Each fragment is looked after by it's own team. There are overlaps (ie:
Distribution and CDROM) and global projects (Renaissance, art, UX) each
piece has it's user base and it's client base and so the website as an
entirety, obviously has to reflect that.
The home page as it is now was designed originally with one overriding
goal: "increase downloads."
Therefore we had to analyse our catchment, identify our user groups and
their specific needs and patterns of usage of the Website. We then
needed to specifically identify the Home page users and their needs. It
should be noted that while there is a crossover, Homepage users are a
different set to Website users. Regular community members tend to
bypass the homepage because they know where they can fulfil their needs
already, they either go straight to the wiki or the forums or docs or
whichever part is specific to their part of the community.
IMS We identified 5 groups that visit the Homepage.
Casual arrivals
People seeking a download, either for the first time or to upgrade
Users seeking assistance
People wishing to contribute to the community
Developers
Each of these groups have entirely different needs. The original home
page tried to cater for all these different groups and ended up doing it
badly. My intention for the homepage was to have each of these groups
headed to wherever they needed to be on the website within 15 seconds.
We did that by reducing the number of decisions and introducing the
"Action Statements". (There were over 120 links on the original homepage
we reduced them to about 15, not including those in the news column.)
Did it achieve More Downloads? as far as I know, yes. Louis would be
better informed on this. A lot of debate went on with regard to the
concept of the "Action Statements", over many months, but once the web
team were onside the results were, to my eyes, spectacular.
(Just for amusements sake
http://wiki.services.openoffice.org/mwiki/images/a/a3/Home_page_draft_11-27.jpg was my first rather amateurish mockup which the website team, Maarten, Kay, Ivan and others turned into http://www.openoffice.org .)
So the homepage is simply a portal, a signpost that is geared to cater
to the Unsophisticated End User. These people require simplicity,
continuity and a feeling of security and it is only this group that the
warmth and comfort of http://www.openoffice.org would be significant or
necessary.
So, keep the home page as is or find someway to get the CMS to display
it, action statements intact at least.
Then to my mind the only subs to the OOo domain that I would think that
would be compulsory would be:
support.openoffice.org
Why.openoffice.org and
download.openoffice.org
and the NLC subdomains
The rest of the website could happily exist under OpenOffice.apache.org.
Cheers
for now
GL
>
> Regards,
> Dave
>
>
> >
> > Argument could be made for the marketing material to start from scratch.
> > Personally I'd like to see a whole new branding and get shot of the old
> > stuff, make the first Apache release: V4.0 (Historically, significant
> > global change has meant a whole number change in the version: V2 new
> > codebase, V3 Apple compatibility. I think this is significant enough:
> > pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
> > gives us a handle to hang a campaign on.
> >
> > Cheers
> > GL
> >
> > --
> > Graham Lauder,
> > OpenOffice.org MarCon (Marketing Contact) NZ
> > http://marketing.openoffice.org/contacts.html
> >
> > OpenOffice.org Migration and training Consultant.
> >
> >
> >
>
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote:
> On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:
>> Yesterday I got tired of the look of people.mdtext in the project site. It was so 1990s. So, I've improved the look via css and adding defined widths. I guess I am volunteering for the item on https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted
>>
>> Several of us have been surveying the existing openoffice.org website on several wiki pages mostly linked to from:
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan
>>
>> With over 140 "projects" in openoffice.org, it will be important to agree to a mapping which reduces the granularity by more than an order of magnitude. The page http://projects.openoffice.org/ is a good and clear way to start - and pretty much fits the structure on https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning
>>
>> • Product Development
>> • Extension Development
>> • Language Support
>> • Helping Users
>> • Distribution
>> • Promotion
>>
>> I think that these groupings will help us easily have a rule about which projects end up on http://openoffice.apache.org/ or stay on the successor http://*.openoffice.org/.
>>
>> Projects have "webcontent" and/or "wiki" content. On openoffice.org there is a generally consistent look. There are exceptions which are marketing sites like http://why.openoffice.org/. The difference is glaring because that is the first big button on the main site.
>
> The why.openoffice.org page was done as a marketing tool independently
> of the main website and the Website team under the marketing project by
> one of the members of the marketing team and for a specific marketing
> campaign. Andre's design was so good we left it as is, however there
> had been intention to change it suit the overall look but volunteer time
> availability to do it was lacking. It still served a purpose as a very
> useful marketing resource so pulling it down just because of a
> non-standard look was never an option.
Understood, thanks for the detail. It is a nice and tight presentation.
>> Webcontent is available via svn - "svn co https://svn.openoffice.org/svn/${project}~webcontent ${project}" (Thanks Marcus Lange)
>>
>> Some projects are huge and others small. I downloaded several:
>>
>> wave@minotaur:~/ooo-test$ ls -1
>> development
>> documentation
>> download
>> projects
>> www
>>
>> The size is 2.7GB.
>>
>> It would be good to come up with a scripted way to convert existing webcontent to either mdtext, an altered html, or specialized javascript and css. It is likely we can adapt the content and use the Apache CMS to wrap a standard skeleton.
>>
>> Regards, Dave
>>
>
>
> Much of what is on there is legacy material that could be seriously
> pruned. For instance all the old Marketing material that is V2.0 and
> earlier could be deleted.
What would you do to the main openoffice.org site if you were starting from scratch?
Regards,
Dave
>
> Argument could be made for the marketing material to start from scratch.
> Personally I'd like to see a whole new branding and get shot of the old
> stuff, make the first Apache release: V4.0 (Historically, significant
> global change has meant a whole number change in the version: V2 new
> codebase, V3 Apple compatibility. I think this is significant enough:
> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
> gives us a handle to hang a campaign on.
>
> Cheers
> GL
>
> --
> Graham Lauder,
> OpenOffice.org MarCon (Marketing Contact) NZ
> http://marketing.openoffice.org/contacts.html
>
> OpenOffice.org Migration and training Consultant.
>
>
>
Re: Website Content plus Look and Feel Improvements
Posted by Kay Schenk <ka...@gmail.com>.
On 07/03/2011 01:56 AM, Marcus (OOo) wrote:
> Am 07/03/2011 07:43 AM, schrieb C:
>> On Sun, Jul 3, 2011 at 06:29, Graham Lauder<yo...@openoffice.org>
>> wrote:
>>> On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:
>>>> Some projects are huge and others small. I downloaded several:
>>>>
>>>> wave@minotaur:~/ooo-test$ ls -1
>>>> development
>>>> documentation
>>>> download
>>>> projects
>>>> www
>>>>
>>>> The size is 2.7GB.
>>>>
>>>> It would be good to come up with a scripted way to convert existing
>>>> webcontent to either mdtext, an altered html, or specialized
>>>> javascript and css. It is likely we can adapt the content and use
>>>> the Apache CMS to wrap a standard skeleton.
>>>>
>>>> Regards, Dave
>>>>
>>>
>>>
>>> Much of what is on there is legacy material that could be seriously
>>> pruned. For instance all the old Marketing material that is V2.0 and
>>> earlier could be deleted.
>>>
>>> Argument could be made for the marketing material to start from scratch.
>>> Personally I'd like to see a whole new branding and get shot of the old
>>> stuff, make the first Apache release: V4.0 (Historically, significant
>>> global change has meant a whole number change in the version: V2 new
>>> codebase, V3 Apple compatibility. I think this is significant enough:
>>> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
>>> gives us a handle to hang a campaign on.
>>
>> The majority of the documentation project content is not really stored
>> in the stuff that was downloaded in this test. What you find in the
>> web-content side is pretty much just pointers to the Wiki plus a few
>> files here and there that are not in the Wiki.
>>
>> I would much more prefer that when the time comes to migrate content
>> of the documentation directory, that I simply tag which files are to
>> be transferred and the rest are pruned. I have spent time cleaning up
>> what's there, but there are still 10 years of legacy things still
>> laying about, not used anymore.... stuff that should not be copied
>> over.
>
> I know that many things are simply outdated and could be deleted easily
> without loosing value. However, when we grab the content from the Oracle
> server, look into the content, and then decide if to take over and
> publish or modify or delete, then we we have much to do and a longer
> time no real content on our websites.
>
> So, I would prefer to take over all content and make it public *) . Then
> we can go through the content and add/modify/delete/whatever part-by-part.
yes! exactly...investigating ALL this now will take WAY too long.
>
> *) After the license problems are solved.
>
> My 2 ct
>
> Marcus
--
------------------------------------------------------------------------
MzK
"He's got that New Orleans thing crawling all over him, that good stuff,
that 'We Are the Champions', to hell with the rest and
I'll just start over kind of attitude."
-- "1 Dead in the Attic", Chris Rose
Re: IDL Generation and MediaWiki [Was Re: Website Content plus Look
and Feel Improvements]
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On Tue, Jul 5, 2011 at 8:04 PM, Dave Fisher <da...@comcast.net> wrote:
> Hi Clayton,
>
> I am separating into two sub-topics:
>
> (1) IDL Generation.
>
> Thanks for the link to what the Wiki uses to create a short hand for
> various IDL links. This points out a very important topic that needs to be
> co-ordinated. How do those the IDL Pages get generated. This needs to be
> co-ordinated with the build.
>
the IDL documentation is generated from the IDL sources during the normal
build process as part of the SDK build process. The generated docu is part
of the SDK and i have updated the online version with every new release. The
cross references from the wiki into the generated IDL reference and vice
versa are a very useful and effective way to find the matching
documentation.
The IDL tags in the wiki (Developers Guide section) should be collected from
time to time (with a wiki bot, process is not really finished yet when i
remember it) and a generated list with tags referenced on wiki pages is used
as source for the IDL reference generation during the build. This way we can
guarantee a working links. The IDL tags are explained on the page that
Clayton have already referenced.
>
> Who knows about the "UNOIDL - that is, the Unified Network Object Interface
> Description Language compiler, which produces the content of api.oo.o, and
> the input files."?
>
it's me ;-) and i think i have explained it above
Juergen
>
> (2) MediaWiki vs. Confluence vs. MoinMoin vs. Apache CMS
>
> There are several issues.
>
> (a) A MediaWiki at AOOo is the easiest solution for the project -
> short-term - most of the work is export/import.
>
> (b) A MediaWiki is not currently supported by Apache Infrastructure.
> MediaWiki Infra would need to be built.
>
> (c) There are a number of special extensions being used in MediaWIki with
> developers here who can support it.
>
> (d) For Confluence extensions / emulating the extensions that MW uses will
> be a learning curve.
>
> (e) Export requires co-operation with current OOo wiki admins. Confluence
> may require more.
>
> If a MediaWiki is what people want then we'll need to have several people
> who will be dedicated to helping Infrastructure support it. Please join the
> infrastructure-dev list and ask. Please share your contacts with the
> MediaWiki admins here so that others who may want to explore the convertor
> can make progress. If we have enough volunteers we can start on both and
> abandon one if one becomes clearly better.
>
> Regards,
> Dave
>
> On Jul 5, 2011, at 9:13 AM, C wrote:
>
> > On Sun, Jul 3, 2011 at 21:16, Dave Fisher <da...@comcast.net> wrote:
> >> On Jul 3, 2011, at 11:16 AM, C wrote:
> >>> - PDF and ODT export. Confluence can do PDF, but cannot do ODT..
> >>> only MS Word DOC format (a significant issue in my view for an OOo
> >>> Wiki... a bit sad and embarassing that we'd only be able to export a
> >>> proprietary document format, and not the primary doc format that OOo
> >>> is known for). Export to PDF and ODT is something a lot of people use
> >>> for the OOo Docs - especially the Basic and Developer's Guides.
> >>
> >> I understand the need for ODT export. Tell us about the MediaWiki
> extension that is being used, is it part of OOo or is it a third party
> extension?
> >
> > It's a MediaWiki extension, created by PediaPress -
> > http://www.mediawiki.org/wiki/Extension:Collection
> >
> >
> >>> - IDL Tags - custom (but simple) MW extension that creates links to
> >>> the IDL library
> >>
> >> Do you mean these links:
> >>
> >>
> http://api.openoffice.org/docs/common/ref/com/sun/star/awt/XTopWindowListener.html
> >>
> >> We will need to rewrite these anyway. Tell me how these are marked up in
> MediaWiki.
> >>
> >> Is the IDL reference generated from the source code? We'll need to get
> into that workflow too.
> >
> > The IDL Extension is all documented here - including the full source
> > of the extension itself, and how it's implemented/used within the Wiki
> > text:
> http://wiki.services.openoffice.org/wiki/Wiki_maintenance/IDLTagExtension
> >
> >
> >> No doubt this is a challenge in Confluence - it likes a flat hierarchy.
> >>
> >> If a MoinMoin Wiki is a better fit for conversion from MediaWiki we can
> certainly try it.
> >
> > I've never done a lot with MoinMoin, so can't really comment on that
> > one. The book-like hierarchy in the existing MediaWiki is created by
> > a combination of sub-pages and the TOC navigation. It is not really
> > the perfect implementation, but it works and keeps things at least
> > somewhat "book-like".... makes it possible to generate PDF books, and
> > provides a book-like navigation or flow through a topic. The other
> > choice, and something I experimented with, is huge monster long pages
> > with entire chapters in a single Wiki page. This is a nightmare to
> > try and edit and maintain.
> >
> >
> > C.
> > --
> > Clayton Cornell ccornell@openoffice.org
> > OpenOffice.org Documentation Project co-lead
>
>
Re: IDL Generation and MediaWiki [Was Re: Website Content plus Look
and Feel Improvements]
Posted by Rob Weir <ap...@robweir.com>.
On Tue, Jul 5, 2011 at 2:04 PM, Dave Fisher <da...@comcast.net> wrote:
> Hi Clayton,
>
> I am separating into two sub-topics:
>
> (1) IDL Generation.
>
> Thanks for the link to what the Wiki uses to create a short hand for various IDL links. This points out a very important topic that needs to be co-ordinated. How do those the IDL Pages get generated. This needs to be co-ordinated with the build.
>
> Who knows about the "UNOIDL - that is, the Unified Network Object Interface Description Language compiler, which produces the content of api.oo.o, and the input files."?
>
> (2) MediaWiki vs. Confluence vs. MoinMoin vs. Apache CMS
>
> There are several issues.
>
> (a) A MediaWiki at AOOo is the easiest solution for the project - short-term - most of the work is export/import.
>
> (b) A MediaWiki is not currently supported by Apache Infrastructure. MediaWiki Infra would need to be built.
>
> (c) There are a number of special extensions being used in MediaWIki with developers here who can support it.
>
> (d) For Confluence extensions / emulating the extensions that MW uses will be a learning curve.
>
> (e) Export requires co-operation with current OOo wiki admins. Confluence may require more.
>
Another factor is the preservation of external links, including deep
links into the OOo website. With MediaWiki we should be able to
preserve the URL's or at least allow a trivial rewrite rule for
redirections. With Confluence I think we would have a harder time.
> If a MediaWiki is what people want then we'll need to have several people who will be dedicated to helping Infrastructure support it. Please join the infrastructure-dev list and ask. Please share your contacts with the MediaWiki admins here so that others who may want to explore the convertor can make progress. If we have enough volunteers we can start on both and abandon one if one becomes clearly better.
>
> Regards,
> Dave
>
> On Jul 5, 2011, at 9:13 AM, C wrote:
>
>> On Sun, Jul 3, 2011 at 21:16, Dave Fisher <da...@comcast.net> wrote:
>>> On Jul 3, 2011, at 11:16 AM, C wrote:
>>>> - PDF and ODT export. Confluence can do PDF, but cannot do ODT..
>>>> only MS Word DOC format (a significant issue in my view for an OOo
>>>> Wiki... a bit sad and embarassing that we'd only be able to export a
>>>> proprietary document format, and not the primary doc format that OOo
>>>> is known for). Export to PDF and ODT is something a lot of people use
>>>> for the OOo Docs - especially the Basic and Developer's Guides.
>>>
>>> I understand the need for ODT export. Tell us about the MediaWiki extension that is being used, is it part of OOo or is it a third party extension?
>>
>> It's a MediaWiki extension, created by PediaPress -
>> http://www.mediawiki.org/wiki/Extension:Collection
>>
>>
>>>> - IDL Tags - custom (but simple) MW extension that creates links to
>>>> the IDL library
>>>
>>> Do you mean these links:
>>>
>>> http://api.openoffice.org/docs/common/ref/com/sun/star/awt/XTopWindowListener.html
>>>
>>> We will need to rewrite these anyway. Tell me how these are marked up in MediaWiki.
>>>
>>> Is the IDL reference generated from the source code? We'll need to get into that workflow too.
>>
>> The IDL Extension is all documented here - including the full source
>> of the extension itself, and how it's implemented/used within the Wiki
>> text: http://wiki.services.openoffice.org/wiki/Wiki_maintenance/IDLTagExtension
>>
>>
>>> No doubt this is a challenge in Confluence - it likes a flat hierarchy.
>>>
>>> If a MoinMoin Wiki is a better fit for conversion from MediaWiki we can certainly try it.
>>
>> I've never done a lot with MoinMoin, so can't really comment on that
>> one. The book-like hierarchy in the existing MediaWiki is created by
>> a combination of sub-pages and the TOC navigation. It is not really
>> the perfect implementation, but it works and keeps things at least
>> somewhat "book-like".... makes it possible to generate PDF books, and
>> provides a book-like navigation or flow through a topic. The other
>> choice, and something I experimented with, is huge monster long pages
>> with entire chapters in a single Wiki page. This is a nightmare to
>> try and edit and maintain.
>>
>>
>> C.
>> --
>> Clayton Cornell ccornell@openoffice.org
>> OpenOffice.org Documentation Project co-lead
>
>
IDL Generation and MediaWiki [Was Re: Website Content plus Look and Feel Improvements]
Posted by Dave Fisher <da...@comcast.net>.
Hi Clayton,
I am separating into two sub-topics:
(1) IDL Generation.
Thanks for the link to what the Wiki uses to create a short hand for various IDL links. This points out a very important topic that needs to be co-ordinated. How do those the IDL Pages get generated. This needs to be co-ordinated with the build.
Who knows about the "UNOIDL - that is, the Unified Network Object Interface Description Language compiler, which produces the content of api.oo.o, and the input files."?
(2) MediaWiki vs. Confluence vs. MoinMoin vs. Apache CMS
There are several issues.
(a) A MediaWiki at AOOo is the easiest solution for the project - short-term - most of the work is export/import.
(b) A MediaWiki is not currently supported by Apache Infrastructure. MediaWiki Infra would need to be built.
(c) There are a number of special extensions being used in MediaWIki with developers here who can support it.
(d) For Confluence extensions / emulating the extensions that MW uses will be a learning curve.
(e) Export requires co-operation with current OOo wiki admins. Confluence may require more.
If a MediaWiki is what people want then we'll need to have several people who will be dedicated to helping Infrastructure support it. Please join the infrastructure-dev list and ask. Please share your contacts with the MediaWiki admins here so that others who may want to explore the convertor can make progress. If we have enough volunteers we can start on both and abandon one if one becomes clearly better.
Regards,
Dave
On Jul 5, 2011, at 9:13 AM, C wrote:
> On Sun, Jul 3, 2011 at 21:16, Dave Fisher <da...@comcast.net> wrote:
>> On Jul 3, 2011, at 11:16 AM, C wrote:
>>> - PDF and ODT export. Confluence can do PDF, but cannot do ODT..
>>> only MS Word DOC format (a significant issue in my view for an OOo
>>> Wiki... a bit sad and embarassing that we'd only be able to export a
>>> proprietary document format, and not the primary doc format that OOo
>>> is known for). Export to PDF and ODT is something a lot of people use
>>> for the OOo Docs - especially the Basic and Developer's Guides.
>>
>> I understand the need for ODT export. Tell us about the MediaWiki extension that is being used, is it part of OOo or is it a third party extension?
>
> It's a MediaWiki extension, created by PediaPress -
> http://www.mediawiki.org/wiki/Extension:Collection
>
>
>>> - IDL Tags - custom (but simple) MW extension that creates links to
>>> the IDL library
>>
>> Do you mean these links:
>>
>> http://api.openoffice.org/docs/common/ref/com/sun/star/awt/XTopWindowListener.html
>>
>> We will need to rewrite these anyway. Tell me how these are marked up in MediaWiki.
>>
>> Is the IDL reference generated from the source code? We'll need to get into that workflow too.
>
> The IDL Extension is all documented here - including the full source
> of the extension itself, and how it's implemented/used within the Wiki
> text: http://wiki.services.openoffice.org/wiki/Wiki_maintenance/IDLTagExtension
>
>
>> No doubt this is a challenge in Confluence - it likes a flat hierarchy.
>>
>> If a MoinMoin Wiki is a better fit for conversion from MediaWiki we can certainly try it.
>
> I've never done a lot with MoinMoin, so can't really comment on that
> one. The book-like hierarchy in the existing MediaWiki is created by
> a combination of sub-pages and the TOC navigation. It is not really
> the perfect implementation, but it works and keeps things at least
> somewhat "book-like".... makes it possible to generate PDF books, and
> provides a book-like navigation or flow through a topic. The other
> choice, and something I experimented with, is huge monster long pages
> with entire chapters in a single Wiki page. This is a nightmare to
> try and edit and maintain.
>
>
> C.
> --
> Clayton Cornell ccornell@openoffice.org
> OpenOffice.org Documentation Project co-lead
Re: Website Content plus Look and Feel Improvements
Posted by C <sm...@gmail.com>.
On Sun, Jul 3, 2011 at 21:16, Dave Fisher <da...@comcast.net> wrote:
> On Jul 3, 2011, at 11:16 AM, C wrote:
>> - PDF and ODT export. Confluence can do PDF, but cannot do ODT..
>> only MS Word DOC format (a significant issue in my view for an OOo
>> Wiki... a bit sad and embarassing that we'd only be able to export a
>> proprietary document format, and not the primary doc format that OOo
>> is known for). Export to PDF and ODT is something a lot of people use
>> for the OOo Docs - especially the Basic and Developer's Guides.
>
> I understand the need for ODT export. Tell us about the MediaWiki extension that is being used, is it part of OOo or is it a third party extension?
It's a MediaWiki extension, created by PediaPress -
http://www.mediawiki.org/wiki/Extension:Collection
>> - IDL Tags - custom (but simple) MW extension that creates links to
>> the IDL library
>
> Do you mean these links:
>
> http://api.openoffice.org/docs/common/ref/com/sun/star/awt/XTopWindowListener.html
>
> We will need to rewrite these anyway. Tell me how these are marked up in MediaWiki.
>
> Is the IDL reference generated from the source code? We'll need to get into that workflow too.
The IDL Extension is all documented here - including the full source
of the extension itself, and how it's implemented/used within the Wiki
text: http://wiki.services.openoffice.org/wiki/Wiki_maintenance/IDLTagExtension
> No doubt this is a challenge in Confluence - it likes a flat hierarchy.
>
> If a MoinMoin Wiki is a better fit for conversion from MediaWiki we can certainly try it.
I've never done a lot with MoinMoin, so can't really comment on that
one. The book-like hierarchy in the existing MediaWiki is created by
a combination of sub-pages and the TOC navigation. It is not really
the perfect implementation, but it works and keeps things at least
somewhat "book-like".... makes it possible to generate PDF books, and
provides a book-like navigation or flow through a topic. The other
choice, and something I experimented with, is huge monster long pages
with entire chapters in a single Wiki page. This is a nightmare to
try and edit and maintain.
C.
--
Clayton Cornell ccornell@openoffice.org
OpenOffice.org Documentation Project co-lead
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 3, 2011, at 11:16 AM, C wrote:
> On Sun, Jul 3, 2011 at 18:53, Dave Fisher <da...@comcast.net> wrote:
>>> The short of it is.. I'll help move the MediaWiki to a new server on
>>> the Apache side (if the decision is made to do this), but I'm not
>>> interested in moving the content to Confluence (if this is the final
>>> decision).
>>
>> Please provide a few concrete examples of the thousands of pages that will need to be reworked. What features of MediaWiki are required and what is the purpose. Give me some of the gory details.
>>
>> The bar is much higher to add to Apache Infrastructure. It must be proven to Infrastructure that we have enough volunteers that can administer the service. Confluence is already present, as is the Apache CMS.
>>
>> We have individuals with scripting abilities. If the wiki re-work is mechanical then we can script it.
>>
>> Regards,
>> Dave
>
>
> A few example items... the existing/legacy MediaWiki instance is using
> several creative tweaks such as (not an exhaustive list.. just a few):
>
> - PDF and ODT export. Confluence can do PDF, but cannot do ODT..
> only MS Word DOC format (a significant issue in my view for an OOo
> Wiki... a bit sad and embarassing that we'd only be able to export a
> proprietary document format, and not the primary doc format that OOo
> is known for). Export to PDF and ODT is something a lot of people use
> for the OOo Docs - especially the Basic and Developer's Guides.
I understand the need for ODT export. Tell us about the MediaWiki extension that is being used, is it part of OOo or is it a third party extension?
BTW - confluence uses an intermediate html format in its conversion to PDF. Perhaps that is something that AOOo could provide as an extension to confluence.
Or, maybe as part of an Apache CMS publishing and we can then contribute the facility to all of Apache.
> - Dynamic page lists - creates dynamic page set views of doc content.
> This is used for dynamically indexing the FAQs for example.
A similar effect is possible in both Confluence and Apache CMS.
> - IDL Tags - custom (but simple) MW extension that creates links to
> the IDL library
Do you mean these links:
http://api.openoffice.org/docs/common/ref/com/sun/star/awt/XTopWindowListener.html
We will need to rewrite these anyway. Tell me how these are marked up in MediaWiki.
Is the IDL reference generated from the source code? We'll need to get into that workflow too.
> As for the number of pages... start with the big one.. the Developer's
> Guide. http://wiki.services.openoffice.org/wiki/Category:Documentation/Developer%27s_Guide
> This doc alone is approximately 1000 Wiki pages (something close to
> that... I don't know the exact number off the top of my head... it's
> around 2000 A4 pages when printed out or converted to PDF/ODT). Like
> the other manuals in the existing/legacy OOo Wiki, it uses a
> combination of nested templates and various extensions to manage the
> subpages as a book. It has a detailed TOC and navigation tree, IDL
> linking, etc. This would all need to be stripped and adapted to
> convert to Confluence. Each page would need to land in the right
> place in the document hierarchy. Someone would need to write a
> Confluence macro or extension to handle the IDL tagging. All the
> MediaWiki tagging would need to be converted.... and then someone
> would need to wade through the document and double check that it's
> still in a logical correct order, and tidy up the little oopses.
No doubt this is a challenge in Confluence - it likes a flat hierarchy.
If a MoinMoin Wiki is a better fit for conversion from MediaWiki we can certainly try it.
I am really for a scripted conversion no matter how we do it. We can test it on parts, make sure it fits everyone's needs, I expect this to be iterative and repeatable.
> Add to the list, the Basic Guide, the Reference Lists, and the
> FAQs/HowTos, plus whatever Doc pages have been translated into
> Russian, French, Spanish, German etc etc, and you've got a whole lot
> of pages that need to be migrated, managed, validated, etc.
>
> I'm not saying it cannot be done... I am familiar with Confluence
> Wikis... I have a fair idea what you can do in them. I also have a
> rough idea just how much work will need to be done to get the Wiki
> docs migrated to Confluence.
Each option does present challenges.
> Frank Peters also raised this point a couple of weeks ago... so I'm
> not the only one raising a little white flag and saying this part of
> the website migration is not going to be as easy as migrating basic MW
> content. :-)
>
> One other minor point... licensing shouldn't be a barrier for these
> Doc Wiki pages regardless of what is done with them... all of the
> Documentation subpages are either CC-By or PDL (or both). If a Doc
> Wiki page isn't clearly licensed, then it doesn't belong, or needs to
> be corrected.
License due diligence is a key factor. Every page is going to need to be visible and checked by PPMC members. This part of our duty for due diligence. ASF Legal Affairs may have an opinion.
Regards,
Dave
>
>
> C.
> --
> Clayton Cornell ccornell@openoffice.org
> OpenOffice.org Documentation Project co-lead
Re: Website Content plus Look and Feel Improvements
Posted by Jean Hollis Weber <je...@gmail.com>.
On Sun, 2011-07-03 at 16:08 -0700, Dave Fisher wrote:
> On Jul 3, 2011, at 2:14 PM, Jean Weber wrote:
>
> > On Mon, Jul 4, 2011 at 04:16, C <sm...@gmail.com> wrote:
> >> On Sun, Jul 3, 2011 at 18:53, Dave Fisher <da...@comcast.net> wrote:
> >>
> >> A few example items... the existing/legacy MediaWiki instance is using
> >> several creative tweaks such as (not an exhaustive list.. just a few):
> >>
> >> - PDF and ODT export. Confluence can do PDF, but cannot do ODT..
> >> only MS Word DOC format (a significant issue in my view for an OOo Wiki...
> >
> > Even worse, AFAICT Confluence cannot export more than one wiki page at
> > a time to MS Word DOC format, which would make compiling a whole book
> > in that format a lot more difficult.
>
> It is very cumbersome, but it is possible to export all or part of a space to PDF in Confluence - The function is found on the Advanced page.
PDFs exported from a wiki may be convenient for individuals wanting a
copy of info but not concerned about its appearance. They are not of an
acceptable quality for publishing as a book, particularly if they
contain images -- or at least I have never seen one that was acceptable,
by which I mean looking like a reasonably professional publication.
We (people producing user guides) need to be able to get editable
documents that can be massaged into an acceptable form before exporting
to PDF. Indeed, that is one of the major reasons why we want the user
guides to be maintained in ODT, not wiki form.
> >
> >> Export to PDF and ODT is something a lot of people use
> >> for the OOo Docs - especially the Basic and Developer's Guides.
> >> [...]
> >>
Those are the books maintained on the wiki, with input from the
developers. They don't have many images. Getting a reasonable result
from the export is still challenging, but Clayton (and whoever else has
worked on this) has done a heroic job creating templates for export from
MediaWiki.
--Jean
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 3, 2011, at 2:14 PM, Jean Weber wrote:
> On Mon, Jul 4, 2011 at 04:16, C <sm...@gmail.com> wrote:
>> On Sun, Jul 3, 2011 at 18:53, Dave Fisher <da...@comcast.net> wrote:
>>
>> A few example items... the existing/legacy MediaWiki instance is using
>> several creative tweaks such as (not an exhaustive list.. just a few):
>>
>> - PDF and ODT export. Confluence can do PDF, but cannot do ODT..
>> only MS Word DOC format (a significant issue in my view for an OOo Wiki...
>
> Even worse, AFAICT Confluence cannot export more than one wiki page at
> a time to MS Word DOC format, which would make compiling a whole book
> in that format a lot more difficult.
It is very cumbersome, but it is possible to export all or part of a space to PDF in Confluence - The function is found on the Advanced page.
>
>> Export to PDF and ODT is something a lot of people use
>> for the OOo Docs - especially the Basic and Developer's Guides.
>> [...]
>> As for the number of pages... start with the big one.. the Developer's
>> Guide. This doc alone is approximately 1000 Wiki pages ... Like
>> the other manuals in the existing/legacy OOo Wiki, it uses a
>> combination of nested templates and various extensions to manage the
>> subpages as a book.
>>
>> Add to the list, the Basic Guide, the Reference Lists, and the
>> FAQs/HowTos, plus whatever Doc pages have been translated into
>> Russian, French, Spanish, German etc etc, and you've got a whole lot
>> of pages that need to be migrated, managed, validated, etc.
>
> Also all the user guides that are in wiki format contribute a lot of
> pages. Some of those can (and probably should) be dropped (anything
> for OOo 2.x, for example) but that may not make a significant dent in
> the total. We could keep the PDFs and ODTs for the v2.x guides for
> historical archives, but dump the wiki pages.
Good.
Regards,
Dave
>
>>
>> Frank Peters also raised this point a couple of weeks ago... so I'm
>> not the only one raising a little white flag and saying this part of
>> the website migration is not going to be as easy as migrating basic MW
>> content. :-)
>
> --Jean
> Jean Hollis Weber
> Co-Lead, OpenOffice.org Documentation Project
Re: Website Content plus Look and Feel Improvements
Posted by Jean Weber <je...@gmail.com>.
On Mon, Jul 4, 2011 at 04:16, C <sm...@gmail.com> wrote:
> On Sun, Jul 3, 2011 at 18:53, Dave Fisher <da...@comcast.net> wrote:
>
> A few example items... the existing/legacy MediaWiki instance is using
> several creative tweaks such as (not an exhaustive list.. just a few):
>
> - PDF and ODT export. Confluence can do PDF, but cannot do ODT..
> only MS Word DOC format (a significant issue in my view for an OOo Wiki...
Even worse, AFAICT Confluence cannot export more than one wiki page at
a time to MS Word DOC format, which would make compiling a whole book
in that format a lot more difficult.
> Export to PDF and ODT is something a lot of people use
> for the OOo Docs - especially the Basic and Developer's Guides.
> [...]
> As for the number of pages... start with the big one.. the Developer's
> Guide. This doc alone is approximately 1000 Wiki pages ... Like
> the other manuals in the existing/legacy OOo Wiki, it uses a
> combination of nested templates and various extensions to manage the
> subpages as a book.
>
> Add to the list, the Basic Guide, the Reference Lists, and the
> FAQs/HowTos, plus whatever Doc pages have been translated into
> Russian, French, Spanish, German etc etc, and you've got a whole lot
> of pages that need to be migrated, managed, validated, etc.
Also all the user guides that are in wiki format contribute a lot of
pages. Some of those can (and probably should) be dropped (anything
for OOo 2.x, for example) but that may not make a significant dent in
the total. We could keep the PDFs and ODTs for the v2.x guides for
historical archives, but dump the wiki pages.
>
> Frank Peters also raised this point a couple of weeks ago... so I'm
> not the only one raising a little white flag and saying this part of
> the website migration is not going to be as easy as migrating basic MW
> content. :-)
--Jean
Jean Hollis Weber
Co-Lead, OpenOffice.org Documentation Project
Re: Website Content plus Look and Feel Improvements
Posted by C <sm...@gmail.com>.
On Sun, Jul 3, 2011 at 18:53, Dave Fisher <da...@comcast.net> wrote:
>> The short of it is.. I'll help move the MediaWiki to a new server on
>> the Apache side (if the decision is made to do this), but I'm not
>> interested in moving the content to Confluence (if this is the final
>> decision).
>
> Please provide a few concrete examples of the thousands of pages that will need to be reworked. What features of MediaWiki are required and what is the purpose. Give me some of the gory details.
>
> The bar is much higher to add to Apache Infrastructure. It must be proven to Infrastructure that we have enough volunteers that can administer the service. Confluence is already present, as is the Apache CMS.
>
> We have individuals with scripting abilities. If the wiki re-work is mechanical then we can script it.
>
> Regards,
> Dave
A few example items... the existing/legacy MediaWiki instance is using
several creative tweaks such as (not an exhaustive list.. just a few):
- PDF and ODT export. Confluence can do PDF, but cannot do ODT..
only MS Word DOC format (a significant issue in my view for an OOo
Wiki... a bit sad and embarassing that we'd only be able to export a
proprietary document format, and not the primary doc format that OOo
is known for). Export to PDF and ODT is something a lot of people use
for the OOo Docs - especially the Basic and Developer's Guides.
- Dynamic page lists - creates dynamic page set views of doc content.
This is used for dynamically indexing the FAQs for example.
- IDL Tags - custom (but simple) MW extension that creates links to
the IDL library
As for the number of pages... start with the big one.. the Developer's
Guide. http://wiki.services.openoffice.org/wiki/Category:Documentation/Developer%27s_Guide
This doc alone is approximately 1000 Wiki pages (something close to
that... I don't know the exact number off the top of my head... it's
around 2000 A4 pages when printed out or converted to PDF/ODT). Like
the other manuals in the existing/legacy OOo Wiki, it uses a
combination of nested templates and various extensions to manage the
subpages as a book. It has a detailed TOC and navigation tree, IDL
linking, etc. This would all need to be stripped and adapted to
convert to Confluence. Each page would need to land in the right
place in the document hierarchy. Someone would need to write a
Confluence macro or extension to handle the IDL tagging. All the
MediaWiki tagging would need to be converted.... and then someone
would need to wade through the document and double check that it's
still in a logical correct order, and tidy up the little oopses.
Add to the list, the Basic Guide, the Reference Lists, and the
FAQs/HowTos, plus whatever Doc pages have been translated into
Russian, French, Spanish, German etc etc, and you've got a whole lot
of pages that need to be migrated, managed, validated, etc.
I'm not saying it cannot be done... I am familiar with Confluence
Wikis... I have a fair idea what you can do in them. I also have a
rough idea just how much work will need to be done to get the Wiki
docs migrated to Confluence.
Frank Peters also raised this point a couple of weeks ago... so I'm
not the only one raising a little white flag and saying this part of
the website migration is not going to be as easy as migrating basic MW
content. :-)
One other minor point... licensing shouldn't be a barrier for these
Doc Wiki pages regardless of what is done with them... all of the
Documentation subpages are either CC-By or PDL (or both). If a Doc
Wiki page isn't clearly licensed, then it doesn't belong, or needs to
be corrected.
C.
--
Clayton Cornell ccornell@openoffice.org
OpenOffice.org Documentation Project co-lead
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 3, 2011, at 2:06 PM, Raphael Bircher wrote:
> Am 03.07.11 21:39, schrieb Dave Fisher:
>> On Jul 3, 2011, at 12:01 PM, Pedro F. Giffuni wrote:
>>
>>> FWIW,
>>>
>>> I looked to see if a Wiki converter exists and I found this:
>>>
>>> https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter
>>>
>>> Probably not everything that's needed but quite a good start?
>> It sure does look like it is worth a try. It also looks like it may require some configuration within Kenai to get the export. If someone wants to get a proper export from Kenai's Media Wiki admins (or the proper access to run UWC).
> To avoid missunderstanding, the Mediawiki from OOo is not located at the kenai infrastructure. I'ts on a separate server hosted at Hamburg. All webside located under (foobar).services.openoffice.org are external services outside the main infrastructure.
Thanks, I was confused by that. It would be good to see if they will support an UWC export for testing.
Regards,
Dave
>
>
> --
> My private Homepage: http://www.raphaelbircher.ch/
Re: Website Content plus Look and Feel Improvements
Posted by Raphael Bircher <r....@gmx.ch>.
Am 03.07.11 21:39, schrieb Dave Fisher:
> On Jul 3, 2011, at 12:01 PM, Pedro F. Giffuni wrote:
>
>> FWIW,
>>
>> I looked to see if a Wiki converter exists and I found this:
>>
>> https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter
>>
>> Probably not everything that's needed but quite a good start?
> It sure does look like it is worth a try. It also looks like it may require some configuration within Kenai to get the export. If someone wants to get a proper export from Kenai's Media Wiki admins (or the proper access to run UWC).
To avoid missunderstanding, the Mediawiki from OOo is not located at the
kenai infrastructure. I'ts on a separate server hosted at Hamburg. All
webside located under (foobar).services.openoffice.org are external
services outside the main infrastructure.
--
My private Homepage: http://www.raphaelbircher.ch/
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 3, 2011, at 2:03 PM, Jean Weber wrote:
> On Mon, Jul 4, 2011 at 05:39, Dave Fisher <da...@comcast.net> wrote:
>>
>> It sure does look like it is worth a try. It also looks like it may require some configuration within Kenai to get the export. If someone wants to get a proper export from Kenai's Media Wiki admins (or the proper access to run UWC).
>>
>
> I may be wrong, but I think we're mixing up two things here: the OOo
> *website* (under Kenai) and the OOo *wiki* (under Mediawiki). I don't
> think they are the same at all, and what needs to be done to bring
> them into the Apache system isn't the same.
Thanks, this is very helpful. I am currently thinking that we should fold website/Kenai content towards a combination of mdtext, html, javascript and css into the current podling website.
>
> Clayton's recent posts have been about the *wiki* (after saying that
> there is essentially nothing left on the website of importance in the
> Documentation area).
Good point. Let's separate the efforts. It looks like the website is a larger effort.
Raphael attached some directory listings for the foreign language sites. These look like they are made to parallel the main openoffice.org website.
Back to the website.
(1) An initial test could focus on the current main page in English followed by versions in several languages. This will need to script the conversion of existing webcontent from Kenai into format for the Apache CMS.
(2) A second focus would be on the Kenai content for one of the product development areas. This script may be substantially different.
(3) A third focus would be building the documentation area. If a wiki is preferred then we should create a website page that provides good links.
(4) A fourth focus for the website migration is how to best integrate the project's choices for Bugzilla or JIRA, user forums, and mailing lists.
>> Tell us about the MediaWiki extension that is being used, is it part of OOo or is it a third party extension?
>
> AFAIK, it's a standard extension provided by MediaWiki, though I don't
> know more details. Clayton or someone else can be more specific.
(5) MediaWiki to Apache Wiki can be a separate effort as described in another part of this thread.
Regards,
Dave
>
> --Jean
> Jean Hollis Weber
> Co-Lead, OpenOffice.org Documentation
Re: Website Content plus Look and Feel Improvements
Posted by Jean Weber <je...@gmail.com>.
On Mon, Jul 4, 2011 at 05:39, Dave Fisher <da...@comcast.net> wrote:
>
> It sure does look like it is worth a try. It also looks like it may require some configuration within Kenai to get the export. If someone wants to get a proper export from Kenai's Media Wiki admins (or the proper access to run UWC).
>
I may be wrong, but I think we're mixing up two things here: the OOo
*website* (under Kenai) and the OOo *wiki* (under Mediawiki). I don't
think they are the same at all, and what needs to be done to bring
them into the Apache system isn't the same.
Clayton's recent posts have been about the *wiki* (after saying that
there is essentially nothing left on the website of importance in the
Documentation area).
>Tell us about the MediaWiki extension that is being used, is it part of OOo or is it a third party extension?
AFAIK, it's a standard extension provided by MediaWiki, though I don't
know more details. Clayton or someone else can be more specific.
--Jean
Jean Hollis Weber
Co-Lead, OpenOffice.org Documentation
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 3, 2011, at 12:01 PM, Pedro F. Giffuni wrote:
> FWIW,
>
> I looked to see if a Wiki converter exists and I found this:
>
> https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter
>
> Probably not everything that's needed but quite a good start?
It sure does look like it is worth a try. It also looks like it may require some configuration within Kenai to get the export. If someone wants to get a proper export from Kenai's Media Wiki admins (or the proper access to run UWC).
I think we need to start with a single representative project and then work out the details for that before we do everything.
It is also worth noting that the UWC is AL2.0 licensed and can be modified.
I'll discuss the UWC with Apache Infrastructure.
Regards,
Dave
>
> cheers,
>
> Pedro.
>
> --- On Sun, 7/3/11, Dave Fisher <da...@comcast.net> wrote:
>
>> From: Dave Fisher <da...@comcast.net>
>> Subject: Re: Website Content plus Look and Feel Improvements
>> To: ooo-dev@incubator.apache.org
>> Date: Sunday, July 3, 2011, 11:53 AM
>> On Jul 3, 2011, at 3:51 AM, C wrote:
>>
>>> On Sun, Jul 3, 2011 at 12:35, TJ Frazier <tj...@cfl.rr.com>
>> wrote:
>>>> Moving the wiki is going to be a bear. I can only
>> help with the cleanup
>>>> afterward, since that merely requires some OO.o
>> familiarity, and modest
>>>> Confluence skill.
>>>
>>>
>>> The documentation in the current MediaWiki instance
>> has, as many of
>>> you well know, some very deep dependencies on MW and
>> on the various
>>> extensions (custom written and standard). I have
>> a feeling that there
>>> are quite a few people here who have no idea just how
>> monumental of a
>>> task that would be. It will not be a "simple"
>> import... it will
>>> require a manual rework of a couple thousand pages of
>> Wiki content
>>> just to pull in the docs...
>>
>> Please provide a few concrete examples of the thousands of
>> pages that will need to be reworked. What features of
>> MediaWiki are required and what is the purpose. Give me some
>> of the gory details.
>>
>>> The short of it is.. I'll help move the MediaWiki to a
>> new server on
>>> the Apache side (if the decision is made to do this),
>> but I'm not
>>> interested in moving the content to Confluence (if
>> this is the final
>>> decision).
>>
>> The bar is much higher to add to Apache Infrastructure. It
>> must be proven to Infrastructure that we have enough
>> volunteers that can administer the service. Confluence is
>> already present, as is the Apache CMS.
>>
>> We have individuals with scripting abilities. If the wiki
>> re-work is mechanical then we can script it.
>>
>> Regards,
>> Dave
>>
>>>
>>>
>>> C.
>>> --
>>> Clayton Cornell ccornell@openoffice.org
>>> OpenOffice.org Documentation Project co-lead
>>
>>
>> co
Re: Website Content plus Look and Feel Improvements
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
FWIW,
I looked to see if a Wiki converter exists and I found this:
https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter
Probably not everything that's needed but quite a good start?
cheers,
Pedro.
--- On Sun, 7/3/11, Dave Fisher <da...@comcast.net> wrote:
> From: Dave Fisher <da...@comcast.net>
> Subject: Re: Website Content plus Look and Feel Improvements
> To: ooo-dev@incubator.apache.org
> Date: Sunday, July 3, 2011, 11:53 AM
> On Jul 3, 2011, at 3:51 AM, C wrote:
>
> > On Sun, Jul 3, 2011 at 12:35, TJ Frazier <tj...@cfl.rr.com>
> wrote:
> >> Moving the wiki is going to be a bear. I can only
> help with the cleanup
> >> afterward, since that merely requires some OO.o
> familiarity, and modest
> >> Confluence skill.
> >
> >
> > The documentation in the current MediaWiki instance
> has, as many of
> > you well know, some very deep dependencies on MW and
> on the various
> > extensions (custom written and standard). I have
> a feeling that there
> > are quite a few people here who have no idea just how
> monumental of a
> > task that would be. It will not be a "simple"
> import... it will
> > require a manual rework of a couple thousand pages of
> Wiki content
> > just to pull in the docs...
>
> Please provide a few concrete examples of the thousands of
> pages that will need to be reworked. What features of
> MediaWiki are required and what is the purpose. Give me some
> of the gory details.
>
> > The short of it is.. I'll help move the MediaWiki to a
> new server on
> > the Apache side (if the decision is made to do this),
> but I'm not
> > interested in moving the content to Confluence (if
> this is the final
> > decision).
>
> The bar is much higher to add to Apache Infrastructure. It
> must be proven to Infrastructure that we have enough
> volunteers that can administer the service. Confluence is
> already present, as is the Apache CMS.
>
> We have individuals with scripting abilities. If the wiki
> re-work is mechanical then we can script it.
>
> Regards,
> Dave
>
> >
> >
> > C.
> > --
> > Clayton Cornell ccornell@openoffice.org
> > OpenOffice.org Documentation Project co-lead
>
>
> co
Re: Website Content plus Look and Feel Improvements
Posted by Dave Fisher <da...@comcast.net>.
On Jul 3, 2011, at 3:51 AM, C wrote:
> On Sun, Jul 3, 2011 at 12:35, TJ Frazier <tj...@cfl.rr.com> wrote:
>> Moving the wiki is going to be a bear. I can only help with the cleanup
>> afterward, since that merely requires some OO.o familiarity, and modest
>> Confluence skill.
>
>
> The documentation in the current MediaWiki instance has, as many of
> you well know, some very deep dependencies on MW and on the various
> extensions (custom written and standard). I have a feeling that there
> are quite a few people here who have no idea just how monumental of a
> task that would be. It will not be a "simple" import... it will
> require a manual rework of a couple thousand pages of Wiki content
> just to pull in the docs...
Please provide a few concrete examples of the thousands of pages that will need to be reworked. What features of MediaWiki are required and what is the purpose. Give me some of the gory details.
> The short of it is.. I'll help move the MediaWiki to a new server on
> the Apache side (if the decision is made to do this), but I'm not
> interested in moving the content to Confluence (if this is the final
> decision).
The bar is much higher to add to Apache Infrastructure. It must be proven to Infrastructure that we have enough volunteers that can administer the service. Confluence is already present, as is the Apache CMS.
We have individuals with scripting abilities. If the wiki re-work is mechanical then we can script it.
Regards,
Dave
>
>
> C.
> --
> Clayton Cornell ccornell@openoffice.org
> OpenOffice.org Documentation Project co-lead
Re: Website Content plus Look and Feel Improvements
Posted by C <sm...@gmail.com>.
On Sun, Jul 3, 2011 at 12:35, TJ Frazier <tj...@cfl.rr.com> wrote:
> Moving the wiki is going to be a bear. I can only help with the cleanup
> afterward, since that merely requires some OO.o familiarity, and modest
> Confluence skill.
The documentation in the current MediaWiki instance has, as many of
you well know, some very deep dependencies on MW and on the various
extensions (custom written and standard). I have a feeling that there
are quite a few people here who have no idea just how monumental of a
task that would be. It will not be a "simple" import... it will
require a manual rework of a couple thousand pages of Wiki content
just to pull in the docs...
The short of it is.. I'll help move the MediaWiki to a new server on
the Apache side (if the decision is made to do this), but I'm not
interested in moving the content to Confluence (if this is the final
decision).
C.
--
Clayton Cornell ccornell@openoffice.org
OpenOffice.org Documentation Project co-lead
Re: Website Content plus Look and Feel Improvements
Posted by TJ Frazier <tj...@cfl.rr.com>.
On 7/3/2011 05:38, C wrote:
>
> I'm only speaking for the Doc Project web content.
>
> As long as the MediaWiki content is still around (and I hope it stays
> around), the Doc project web content "move" could probably be stripped
> down to just one HTML page and a few ZIP and PDF files that should be
> archived somewhere. All other usable content has been moved to the
> OOoWiki. It would work to move all the old Doc Project debris over,
> but it really adds no value.
>
> I'd rather say "move this file and these other files and the rest can
> be ignored" than to see it all moved over once again... or even
> better... to not move anything and simply create a new Doc Project
> page from scratch.
>
> If everything is simply copied over, it'll be like the Colabnet to
> Kenai move... everything is copied and the legacy cruft tags along,
> never to be weeded out.
>
> C.
> --
> Clayton Cornell ccornell@openoffice.org
> OpenOffice.org Documentation Project co-lead
>
Normally, I would disagree with cleaning up during a conversion: it is
the number-one error to avoid. But in this case . . . if we can create a
new page that says little more than, "See the wiki" . . .
Moving the wiki is going to be a bear. I can only help with the cleanup
afterward, since that merely requires some OO.o familiarity, and modest
Confluence skill.
--
/tj/
T. J. Frazier
Melbourne, FL
(TJFrazier on OO.o)
Re: Website Content plus Look and Feel Improvements
Posted by Jean Hollis Weber <je...@gmail.com>.
On Sun, 2011-07-03 at 12:05 +0200, Marcus (OOo) wrote:
> Am 07/03/2011 11:38 AM, schrieb C:
> >>>
> >>> The majority of the documentation project content is not really stored
> >>> in the stuff that was downloaded in this test. What you find in the
> >>> web-content side is pretty much just pointers to the Wiki plus a few
> >>> files here and there that are not in the Wiki.
> >>>
> >>> I would much more prefer that when the time comes to migrate content
> >>> of the documentation directory, that I simply tag which files are to
> >>> be transferred and the rest are pruned. I have spent time cleaning up
> >>> what's there, but there are still 10 years of legacy things still
> >>> laying about, not used anymore.... stuff that should not be copied
> >>> over.
> >
> > I'm only speaking for the Doc Project web content.
>
> OK, you know the doc project very well of course. So we can take what is
> still of value and kick the other stuff.
>
+1
> > As long as the MediaWiki content is still around (and I hope it stays
> > around), the Doc project web content "move" could probably be stripped
> > down to just one HTML page and a few ZIP and PDF files that should be
> > archived somewhere. All other usable content has been moved to the
> > OOoWiki. It would work to move all the old Doc Project debris over,
> > but it really adds no value.
> >
> > I'd rather say "move this file and these other files and the rest can
> > be ignored" than to see it all moved over once again... or even
> > better... to not move anything and simply create a new Doc Project
> > page from scratch.
>
> IMHO better to start with nothing and add page-by-page. I don't think
> that the old stuff will remain with what we are doing here, a restart. ;-)
+1
Jean
--
Jean Hollis Weber
Co-Lead, OpenOffice.org Documentation Project
Re: Website Content plus Look and Feel Improvements
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/03/2011 11:38 AM, schrieb C:
> On Sun, Jul 3, 2011 at 10:56, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 07/03/2011 07:43 AM, schrieb C:
>>>
>>> On Sun, Jul 3, 2011 at 06:29, Graham Lauder<yo...@openoffice.org>
>>> wrote:
>>>>
>>>> On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:
>>>>>
>>>>> Some projects are huge and others small. I downloaded several:
>>>>>
>>>>> wave@minotaur:~/ooo-test$ ls -1
>>>>> development
>>>>> documentation
>>>>> download
>>>>> projects
>>>>> www
>>>>>
>>>>> The size is 2.7GB.
>>>>>
>>>>> It would be good to come up with a scripted way to convert existing
>>>>> webcontent to either mdtext, an altered html, or specialized javascript and
>>>>> css. It is likely we can adapt the content and use the Apache CMS to wrap a
>>>>> standard skeleton.
>>>>>
>>>>> Regards, Dave
>>>>>
>>>>
>>>>
>>>> Much of what is on there is legacy material that could be seriously
>>>> pruned. For instance all the old Marketing material that is V2.0 and
>>>> earlier could be deleted.
>>>>
>>>> Argument could be made for the marketing material to start from scratch.
>>>> Personally I'd like to see a whole new branding and get shot of the old
>>>> stuff, make the first Apache release: V4.0 (Historically, significant
>>>> global change has meant a whole number change in the version: V2 new
>>>> codebase, V3 Apple compatibility. I think this is significant enough:
>>>> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
>>>> gives us a handle to hang a campaign on.
>>>
>>> The majority of the documentation project content is not really stored
>>> in the stuff that was downloaded in this test. What you find in the
>>> web-content side is pretty much just pointers to the Wiki plus a few
>>> files here and there that are not in the Wiki.
>>>
>>> I would much more prefer that when the time comes to migrate content
>>> of the documentation directory, that I simply tag which files are to
>>> be transferred and the rest are pruned. I have spent time cleaning up
>>> what's there, but there are still 10 years of legacy things still
>>> laying about, not used anymore.... stuff that should not be copied
>>> over.
>>
>> I know that many things are simply outdated and could be deleted easily
>> without loosing value. However, when we grab the content from the Oracle
>> server, look into the content, and then decide if to take over and publish
>> or modify or delete, then we we have much to do and a longer time no real
>> content on our websites.
>>
>> So, I would prefer to take over all content and make it public *) . Then we
>> can go through the content and add/modify/delete/whatever part-by-part.
>>
>> *) After the license problems are solved.
>>
>> My 2 ct
>>
>> Marcus
>
> I'm only speaking for the Doc Project web content.
OK, you know the doc project very well of course. So we can take what is
still of value and kick the other stuff.
> As long as the MediaWiki content is still around (and I hope it stays
> around), the Doc project web content "move" could probably be stripped
> down to just one HTML page and a few ZIP and PDF files that should be
> archived somewhere. All other usable content has been moved to the
> OOoWiki. It would work to move all the old Doc Project debris over,
> but it really adds no value.
>
> I'd rather say "move this file and these other files and the rest can
> be ignored" than to see it all moved over once again... or even
> better... to not move anything and simply create a new Doc Project
> page from scratch.
>
> If everything is simply copied over, it'll be like the Colabnet to
> Kenai move... everything is copied and the legacy cruft tags along,
> never to be weeded out.
IMHO better to start with nothing and add page-by-page. I don't think
that the old stuff will remain with what we are doing here, a restart. ;-)
Marcus
Re: Website Content plus Look and Feel Improvements
Posted by C <sm...@gmail.com>.
On Sun, Jul 3, 2011 at 10:56, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 07/03/2011 07:43 AM, schrieb C:
>>
>> On Sun, Jul 3, 2011 at 06:29, Graham Lauder<yo...@openoffice.org>
>> wrote:
>>>
>>> On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:
>>>>
>>>> Some projects are huge and others small. I downloaded several:
>>>>
>>>> wave@minotaur:~/ooo-test$ ls -1
>>>> development
>>>> documentation
>>>> download
>>>> projects
>>>> www
>>>>
>>>> The size is 2.7GB.
>>>>
>>>> It would be good to come up with a scripted way to convert existing
>>>> webcontent to either mdtext, an altered html, or specialized javascript and
>>>> css. It is likely we can adapt the content and use the Apache CMS to wrap a
>>>> standard skeleton.
>>>>
>>>> Regards, Dave
>>>>
>>>
>>>
>>> Much of what is on there is legacy material that could be seriously
>>> pruned. For instance all the old Marketing material that is V2.0 and
>>> earlier could be deleted.
>>>
>>> Argument could be made for the marketing material to start from scratch.
>>> Personally I'd like to see a whole new branding and get shot of the old
>>> stuff, make the first Apache release: V4.0 (Historically, significant
>>> global change has meant a whole number change in the version: V2 new
>>> codebase, V3 Apple compatibility. I think this is significant enough:
>>> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
>>> gives us a handle to hang a campaign on.
>>
>> The majority of the documentation project content is not really stored
>> in the stuff that was downloaded in this test. What you find in the
>> web-content side is pretty much just pointers to the Wiki plus a few
>> files here and there that are not in the Wiki.
>>
>> I would much more prefer that when the time comes to migrate content
>> of the documentation directory, that I simply tag which files are to
>> be transferred and the rest are pruned. I have spent time cleaning up
>> what's there, but there are still 10 years of legacy things still
>> laying about, not used anymore.... stuff that should not be copied
>> over.
>
> I know that many things are simply outdated and could be deleted easily
> without loosing value. However, when we grab the content from the Oracle
> server, look into the content, and then decide if to take over and publish
> or modify or delete, then we we have much to do and a longer time no real
> content on our websites.
>
> So, I would prefer to take over all content and make it public *) . Then we
> can go through the content and add/modify/delete/whatever part-by-part.
>
> *) After the license problems are solved.
>
> My 2 ct
>
> Marcus
I'm only speaking for the Doc Project web content.
As long as the MediaWiki content is still around (and I hope it stays
around), the Doc project web content "move" could probably be stripped
down to just one HTML page and a few ZIP and PDF files that should be
archived somewhere. All other usable content has been moved to the
OOoWiki. It would work to move all the old Doc Project debris over,
but it really adds no value.
I'd rather say "move this file and these other files and the rest can
be ignored" than to see it all moved over once again... or even
better... to not move anything and simply create a new Doc Project
page from scratch.
If everything is simply copied over, it'll be like the Colabnet to
Kenai move... everything is copied and the legacy cruft tags along,
never to be weeded out.
C.
--
Clayton Cornell ccornell@openoffice.org
OpenOffice.org Documentation Project co-lead
Re: Website Content plus Look and Feel Improvements
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/03/2011 07:43 AM, schrieb C:
> On Sun, Jul 3, 2011 at 06:29, Graham Lauder<yo...@openoffice.org> wrote:
>> On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:
>>> Some projects are huge and others small. I downloaded several:
>>>
>>> wave@minotaur:~/ooo-test$ ls -1
>>> development
>>> documentation
>>> download
>>> projects
>>> www
>>>
>>> The size is 2.7GB.
>>>
>>> It would be good to come up with a scripted way to convert existing webcontent to either mdtext, an altered html, or specialized javascript and css. It is likely we can adapt the content and use the Apache CMS to wrap a standard skeleton.
>>>
>>> Regards, Dave
>>>
>>
>>
>> Much of what is on there is legacy material that could be seriously
>> pruned. For instance all the old Marketing material that is V2.0 and
>> earlier could be deleted.
>>
>> Argument could be made for the marketing material to start from scratch.
>> Personally I'd like to see a whole new branding and get shot of the old
>> stuff, make the first Apache release: V4.0 (Historically, significant
>> global change has meant a whole number change in the version: V2 new
>> codebase, V3 Apple compatibility. I think this is significant enough:
>> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
>> gives us a handle to hang a campaign on.
>
> The majority of the documentation project content is not really stored
> in the stuff that was downloaded in this test. What you find in the
> web-content side is pretty much just pointers to the Wiki plus a few
> files here and there that are not in the Wiki.
>
> I would much more prefer that when the time comes to migrate content
> of the documentation directory, that I simply tag which files are to
> be transferred and the rest are pruned. I have spent time cleaning up
> what's there, but there are still 10 years of legacy things still
> laying about, not used anymore.... stuff that should not be copied
> over.
I know that many things are simply outdated and could be deleted easily
without loosing value. However, when we grab the content from the Oracle
server, look into the content, and then decide if to take over and
publish or modify or delete, then we we have much to do and a longer
time no real content on our websites.
So, I would prefer to take over all content and make it public *) . Then
we can go through the content and add/modify/delete/whatever part-by-part.
*) After the license problems are solved.
My 2 ct
Marcus
RE: Website Content plus Look and Feel Improvements
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: C [mailto:smaug42@gmail.com]
> Sent: Sunday, 3 July 2011 6:00 PM
> To: ooo-dev@incubator.apache.org
> Subject: Re: Website Content plus Look and Feel Improvements
>
> On Sun, Jul 3, 2011 at 09:53, Gavin McDonald <ga...@16degrees.com.au>
> wrote:
> >> -----Original Message-----
> >> From: C [mailto:smaug42@gmail.com]
> >> Sent: Sunday, 3 July 2011 3:43 PM
> >> To: ooo-dev@incubator.apache.org
> >> Subject: Re: Website Content plus Look and Feel Improvements
> >
> > <snip>
> >
> >> C.
> >
> > I've been told off before for simply using my first name.
> > (and I have been here 6 years)
> >
> > Using 'C' in both you rsig and your from address, not good enough for
> > me I'm afraid, what's you name please?
>
> Old habits die hard. I've used "C" on my private email for more years
than I
> can remember... for many reasons.
>
> My OOo signature is/was:
> --
> Clayton Cornell ccornell@openoffice.org
> OpenOffice.org Documentation Project co-lead
Great, thanks muchly :)
Gav...
Re: Website Content plus Look and Feel Improvements
Posted by C <sm...@gmail.com>.
On Sun, Jul 3, 2011 at 09:53, Gavin McDonald <ga...@16degrees.com.au> wrote:
>> -----Original Message-----
>> From: C [mailto:smaug42@gmail.com]
>> Sent: Sunday, 3 July 2011 3:43 PM
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: Website Content plus Look and Feel Improvements
>
> <snip>
>
>> C.
>
> I've been told off before for simply using my first name.
> (and I have been here 6 years)
>
> Using 'C' in both you rsig and your from address, not good enough for
> me I'm afraid, what's you name please?
Old habits die hard. I've used "C" on my private email for more years
than I can remember... for many reasons.
My OOo signature is/was:
--
Clayton Cornell ccornell@openoffice.org
OpenOffice.org Documentation Project co-lead
RE: Website Content plus Look and Feel Improvements
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: C [mailto:smaug42@gmail.com]
> Sent: Sunday, 3 July 2011 3:43 PM
> To: ooo-dev@incubator.apache.org
> Subject: Re: Website Content plus Look and Feel Improvements
<snip>
> C.
I've been told off before for simply using my first name.
(and I have been here 6 years)
Using 'C' in both you rsig and your from address, not good enough for
me I'm afraid, what's you name please?
Gav...
Re: Website Content plus Look and Feel Improvements
Posted by C <sm...@gmail.com>.
On Sun, Jul 3, 2011 at 06:29, Graham Lauder <yo...@openoffice.org> wrote:
> On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:
>> Some projects are huge and others small. I downloaded several:
>>
>> wave@minotaur:~/ooo-test$ ls -1
>> development
>> documentation
>> download
>> projects
>> www
>>
>> The size is 2.7GB.
>>
>> It would be good to come up with a scripted way to convert existing webcontent to either mdtext, an altered html, or specialized javascript and css. It is likely we can adapt the content and use the Apache CMS to wrap a standard skeleton.
>>
>> Regards, Dave
>>
>
>
> Much of what is on there is legacy material that could be seriously
> pruned. For instance all the old Marketing material that is V2.0 and
> earlier could be deleted.
>
> Argument could be made for the marketing material to start from scratch.
> Personally I'd like to see a whole new branding and get shot of the old
> stuff, make the first Apache release: V4.0 (Historically, significant
> global change has meant a whole number change in the version: V2 new
> codebase, V3 Apple compatibility. I think this is significant enough:
> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
> gives us a handle to hang a campaign on.
The majority of the documentation project content is not really stored
in the stuff that was downloaded in this test. What you find in the
web-content side is pretty much just pointers to the Wiki plus a few
files here and there that are not in the Wiki.
I would much more prefer that when the time comes to migrate content
of the documentation directory, that I simply tag which files are to
be transferred and the rest are pruned. I have spent time cleaning up
what's there, but there are still 10 years of legacy things still
laying about, not used anymore.... stuff that should not be copied
over.
Then there's the MediaWiki documentation content...
C.
Re: Website Content plus Look and Feel Improvements
Posted by Graham Lauder <yo...@openoffice.org>.
On Sat, 2011-07-02 at 12:57 -0700, Dave Fisher wrote:
> Yesterday I got tired of the look of people.mdtext in the project site. It was so 1990s. So, I've improved the look via css and adding defined widths. I guess I am volunteering for the item on https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted
>
> Several of us have been surveying the existing openoffice.org website on several wiki pages mostly linked to from:
> https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan
>
> With over 140 "projects" in openoffice.org, it will be important to agree to a mapping which reduces the granularity by more than an order of magnitude. The page http://projects.openoffice.org/ is a good and clear way to start - and pretty much fits the structure on https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning
>
> • Product Development
> • Extension Development
> • Language Support
> • Helping Users
> • Distribution
> • Promotion
>
> I think that these groupings will help us easily have a rule about which projects end up on http://openoffice.apache.org/ or stay on the successor http://*.openoffice.org/.
>
> Projects have "webcontent" and/or "wiki" content. On openoffice.org there is a generally consistent look. There are exceptions which are marketing sites like http://why.openoffice.org/. The difference is glaring because that is the first big button on the main site.
The why.openoffice.org page was done as a marketing tool independently
of the main website and the Website team under the marketing project by
one of the members of the marketing team and for a specific marketing
campaign. Andre's design was so good we left it as is, however there
had been intention to change it suit the overall look but volunteer time
availability to do it was lacking. It still served a purpose as a very
useful marketing resource so pulling it down just because of a
non-standard look was never an option.
>
> Webcontent is available via svn - "svn co https://svn.openoffice.org/svn/${project}~webcontent ${project}" (Thanks Marcus Lange)
>
> Some projects are huge and others small. I downloaded several:
>
> wave@minotaur:~/ooo-test$ ls -1
> development
> documentation
> download
> projects
> www
>
> The size is 2.7GB.
>
> It would be good to come up with a scripted way to convert existing webcontent to either mdtext, an altered html, or specialized javascript and css. It is likely we can adapt the content and use the Apache CMS to wrap a standard skeleton.
>
> Regards, Dave
>
Much of what is on there is legacy material that could be seriously
pruned. For instance all the old Marketing material that is V2.0 and
earlier could be deleted.
Argument could be made for the marketing material to start from scratch.
Personally I'd like to see a whole new branding and get shot of the old
stuff, make the first Apache release: V4.0 (Historically, significant
global change has meant a whole number change in the version: V2 new
codebase, V3 Apple compatibility. I think this is significant enough:
pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it
gives us a handle to hang a campaign on.
Cheers
GL
--
Graham Lauder,
OpenOffice.org MarCon (Marketing Contact) NZ
http://marketing.openoffice.org/contacts.html
OpenOffice.org Migration and training Consultant.