Re: [WWW] I think we need a redo for /download/other.html
Kay Schenk wrote: Do to recent updates to the download logic /download/other.html still exists as an entity but its basically blank since the table no longer renders. According to our Google Analytics, this page has quite a number of references, including using it as a convenient way to show what languages we have releases for -- http://www.openoffice.org/projects/native-lang.html. Should we retool this based on the new changes? Or ... even without js, to just provide basic information like the native-lang name, and links over to the latest binary area for that language on SourceForge? Example: German (de) - http://sourceforge.net/projects/openofficeorg.mirror/files/4.1.0/binaries/de/ or Out of curiosity: the use of javascript to build the table is because you prefer javascript or a plain html would be good as well? Because after my digging last time, I'm pretty sure (well, I mostly did it) that it's possible to generate the entire table during the build adding few subs to view.pm and using some trick. For example I used a piece of JSON enclosed in kind of HTML tags that I then parsed and converted into the table. You can see the code at [1] it doesn't work entirely, for example the SDK table is not built and the version in the title is not added, but the rest is more or less working. Emanuele [1] https://gist.github.com/emanuele45/e7f7e73d05172da5981c - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
It would be better if you use the site to show it. That said, the reason for the table is because we werent that open to use Javascript. We would still argue that we have a noscript code. Regardless if its XML, JSON or HTML or even a bash script to autogenerate the HTML from a sqlite datasource. On 7/23/14, Emanuele emanuel...@gmail.com wrote: Kay Schenk wrote: Do to recent updates to the download logic /download/other.html still exists as an entity but its basically blank since the table no longer renders. According to our Google Analytics, this page has quite a number of references, including using it as a convenient way to show what languages we have releases for -- http://www.openoffice.org/projects/native-lang.html. Should we retool this based on the new changes? Or ... even without js, to just provide basic information like the native-lang name, and links over to the latest binary area for that language on SourceForge? Example: German (de) - http://sourceforge.net/projects/openofficeorg.mirror/files/4.1.0/binaries/de/ or Out of curiosity: the use of javascript to build the table is because you prefer javascript or a plain html would be good as well? Because after my digging last time, I'm pretty sure (well, I mostly did it) that it's possible to generate the entire table during the build adding few subs to view.pm and using some trick. For example I used a piece of JSON enclosed in kind of HTML tags that I then parsed and converted into the table. You can see the code at [1] it doesn't work entirely, for example the SDK table is not built and the version in the title is not added, but the rest is more or less working. Emanuele [1] https://gist.github.com/emanuele45/e7f7e73d05172da5981c - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor 882C 4389 3C27 E8DF 41B9 5C4C 1DB7 9D1C 7F4C 2614 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
Alexandro Colorado wrote: It would be better if you use the site to show it. I'm showing you the code, not the result, because the result is an almost exact copy of the table you already know (provided you have javascript enabled), only in pure HTML (no javascript required). The difference is that it is generated while building the site, and being the generation the point of my comment, I published only that part. That said, the reason for the table is because we werent that open to use Javascript. We would still argue that we have a noscript code. Regardless if its XML, JSON or HTML or even a bash script to autogenerate the HTML from a sqlite datasource. Not sure what you want to say here: is it fine with you to use js? Then it's fine with me as well. ;-) Emanuele - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
Am 07/23/2014 02:34 PM, schrieb Emanuele: Kay Schenk wrote: Do to recent updates to the download logic /download/other.html still exists as an entity but its basically blank since the table no longer renders. According to our Google Analytics, this page has quite a number of references, including using it as a convenient way to show what languages we have releases for -- http://www.openoffice.org/projects/native-lang.html. Should we retool this based on the new changes? Or ... even without js, to just provide basic information like the native-lang name, and links over to the latest binary area for that language on SourceForge? Example: German (de) - http://sourceforge.net/projects/openofficeorg.mirror/files/4.1.0/binaries/de/ or Out of curiosity: the use of javascript to build the table is because you prefer javascript or a plain html would be good as well? before this JS table we had indeed plain HTML that had to be updated for every new release (links, version, data). No fun and error prone. So, I've created a script that has done this automatically. I've used JS because there was nothing else possible - at least not for me. ;-) Because after my digging last time, I'm pretty sure (well, I mostly did it) that it's possible to generate the entire table during the build adding few subs to view.pm and using some trick. For example I used a piece of JSON enclosed in kind of HTML tags that I then parsed and converted into the table. You can see the code at [1] it doesn't work entirely, for example the SDK table is not built and the version in the title is not added, but the rest is more or less working. Emanuele [1] https://gist.github.com/emanuele45/e7f7e73d05172da5981c That looks good. However, I think I've to disappoint you a bit. ;-( Now that we have the drop-down-box on the main download webpage, the users can choose themselves what they want to have. No need for a large table anymore. We shouldn't simply delete the webpage as the Google hits are really high and shouldn't get lost. But for AOO 4.1.1 we can place a short text and link to the main download. So, we can fade out this over the time. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
On 7/23/14, Emanuele emanuel...@gmail.com wrote: Alexandro Colorado wrote: It would be better if you use the site to show it. I'm showing you the code, not the result, because the result is an almost exact copy of the table you already know (provided you have javascript enabled), only in pure HTML (no javascript required). The difference is that it is generated while building the site, and being the generation the point of my comment, I published only that part. That said, the reason for the table is because we werent that open to use Javascript. We would still argue that we have a noscript code. Regardless if its XML, JSON or HTML or even a bash script to autogenerate the HTML from a sqlite datasource. Not sure what you want to say here: is it fine with you to use js? Then it's fine with me as well. ;-) Yes, sorry it didnt make sense, my point is how to allocate the information of the download, I think embeded in the JS is not good, and we could have a different feed (whenever XML, JSON or other). The point is to make it easily maintainable. Emanuele - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor 882C 4389 3C27 E8DF 41B9 5C4C 1DB7 9D1C 7F4C 2614 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
On 07/23/2014 12:17 PM, Marcus (OOo) wrote: Am 07/23/2014 02:34 PM, schrieb Emanuele: Kay Schenk wrote: Do to recent updates to the download logic /download/other.html still exists as an entity but its basically blank since the table no longer renders. According to our Google Analytics, this page has quite a number of references, including using it as a convenient way to show what languages we have releases for -- http://www.openoffice.org/projects/native-lang.html. Should we retool this based on the new changes? Or ... even without js, to just provide basic information like the native-lang name, and links over to the latest binary area for that language on SourceForge? Example: German (de) - http://sourceforge.net/projects/openofficeorg.mirror/files/4.1.0/binaries/de/ or Out of curiosity: the use of javascript to build the table is because you prefer javascript or a plain html would be good as well? before this JS table we had indeed plain HTML that had to be updated for every new release (links, version, data). No fun and error prone. So, I've created a script that has done this automatically. I've used JS because there was nothing else possible - at least not for me. ;-) Because after my digging last time, I'm pretty sure (well, I mostly did it) that it's possible to generate the entire table during the build adding few subs to view.pm and using some trick. For example I used a piece of JSON enclosed in kind of HTML tags that I then parsed and converted into the table. You can see the code at [1] it doesn't work entirely, for example the SDK table is not built and the version in the title is not added, but the rest is more or less working. Emanuele [1] https://gist.github.com/emanuele45/e7f7e73d05172da5981c That looks good. However, I think I've to disappoint you a bit. ;-( Now that we have the drop-down-box on the main download webpage, the users can choose themselves what they want to have. No need for a large table anymore. We shouldn't simply delete the webpage as the Google hits are really high and shouldn't get lost. But for AOO 4.1.1 we can place a short text and link to the main download. So, we can fade out this over the time. Marcus I think the downlaod drop-down box is a HUGE step forward for our user base, no doubt about it. But I really LIKE other.html as well. I hope we can find some middle ground on keeping it. Emanuele's code here has got me thinking about investigating the CMS/Django approach more. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK To be trusted is a greater compliment than being loved. -- George MacDonald - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
On 7/23/14, Alexandro Colorado j...@oooes.org wrote: On 7/23/14, Emanuele emanuel...@gmail.com wrote: Alexandro Colorado wrote: It would be better if you use the site to show it. I'm showing you the code, not the result, because the result is an almost exact copy of the table you already know (provided you have javascript enabled), only in pure HTML (no javascript required). The difference is that it is generated while building the site, and being the generation the point of my comment, I published only that part. That said, the reason for the table is because we werent that open to use Javascript. We would still argue that we have a noscript code. Regardless if its XML, JSON or HTML or even a bash script to autogenerate the HTML from a sqlite datasource. Not sure what you want to say here: is it fine with you to use js? Then it's fine with me as well. ;-) By the way here is a sample of a JQuery Filter table that could be a big step forward in UX. http://sunnywalker.github.io/jQuery.FilterTable/filtertable-existing-input.html Here is the plugin source: https://github.com/sunnywalker/jQuery.FilterTable Yes, sorry it didnt make sense, my point is how to allocate the information of the download, I think embeded in the JS is not good, and we could have a different feed (whenever XML, JSON or other). The point is to make it easily maintainable. Emanuele - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor 882C 4389 3C27 E8DF 41B9 5C4C 1DB7 9D1C 7F4C 2614 -- Alexandro Colorado Apache OpenOffice Contributor 882C 4389 3C27 E8DF 41B9 5C4C 1DB7 9D1C 7F4C 2614 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
Am 07/23/2014 11:42 PM, schrieb Alexandro Colorado: On 7/23/14, Alexandro Coloradoj...@oooes.org wrote: On 7/23/14, Emanueleemanuel...@gmail.com wrote: Alexandro Colorado wrote: It would be better if you use the site to show it. I'm showing you the code, not the result, because the result is an almost exact copy of the table you already know (provided you have javascript enabled), only in pure HTML (no javascript required). The difference is that it is generated while building the site, and being the generation the point of my comment, I published only that part. That said, the reason for the table is because we werent that open to use Javascript. We would still argue that we have anoscript code. Regardless if its XML, JSON or HTML or even a bash script to autogenerate the HTML from a sqlite datasource. Not sure what you want to say here: is it fine with you to use js? Then it's fine with me as well. ;-) By the way here is a sample of a JQuery Filter table that could be a big step forward in UX. http://sunnywalker.github.io/jQuery.FilterTable/filtertable-existing-input.html Here is the plugin source: https://github.com/sunnywalker/jQuery.FilterTable nice find. Putting the filter box - enlarged - more visible into the middle right above the table could be indeed a big step forward in UX. Marcus Yes, sorry it didnt make sense, my point is how to allocate the information of the download, I think embeded in the JS is not good, and we could have a different feed (whenever XML, JSON or other). The point is to make it easily maintainable. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
Am 07/23/2014 11:34 PM, schrieb Kay Schenk: On 07/23/2014 12:17 PM, Marcus (OOo) wrote: Am 07/23/2014 02:34 PM, schrieb Emanuele: Kay Schenk wrote: Do to recent updates to the download logic /download/other.html still exists as an entity but its basically blank since the table no longer renders. According to our Google Analytics, this page has quite a number of references, including using it as a convenient way to show what languages we have releases for -- http://www.openoffice.org/projects/native-lang.html. Should we retool this based on the new changes? Or ... even without js, to just provide basic information like the native-lang name, and links over to the latest binary area for that language on SourceForge? Example: German (de) - http://sourceforge.net/projects/openofficeorg.mirror/files/4.1.0/binaries/de/ or Out of curiosity: the use of javascript to build the table is because you prefer javascript or a plain html would be good as well? before this JS table we had indeed plain HTML that had to be updated for every new release (links, version, data). No fun and error prone. So, I've created a script that has done this automatically. I've used JS because there was nothing else possible - at least not for me. ;-) Because after my digging last time, I'm pretty sure (well, I mostly did it) that it's possible to generate the entire table during the build adding few subs to view.pm and using some trick. For example I used a piece of JSON enclosed in kind of HTML tags that I then parsed and converted into the table. You can see the code at [1] it doesn't work entirely, for example the SDK table is not built and the version in the title is not added, but the rest is more or less working. Emanuele [1] https://gist.github.com/emanuele45/e7f7e73d05172da5981c That looks good. However, I think I've to disappoint you a bit. ;-( Now that we have the drop-down-box on the main download webpage, the users can choose themselves what they want to have. No need for a large table anymore. We shouldn't simply delete the webpage as the Google hits are really high and shouldn't get lost. But for AOO 4.1.1 we can place a short text and link to the main download. So, we can fade out this over the time. Marcus I think the downlaod drop-down box is a HUGE step forward for our user base, no doubt about it. But I really LIKE other.html as well. I hope we can find some middle ground on keeping it. Emanuele's code here has got me thinking about investigating the CMS/Django approach more. with Alexandro's suggestion it can get really nice. However, I don't know why we should keep a large table with links when the whole functionality now existing in the greeen download box. If it's the text around the table we can keep into and turn the page into an information webpage. So, I'm curious about your reason(s). :-) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
Marcus (OOo) wrote: However, I don't know why we should keep a large table with links when the whole functionality now existing in the greeen download box. If the approach by Emanuele yields (this is the impression I got from the Github code) a pure HTML output, not depending on JS, and can be automated, then this table is the basic version of the download page good for many reasons, from accessibility to people in text-only mode. I admit these are rare use cases, but this would be a nice to have advantage. Provided it can be automated or semi-automated at every release, otherwise we go back to the problem of manual maintenance... Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
Am 07/24/2014 12:16 AM, schrieb Andrea Pescetti: Marcus (OOo) wrote: However, I don't know why we should keep a large table with links when the whole functionality now existing in the greeen download box. If the approach by Emanuele yields (this is the impression I got from the Github code) a pure HTML output, not depending on JS, and can be automated, then this table is the basic version of the download page good for many reasons, from accessibility to people in text-only mode. I admit these are rare use cases, but this would be a nice to have OK, could be an advantage for some. advantage. Provided it can be automated or semi-automated at every release, otherwise we go back to the problem of manual maintenance... Yes, the header data in the starting JSON data ( version: 4.1.0, ... beta_version: 4.1.1 ) needs to be exchanged with a connection to the globalvars.js file or something from SVN. Otherwise we have to keep 2 places up-to-date. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WWW] I think we need a redo for /download/other.html
On Sun, Jul 20, 2014 at 3:40 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 07/20/2014 11:58 PM, schrieb Kay Schenk: Do to recent updates to the download logic /download/other.html still exists as an entity but its basically blank since the table no longer renders. ah, thanks. I've fixed this. Reason is the recent change to use the variable names as object properties. wonderful! thanks for taking of this so quickly... According to our Google Analytics, this page has quite a number of That's unforfortunately a reason why we shouldn't simply delete it. references, including using it as a convenient way to show what languages we have releases for -- http://www.openoffice.org/ projects/native-lang.html. Should we retool this based on the new changes? Or ... even without js, to just provide basic information like the native-lang name, and links over to the latest binary area for that language on SourceForge? Please no hard links as this is hard to maintain. We see this already with many localized webpages. ;-) or Our long term goal should be to get rid of it as it is of no use anymore with the new green download box - accept for satisfying Google search hits. If you see somewhere links to other.html please change it to the main download. Marcus OK...I really like the overview nature of other.html despite the fact that we now have a better way for individual users to quickly find their preferred download. I hope it never goes away! :) Thanks again... - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK To be trusted is a greater compliment than being loved. -- George MacDonald
