WordPress.org

Making WordPress.org

Opened 6 years ago

Closed 3 years ago

Last modified 3 years ago

#334 closed enhancement (fixed)

Improve the Coming Soon design for new WordCamp sites

Reported by: iandunn Owned by: iandunn
Milestone: Priority: normal
Component: WordCamp Site & Plugins Keywords: has-screenshots
Cc:

Description

New WordCamp sites now display a 'Coming Soon' page to logged-out users, instead of the regular site. The idea behind this is to give organizers a chance to setup their new site the way they want before it's published, while still letting users access some of the basic things that they'd like to do early in the planning process (like subscribe to the mailing list and contact the organizers). You can see it in action at http://testing.wordcamp.org.

The initial version just has a very rough design, though. Are there any designers out there who could put together a mockup for an improved version? It doesn't have to be a huge redesign or anything, just an iteration to improve the details. I can take care of the markup/CSS changes (or you're welcome to do that too if you'd like).

The source code is at https://meta.trac.wordpress.org/browser/sites/trunk/wordcamp.org/public_html/wp-content/plugins/wordcamp-coming-soon-page

Attachments (7)

WordCamp-Landing.png (210.9 KB) - added by melchoyce 3 years ago.
WordCamp-Landing_headerimage.png (2.9 MB) - added by melchoyce 3 years ago.
WordCamp-Landing_logo.png (293.8 KB) - added by melchoyce 3 years ago.
WordCamp-Landing_before.png (157.5 KB) - added by melchoyce 3 years ago.
coming-soon.diff (38.1 KB) - added by ryelle 3 years ago.
coming-soon.2.diff (38.9 KB) - added by ryelle 3 years ago.
coming-soon.3.diff (3.2 KB) - added by ryelle 3 years ago.

Change History (43)

#1 follow-up: @siobhan
6 years ago

Can you add a space to the labeling on the form fields for the contact form? i.e.:

Name (required)
Email (required)
Comment (required)

Thanks! :)

#2 in reply to: ↑ 1 @iandunn
6 years ago

Replying to siobhan:

Can you add a space to the labeling on the form fields for the contact form? i.e.:

Oops. That was there initially and got reverted by r394. I'll add it back.

#3 @iandunn
6 years ago

In 397:

Coming Soon Page: Add space between Grunion field names and required flag. See #334.

The space was accidentally removed in r394.

#4 @brodyvercher
6 years ago

I'd be happy to help out with this. I do have a couple of quick questions before getting started though:

  • Will the 10th anniversary logo show up on all the coming soon pages, or is that just a placeholder for the different locations' logos?
  • Will WordCamp organizers have the ability to customize styles, like color, or is the deafult template the only thing that ever shows?

#5 @jenmylo
6 years ago

The Coming Soon page is a tool requested by the team at WordCamp Central. Our weekly community team meeting is tomorrow and we can make this a topic of discussion. Without people knowing what's on the back end and the purpose of the page, it's tough to get people on the same page with design.

@brodyvercher: The point of the page is that is a basic placeholder while new org teams get their sites in order. What you see at http://testing.wordcamp.org is the output based on the prototype, not a static design. The settings page allows the organizers to upload a graphic/logo (the wp10 was just used for the test), set the text and 2 background colors, and input the description text. So that is all built in already. The forms are generated by Jetpack. The page doesn't really need to be "designed," we just need to tidy it up.

#6 @GrahamArmfield
6 years ago

As soon as there is a version that is available for me to see, I'm happy to have a look at it from an accessibility perspective.

For some reason I can't add myself to the ticket watch list.

#7 @Kau-Boy
5 years ago

In the meantime, could you please make the current page responsive? There is already a patch for the corresponding ticket #616.

#8 @melchoyce
4 years ago

  • Keywords needs-ui added

While I understand the coming soon page can be customized, I think the default design could use some refinements.

@GrahamArmfield — did you ever have a chance to do an accessibility review?

#9 @iandunn
4 years ago

@GrahamArmfield, links to the source code and testing site are in the ticket description; is there anything else that you need for your review?

#10 @iandunn
3 years ago

  • Owner set to iandunn
  • Status changed from new to accepted

#11 @melchoyce
3 years ago

@melsenc and I worked on an updated design for these landing pages at WordCamp Boston's contributor day this past weekend, using some of the recent WordPress.org designs being worked on by @mapk as inspiration:

WordCamp-Landing.png
WordCamp-Landing_headerimage.png
WordCamp-Landing_logo.png

@ryelle has volunteered to build the updated landing page plugin. The customization options will be relocated to the Customizer, and will feature support for Header Images, Logos, and maybe some color/font options. Going to work with ryelle to determine what is feasible.

#12 follow-up: @DrewAPicture
3 years ago

  • Keywords has-screenshots added

Looks great! This would be a big improvement. For the uninitiated, it would probably be helpful to also provide a before screenshot of the current coming soon page ;)

#13 in reply to: ↑ 12 @melchoyce
3 years ago

  • Keywords needs-ui removed

Replying to DrewAPicture:

For the uninitiated, it would probably be helpful to also provide a before screenshot of the current coming soon page ;)

Excellent point. Added WordCamp-Landing_before.png.

#14 follow-up: @samuelsidler
3 years ago

It's so pretty. :) It definitely would be cool if WordCamps could customize the color of the main gradient and perhaps buttons? If that becomes an option, I'm sure we'd only want them to set the starting color for the gradient, then automagically build the second color.

#15 in reply to: ↑ 14 @melchoyce
3 years ago

Replying to samuelsidler:

It's so pretty. :) It definitely would be cool if WordCamps could customize the color of the main gradient and perhaps buttons? If that becomes an option, I'm sure we'd only want them to set the starting color for the gradient, then automagically build the second color.

@ryelle and I were talking about that earlier and it's totally doable, sounds like. We'll probably go with one color option that'll be used to generate both the gradient and the button.

@ryelle
3 years ago

#16 @ryelle
3 years ago

coming-soon.diff implements this new design. This adds a new panel to the customizer, which allows organizers to customize the background image, logo image, and color before turning it on for everyone.

This is semi-backwards-compatible. I've "deprecated" the text color and container background color -- but the current body color will be used as the header color (unless it's #666666, the current default -- in that case, it uses the new default blue). No other colors are customizable, it uses Jetpack's color library to lighten and darken the main color for the gradient and buttons. The logo is also the same setting, so for any currently-coming-soon sites, the logo will carry over.

The settings page in wp-admin has been turned into just a blurb and link to the customizer, just to give the heads up to any organizer currently using this.

Gallery of "in action" screenshots.

#17 @iandunn
3 years ago

  • Keywords ui-feedback removed

I skimmed the diff and it looks really good, thanks! I'll try to fit in some time this week to merge it.

The only minor thing I'd change would be to esc_attr() each time a value is echo'd, rather than using array_walk(). That way, it's completely obvious that the value has been escaped, rather than having to look higher up the code to check. It also makes it possible for static analysis tools like PHP Code Sniffer to know it's escaped, reducing the number of false-positives.

For the old Settings page, what do you think about getting rid of it completely, and just making it a link to wp-admin/customize.php?autofocus[section]=wccsp_live_preview ? Would users be confused by that, or would they understand that it's moved? If it wouldn't confuse people, it seems better to me, since it's fewer clicks and less code.

#18 @melchoyce
3 years ago

For the old Settings page, what do you think about getting rid of it completely, and just making it a link to wp-admin/customize.php?autofocus[section]=wccsp_live_preview ? Would users be confused by that, or would they understand that it's moved? If it wouldn't confuse people, it seems better to me, since it's fewer clicks and less code.

Yeah, let's do that. I think folks who know about the existing screen would be momentarily confused, but would probably figure it out pretty quickly. I don't think it would be confusing for new organizers.

@ryelle
3 years ago

#19 @ryelle
3 years ago

I've uploaded a new patch which links right to the customizer (coming-soon.2.diff). I also switched back to esc_attr over the array_walk approach.

#20 @iandunn
3 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 3784:

WordCamp Coming Soon Page: Implement new design and migrate to Customizer.

Fixes #334
Props melchoyce, melsenc, ryelle

#21 @iandunn
3 years ago

Woot! This is live now :)

It looks and functions so much better than the original. Kudos to all of you :)

#22 @melchoyce
3 years ago

Awesome!

I noticed that Open Sans isn't loading correctly. Can we fix that?

Some of the line-height and font weights appear to be different, too — do you know what happened there?

#23 follow-up: @iandunn
3 years ago

Doh, my bad. I replaced Open Sans with the new 4.6 font stack and missed the height/weight issues. We can definitely fix those, or maybe revert to Open Sans if you feel like that's best.

The reason I switched was to avoid the external dependency and extra HTTP request, and also to avoid the potential for leaking sensitive information via referrer headers (and all the other issues with Open Sans: 1, 2). Leaking info is admittedly unlikely in this context, but it still makes me leery when combined with everything else.

It also sounds like the new stack has several advantages over Open Sans, like instant loading, better language support, and consistency with the device's native UI.

What are your thoughts on all that?

#24 in reply to: ↑ 23 ; follow-up: @melchoyce
3 years ago

Replying to iandunn:

Doh, my bad. I replaced Open Sans with the new 4.6 font stack and missed the height/weight issues. We can definitely fix those, or maybe revert to Open Sans if you feel like that's best.

The reason I switched was to avoid the external dependency and extra HTTP request, and also to avoid the potential for leaking sensitive information via referrer headers (and all the other issues with Open Sans: 1, 2). Leaking info is admittedly unlikely in this context, but it still makes me leery when combined with everything else.

It also sounds like the new stack has several advantages over Open Sans, like instant loading, better language support, and consistency with the device's native UI.

What are your thoughts on all that?

I think in this case, the site is small enough that an extra HTTP request isn't going to be a big deal. Since already using Open Sans on WordPress.org, I'm not really worried about the security aspect. However, if you are worried, we can host the files internally rather than linking to Google's versions.

The new core font stack was designed to address the needs of an application, not websites. We made the explicit decision to use the native stack for UI elements, and continue using serif fonts for content. Most of the fonts within the font stack were designed for things like labels, menus, etc., and don't work as well for the kind of content you'd find in websites themselves — large titles, paragraphs, etc. You can especially see this in OSX's San Francisco, which was designed with ample letter-spacing that makes it ideal for applications but difficult for reading longer lines of text.

As far as I know, we haven't made a decision to stop using Open Sans for our community materials. If we do (and we have been talking about it), we will likely choose a different sans-serif webfont (not native UI font). However, until we make that decision, we should use Open Sans here to provide an easier to read, more consistent experience.

#25 in reply to: ↑ 24 @hugobaeta
3 years ago

Replying to melchoyce:

I think in this case, the site is small enough that an extra HTTP request isn't going to be a big deal.

I said this to Mel, but I'll reiterate here: even if the site wasn't small - the 4.6 font stack is a UI stack - it's definitely not meant for copy. As Mel said, there are conversations happening about moving on from Open Sans in .org, but until then, the rules in the design handbook remain the law of the land ;)

I do have other small feedback here, looking at the live implementation vs the mockups Mel posted here:

https://cldup.com/a8Q1hT0DYQ.png

  • The font stack definitely needs to change back to Open Sans.
  • The default colors should be WordPress colors. I believe this was a lapse in implementation, but worth commenting. Base color should probably be the WordPress Blue from our color palette
  • The form button isn't aligned properly, and it includes a rogue » character. The color on the button is also off
  • The form layout could likely be optimized on larger screens and break down to a full width form on narrow screens, something like:

https://cldup.com/VWreM4dFCb.png

Aside from this, this is a tremendous step forward. It's a gorgeous design that fits the WordPress brand perfectly! :)

#26 @iandunn
3 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Ah, I see now, thanks for explaining that! I'll change it back to Open Sans and work on the other things Hugo mentioned.

@ryelle
3 years ago

#28 @ryelle
3 years ago

The URL returned by WCCSP_Settings::get_customizer_section_url() should be relative, not wrapped in admin_url, that'll fix the "repeated" url.

@hugobaeta It looks like the default color is already using WordPress Blue -- maybe the issue is the way it's being lightened for the gradient? The button background is definitely #0073AA.

I'm not sure that the » can be removed from the submit button, I think that's a Jetpack-default (you can see it on the contact pages, which is how this form is generated).

coming-soon.3.diff fixes the customizer URL, the fonts, the submit button alignment, and some form styling that was being overridden by Jetpack styles.

#29 @iandunn
3 years ago

In 3835:

WordCamp Coming Soon Page: Fix broken menu link.

This bug didn't exist in the original patch, but was introduced during the review phase, because I didn't connect the dots between register_settings_pages() and get_customizer_section_url(), and thought it'd be better to use an absolute URL.

The bug didn't show up during local testing because of differences between the nginx configuration on my sandbox and the config on production, and I failed to test production after deploying.

This commit reverts it back to a relative URL so that it will work again, and also moves it inside register_settings_pages() to avoid confusing it with a complete URL that would be safe to use in other contexts.

See #334
Props ryelle

#30 @iandunn
3 years ago

In 3836:

WordCamp Coming Soon Page: Revert font to Open Sans.

The original design used Open Sans, but during the merge I switched to the new 4.6 font stack, because I assumed the new stack could be (and should be) used to replace Open Sans in all contexts. Using native fonts would have avoided all of the problems associated with Open Sans (extra HTTP request, leaking information via headers, etc).

That assumption was incorrect, though, because the new font stack is only meant to be used for UI elements, not content.

See #334
Props ryelle

#31 @iandunn
3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 3837:

WordCamp Coming Soon Page: Minor design revisions to align with mockups.

  • Align submit button on the right
  • Override Jetpack form styles
  • Hide Jetpack's Infinite Scroll element

Fixes #334
Props ryelle

#32 @gounder
3 years ago

Not sure if this is should be posted here, but I'm not sure why we are still not getting the contact form on our coming soon page here on https://2017.mumbai.wordcamp.org/

Last edited 3 years ago by gounder (previous) (diff)

#33 @iandunn
3 years ago

In 3838:

WordCamp Coming Soon Page: Bump the cachebuster.

See #334

#34 @iandunn
3 years ago

Hey everyone, sorry for all the problems I caused with this. They should be fixed now thanks to @ryelle's patch, but let me know if there's anything else that's needed.

I think the layout omptimizations that @hugobaeta suggested are probably better for a new ticket, since they weren't part of the original design and this ticket has already gotten lengthy.

@gounder, that is odd. I'll look into it.

#35 @iandunn
3 years ago

@gounder, it looks like the default content wasn't inserted into your site automatically when it was created. I think there was another report of that recently too (cc @kovshenin as FYI).

I fixed it by creating a Contact page.

This ticket was mentioned in Slack in #core by sergey. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.