Hi,
I don't see many show stoppers anymore, so we could make it the default
download page. Few comments that would make it just a little better in
my opinion, but let them rest if you don't like to, or don't care. We
can even think about it after the new download page has been put online.
Related link: http://website.openoffice.org/tryouts/cloph/options.html
[...]
- Make the whole download box clickable (where the hand is), just like
the very current download page. (Christian does not think it's makes
much of a difference, James and Maarten however do (possibly James only
because there is a hand-cursor (removing this would the least that could
be changed according to Maarten))
I also don't very much like it since it collapses the list-boxes unless
you hold and click..
I guess that was the reason why I changed it in the first place....
Apart from that it "steals" the onclick events for the other elements,
rendering the design unusable.
As a mid-term solution I incorporated the two paragraphs into the
clickable-area (so not the whole box, but all the text that is visible
initially.
Why is it a problem that it 'steals' onclick events? It will only steal
the event when javascript is enabled and then only respond to the
onclick event. When this response has been triggered, which is necessary
to display the download options in the first place, the event is being
removed from the optionitem div. And I haven't been able to spot any
irregularities in firefox, nor in opera, where in the case of no
stylesheets (but with javascript) the behaviour seems to conflict. I
therefore assumed the javascript is not making the page less usable for
people using less-default ways of browsing, and makes behaviour easier
for those who do. But maybe you can give a case in which behaviour with
the current download page [1] is distorted by the javascript.
The problem is that I've clicked, testing your new proposal, even in the
latest version, several times at the box without result. This is
frustrating. Restoring it to normal behaviour would only require replacing
<div class="optionitem" id="optionitem1" >
with
<div class="optionitem" id="optionitem1"
onclick="openItem('optionitem1',null); return false;">
.
[1] http://download.openoffice.org/2.0.2/
__TO VERIFY______
- Contribution page will be skipped when there is a contribution page on
the page where it leads to, will, and can, be set on a per-link basis.
(per language-basis)
Making it per-version would be possible, but doesn't make much sense
IMHO.
And the "other" platforms will be "hardcoded" (i.e. not "configured")
I indeed meant per language basis... Can we do it already for the other
platforms then? I don't see many calls for contribution directly, but
the fact that they're emphasizing on non-QA'd build etcetera, actually
calls for contributions in a more indirect way.
[...]
- Not to implement: It would be more user friendly (maybe only to a more
tech oriented audience) when the javascript would also make the href
contents of the <a> element change (containing a link to the next page)
which is more accessible. Currently 'open in new tab' clicking on the
link leads to an empty page referring to a javascript function in the
location-bar. (maarten does not mind this option very much, christian
argues it might not even be possible, since the URL is generated
dynamically, Maarten would counterargue that the URL's could already be
generated beforehand, like the server URL).
The server-URL is stored in a hidden (not displayed) form-element...
Modifying the link targed probably would involve some ugly
document.write stuff and is not necessary IMHO....
You could just use DOM-scripting to change the href's content of a link.
But what I said: if it's too difficult, leave it as is. Good btw that
you've removed the document.write stuff from the page, had not noticed
that before.
Great work Christian!
g.,
Maarten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
