2011/11/24 Jürgen Schmidt <[email protected]> > On 11/23/11 5:55 PM, Kay Schenk wrote: > >> +1...all good, and something we had discussed early on. >> >> However, as I work on porting legacy info over, I am wondering what to do >> about the more "developer" centered areas of the site: api, sc, sw, >> framework, external (? -- I need to look at this one), tools,porting, and >> many others that are not really "user centered". I will load these into >> the >> ooo-site tree, but at some point, someone on the "developer" side should >> really cull this out and move them to the "developer" side so we don't >> continually deal with these areas on the "user portal". >> > > i also have thought about the api page and i would like to support it in > the future as well. Because it provides some useful stuff for macro, > extension developers. But maybe in a simplified and reduced form. > > things i would i would like to keep > > - API reference > - C++/Java UNO Runtime reference > - search features into the different reference documentation as well as > the Developer's Guide > - links to the SDK > - link to the API wiki pages > > Most of the content will i move into the wiki as soon as possible. > > I would really like to work with you or somebody else who knows the Apache > framework better then i to rework the API page. > It would be really helpful if we can find an easy way to update the > generated reference docu without checking in thousands of files. >
Jurgen-- Everything form the old "api" site is available via -- https://svn.apache.org/repos/asf/incubator/ooo/ooo-site/trunk/content/api/ just plain ole html...I don't think you should have any problems > extensions.openoffice.org points today already in the wiki and i would > like to redirect this page today to the api side. And in the future we can > hopefully reactivate this page for an extension repository. > > And hopefully templates.openoffice.org for templates ;-) > > Juergen > > > > >> On Mon, Nov 21, 2011 at 3:46 PM, Rob Weir<[email protected]> wrote: >> >> We have with this project something that most other Apache projects >>> don't have and which the legacy OOo project never had. We have two >>> independent websites. >>> >>> We have the legacy www.openoffice.org website, which served as an >>> end-user portal for OpenOffice as well as a website for project >>> participants. >>> >>> And we have the >>> http://incubator.apache.org/**openofficeorg/<http://incubator.apache.org/openofficeorg/>, >>> which on >>> graduation probably becomes something shorter, like >>> http://openoffice.apache.org. For most Apache projects their website >>> also serves both purposes: a site for users as well as project >>> participants. >>> >>> So, we have both of these websites, and a lot of redundancy caused by >>> it. This obviously has a downside. It makes it hard to update, since >>> a lot of information is in both places. And it confuses users since >>> the websites are out of sync on some important topics. It also >>> prevents us from really optimizing the experience for each audience. >>> I suspect that long-term this dual-website with overlapping content is >>> not a maintainable model. >>> >>> What can we do? >>> >>> I hope I am not committing heresy if I say that most users of >>> OpenOffice care as little about Apache as drinker of a Pepsi cares >>> about the Board of Directors of PepsiCo Corporation. The average user >>> (and we're talking about millions of them) cares about downloading, >>> installing, using, learning about and generally being productive with >>> OpenOffice. It is a tool they use to do their work. Their work is >>> what matters to them, not our work. >>> >>> But of course we also have a growing number of users, contributors and >>> committers who want to get more involved with the project. OpenOffice >>> is interesting to them. They identify with it. They want to learn >>> more than just the basics. They are intrigued by open source. They >>> want to help. They want to get more involved. >>> >>> The trick I think, is to have websites that speak to each of these >>> audiences, as well as an easy/obvious way to navigate between them, >>> while at the same time avoiding unnecessary cross talk and redundancy. >>> >>> For example, could we have something like this: >>> >>> 1) www.openoffice.org is the website for the OpenOffice product. It >>> is the end user site, focused on their interactions with the product. >>> So download, help, extensions, support. It is not how they interact >>> with the project. It serves the narrow focus on the product. >>> >>> >>> 2) >>> incubator.apache.org/**openofficeorg<http://incubator.apache.org/openofficeorg>(eventually >>> openoffice.apache.org) on the other hand is where the project members >>> work and where the public (includiing users) interacts with the >>> project. Not the product, but the project. >>> >>> This dual website is quite commonly used for managing large and >>> important brands. For example, the consumer, when interfacting with >>> the brand Pepsi and Pepsi products goes to: >>> >>> http://www.pepsi.com >>> >>> But the person who wants to learn more about the company goes to another >>> URL: >>> >>> http://www.pepsico.com/ >>> >>> Navigating between then is possible via a link on the page footer. >>> But generally each site is optimized for its target audience. >>> >>> >> >> >> > -- ---------------------------------------------------------------------------------------- MzK "The greatness of a nation and its moral progress can be judged by the way its animals are treated." -- Mohandas Gandhi
