httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gruno <>
Subject Re: Change of web site layout
Date Mon, 16 Jun 2014 01:22:22 GMT
[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
>> (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
>> 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, 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.

As stated earlier, I find that to be a very...vague argument. Other than
actively choosing to disable JavaScript while retaining CSS styles, you
won't find yourself in a situation where you can't use the navigation
> - Once I activated JS, I immediatetly found the carousel autoscrolling 
>   annoying (the animation too, because it steals my time, but YMMV).

That can be adjusted/disabled. I have changed it to 15 seconds per
frame, up from 10 sec/frame. I'm interested in hearing what others think
of this.

> - A final version should remove external dependencies and all inline style 
>   attributes. Also, unscoped style blocks within the body are invalid HTML.

Yes, I have that on my To-do list. I was initially more interested in
comments on the overall look and feel, and not so much whether it's
valid HTML - those things can always be fixed, and any modern browser
will work with it in any case.

> - Btw: There are many !important styles. Why is that?
It's an easy way to override other style settings one disagrees with in
> - The align attribute for the img element is deprecated in HTML5
> - Empty elements have bad semantics: <b class="caret"></b>. I know, it's
>   neat CSS trick, but that doesn't make it better. A background image would 
>   be a better choice here.
> - <span class="glyphicon glyphicon-chevron-right"></span> 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

View raw message