incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wolf Halton <wolf.hal...@gmail.com>
Subject Re: Website Content plus Look and Feel Improvements
Date Wed, 06 Jul 2011 04:59:40 GMT
I am going to do some research into *2odf in python.

On Jul 5, 2011 11:57 PM, "Dave Fisher" <dave2wave@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" <dave2wave@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.a.lauder@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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message