x/website: include release date on dl page

[kevinburke1]

It would be nice if the releases also had a line including the date they were released. I couldn't remember if I had rebuilt AMI's for 1.15rc1 or just beta1, but if the release date was present on the dl page, I would have been able to do so.

[kevinburke1]

@broady it looks like we have this information present in internal/history/release.go, I'd be happy to take a stab at trying to include that on the DL page, but the DL page appears to take memcache + cloud datastore as hard dependencies and I'm not sure how to bootstrap either the memcache or cloud datastore locally; it doesn't look like there are docs for those?

[gopherbot]

Change https://golang.org/cl/254538 mentions this issue: internal/dl: add release dates to dl page

[dmitshur]

Copying a comment from the CL:

Here's a screenshot of what the addition to the page looks like.

That looks somewhat inconsistent with the rest of the design of the golang.org website to me. It's not a complete English sentence.

If we're going to do this, I would suggest we consider either putting the date into the header, similar to how it's done on the release history page:

An alternative to consider would be to include an entire paragraph that states the release date and describes the release (using information from the ./internal/history package), like so:

However, I'm not sure this is an improvement. It copies information from the release history page, which already exists. It seems the download page should focus more on the downloads rather than duplicating what's on the release history page.

I'm more okay with just the date in the header, but given the complexity/size of the change, I'd like to see more arguments for why this is a good change for users first. Can you elaborate on why consulting the release history page doesn't work well? Thanks.

@andybons What do you think about this?

[dmitshur]

It's not a complete English sentence.

An in-between solution that addresses this could be something like:

"Go {{.V}} was released on {{.Date}}. See the Release History for more information."

[kevinburke1]

I answered the question of why this is a good change for users in the issue description. I'm trying to answer the question "am I running the most recent Go release in production." I know when I last rebuilt an AMI or deb package, and I know I always release the most recent version. I don't know when the most recent Go version was released.

1. The information hierarchy on the release history page makes it difficult to pick out a) the most recent release b) the date of the most recent release.

   Here is a screenshot of the entire release history page; I have underlined the location of the release date information for the most recent release in that page. It's below the page fold, halfway through a sentence, three paragraphs below a subheader.

   

   Contrast with proposed location on the DL page - by itself on a line, above the fold, obvious placement. The DL page also gets more traffic.

   

2. The release history page does not contain any information about beta or release candidate versions, so it is impossible to determine when betas or RC's were released.

For more on this topic see How Users Read on the Internet (hint: they don't) or my talk about how to write documentation for people that don't read. https://www.youtube.com/watch?v=sQP_hUNCrcE

I don't think it is ideal to place in the blue header bar next to the version number, because it makes the version number harder to scan for, putting it off of the left hand line makes it more likely that users will miss it when scanning, the word "September" is easier to scan for than a YYYY/MM/DD formatted date, and too much text in the blue header makes it look like a banner ad which also makes users miss it when scanning. But if that's the only place to put it then sure we can put it there.

I understand the change is large but there are also some benefits. It was previously tightly coupled to both memcache and Google Cloud. Removing this tight coupling makes it possible to add tests that the page renders, as well as makes it more easy to view and test local changes.

I could submit this as two separate CL's, one that removes the tight coupling and one that actually updates the page. But it was necessary to remove the coupling in order to actually figure out how the changes I was making would be styled.

[kevinburke]

Hi, just following up here.

I see you gave an emoji thumbs up, but I'm not sure what you are giving the thumbs up to - the CL, the suggestion to split it into two CL's, the explanation of why I think this is a good change...

[dmitshur]

My 👍 reaction was to indicate that I thought it was a good explanation of why it is a good change that we should make.

I'm convinced that adding the release date to the https://golang.org/dl/ page is worth doing, even though this information is available on the release history page, because of the rationale you elaborated on. Let's agree on how it should look.

My concern is that the current design, as far as I can tell, looks like no other element of the website (due to the smaller font, being an incomplete sentence, using a different date format). Please let me know if I missed some page which you used as a reference. Otherwise, are you okay with trying to get something that looks more consistent with the rest of the golang.org website? I've made some suggestions in comments above.

[kevinburke1]

Okay, I've updated the CL to incorporate the proposed changes.