Hi, > Hi Maarten, all, > > Sorry for the long email and for not having snipped out much. i > propose a plan at the end of this ... :) partly my fault :) >> Ok, let me try to give my interpretation of what you are suggesting: >> >> portal.openoffice.org is going to be an attempt to offer >> 'everything' the >> end-user needs (so no other domains), > > .... and more than enduser :-) eg, developers who want to learn about > OOo. Right now, we have to send them to development.ooo (poor) or the > thick wikis (great but sometimes non-navigable).
Excellent. >> and is thus going to replace >> download.openoffice.org, support.openoffice.org, why.openoffice.org, >> about.openoffice.org and large parts of www.openoffice.org (and >> maybe even >> the introduction part of contributing/participating). > > Not quite. Some of those will be progressively deprecated as portal > gains strength but I doubt if why.ooo will be replaced, as its > function is marketing; about.ooo won't be replaced--should it?-- > contributing/participate: no, not really. Well, I think we agree ;) ... with "going to" I was not necessarily rejecting a progressive approach (actually, I hereby rule out the possibility of a perfect instant approach), however we should think about what we in the end want to serve. And which sites exactly are becoming obsolete will depend a) on the requirements [1] and b) on the users (whether they choose to visit them not) > I prefer it (centralization) for downloads. But coordinating the NLCs > is not trivial here, not because they don't agree, necessarily, but > because QA'ing works at different rates and not all servers are the > same. To this end, I'm also in contact with the Bouncer people in > Oregon, USA, about seeing if Bouncer can serve up local servers only > (and read the user's locale). Actually I was talking in general, now the portal to support is managed by the support group. Somehow this makes sense, but I am suggesting that it is better that this is something we do, to keep the site consistent (of course in partnership with support, but I would move the end-responsibility for the web presence to this group). I had a related problem with the call for participating in testing a while ago. We wanted to create a campaign, but the landing page for the button is the responsibility of another team, leading to inconsistencies, which is bad for the site's UX... Just like UX is becoming a kind of last stage for a proposal related to the product's interface, I would like to see that website-dev is becoming a last stage for an website improvement (at least for the international end-user pages). > As well, if a user goes to, say, nl.openoffice.org/about- > downloads.html and clicks on OOo 3.0 in Dutch, is she taken to > portal.ooo or just start downloading it? I think that a better model > would be for either: user -> nl.openoffice.org ->download link > immediate using Bouncer or user ->homepage (www.openoffice.org) - > >clicks on download and is given the page in Dutch automatically or > starts download automatically, the latter preferred. True. But if I would send my mother out to download OOo, she will visit www.openoffice.org, not nl.openoffice.org. "Download" she understands, so she will click that, but then it is relatively difficult to get the Dutch version, which she definitely prefers. Normally users will not see the bouncer website, so I wouldn't require them to offer translated errors. What would be nice is that instead of passing an url with language & version, we could pass something as language & version=latest. Another option would be to have some kind of webservice communication serverside with bouncer... btw, about the number of clicks (something we can improve now actually): have you tried downloading OOo with javascript turned of? 2 clicks (but yes, it still includes OS selection). > Ah. Yes, I don't really want to have too much confusion :-) This is > not supposed to be a postmodern site :-) (you know, where confusion is > the point ....) ;) > In sum, then, how about this: > > * We ask CollabNet to make download.openoffice.org point to an outside > server. (It may have to be renamed, say to "downloads.openoffice.org) maybe get.openoffice.org is also an option, the plural downloads I don't like that much > * We work on the homepage as has been and is being done. I'm still thinking about the homepage=>portal transition... maybe when portal.openoffice.org is in a quite ready state, www.openoffice.org/index.html (or www/www/index.html) should redirect to portal.openoffice.org > * We being work on portal.openoffice.org secondarily, with the notion > that portal.ooo will be a more or less comprehensive place for > endusers and even developers, but the focus on endusers. g., Maarten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
