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" <dave2w...@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.lau...@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. >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>
