Re: Change of web site layout

[Daniel Gruno]

[Disclaimer: I am being terse. It is late here. Or early, as it were.]

On 06/16/2014 01:44 AM, André Malo wrote:
> Hi,
> 
> * Daniel Gruno wrote:
> 
>> Hi there, dev@ people (and docs@ cc'ed),
>>
>> For some time now, a lot of us from the documentation team have been
>> pondering on making our site, well, not so 1990s looking and unappealing.
> 
> +1 at the point.
> 
>>
>> We've had some input from various people over time, and together with my
>> own thoughts, I've come up with a new core template that I plan to
>> submit to our CMS system if there aren't too many objections.
>>
>> A mockup front-page featuring this new design can be seen at
>> http://httpd.apache.pw/ (please don't start browsing the entire site, IT
>> DOES NOT WORK, it needs to be behind our CMS system to be pretty and
>> useable).
>>
>> And yes, this new layout will feature some changes:
>>
>> - News are placed in a carousel to eliminate the 'wall of text' we
>> currently have. RMs will have to get acquainted with how to change the
>> news on the site (which shouldn't be difficult if you look at the source
>> code, you will still be able to use the CMS to edit it)
>> - The menu is now a top bar instead of a side bar
>> - Some menu items have been grouped together differently than before
>> - The 8 bit feather has been replaced with the 32 bit one.
>> - It's not quite as...blue
>>
>> Now, before half the team starts complaining that this uses HTML5,
>> JavaScript or CSS3, please bear in mind that *we are not the intended
>> audience*. This is not - and should not be - about what we want, it's
>> about what modern (non-lynx) users will find attractive or off-putting
>> about a site.
> 
> That's a killer phrase. User typically find a site attractive, if they find 
> their use cases served (properly). If it looks nice, the better, of course. 
> If it wastes her time looking attractive, but not being helpful, it's just 
> making her angry.
> 
> As a user, I'd like to see relevant information. It must be possible to get 
> the relevant information without javascript (yes!) and without random 
> clicking (what should I expect from a non-descriptive arrow-link which 
> feels like an adverstisement?).
I disagree with the use of the word 'must' here, 'should' is a much
nicer word to use when one has only personal preference behind ones
css+noscript combo (identical comment further down, I write in reverse).

> Which means, all maintained releases should be visible at once. That has 
> nothing to do with Apache, that's a simple observation, how people look on 
> software pages.
A counter-observation is that a big wall of text, where everything looks
the same, isn't preferable either. I have tried to counter that, but I
will gladly accept any proposals to add all the (non-EOL) releases to
some form of matrix on the front page. I'm just not sure how to tackle
it yet.

> 
> And yes, as an admin I may have only a text browser available if I want to 
> check the current security state of a software *on my server*. Shit 
> happens.
Good thing this proposal works perfectly well with Lynx then.
> 
> Anyway, here are some more comments based on a *quick* review. I find the 
> 72h timebox way too short for such a change, by the way, especially over a 
> weekend.
It's not _over a weekend_, and I'm not trying to sneak in a change this
big. If I wanted that, I would've JFDI'ed it and taken the flak. But I
also don't want yet another 17(!) years of saying "hmm we should do
something" and then not doing anything because we're too busy staring at
our own navels. I asked that anyone object if they found something wrong
with a 72h lazy consensus, and you have objected, and I will naturally
take that into account.

We have a web site that screams "we don't care anymore!", and that makes
me an angry pony. And sometimes angry ponies use lazy consensus because
it seems like we are only a handful of people who really care enough. I
am glad that you care, that makes another one of us.

> 
> (also a screenshot: )
That's a matter of tweaking the CSS, although I hadn't imagined anyone
visiting with less than 720p these days, so I hadn't tried what would
happen if someone did. I will correct the styles to also work with very
narrow screens.
> 
> - Don't fix the fonts to px size.
> - The maint font (Libertine) is badly readable.
I disagree, but we can probably find a font more suitable (or settle for
Serif if all else fails)
> - the tagline is weirdly placed (see screenshot, made with a current 
>   firefox)
Due to the above issue with a very narrow screen.
I have now opted to not fix the top bar to the screen, thus avoiding this.
> - The carousel padding seems strange, too
> - also, it's italic, that looks, like, 80s, sorry (as in: Text processing 
>   software on my good old Atari ST :-)
There was one line of italic, just the one. It is now gone.

> - (Maybe the points above are due to freetype, but that's how it is.
> 
> - As said, a

Re: Change of web site layout

[André Malo]

Hi,

* Daniel Gruno wrote:

> Hi there, dev@ people (and docs@ cc'ed),
>
> For some time now, a lot of us from the documentation team have been
> pondering on making our site, well, not so 1990s looking and unappealing.

+1 at the point.

>
> We've had some input from various people over time, and together with my
> own thoughts, I've come up with a new core template that I plan to
> submit to our CMS system if there aren't too many objections.
>
> A mockup front-page featuring this new design can be seen at
> http://httpd.apache.pw/ (please don't start browsing the entire site, IT
> DOES NOT WORK, it needs to be behind our CMS system to be pretty and
> useable).
>
> And yes, this new layout will feature some changes:
>
> - News are placed in a carousel to eliminate the 'wall of text' we
> currently have. RMs will have to get acquainted with how to change the
> news on the site (which shouldn't be difficult if you look at the source
> code, you will still be able to use the CMS to edit it)
> - The menu is now a top bar instead of a side bar
> - Some menu items have been grouped together differently than before
> - The 8 bit feather has been replaced with the 32 bit one.
> - It's not quite as...blue
>
> Now, before half the team starts complaining that this uses HTML5,
> JavaScript or CSS3, please bear in mind that *we are not the intended
> audience*. This is not - and should not be - about what we want, it's
> about what modern (non-lynx) users will find attractive or off-putting
> about a site.

That's a killer phrase. User typically find a site attractive, if they find 
their use cases served (properly). If it looks nice, the better, of course. 
If it wastes her time looking attractive, but not being helpful, it's just 
making her angry.

As a user, I'd like to see relevant information. It must be possible to get 
the relevant information without javascript (yes!) and without random 
clicking (what should I expect from a non-descriptive arrow-link which 
feels like an adverstisement?).
Which means, all maintained releases should be visible at once. That has 
nothing to do with Apache, that's a simple observation, how people look on 
software pages.

And yes, as an admin I may have only a text browser available if I want to 
check the current security state of a software *on my server*. Shit 
happens.

Anyway, here are some more comments based on a *quick* review. I find the 
72h timebox way too short for such a change, by the way, especially over a 
weekend.

(also a screenshot: )

- Don't fix the fonts to px size.
- The maint font (Libertine) is badly readable.
- the tagline is weirdly placed (see screenshot, made with a current 
  firefox)
- The carousel padding seems strange, too
- also, it's italic, that looks, like, 80s, sorry (as in: Text processing 
  software on my good old Atari ST :-)
- (Maybe the points above are due to freetype, but that's how it is.

- As said, all the technologies are fine, just make sure, it's usable 
  without it. An implementation could be to add real links to the dropdown 
  headings pointing to pages listing the submenus).

  Also, the legal stuff should be reachable without Javascript anyway.

- Once I activated JS, I immediatetly found the carousel autoscrolling 
  annoying (the animation too, because it steals my time, but YMMV).

- A final version should remove external dependencies and all inline style 
  attributes. Also, unscoped style blocks within the body are invalid HTML.
- Btw: There are many !important styles. Why is that?

- The align attribute for the img element is deprecated in HTML5
- Empty elements have bad semantics: . I know, it's a 
  neat CSS trick, but that doesn't make it better. A background image would 
  be a better choice here.
-  is similar. Just 
  put the font character inside the link and set the font properly. However, 
  not everybody executes remote font files (I usually don't by default). 
  These people see strange letters instead of carousel arrows.

  There are a few tricks involving putting real arrow characters inside 
  another container and adding font defining classes / display: none for the 
  arrow after a modernizr-like detection for font-face support.
  Or just use SVG images as link content.

I did not dig deeper so far, as said, that was a quick view.

-1 at the implementation, sorry.

nd
-- 
Das einzige, das einen Gebäudekollaps (oder auch einen
thermonuklearen Krieg) unbeschadet übersteht, sind Kakerlaken
und AOL-CDs.
  -- Bastian Lipp in dcsm

Re: Change of web site layout

[Rich Bowen]

+1,000,000

On 06/15/2014 04:55 PM, Daniel Gruno wrote:
> Hi there, dev@ people (and docs@ cc'ed),
> 
> For some time now, a lot of us from the documentation team have been
> pondering on making our site, well, not so 1990s looking and unappealing.
> 
> We've had some input from various people over time, and together with my
> own thoughts, I've come up with a new core template that I plan to
> submit to our CMS system if there aren't too many objections.
> 
> A mockup front-page featuring this new design can be seen at
> http://httpd.apache.pw/ (please don't start browsing the entire site, IT
> DOES NOT WORK, it needs to be behind our CMS system to be pretty and
> useable).
> 
> And yes, this new layout will feature some changes:
> 
> - News are placed in a carousel to eliminate the 'wall of text' we
> currently have. RMs will have to get acquainted with how to change the
> news on the site (which shouldn't be difficult if you look at the source
> code, you will still be able to use the CMS to edit it)
> - The menu is now a top bar instead of a side bar
> - Some menu items have been grouped together differently than before
> - The 8 bit feather has been replaced with the 32 bit one.
> - It's not quite as...blue
> 
> Now, before half the team starts complaining that this uses HTML5,
> JavaScript or CSS3, please bear in mind that *we are not the intended
> audience*. This is not - and should not be - about what we want, it's
> about what modern (non-lynx) users will find attractive or off-putting
> about a site.
> 
> So, I will leave it to you to either love or hate this idea, and if I
> don't hear any (good) arguments against this, I will update the site
> layout in about 72 hours. If, however, someone feels very strongly about
> not changing status quo, I will of course take it to a vote on dev@ (I
> assume docs@ people also follow dev@).
> 
> So, throw me some indicative pluses or minuses, or some comments, if you
> care about our site :)
> 
> With regards,
> Daniel.
> 
> -
> To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
> For additional commands, e-mail: docs-h...@httpd.apache.org
> 

-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Change of web site layout

[Daniel Gruno]

Hi there, dev@ people (and docs@ cc'ed),

For some time now, a lot of us from the documentation team have been
pondering on making our site, well, not so 1990s looking and unappealing.

We've had some input from various people over time, and together with my
own thoughts, I've come up with a new core template that I plan to
submit to our CMS system if there aren't too many objections.

A mockup front-page featuring this new design can be seen at
http://httpd.apache.pw/ (please don't start browsing the entire site, IT
DOES NOT WORK, it needs to be behind our CMS system to be pretty and
useable).

And yes, this new layout will feature some changes:

- News are placed in a carousel to eliminate the 'wall of text' we
currently have. RMs will have to get acquainted with how to change the
news on the site (which shouldn't be difficult if you look at the source
code, you will still be able to use the CMS to edit it)
- The menu is now a top bar instead of a side bar
- Some menu items have been grouped together differently than before
- The 8 bit feather has been replaced with the 32 bit one.
- It's not quite as...blue

Now, before half the team starts complaining that this uses HTML5,
JavaScript or CSS3, please bear in mind that *we are not the intended
audience*. This is not - and should not be - about what we want, it's
about what modern (non-lynx) users will find attractive or off-putting
about a site.

So, I will leave it to you to either love or hate this idea, and if I
don't hear any (good) arguments against this, I will update the site
layout in about 72 hours. If, however, someone feels very strongly about
not changing status quo, I will of course take it to a vote on dev@ (I
assume docs@ people also follow dev@).

So, throw me some indicative pluses or minuses, or some comments, if you
care about our site :)

With regards,
Daniel.

Re: mod_ssl SSL session timeout

[Kaspar Brand]

On 14.06.2014 12:53, Rainer Jung wrote:
> SSL_CTX_set_timeout() seems to work pretty well.

Indeed. I missed the fact that after the ticket has been decrypted/processed,
there's a timeout check in ssl_sess.c:ssl_get_prev_session(), based on the
SSL_SESSION's "time" value, which is the timestamp of its creation.

SSL_CTX_set_timeout() adjusts the default value for SSL sessions created by
ssl_sess.c:ssl_get_new_session(). Right now, mod_ssl relies on the builtin
OpenSSL defaults, which are somewhat inconsistent:

- if SSLProtocol specifies multiple protocols, the default timeout
  for TLS session tickets is 300 seconds

- if SSLProtocol only specifies one of "TLSv1", "TLSv1.1", or "TLSv1.2",
  the default timeout for session tickets is 7200 seconds

> In addition to the usual directive management lines, the patch should be
> as simple as
> 
> Index: modules/ssl/ssl_engine_init.c
> ===
> --- modules/ssl/ssl_engine_init.c   (revision 1593916)
> +++ modules/ssl/ssl_engine_init.c   (working copy)
> @@ -1365,6 +1365,8 @@
>  }
>  #endif
> 
> +SSL_CTX_set_timeout(sc->server->ssl_ctx, sc->server->session_timeout);
> +
>  return APR_SUCCESS;
>  }
> 
> where sc->server->session_timeout is the new configuration item (if we
> do not stick to the existing cache timeout).

I'm slightly in favor of the latter, i.e. something like

SSL_CTX_set_timeout(sc->server->ssl_ctx,
sc->session_cache_timeout == UNSET ?
SSL_SESSION_CACHE_TIMEOUT : sc->session_cache_timeout);

(As a side effect, this would also make sure that the timeout for
TLS session tickets is 300 seconds for all SSLProtocol settings,
if SSLSessionCacheTimeout is not explicitly configured.)

Kaspar