#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)
Change History (43)
#4
@
11 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
@
11 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
@
11 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
@
10 years ago
In the meantime, could you please make the current page responsive? There is already a patch for the corresponding ticket #616.
#8
@
10 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
@
10 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?
#11
@
8 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:
↓ 13
@
8 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
@
8 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:
↓ 15
@
8 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
@
8 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.
#16
@
8 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.
#17
@
8 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
@
8 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.
#19
@
8 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.
#21
@
8 years ago
Woot! This is live now :)
It looks and functions so much better than the original. Kudos to all of you :)
#22
@
8 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:
↓ 24
@
8 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:
↓ 25
@
8 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
@
8 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:
- 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:
Aside from this, this is a tremendous step forward. It's a gorgeous design that fits the WordPress brand perfectly! :)
#26
@
8 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.
#27
@
8 years ago
The Link for coming soon under settings seems to be broken, the site url gets repeated something like below:
#28
@
8 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.
#32
@
8 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/
#34
@
8 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
@
8 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.
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! :)