Re: Should download pages *require* Javascript?
On 19 August 2013 19:44, Rory O'Farrell ofarr...@iol.ie wrote: On Mon, 19 Aug 2013 20:14:08 +0200 Andrea Pescetti pesce...@apache.org wrote: On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/download/other.html also requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). Regards, Andrea. I think the automatic selection of a best fit OpenOffice for the user is good. Agreed. Forum experience suggests that many unskilled users will get confused if offered the full range of options of versions for operating sytems, languages and language packs. Yet that is exactly what the page http://www.openoffice.org/download/other.html does. All the versions and all the language packs are laid out in one huge table. Probably easier to use than the ASF mirror structure, but still not easy. However, although the page requires Javascript, it does not use Javascript to narrow the choices for the user. AFAICT the Javascript is only used to build the table so it might as well be static HTML that any browser can use. If it were turned into a static page, I think it might be a better alternative to the ASF mirror structure. Maybe there should be a separate discussion about how to organise the download pages when the autodetection does not work. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
On 20 August 2013 01:20, Rob Weir robw...@apache.org wrote: On Mon, Aug 19, 2013 at 6:39 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 08/19/2013 09:51 PM, schrieb sebb: On 19 August 2013 20:27, Rob Weirrobw...@apache.org wrote: On Mon, Aug 19, 2013 at 2:14 PM, Andrea Pescettipesce...@apache.org wrote: On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/download/other.html also requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). I think this is the key insight. There are actually three cases to consider: 1) Java script disabled 2) Javascript is supported, but not working with our page 3) Javascript working fine. Some of the more recent reports are about #2. These are older versions of Internet Explorer, e.g., I.E. 6. Anoscript block will not help in this case. But if it is possible to detect the broken Javascript without crashing, then it would be possible to treat the browser as if it did not have Javascript. Right, has anybody an idea how to detect such broken JS engines? From this test it looks like the main issue is Internet Explorer before I.E. 8: http://browsershots.org/http://www.openoffice.org/download/ One approach is to see if you can code around that error and get it to work correctly on older I.E. installs. Another approach is to use one of these techniques to detect older I.E. and then fall back to a non-script page: http://msdn.microsoft.com/en-us/library/ms537509%28v=vs.85%29.aspx It might also be possible to use the HTTP headers User-Agent and Accepts-Language as a backstop for when Javascript is not available. This might need some Infra config support. -Rob Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
On Tue, Aug 20, 2013 at 5:29 AM, sebb seb...@gmail.com wrote: On 20 August 2013 01:20, Rob Weir robw...@apache.org wrote: On Mon, Aug 19, 2013 at 6:39 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 08/19/2013 09:51 PM, schrieb sebb: On 19 August 2013 20:27, Rob Weirrobw...@apache.org wrote: On Mon, Aug 19, 2013 at 2:14 PM, Andrea Pescettipesce...@apache.org wrote: On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/download/other.htmlalso requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). I think this is the key insight. There are actually three cases to consider: 1) Java script disabled 2) Javascript is supported, but not working with our page 3) Javascript working fine. Some of the more recent reports are about #2. These are older versions of Internet Explorer, e.g., I.E. 6. Anoscript block will not help in this case. But if it is possible to detect the broken Javascript without crashing, then it would be possible to treat the browser as if it did not have Javascript. Right, has anybody an idea how to detect such broken JS engines? From this test it looks like the main issue is Internet Explorer before I.E. 8: http://browsershots.org/http://www.openoffice.org/download/ One approach is to see if you can code around that error and get it to work correctly on older I.E. installs. Another approach is to use one of these techniques to detect older I.E. and then fall back to a non-script page: http://msdn.microsoft.com/en-us/library/ms537509%28v=vs.85%29.aspx It might also be possible to use the HTTP headers User-Agent and Accepts-Language as a backstop for when Javascript is not available. This might need some Infra config support. -Rob Marcus Just me-too-ing here...I can't get to the download list right now from my office, with IE8, scripting disabled and a somewhat draconian firewall. I can get to SourceForge, though. Should there be an If that doesn't work, click here link, perhaps pointing to...? http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/ Don
Re: Should download pages *require* Javascript?
Am 08/20/2013 11:25 AM, schrieb sebb: On 19 August 2013 19:44, Rory O'Farrellofarr...@iol.ie wrote: On Mon, 19 Aug 2013 20:14:08 +0200 Andrea Pescettipesce...@apache.org wrote: On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/download/other.html also requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). Regards, Andrea. I think the automatic selection of a best fit OpenOffice for the user is good. Agreed. Forum experience suggests that many unskilled users will get confused if offered the full range of options of versions for operating sytems, languages and language packs. Yet that is exactly what the page http://www.openoffice.org/download/other.html does. All the versions and all the language packs are laid out in one huge table. Probably easier to use than the ASF mirror structure, but still not easy. However, although the page requires Javascript, it does not use Javascript to narrow the choices for the user. AFAICT the Javascript is only used to build the table so it might as well be static HTML that any browser can use. In the past it was, sorry, a pain in the ass to keep this webpage up-to-date as there were always changes in paths, version number and languages (new were included, old were dropped out). Copy paste errors were often occurring. Now it is much easier to update it as the table is generated via JS logic and this logic is filled via a few variables. If it were turned into a static page, I think it might be a better alternative to the ASF mirror structure. IMHO this wouldn't change anything, except for JS or no-JS. So, it seems we need an intermediate step between the green box and the big table. Maybe there should be a separate discussion about how to organise the download pages when the autodetection does not work. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
On Tue, Aug 20, 2013 at 2:34 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: In the past it was, sorry, a pain in the ass to keep this webpage up-to-date as there were always changes in paths, version number and languages (new were included, old were dropped out). Copy paste errors were often occurring. Now it is much easier to update it as the table is generated via JS logic and this logic is filled via a few variables. If it were turned into a static page, I think it might be a better alternative to the ASF mirror structure. IMHO this wouldn't change anything, except for JS or no-JS. So, it seems we need an intermediate step between the green box and the big table. Can the table be generated server-side, perhaps, by a PHP script? Don
Re: Should download pages *require* Javascript?
Am 08/20/2013 08:12 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 5:29 AM, sebbseb...@gmail.com wrote: On 20 August 2013 01:20, Rob Weirrobw...@apache.org wrote: On Mon, Aug 19, 2013 at 6:39 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/19/2013 09:51 PM, schrieb sebb: On 19 August 2013 20:27, Rob Weirrobw...@apache.org wrote: On Mon, Aug 19, 2013 at 2:14 PM, Andrea Pescettipesce...@apache.org wrote: On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/download/other.htmlalso requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). I think this is the key insight. There are actually three cases to consider: 1) Java script disabled 2) Javascript is supported, but not working with our page 3) Javascript working fine. Some of the more recent reports are about #2. These are older versions of Internet Explorer, e.g., I.E. 6. Anoscript block will not help in this case. But if it is possible to detect the broken Javascript without crashing, then it would be possible to treat the browser as if it did not have Javascript. Right, has anybody an idea how to detect such broken JS engines? From this test it looks like the main issue is Internet Explorer before I.E. 8: http://browsershots.org/http://www.openoffice.org/download/ One approach is to see if you can code around that error and get it to work correctly on older I.E. installs. Another approach is to use one of these techniques to detect older I.E. and then fall back to a non-script page: http://msdn.microsoft.com/en-us/library/ms537509%28v=vs.85%29.aspx It might also be possible to use the HTTP headers User-Agent and Accepts-Language as a backstop for when Javascript is not available. This might need some Infra config support. -Rob Marcus Just me-too-ing here...I can't get to the download list right now from my office, with IE8, scripting disabled and a somewhat draconian firewall. I can get to SourceForge, though. Should there be an If that doesn't work, click here link, perhaps pointing to...? http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/ But then we run into the problem that Rainer has already reported: The file names in the visible area are all the same. You cannot differenciate between them - as long as you don't hover the mouse over each one until you have found your favorite. See here: http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-US/ So, a fallback to the Apache mirror is currently the better option. @Roberto: I've lost a bit the latest update. Is it possible to change it in a way that the file names are completely shown? Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
2013/8/20 Marcus (OOo) marcus.m...@wtnet.de Am 08/20/2013 08:12 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 5:29 AM, sebbseb...@gmail.com wrote: On 20 August 2013 01:20, Rob Weirrobw...@apache.org wrote: On Mon, Aug 19, 2013 at 6:39 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/19/2013 09:51 PM, schrieb sebb: On 19 August 2013 20:27, Rob Weirrobw...@apache.org wrote: On Mon, Aug 19, 2013 at 2:14 PM, Andrea Pescettipesce...@apache.org wrote: On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/** download/other.htmlalsohttp://www.openoffice.org/download/other.htmlalso requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-**closer.cgi/openoffice/http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). I think this is the key insight. There are actually three cases to consider: 1) Java script disabled 2) Javascript is supported, but not working with our page 3) Javascript working fine. Some of the more recent reports are about #2. These are older versions of Internet Explorer, e.g., I.E. 6. Anoscript block will not help in this case. But if it is possible to detect the broken Javascript without crashing, then it would be possible to treat the browser as if it did not have Javascript. Right, has anybody an idea how to detect such broken JS engines? From this test it looks like the main issue is Internet Explorer before I.E. 8: http://browsershots.org/http:/**/www.openoffice.org/download/http://browsershots.org/http://www.openoffice.org/download/ One approach is to see if you can code around that error and get it to work correctly on older I.E. installs. Another approach is to use one of these techniques to detect older I.E. and then fall back to a non-script page: http://msdn.microsoft.com/en-**us/library/ms537509%28v=vs.85%**29.aspxhttp://msdn.microsoft.com/en-us/library/ms537509%28v=vs.85%29.aspx It might also be possible to use the HTTP headers User-Agent and Accepts-Language as a backstop for when Javascript is not available. This might need some Infra config support. -Rob Marcus Just me-too-ing here...I can't get to the download list right now from my office, with IE8, scripting disabled and a somewhat draconian firewall. I can get to SourceForge, though. Should there be an If that doesn't work, click here link, perhaps pointing to...? http://sourceforge.net/**projects/openofficeorg.mirror/** files/4.0.0/binaries/http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/ But then we run into the problem that Rainer has already reported: The file names in the visible area are all the same. You cannot differenciate between them - as long as you don't hover the mouse over each one until you have found your favorite. See here: http://sourceforge.net/**projects/openofficeorg.mirror/** files/4.0.0/binaries/en-US/http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-US/ So, a fallback to the Apache mirror is currently the better option. @Roberto: I've lost a bit the latest update. Is it possible to change it in a way that the file names are completely shown? Hi Marcus, I've just added a comment on bugzilla. I was wondering if it would work for you since you're a project admin and by logging in you should be able to see files full names. Correct? Roberto Marcus --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
Am 08/20/2013 02:20 AM, schrieb Rob Weir: On Mon, Aug 19, 2013 at 6:39 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/19/2013 09:51 PM, schrieb sebb: On 19 August 2013 20:27, Rob Weirrobw...@apache.org wrote: On Mon, Aug 19, 2013 at 2:14 PM, Andrea Pescettipesce...@apache.org wrote: On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/download/other.html also requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). I think this is the key insight. There are actually three cases to consider: 1) Java script disabled 2) Javascript is supported, but not working with our page 3) Javascript working fine. Some of the more recent reports are about #2. These are older versions of Internet Explorer, e.g., I.E. 6. Anoscript block will not help in this case. But if it is possible to detect the broken Javascript without crashing, then it would be possible to treat the browser as if it did not have Javascript. Right, has anybody an idea how to detect such broken JS engines? From this test it looks like the main issue is Internet Explorer before I.E. 8: http://browsershots.org/http://www.openoffice.org/download/ OK, but before fixing the issues we should think about which minimum version we need to support. When looking here [1] I doubt that it's worth the big effort to fix all IE 5 problems just to please a handful users. IE 7 could be OK. But IE 6, hm, we need to discuss. One approach is to see if you can code around that error and get it to work correctly on older I.E. installs. Another approach is to use one of these techniques to detect older I.E. and then fall back to a non-script page: http://msdn.microsoft.com/en-us/library/ms537509%28v=vs.85%29.aspx This could be a workaround when all older browsers can be detected. Thanks for the link. [1] http://en.wikipedia.org/wiki/Internet_Explorer#Internet_Explorer_5 BTW: In the Internet company where I'm working we have decided to drop any support for browsers with a market share lower than 4% (regarding our own website tracking via Webtrekk.com). That means we don't fix any problems with IE 7 and older. Othwrwise it's too expensive. If it's working, then fine. If not, then not. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
Am 08/20/2013 08:59 PM, schrieb Roberto Galoppini: 2013/8/20 Marcus (OOo)marcus.m...@wtnet.de Am 08/20/2013 08:12 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 5:29 AM, sebbseb...@gmail.com wrote: On 20 August 2013 01:20, Rob Weirrobw...@apache.org wrote: On Mon, Aug 19, 2013 at 6:39 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/19/2013 09:51 PM, schrieb sebb: On 19 August 2013 20:27, Rob Weirrobw...@apache.orgwrote: On Mon, Aug 19, 2013 at 2:14 PM, Andrea Pescettipesce...@apache.org wrote: On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/** download/other.htmlalsohttp://www.openoffice.org/download/other.htmlalso requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-**closer.cgi/openoffice/http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). I think this is the key insight. There are actually three cases to consider: 1) Java script disabled 2) Javascript is supported, but not working with our page 3) Javascript working fine. Some of the more recent reports are about #2. These are older versions of Internet Explorer, e.g., I.E. 6. Anoscriptblock will not help in this case. But if it is possible to detect the broken Javascript without crashing, then it would be possible to treat the browser as if it did not have Javascript. Right, has anybody an idea how to detect such broken JS engines? From this test it looks like the main issue is Internet Explorer before I.E. 8: http://browsershots.org/http:/**/www.openoffice.org/download/http://browsershots.org/http://www.openoffice.org/download/ One approach is to see if you can code around that error and get it to work correctly on older I.E. installs. Another approach is to use one of these techniques to detect older I.E. and then fall back to a non-script page: http://msdn.microsoft.com/en-**us/library/ms537509%28v=vs.85%**29.aspxhttp://msdn.microsoft.com/en-us/library/ms537509%28v=vs.85%29.aspx It might also be possible to use the HTTP headers User-Agent and Accepts-Language as a backstop for when Javascript is not available. This might need some Infra config support. -Rob Marcus Just me-too-ing here...I can't get to the download list right now from my office, with IE8, scripting disabled and a somewhat draconian firewall. I can get to SourceForge, though. Should there be an If that doesn't work, click here link, perhaps pointing to...? http://sourceforge.net/**projects/openofficeorg.mirror/** files/4.0.0/binaries/http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/ But then we run into the problem that Rainer has already reported: The file names in the visible area are all the same. You cannot differenciate between them - as long as you don't hover the mouse over each one until you have found your favorite. See here: http://sourceforge.net/**projects/openofficeorg.mirror/** files/4.0.0/binaries/en-US/http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-US/ So, a fallback to the Apache mirror is currently the better option. @Roberto: I've lost a bit the latest update. Is it possible to change it in a way that the file names are completely shown? Hi Marcus, I've just added a comment on bugzilla. I was wondering if it would work for you since you're a project admin and by logging in you should be able to see files full names. Correct? Right, I've checked with 3 languages and for all I can see the full filenames. No additional text box on the right. Is this something that can be enrolled for all users? Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
Am 08/20/2013 08:37 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 2:34 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: In the past it was, sorry, a pain in the ass to keep this webpage up-to-date as there were always changes in paths, version number and languages (new were included, old were dropped out). Copy paste errors were often occurring. Now it is much easier to update it as the table is generated via JS logic and this logic is filled via a few variables. If it were turned into a static page, I think it might be a better alternative to the ASF mirror structure. IMHO this wouldn't change anything, except for JS or no-JS. So, it seems we need an intermediate step between the green box and the big table. Can the table be generated server-side, perhaps, by a PHP script? Good question but I don't know. Mostly it depends on: - can the script grab the content of the JS variables from the webpage? - which server do you mean? - who is willing/able to change it into PHP? However, I would like to keep everything download-releated in a single area. It's simply better to maintain. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
On Tue, Aug 20, 2013 at 3:22 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 08/20/2013 08:37 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 2:34 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: In the past it was, sorry, a pain in the ass to keep this webpage up-to-date as there were always changes in paths, version number and languages (new were included, old were dropped out). Copy paste errors were often occurring. Now it is much easier to update it as the table is generated via JS logic and this logic is filled via a few variables. If it were turned into a static page, I think it might be a better alternative to the ASF mirror structure. IMHO this wouldn't change anything, except for JS or no-JS. So, it seems we need an intermediate step between the green box and the big table. Can the table be generated server-side, perhaps, by a PHP script? Good question but I don't know. Mostly it depends on: - can the script grab the content of the JS variables from the webpage? Not sure I understand this question. A PHP script would be pushing HTML (and perhaps embedded JS) from the server...it runs before the JS, and therefore before any JS variables get set. Where does the JS now get the data to build the table? - which server do you mean? Whatever server is hosting the download page. A PHP script is server-side and can serve as a webpage -- rather than having an index.html, you'd have an index.php. - who is willing/able to change it into PHP? This is the biggest question, really. :) I believe I'm able to do the PHP, though you'd probably want matching CSS, which isn't really a strong point for me. Don
Re: Should download pages *require* Javascript?
2013/8/20 Marcus (OOo) marcus.m...@wtnet.de Am 08/20/2013 08:59 PM, schrieb Roberto Galoppini: 2013/8/20 Marcus (OOo)marcus.m...@wtnet.de Am 08/20/2013 08:12 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 5:29 AM, sebbseb...@gmail.com wrote: On 20 August 2013 01:20, Rob Weirrobw...@apache.org wrote: On Mon, Aug 19, 2013 at 6:39 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/19/2013 09:51 PM, schrieb sebb: On 19 August 2013 20:27, Rob Weirrobw...@apache.orgwrote: On Mon, Aug 19, 2013 at 2:14 PM, Andrea Pescetti pesce...@apache.org wrote: On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/** download/other.htmlalsohttp:/**/www.openoffice.org/download/** other.htmlalsohttp://www.openoffice.org/download/other.htmlalso requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-closer.cgi/openoffice/http://www.apache.org/dyn/aoo-**closer.cgi/openoffice/ http:**//www.apache.org/dyn/aoo-**closer.cgi/openoffice/http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). I think this is the key insight. There are actually three cases to consider: 1) Java script disabled 2) Javascript is supported, but not working with our page 3) Javascript working fine. Some of the more recent reports are about #2. These are older versions of Internet Explorer, e.g., I.E. 6. Anoscriptblock will not help in this case. But if it is possible to detect the broken Javascript without crashing, then it would be possible to treat the browser as if it did not have Javascript. Right, has anybody an idea how to detect such broken JS engines? From this test it looks like the main issue is Internet Explorer before I.E. 8: http://browsershots.org/http://www.openoffice.org/**download/http://browsershots.org/http:/**/www.openoffice.org/download/ http://browsershots.**org/http://www.openoffice.org/**download/http://browsershots.org/http://www.openoffice.org/download/ One approach is to see if you can code around that error and get it to work correctly on older I.E. installs. Another approach is to use one of these techniques to detect older I.E. and then fall back to a non-script page: http://msdn.microsoft.com/en-us/library/ms537509%28v=vs.** 85%**29.aspxhttp://msdn.**microsoft.com/en-us/library/** ms537509%28v=vs.85%29.aspxhttp://msdn.microsoft.com/en-us/library/ms537509%28v=vs.85%29.aspx It might also be possible to use the HTTP headers User-Agent and Accepts-Language as a backstop for when Javascript is not available. This might need some Infra config support. -Rob Marcus Just me-too-ing here...I can't get to the download list right now from my office, with IE8, scripting disabled and a somewhat draconian firewall. I can get to SourceForge, though. Should there be an If that doesn't work, click here link, perhaps pointing to...? http://sourceforge.net/projects/openofficeorg.mirror/http://sourceforge.net/**projects/openofficeorg.mirror/** files/4.0.0/binaries/http://**sourceforge.net/projects/** openofficeorg.mirror/files/4.**0.0/binaries/http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/ But then we run into the problem that Rainer has already reported: The file names in the visible area are all the same. You cannot differenciate between them - as long as you don't hover the mouse over each one until you have found your favorite. See here: http://sourceforge.net/projects/openofficeorg.mirror/http://sourceforge.net/**projects/openofficeorg.mirror/** files/4.0.0/binaries/en-US/ht**tp://sourceforge.net/projects/** openofficeorg.mirror/files/4.**0.0/binaries/en-US/http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-US/ So, a fallback to the Apache mirror is currently the better option. @Roberto: I've lost a bit the latest update. Is it possible to change it in a way that the file names are completely shown? Hi Marcus, I've just added a comment on bugzilla. I was wondering if it would work for you since you're a project admin and by logging in you should be able to see files full names. Correct? Right, I've checked with 3 languages and for all I can see the full filenames. No additional text box on the right. Cool. Is this something that can be enrolled for all users? Not short term, since it would require a complete UI redesign and
Re: Should download pages *require* Javascript?
Am 08/20/2013 09:45 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 3:22 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/20/2013 08:37 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 2:34 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: In the past it was, sorry, a pain in the ass to keep this webpage up-to-date as there were always changes in paths, version number and languages (new were included, old were dropped out). Copy paste errors were often occurring. Now it is much easier to update it as the table is generated via JS logic and this logic is filled via a few variables. If it were turned into a static page, I think it might be a better alternative to the ASF mirror structure. IMHO this wouldn't change anything, except for JS or no-JS. So, it seems we need an intermediate step between the green box and the big table. Can the table be generated server-side, perhaps, by a PHP script? Good question but I don't know. Mostly it depends on: - can the script grab the content of the JS variables from the webpage? Not sure I understand this question. A PHP script would be pushing HTML (and perhaps embedded JS) from the server...it runs before the JS, and therefore before any JS variables get set. Where does the JS now get the data to build the table? The script get its data from some variables in the globalvars.js file. - which server do you mean? Whatever server is hosting the download page. A PHP script is server-side and can serve as a webpage -- rather than having an index.html, you'd have an index.php. OK, seems without Infra support this isn't possbile. - who is willing/able to change it into PHP? This is the biggest question, really. :) I believe I'm able to do the PHP, though you'd probably want matching CSS, which isn't really a strong point for me. I've no clue about PHP. So, I cannot help directly. ;-) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
On Tue, Aug 20, 2013 at 3:52 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 08/20/2013 09:45 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 3:22 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: - which server do you mean? Whatever server is hosting the download page. A PHP script is server-side and can serve as a webpage -- rather than having an index.html, you'd have an index.php. OK, seems without Infra support this isn't possbile. You're currently editing server-side files in order to change the embedded javascript, right? What files are you modifying? Don
Re: Should download pages *require* Javascript?
Am 08/20/2013 10:23 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 3:52 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/20/2013 09:45 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 3:22 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: - which server do you mean? Whatever server is hosting the download page. A PHP script is server-side and can serve as a webpage -- rather than having an index.html, you'd have an index.php. OK, seems without Infra support this isn't possbile. You're currently editing server-side files in order to change the embedded javascript, right? What files are you modifying? I don't know if server-side is correct when the JS files are transferred to the local browser and executed there. Is it then client-side? I only use files that are stored in w.oo.o/download/. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
On Tue, Aug 20, 2013 at 1:50 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 08/20/2013 10:23 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 3:52 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/20/2013 09:45 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 3:22 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: - which server do you mean? Whatever server is hosting the download page. A PHP script is server-side and can serve as a webpage -- rather than having an index.html, you'd have an index.php. OK, seems without Infra support this isn't possbile. You're currently editing server-side files in order to change the embedded javascript, right? What files are you modifying? I don't know if server-side is correct when the JS files are transferred to the local browser and executed there. Is it then client-side? yes...we don't use any server-side js. I only use files that are stored in w.oo.o/download/. Marcus --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK When in doubt, cop an attitude. -- Cat laws
Re: Should download pages *require* Javascript?
On Tue, Aug 20, 2013 at 4:58 PM, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Aug 20, 2013 at 1:50 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 08/20/2013 10:23 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 3:52 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/20/2013 09:45 PM, schrieb Donald Whytock: On Tue, Aug 20, 2013 at 3:22 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: - which server do you mean? Whatever server is hosting the download page. A PHP script is server-side and can serve as a webpage -- rather than having an index.html, you'd have an index.php. OK, seems without Infra support this isn't possbile. You're currently editing server-side files in order to change the embedded javascript, right? What files are you modifying? I don't know if server-side is correct when the JS files are transferred to the local browser and executed there. Is it then client-side? yes...we don't use any server-side js. The trick is to work with the Apache CMS. We already have a system where source files (like MDText and HTML) are converted into HTML which we then review and publish. That's how our templating works. The glue is Perl. And I bet Python is used behind the scenes for the MDText conversion. This is not interactive on a per-request basis. But if we can think of this as a data-driven problem where we have an XML (or CSV or some other structured data file) that we want to convert into some web content like JSON or HTML, and have the web content automatically regenerated whenever the underlying data file changes, then we might consider the CMS as part of the solution. This could work well for our update notification scripts as well. These should also probably be data drive. And I bet they would use some of the same data that is needed for the download pages. Wouldn't it be cool to update an XML file describing our release files and then have it automatically generate the download page logic as well as the update notification XML's? -Rob I only use files that are stored in w.oo.o/download/. Marcus --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK When in doubt, cop an attitude. -- Cat laws - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
On Tue, Aug 20, 2013 at 5:06 PM, Rob Weir robw...@apache.org wrote: The trick is to work with the Apache CMS. We already have a system where source files (like MDText and HTML) are converted into HTML which we then review and publish. That's how our templating works. The glue is Perl. And I bet Python is used behind the scenes for the MDText conversion. This is not interactive on a per-request basis. But if we can think of this as a data-driven problem where we have an XML (or CSV or some other structured data file) that we want to convert into some web content like JSON or HTML, and have the web content automatically regenerated whenever the underlying data file changes, then we might consider the CMS as part of the solution. This could work well for our update notification scripts as well. These should also probably be data drive. And I bet they would use some of the same data that is needed for the download pages. Wouldn't it be cool to update an XML file describing our release files and then have it automatically generate the download page logic as well as the update notification XML's? It'd probably be good to have the info in generic XML anyway. That could be AJAX-ed by JS client-side or used server-side to dynamically generate the page. Don
Should download pages *require* Javascript?
The download page at present requires Javascript. Without Javascript, there is no obvious way to download AOO 4.0 at all. Note that the page http://www.openoffice.org/download/other.html also requires Javascript! It's nice to be able to use Javascript to guess which download the user wants, but I don't think that this convenience should be at the expense of preventing users from finding the download link if they don't have Javascript (or they have a broken version of Javascript). How about having drop-down lists for the OS and Language? Javascript could be used to preset the values, but at least the user would remain in control, e.g. if the Javascript failed to recognise their system or they wanted to download a different language from the one supported by their browser. Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/download/other.html also requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Should download pages *require* Javascript?
Am 08/19/2013 08:14 PM, schrieb Andrea Pescetti: On 19/08/2013 sebb wrote: Note that the page http://www.openoffice.org/download/other.html also requires Javascript! This is not so good. The noscript option should direct the user to http://www.apache.org/dyn/aoo-closer.cgi/openoffice/ (users who disable JavaScript are likely to be able to browse the FTP-like structure they will see there). That's a good alternative as this is already available and completely working. So the green NOJS box could link to this webpage. Marcus Whatever method is chosen, I think it should be possible to download AOO without the use of Javascript. It should also be possible to download OpenOffice in the cases where JavaScript parsing breaks, i.e., we should have alternative download links that are always visible (working JavaScript, broken Javascript, no JavaScript). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
