Re: Change of web site layout
On Tue, Jun 17, 2014 at 11:19 AM, Daniel Gruno wrote: > I have tried to incorporate your suggestions into my own proposal, and > the result can be seen at http://httpd.apache.pw/index2 I really like this version, +1 for me. However, as André, I'd also like the ability to download the archives (hence navigate on the versions' tabs) without javascript and ajax.googleapis enabled. Thanks a lot for you work anyway.
Re: svn commit: r1598946 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_fdpass.c
Finally, won't have time tonight :( and this week and week-end will be already busy. CJ Le 17/06/2014 11:31, Marion et Christophe JAILLET a écrit : Hi, obviously, no problem for me for merging the 2 in the same proposal. I'll have a look at it tonight. CJ
Re: Change of web site layout
On 17 Jun 2014, at 14:24, Rich Bowen wrote: > On 06/17/2014 05:19 AM, Daniel Gruno wrote: >> On 06/17/2014 12:46 AM, Tim Bannister wrote: >>> On 16 Jun 2014, at 22:23, Rich Bowen wrote: >>> >> In addition, I have some comments about your design proposal: >> >> - The apache.org design might be changing RSN (it's being discussed), so >> using it might not be the most optimal route. > There is no requirement that a project site look like the main foundation > site. Pick any project. Say, http://flume.apache.org/ or > http://cloudstack.apache.org/ or http://etch.apache.org/ - each has their own > unique feel. If I could, I'd have httpd and Tomcat use the same site structure. There two projects are complements / substitutes, and users don't particularly like learning a new site layout for each thing. Tomcat has the same sort of problem with having multiple versions that are out there in production use, too. …I'm saying this even though I don't have the time or the contacts to liaise with the Tomcat web people properly. >> - You use JavaScript to display the tabs. This, apparently, needs to be >> done in a way that people without JS can view it as well. I have tried >> to accommodate that in my second proposal (see link above). >> - The documentation link just leads to our boring and unattractive docs >> front page. I would prefer if people can go directly to documentation >> for e.g. 2.4 right away from the front page (dropdowns?). > > Yes, please. “+1” to this. -- Tim Bannister - +44 7980408788 - is...@jellybaby.net
Re: Change of web site layout
On 06/17/2014 05:19 AM, Daniel Gruno wrote: On 06/17/2014 12:46 AM, Tim Bannister wrote: On 16 Jun 2014, at 22:23, Rich Bowen wrote: In addition, I have some comments about your design proposal: - The apache.org design might be changing RSN (it's being discussed), so using it might not be the most optimal route. There is no requirement that a project site look like the main foundation site. Pick any project. Say, http://flume.apache.org/ or http://cloudstack.apache.org/ or http://etch.apache.org/ - each has their own unique feel. And, frankly, at this point in time, I think that basing our design after the http://apache.org/ design is not at all desirable, as that site has a strong feeling of nostalgia too. - Using the apache.org design will require making a ton of new pages, as the menu is not as complex as the original design or my proposal. There are some new pages that need to be made, but I'm concerned about getting bogged down and this never happening. - Where are the download/changelog links? We need to push that, not hide it away. +1.. The call to action for the httpd site is Documentation, Release/Change notes, and Download, probably in that order. Ideally, we push "get involved" a lot, too. - The user guide/tips is a great idea on paper, but would require yet more new documents, which won't be done until November (at ApacheCon). perhaps we could just add those to the carousel? Yeah, we need to not predicate a design on a bunch of new content. The content will come, I'm sure, and I've actually been thinking about a bunch of new content over the last few days (I just went to a documentation conference!) but it's going to be a long time coming. - Adding a search bar is always fun to do, but we don't have the tech to implement a search as it is, unless we use Google (which people can just use themselves) The docs already use a custom Google Search thingy. We should extend that to the entire httpd.a.o site rather than try to implement something on our own. Years ago, I approached the Lucene people about site search, but that never got anywhere. If someone wants to try again, it would be great to use our own technology. But I don't know how to get from here to there. - You use JavaScript to display the tabs. This, apparently, needs to be done in a way that people without JS can view it as well. I have tried to accommodate that in my second proposal (see link above). - The documentation link just leads to our boring and unattractive docs front page. I would prefer if people can go directly to documentation for e.g. 2.4 right away from the front page (dropdowns?). Yes, please. I'd like to do something better with the main docs landing page but until then, bypassing it would be grand. I see this discussion going two ways now: 1) Which overall layout should we pick for the site? 2) How do we present out project on the front page? I think both proposals are valid, and I won't go into "who's got the prettiest design", as that's entirely personal opinions, but I think the second proposal leaves people wondering "where can I get it, and where can I find the changelog/docs/release notes quickly". Not that there aren't links to some of it, it's just not that obvious where to click. The question needs to be, what do people come to the httpd site for? This is where some actual site usage stats would be lovely to have, but I don't think we've ever gotten around to doing that. (Tangent - Daniel - you think this is something that Infra would be the right place to go, or should we look at doing this ourselves?) Anecdotally, I believe that the majority of people come for the reasons enumerated above - Documentation, Change/Release notes (what changed? Was it a security release?), and Downloads as a distant third, since most folks are using packages in this century. I'd like to play up the "get involved" bit a lot more than we currently do. So, whatever we do, these are the links that need to be most prominent, and to stand out in the navigation. I think Daniel's design accomplishes this, while also giving the site a more modern look. This latter part - the more modern look - is not a "nice to have", but really is the reason for this exercise in the first place. Our existing site has all the information, and the links to get to it, but reinforces the growing perception that Apache httpd is yesterday's web server. httpd developers are doing amazingly cool stuff, and we suck at telling the world about it. (By "we", I mean the docs folks, primarily.) We present it as dry and dusty, and cleverly conceal the fact that we're out on the bleeding edge and everyone is copying us, but marketing it better. Anyways, a huge +1 from me to pushing forward with the work that Daniel is doing, and also to incorporating Tim's remarks into this, as he seems to have a clear idea of the kind of information that folks want to hav
Re: svn commit: r1598946 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_fdpass.c
thanks, done in r1603115. On Tue, Jun 17, 2014 at 11:31 AM, Marion et Christophe JAILLET wrote: > Hi, > > > > obviously, no problem for me for merging the 2 in the same proposal. > > I'll have a look at it tonight. > > > CJ > >> Message du 17/06/14 10:02 >> De : "Yann Ylavic" >> A : jaillet...@apache.org, "httpd" >> Copie à : >> Objet : Re: svn commit: r1598946 - in /httpd/httpd/trunk: CHANGES >> modules/proxy/mod_proxy_fdpass.c > >> >> Christophe, >> >> do you agree if I modify the 2.4.x proposal with : >> >> Index: STATUS >> === >> --- STATUS (revision 1603074) >> +++ STATUS (working copy) >> @@ -224,12 +224,14 @@ >> 2.4.x patch: trunk works (modulo CHANGES) >> +1: ylavic >> >> - * mod_proxy_fdpass: Fix computation of the size of 'struct sockaddr_un' >> - when passed to 'connec()'. >> - [Graham Dumpleton ] > >> + * mod_proxy: Don't limit the size of the connectable Unix Domain >> Socket paths. >> + [Graham Dumpleton , Christophe Jaillet, > >> + Yann Ylavic] >> trunk patch: http://svn.apache.org/r1598946 >> - 2.4.x patch: trunk works (modulo CHANGES) >> - +1: jailletc36 >> + http://svn.apache.org/r1602989 >> + 2.4.x patch: >> http://people.apache.org/~ylavic/httpd-2.4.x-ap_proxy_connect_uds.patch >> + (modulo CHANGES/MMN) >> + +1: ylavic >> >> since both commits seem to address the same concern? >> Or should I add a new one? >> >> Please note you would have to re-vote. >> >> Regards, >> Yann. >>
Re: svn commit: r1598946 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_fdpass.c
Hi, obviously, no problem for me for merging the 2 in the same proposal. I'll have a look at it tonight. CJ > Message du 17/06/14 10:02 > De : "Yann Ylavic" > A : jaillet...@apache.org, "httpd" > Copie à : > Objet : Re: svn commit: r1598946 - in /httpd/httpd/trunk: CHANGES > modules/proxy/mod_proxy_fdpass.c > > Christophe, > > do you agree if I modify the 2.4.x proposal with : > > Index: STATUS > === > --- STATUS (revision 1603074) > +++ STATUS (working copy) > @@ -224,12 +224,14 @@ > 2.4.x patch: trunk works (modulo CHANGES) > +1: ylavic > > - * mod_proxy_fdpass: Fix computation of the size of 'struct sockaddr_un' > - when passed to 'connec()'. > - [Graham Dumpleton ] > + * mod_proxy: Don't limit the size of the connectable Unix Domain > Socket paths. > + [Graham Dumpleton , Christophe Jaillet, > + Yann Ylavic] > trunk patch: http://svn.apache.org/r1598946 > - 2.4.x patch: trunk works (modulo CHANGES) > - +1: jailletc36 > + http://svn.apache.org/r1602989 > + 2.4.x patch: > http://people.apache.org/~ylavic/httpd-2.4.x-ap_proxy_connect_uds.patch > + (modulo CHANGES/MMN) > + +1: ylavic > > since both commits seem to address the same concern? > Or should I add a new one? > > Please note you would have to re-vote. > > Regards, > Yann. >
Re: Change of web site layout
On 06/17/2014 12:46 AM, Tim Bannister wrote: > On 16 Jun 2014, at 22:23, Rich Bowen wrote: > >> >>> Apache httpd being #1 on the internet is great news, but personally I'd put >>> that on the carousel. What sort of leading text should go in its place? I'm >>> happy to put some work into this. >> >> Also, it's the text that's been on our website for at least 15 years. So, >> yeah, it's probably time to say something different here. > > …or say it differently? I've made my own mock up front page (attached), which > can be a straw man for further discussion. I based this, as you may well have > guessed, on the design and styles used at http://www.apache.org/ > > This mockup mentions the #1 position and the 1 years but in its own way. > I like the idea of putting versions into tabs instead of littering the front page with a lot of useless text that you may or may not want to read. We should be pushing 2.4, and as such, that should be the first thing any user sees (they can then click on the 2.2 tab to see 2.2 news :p). I also like that you kept the release news short, we don't really need to say "we're so and so proud of presenting this in conjunction with them and them", we need to simply say "there's a new version, it fixes/enhances this and that, go download it or read the changelog". I have tried to incorporate your suggestions into my own proposal, and the result can be seen at http://httpd.apache.pw/index2 In addition, I have some comments about your design proposal: - The apache.org design might be changing RSN (it's being discussed), so using it might not be the most optimal route. - Using the apache.org design will require making a ton of new pages, as the menu is not as complex as the original design or my proposal. - Where are the download/changelog links? We need to push that, not hide it away. - The user guide/tips is a great idea on paper, but would require yet more new documents, which won't be done until November (at ApacheCon). perhaps we could just add those to the carousel? - Adding a search bar is always fun to do, but we don't have the tech to implement a search as it is, unless we use Google (which people can just use themselves) - You use JavaScript to display the tabs. This, apparently, needs to be done in a way that people without JS can view it as well. I have tried to accommodate that in my second proposal (see link above). - The documentation link just leads to our boring and unattractive docs front page. I would prefer if people can go directly to documentation for e.g. 2.4 right away from the front page (dropdowns?). I see this discussion going two ways now: 1) Which overall layout should we pick for the site? 2) How do we present out project on the front page? I think both proposals are valid, and I won't go into "who's got the prettiest design", as that's entirely personal opinions, but I think the second proposal leaves people wondering "where can I get it, and where can I find the changelog/docs/release notes quickly". Not that there aren't links to some of it, it's just not that obvious where to click. I'm running out of keyboard here, so I'll pause for a while and think some more on the subject. > > > > > - > To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org > For additional commands, e-mail: docs-h...@httpd.apache.org >
Re: svn commit: r1598946 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_fdpass.c
Christophe, do you agree if I modify the 2.4.x proposal with : Index: STATUS === --- STATUS (revision 1603074) +++ STATUS (working copy) @@ -224,12 +224,14 @@ 2.4.x patch: trunk works (modulo CHANGES) +1: ylavic - * mod_proxy_fdpass: Fix computation of the size of 'struct sockaddr_un' - when passed to 'connec()'. - [Graham Dumpleton ] + * mod_proxy: Don't limit the size of the connectable Unix Domain Socket paths. +[Graham Dumpleton , Christophe Jaillet, + Yann Ylavic] trunk patch: http://svn.apache.org/r1598946 - 2.4.x patch: trunk works (modulo CHANGES) - +1: jailletc36 + http://svn.apache.org/r1602989 + 2.4.x patch: http://people.apache.org/~ylavic/httpd-2.4.x-ap_proxy_connect_uds.patch + (modulo CHANGES/MMN) + +1: ylavic since both commits seem to address the same concern? Or should I add a new one? Please note you would have to re-vote. Regards, Yann.
