Hey :)
"portal.openoffice.org" is logically reached via www.openoffice.org
->portal.openoffice.org. It would include downloads, etc. and be a
simple and obvious site for endusers; links to other things also
possible. It need not use CollabNet infrastructure.
I think this is kind of strange... and what is causing confusion
here. Portal is for end-users but we have to access it through the
harder to use home page hosted at the collabnet infrastructure...
something tells me that it should be the other way around (first
portal, then refer to the homepage for the community members)...
Just my 2c.
yep! I agree completely...well mostly. I don't find the home page hard
to use, but typically, a "portal" (think about a portal in "door"
terms), is the entry point...and moreover, in common parlance
*implies* some sort of "individualized" entrance. I don't mean to be
difficult, but, I agree with Maarten, strange.
but you understand my point? I mean, I agree with Maarten, too. I just
feel that a) we are constrained by technology and b) that we must not
sacrifice our brand identity by using another url for the primary
destination. FWIW, I doubt if I could persuade Sun to support such a
non-OOo branded primary destination; I would be hard to persuade, as it is.
What I am suggesting is that we could make the homepage
(www.openoffice.org) as accessible as the type of design Louis
envisiones for portal.ooo. Actually I agree with Kay that it isn't that
bad, but it is getting dated (especially now with the ugly underlining)
The homepage is rather static anyway, so I don't see anything where e.g.
Molcan's design could interfere with the collabnet infrastructure. It is
not that it is like frontpage entering and removing all kinds of stupid
tags. It only adds some surrounding tags. I have never had problems with
that.
What is difficult to accomplish are things like news and other things
that change and need maintenance. The current download situation an sich
is not that bad as it is I think, it is only a pity that we have to rely
on javascript (for e.g. 'auto-expanding when reaching the OOo-stable
download page from the general download page', for showing the
intermediate contributing page), but that is minimal, and non obtrusive.
What serverside scripting for download could mean though is that we
finally will be able to realize a download page that supports multiple
versions in multiple languages (actually nothing more than a fancier
front end for the bouncer system) for multiple operating systems. This
factor design is rather hard to accomplish without relying purely on
javascript now (and the goal always was to not to offer non-javascript
users degraded versions). With some server side scripting language we
are able to make this actually work without any need for javascript on
the user side. Also things like find the nearest place where I can buy a
CD rom can also be streamlined, and suggestions can even be made based
on some IP location. Furthermore, we should instead of rely on some PHP
script on some univeritie's server for the P2P download to function
properly, have the script at an OOo managed server (I don't mind which
subdomain).
These are the things where Collabnet is not collaborating with us, but
is not with static pages (nice static, visuals are no problem at all).
I don't see why e.g. Molcan's design (in theory) could not become the
design for www.openoffice.org. There are no technical barriers here.
Louis, I think you are right that users shouldn't be forced to go to
portal.openoffice.org directly. That is not what I meant. I meant that
requiring end users (or even potential users) to make an additional step
by forcing them to go to another special end-user website is a bit the
world upside down. You can expect developers to make an additional step
(heck, they might even have bookmarks of deep OOo pages), but not users
you want to convince of your product.
Rather would I use portal.openoffice.org as something that transparently
(well at first sight) integrates with the www.openoffice.org domain.
Just like users download now almost without knowing from
download.openoffice.org, the link on the main page could instead refer
to portal.openoffice.org/download where a much fancier (in terms of ease
of use) is hosted.
By making sure that the the same header and footer are repeated on all
subdomains (including also the wiki as suggested by Alexandro) users
won't notice that much of a difference. I am not saying that it is very
nice that subdomains are switched all the time when a user browses
around, but that would be something I would be able to live with.
Repeating however functionality on two(three) almost identical sites
(www.ooo and portal.ooo (and why.ooo*)) when it is not necessary, is
making things only more complicated for everyone.
Given the fact that www.openoffice.org still needs to refer to a server
with the collabnet infrastructure, I think this is the best solution.
Alternatively I would set up www.openoffice.org with a 0sec delay
redirect to portal.openoffice.org, where we can have all freedom. Imho
Portal=mainpage=endusersite=explainingwhy=offeringeasydownload=givingaccesstohelp...
So lets think about this first a bit... (and thus maybe start to work on
requirements first instead of designing, as Louis suggested from the
beginning...).
Due to lack of thinking what is actually needed, we are actually working
blindfolded in a random direction. First get directions (or buy a proper
map & compass), then start to walk ;) (no matter how long it takes to
get proper directions).
g.,
Maarten
* I am mentioning the why page because I think would think it is hardly
ever used, again because much of the functionality overlaps. That is
what we should be working on, integrating all the random efforts. We
should be careful not to start just another random effort.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
