Merge lp://staging/~pfalcon/linaro-android-build-tools/descr-update into lp://staging/linaro-android-build-tools

While I am not a fan of the pink background (#FFC is my preference for a nice yellow one, but I look at a lot of python docs - I guess I can live with it!

My preference would be to use a heading and define CSS for it to set the "New!" bit up as a different colour. That said, it is in a big colourful box - it is going to get peoples attention - so I think the new is not required and I would just delete it.

> While I am not a fan of the pink

Well, the idea is to get attention. At least it's not red ;-).

> My preference would be to use a heading and define CSS for it to set the "New!" bit up as a different colour. That said, it is in a big colourful box - it is going to get peoples attention - so I think the new is not required and I would just delete it.

Well, it does use CSS to define colors. Do you mean to use styles? If so, the need to define styles all the time (essentially, an extra level of indirection) is overstated. There're cases where self-containment and clarity is more important, and arguably this is the case.

And for "New!", well, it is! I probably wouldn't add it though if we didn't have what we have on the frontpage. But well, let's be user-friendly ;-). The idea is to remove "new!" in a couple of months and let just the box hang. (I don't even dream of actually having better formatted/consisted build descriptions).

On 2 April 2012 17:48, Paul Sokolovsky <email address hidden> wrote:
>> While I am not a fan of the pink
> Well, the idea is to get attention. At least it's not red ;-).

It kind of looks like a warning (anything in the red spectrum does),
but it isn't. It is an information box. I am not sure if there is a
common colour that is used for this sort of thing, but I think it is
safe to say that pink/red isn't it.

>> My preference would be to use a heading and define CSS for it to set
>> the "New!" bit up as a different colour. That said, it is in a big colourful
>> box - it is going to get peoples attention - so I think the new is not
>> required and I would just delete it.
>
> Well, it does use CSS to define colors. Do you mean to use styles? If so,
> the need to define styles all the time (essentially, an extra level of
> indirection) is overstated. There're cases where self-containment and
> clarity is more important, and arguably this is the case.

<div class="info_hilight"> is preferred (if my memory serves) because
that way you are defining what the element contains and you then use
CSS to tell the browser how to render it. This is hardly a case of
having to define styles all the time and it makes it much easier if
someone comes along and wants you to change the colour of the element.

> And for "New!", well, it is! I probably wouldn't add it though if we
> didn't have what we have on the frontpage. But well, let's be
> user-friendly ;-). The idea is to remove "new!" in a couple of months
> and let just the box hang. (I don't even dream of actually having
> better formatted/consisted build descriptions).

Isn't this a patch that is generating some static HTML though, so all
those HTML files will have to be modified in the future? Wouldn't it
be much easier and far more maintainable to create the page using the
Django template engine?

--
James Tunnicliffe

On Mon, 02 Apr 2012 17:31:45 -0000
James Tunnicliffe <email address hidden> wrote:

> On 2 April 2012 17:48, Paul Sokolovsky <email address hidden>
> wrote:
> >> While I am not a fan of the pink
> > Well, the idea is to get attention. At least it's not red ;-).
>
> It kind of looks like a warning (anything in the red spectrum does),
> but it isn't. It is an information box. I am not sure if there is a
> common colour that is used for this sort of thing, but I think it is
> safe to say that pink/red isn't it.

Yes, that's the intention. What it tries to say is "Don't try to miss
me - if you do, and will read the below, your eyes will bleed because
styling there is much worse, and also you might get a headache
following all the (not always cleanly written) instructions below, and
there's still no warranty that it will work, because there's nor
warranty that those instructions are up to date".

>
> >> My preference would be to use a heading and define CSS for it to
> >> set the "New!" bit up as a different colour. That said, it is in a
> >> big colourful box - it is going to get peoples attention - so I
> >> think the new is not required and I would just delete it.
> >
> > Well, it does use CSS to define colors. Do you mean to use styles?
> > If so, the need to define styles all the time (essentially, an
> > extra level of indirection) is overstated. There're cases where
> > self-containment and clarity is more important, and arguably this
> > is the case.
>
> <div class="info_hilight"> is preferred (if my memory serves) because

There's no "preferred" on the global scale, there's only flexibility to
do it this or that way on that scale. It's just as saying that
"preferred" way to do an addition is to assign operands to variables
first:

a = 2; b = 2; c = a + b; c == 4

Nope, it's still fine to just do 2 + 2 = 4 when you need just that ;-).

> that way you are defining what the element contains and you then use
> CSS to tell the browser how to render it. This is hardly a case of
> having to define styles all the time and it makes it much easier if
> someone comes along and wants you to change the colour of the element.

Yes, that works really well (and gets extra boons) when thing is well
maintained. When it is not, making a simple self-contained changes is a
better approach.

> > And for "New!", well, it is! I probably wouldn't add it though if we
> > didn't have what we have on the frontpage. But well, let's be
> > user-friendly ;-). The idea is to remove "new!" in a couple of
> > months and let just the box hang. (I don't even dream of actually
> > having better formatted/consisted build descriptions).
>
> Isn't this a patch that is generating some static HTML though, so all
> those HTML files will have to be modified in the future? Wouldn't it
> be much easier and far more maintainable to create the page using the
> Django template engine?

Actually, pragmatically, what this patch does is finishing deployment
of Andy's work is the least disturbing and the most straightforward
way. Now, semantically, it exactly implements poor man's template
engine, so it would be easy to replace styling/text of that header.
Finally, syntacticall...

Ok, as Andy ok with it, going to deploy it.