#34663 closed task (blessed) (fixed)
4.4 About Page
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.4 | Priority: | normal |
Severity: | normal | Version: | 4.4 |
Component: | Help/About | Keywords: | has-patch |
Focuses: | Cc: |
Description
Tracking ticket.
Attachments (21)
Change History (74)
This ticket was mentioned in Slack in #core by wonderboymusic. View the logs.
9 years ago
#3
@
9 years ago
@DrewAPicture srcset
selection based on the "strength of your connection" is not a feature that any browsers have implemented yet, AFAIK. Maybe something like:
Sites now intelligently provide images in multiple resolutions based on screen size and display density. You don’t need to do anything to your content to enable responsive images; the only difference your visitors might notice would be faster page loads and a better experience across devices!
#4
@
9 years ago
Props thus far: DrewAPicture, markjaquith, helen, nacin, liljimmi, mordauk, melchoyce, ryelle
#5
@
9 years ago
design implemented in 34663.3.diff -- still waiting on some media. The twentysixteen & "responsive images" images need to be optimized & uploaded to w.org; the cloudup gallery for "More third-party embeds" is also a placeholder, to be replaced with another new embed example (I think melchoyce is working on that?).
#6
@
9 years ago
- I don't think we should keep that array of under the hood features to be printed out later, let's just move it back into HTML since it's not being randomized anymore.
- Force the two separate REST API paragraphs to each be in a column. Having one line of the second one in the first column is awkward.
- There are at least 2 too many exclamation points. Both sentences in "WordPress embeds" end that way.
- Title casing is inconsistent. Which way do we go?
- May be better to specify that that interacting with those new objects is more predictable/intuitive *in code*. For a user skimming the page, if your eye catches on comments/networks being more intuitive, that's a false statement.
- Responsive images paragraph doesn't feel right to me. Multiple images aren't provided based on screen/device, a different one is chosen from multiple. The semicolon is weird in that it's not clear that the two halves of the sentence relate in terms of differences noticed, perhaps better just as an
, and
. I also think it's worth noting that you will also reap those benefits as you visit all those other WordPress sites around the web, rather than "so why are you telling me this if I'm not going to notice anything". - This was noted to me already, but Cloudup is not camelcased.
- I know the Cloudup embed is meant to be temporary, but I think generally I would be wary of appearing to promote an Automattic thing more prominently than others. It's certainly not the intent nor is that a blocker, just want to keep that in mind as we choose an actual embed.
#7
@
9 years ago
Adjusted some of the title case inconsistencies and tweaked some of the Twenty Sixteen css in 34663.5.diff.
#8
@
9 years ago
34663.6.diff fixes the CSS for the Cloudup iframe. Incidentally, Cloudup is slow as dirt. I added caching, but overall, not a great experience (might just be slow wifi). Maybe try VideoPress?
#9
@
9 years ago
34663.7.diff addresses feedback from @helen in comment:6 and brings in the CSS changes from 34663.6.diff.
#10
@
9 years ago
34663.9.diff uses the plugin details modal for the REST API plugin link. Just an idea. :-)
I added caching, but overall, not a great experience (might just be slow wifi). Maybe try VideoPress?
Both embeds should be cached, I think we should use the transient API here. For the make/core embed we should also ping systems to add server-side caching.
#16
@
9 years ago
The tagline is still the old one:
Thank you for updating! WordPress 4.4 makes it even easier to format your content and customize your site.
#17
@
9 years ago
- Version changed from 4.4 to trunk
Responsive images plus various speed refactoring (comments) could be summarized as "responsive".
REST API and WordPress post embeds could be summarized as "connected".
Thus, my first swing:
Thank you for updating! WordPress 4.4 makes your site more connected and responsive.
#22
in reply to:
↑ 21
@
9 years ago
Replying to markjaquith:
Any outstanding items or issues?
This ticket was mentioned in Slack in #core by ocean90. View the logs.
9 years ago
#29
@
9 years ago
I added a new patch based on the solution of @melchoyce but from the new repository "develop.svn.wordpress.org" that uses the new directory structure, perhaps it can be useful when making the final commit. Hope that helps!
#30
@
9 years ago
34663.15.diff adds responsive image support to the images on the about page. The URLs used in the src
and srcset
attributes need to be updated once these are moved over to the CDN, but everything else should remain the same.
#31
follow-up:
↓ 41
@
9 years ago
I don't love the idea of every about page hitting two make.wordpress.org URLs, which are full page loads, to then discover the oEmbed endpoint, which we'll then hit, to then load the iframe. The long tail of that is gonna make Barry mad.
I think we should just commit the resulting oEmbed response directly onto the page.
Even better — should we use the wordpress.org/news announcement oEmbed, rather than a make/core explanatory page?
#32
follow-up:
↓ 38
@
9 years ago
Even better — should we use the wordpress.org/news announcement oEmbed, rather than a make/core explanatory page?
Can we do this? I wasn't sure if it would work, since the post won't be published until after the release goes live.
#33
@
9 years ago
34663.16.diff fixes a small typo in one of the srcset
atts in 34553.15.diff.
#38
in reply to:
↑ 32
@
9 years ago
Replying to melchoyce:
Can we do this? I wasn't sure if it would work, since the post won't be published until after the release goes live.
Yes. We'll know the URL. We can drop it in just before release (since it'll have the jazzer's name).
It looks like these images are fully optimized, yeah? In that case, @dd32 or @pento or me can move them to the .org CDN.
#39
follow-up:
↓ 40
@
9 years ago
It looks like these images are fully optimized, yeah?
They've been exported for web from Photoshop, but could probably go through another round of optimization through something like ImageOptim or https://tinypng.com/.
#40
in reply to:
↑ 39
@
9 years ago
Replying to melchoyce:
It looks like these images are fully optimized, yeah?
They've been exported for web from Photoshop, but could probably go through another round of optimization through something like ImageOptim or https://tinypng.com/.
I would recommend Kraken - https://kraken.io/web-interface
#41
in reply to:
↑ 31
@
9 years ago
Replying to nacin:
Even better — should we use the wordpress.org/news announcement oEmbed, rather than a make/core explanatory page?
+1. We should also try to get a featured image in so that both embeds have more or less the same height.
It looks like these images are fully optimized, yeah? In that case, @dd32 or @pento or me can move them to the .org CDN.
Working on this.
#44
@
9 years ago
Updated the embed sections to be rows rather than a section of columns and had @ryelle vertically center the text in 34663.18.diff.
#45
@
9 years ago
Fixed some lingering responsive issues in 34663.19.diff
#49
@
9 years ago
- Owner set to ocean90
- Resolution set to fixed
- Status changed from new to closed
In 35840:
This ticket was mentioned in Slack in #core by pento. View the logs.
9 years ago
#53
@
9 years ago
To avoid needing [35862]-style commits in the future, I've added a new "run grunt precommit
" step to the release checklist.
34663.diff adds the untranslated strings in a patch.