Welcome Screen concept

[dd32]

I'd like to suggest a "Welcome Screen" concept for WordPress.

My initial thought is that its something that we could use to place the rarely viewed information about the release..

For example, Thickbox window covering 70% of the screen. Tabs along the top:

• Welcome to x.y.z
  • Information about what has changed since last version (This would be activated after an upgrade for example)
  • A Quick "Getting Started" tutorial similar to #11008
• WordPress Privacy
  • Quick Transparent overview of the Privacy guidelines WordPress follows with regard to data sent to the API, and what information WordPress exposes to visitors (Useless to most i realise, But its information some people require)
• Server Information
  • This would have 2 sides to it:
  • Allows the user to retrieve a breakdown of server config which is useful when submitting a bug report
  • Gives an "health-check" overview of what the server is running, See #11466 for a few ideas.

The aim isnt to force the information down the users throat, mearly to remind them here's what we have, here's what you have, Now enjoy yourself.

When would it be triggered:

• When the admin first logs in on a new install
• After an upgrade has taken place
  • Might want to customise the order of items for that compared to a new install?
• If the user clicks on a conviently located link somewhere.. Perhaps in the footer?

[dd32]

I'll bring this up during the 3.0 features talks.

[scribu]

+1 from me, btw.

A thickbox with tabs, as you suggested, would be the natural way to do this. Don't know if that's good or bad. :)

[hakre]

Related: #11407

[dd32]

Are we going to push for this in 3.0 or not? Or at least, some kind of welcome/information screen?

[janeforshort]

This wasn't included in the features for 3.0 b/c of the focus on the merge, so I don't think anyone is working on a patch. The last time we talked about it, I thought we were talking about a welcome screen for first-time installs, that would basically be more of a guide to how to use WP, maybe with a progress indicator on the Dashboard or something. This sounds like a separate idea, to be kind of a welcome back post-upgrade feature. I haven't heard that talked about before, though I might have missed it.

[dd32]

The last time we talked about it, I thought we were talking about a welcome screen for first-time installs, that would basically be more of a guide to how to use WP, maybe with a progress indicator on the Dashboard or something

Thats always an option, My idea for it was that it would be a page that gives users information about the new version, Anything that has changed that they need to be aware of, etc. For new installs, it'd give an overview of WordPress and possibly a how-to.

[ocean90]

Related #13514

[ctsttom]

Perhaps the dashboard could just be made more welcoming, currently it feels a little useless as its full of widgets that don't help you get started or access your commonly accessed tasks.

[edwardw]

Is anyone working on this or can I pick up this task and work on it? I wouldn't want to duplicate work if someone is already working on this.

[edwardw]

[PATCH] Version 1 of patch for Welcome Screen

[edwardw]

Please see attached patch above - it is a first revision and can always be polished and improved. It implements the welcome screen in wp-admin.

[bastosmichael]

Will there be hooks for the welcome screen that would allow developers or installers to put their own added content as well as be able to brand it for their users? During WCSD Matt talked about wanting to do a Step by Step first time user thing and allowing an API for the welcome screen I think would help move that forward. Also setting up levels would be nice so that for example Admins would look at security and server info while say Editors or other users could be informed of privacy etc. Just a thought but great idea.

[edwardw]

[PATCH] Version 2 of patch for Welcome Screen

[edwardw]

Example plugin that adds a welcome screen tab

[edwardw]

Replying to bastosmichael:

Will there be hooks for the welcome screen that would allow developers or installers to put their own added content as well as be able to brand it for their users?

You can check the sample plugin attached above for how this will work. Please note that you will need to use the YUI compressor to compress the *.dev.css files to *.css for the CSS to display properly.

[dougwrites]

@edwardw: any way you could upload a .png of what the interface will look like with your patch and a .txt of the content?

Seems like this is really on two tracks: what the UI implementation will be (one big box, a separate screen like Credits or Freedoms, dismissable call-outs as suggested by Matt's NUX slide, or even tooltips, balloons, or a modal box) and then what the points/words/links in the box will be. For the latter, I think it will go through many iterations, takes, and re-re-polishings. I'm uploading a .txt file of what my first take of the wording looks like. I hope it is OK to get a lot of ideas on the table for this.

[dougwrites]

Other content for Welcome Screen. Part of this is modified from changeset [12212] (since reverted)

[edwardw]

Replying to dougwrites:

@edwardw: any way you could upload a .png of what the interface will look like with your patch and a .txt of the content?

Seems like this is really on two tracks: what the UI implementation will be (one big box, a separate screen like Credits or Freedoms, dismissable call-outs as suggested by Matt's NUX slide, or even tooltips, balloons, or a modal box) and then what the points/words/links in the box will be. For the latter, I think it will go through many iterations, takes, and re-re-polishings. I'm uploading a .txt file of what my first take of the wording looks like. I hope it is OK to get a lot of ideas on the table for this.

I have already integrated the contents of that into the patch. Also, the server information tab is different depending on your server, so I haven't uploaded that part into the HTML dump.

[edwardw]

Screendump

[edwardw]

Textdump

[duck_]

Replying to dougwrites:

I'm uploading a .txt file of what my first take of the wording looks like.

A couple of minor notes:

• In k) "GPL License" should be just "GPL", "GNU GPL" or expanded to "GNU General Public License"

• k) again, "Wordcamps" to "WordCamps"

[SergeyBiryukov]

Some suggestions on the patch:

1. Anonymous functions like add_action('admin_head', function() { ... }); are unavailable in PHP 5.2.4, which is still the minimum required version.
2. No need to patch minified .css and .js, they'll quickly become stale. Normally only the .dev versions should be patched, a commiter will re-minify them on commit.
3. For i18n, __() should be used rather than _(), and _e() instead of echo _().

[edwardw]

[PATCH] Version 3 of patch for Welcome Screen

[edwardw]

Replying to SergeyBiryukov:

Some suggestions on the patch:

1. Anonymous functions like add_action('admin_head', function() { ... }); are unavailable in PHP 5.2.4, which is still the minimum required version.
2. No need to patch minified .css and .js, they'll quickly become stale. Normally only the .dev versions should be patched, a commiter will re-minify them on commit.
3. For i18n, __() should be used rather than _(), and _e() instead of echo _().

Please see updated version of patch.

[SergeyBiryukov]

Related: #6479

[edwardw]

[PATCH] Version 4 of patch for Welcome Screen

[edwardw]

Updated with SergeyBiryukov's related suggestion.

[jane]

I think there's too much trying to go in here. My vision for this was simpler.... for new install, some welcome text and links off to the things they ought to do before their blog goes live. For post-update, an 'about this version' thing that outlines the features that are new since last time plus link to credits maybe. Thinking they live under W menu, one replaces other at first update.

[koopersmith]

In [18749]:

Add frame for welcome panel on dashboard (currently hidden). see #11651.

[koopersmith]

I've added the frame for the welcome panel to the dashboard. It is currently hidden and filled with placeholders. We will show different content based upon each user's role.

[jane]

Replying to edwardw:
Hi @edwardw. Only a member of the core team should change the owner field, and it will generally be a member of the core team that "owns" the ticket/is responsible for overseeing it and committing it. Please don't change that field.

[jane]

This original ticket is not quite how we're proceeding. We're splitting it into two separate features: a post-update welcome screen (see ​#18742), and a first-time user box on the dashboard that contains significantly fewer things than have been suggested here (and targeted based on capabilities). Server information and privacy stuff will not be part of either. Privacy would be more appropriate in a screen accessed via footer link.

[edwardw]

Replying to jane:

Replying to edwardw:
Hi @edwardw. Only a member of the core team should change the owner field, and it will generally be a member of the core team that "owns" the ticket/is responsible for overseeing it and committing it. Please don't change that field.

So basically what you're saying is that developers interested in feature development such as myself are simply shafted, ignored and then told to go away. I'm seeing the same narcissistic attitude as seen at #17048.

This ticket sat almost untouched for 20 months, then I thought I might come and help to try to make a welcome screen, then this "koopersmith" user comes in and pays no attention to my work whatsoever. Great attitude WordPress team, putting off new developers who want to help and submit patches.

Same thing with the other patches I've submitted - they sit there stale and then some narcissistic user will come along and ignore my work.

[jane]

Replying to edwardw:

Replying to jane:

Replying to edwardw:
Hi @edwardw. Only a member of the core team should change the owner field, and it will generally be a member of the core team that "owns" the ticket/is responsible for overseeing it and committing it. Please don't change that field.

So basically what you're saying is that developers interested in feature development such as myself are simply shafted, ignored and then told to go away.

No, in that comment I was trying to politely let you know about the protocol. Some fields (milestone, owner, setting component as task (blessed)) are meant for the core team only, and are used to manage the entire project. Anyone can contribute the patch that will be committed, it has no relation to ticket ownership.

This ticket sat almost untouched for 20 months, then I thought I might come and help to try to make a welcome screen, then this "koopersmith" user comes in and pays no attention to my work whatsoever.

"This 'koopersmith'" is a member of the core tam and is the person who was assigned the task in our IRC meetings and listed on the ​3.3 project scope doc. We probably should have linked to when it was confirmed, and noted the change in direction. Putting communication in all channels (IRC, wpdevel blog, Trac, hackers, etc) is something we need to get better at, but no malice was intended here.

Same thing with the other patches I've submitted - they sit there stale and then some narcissistic user will come along and ignore my work.

Every release we have an open scoping meeting in IRC that is publicized ahead of time on wpdevel. Once the scope has been set in that meeting, those are the tickets that will get core team attention (aside from interruptive security issues). Anyone who wants to advocate for a ticket they'd like te see get in (that isn't on the approved version scope) can get core team attention by getting traction on the ticket and getting people to test the patch. If a patch is well-tested, you can ask in IRC for it to be reviewed even if it's not in scope, if it is before freeze.

What you ascribe to narcissism is in this case merely the agreed upon scope and assignments for 3.3. I'm sorry there was a communication gap, but we have thousands of tickets on trac between the current version, future release, and awaiting review, so it's impossible to follow all the tickets while also working on our tasks for a release. We often work a bit heads down on our assigned tasks until we have something that's ready to post for feedback. Hopefully now that you know the process, it will be less frustrating in the future. Sorry for the frustration and poor communication.

[edwardw]

Replying to jane:

Every release we have an open scoping meeting in IRC that is publicized ahead of time on wpdevel. Once the scope has been set in that meeting, those are the tickets that will get core team attention (aside from interruptive security issues).

Anyone who wants to advocate for a ticket they'd like to see get in (that isn't on the approved version scope) can get core team attention by getting traction on the ticket and getting people to test the patch. If a patch is well-tested, you can ask in IRC for it to be reviewed

How might I do that? So far my other patches have been sitting stale for over a month and I'm getting the general feeling of apathy/narcissism towards new contributors.

even if it's not in scope, if it is before freeze.

What you ascribe to narcissism is in this case merely the agreed upon scope and assignments for 3.3. I'm sorry there was a communication gap, but we have thousands of tickets on Trac between the current version, future release, and awaiting review, so it's impossible to follow all the tickets while also working on our tasks for a release. We often work a bit heads down on our assigned tasks until we have something that's ready to post for feedback. Hopefully now that you know the process, it will be less frustrating in the future. Sorry for the frustration and poor communication.

For example, I've tried making patches for open "feature requests" and "bug reports", but they either sit stale and ignored like #14960 or closed by biased, politically-motivated people like #17048. It really has an effect of turning away potential or interested contributors.

Again, thank you for taking the time to explain and clarify how the process works - I've read around documents on the WP Codex and the WordPress development blog, but your explanation certainly helps. Is there a more appropriate forum to discuss this and for developers interested in feature development such as myself to bring tickets to your (core devs) attention?

[nacin]

Replying to edwardw:

For example, I've tried making patches for open "feature requests" and "bug reports", but they either sit stale and ignored like #14960 or closed by biased, politically-motivated people like #17048. It really has an effect of turning away potential or interested contributors.

Hi edwardw,

The biased, politically-motivated person you're referring to is, I imagine, me. I'm also a member of the core team. The comment *is indeed both political and biased, but that's because my comment is outlining a deliberate project decision we have made long ago with regards to absolute/relative links. The conversation comes up every once in a while, and the entire core team always recommits to their existing decision, due to past experiences and expertise in the matter, as well as our development opinions. dd32 also weighed in on that thread, and he too is a member of the core team.

I'm sorry that's not what you want to hear. I too have contributed code to WordPress and other projects that the core developers (or, even after joining the core team, my colleagues) have rejected for reasons other than quality of the code or the fix. That's just how it works.

I've commented to #14960. As it involves an underused feature we've long planned to deprecate in some way, it attracted little attention. I attempt to read every ticket, comment, and patch, but when I looked it up, that ticket was one of the 50 or so currently in my lower priority (and unread) queue.

Contributing to feature development can be tough. Often, the idea exists for a long time, but no direction or traction is given. (The case here.) When the core team decides to bless a feature, which occurs at the start of the cycle in a public scope session, it normally is given vision and direction by Jane, Matt, or another member of the core team. Soon thereafter, iterations will begin. This development may look nothing like what the community has originally proposed, or even what a member of the core team initially proposed.

Something like a welcome screen is really difficult to offer any contribution without any direction. The text will be written at the direction of the user experience lead (jane), and she will also decide how users should be interacting with it. Not all blessed tasks are this UX-focused, though many are. While we normally don't want to discourage contributions, generally it is more productive to contribute to other items while a core group of people (in this case, jane and koopersmith) iterate on things quickly and mold it into what the core team wants. After that, people are welcome to pounce onto it.

Don't think your contribution didn't help. By having some activity here, other developers were able to revisit the ticket, get an idea for its current direction, and figure out where we should probably take it. The patch reminded some of us of the Health Check plugin, which never got off the ground. The point was made that a lot of this text belonged in a plugin, rather than in a simple welcome screen. And thus design iterations began.

At this point, we're far, far outside the bounds of this ticket, so I'll leave it at that.

[jane]

For sake of beta 1, full width box at top of dashboard when new install loads for first time. Includes Dimiss X, but accessible via screen options (show on screen). Hover over dismiss should show tooltip that says, "You can bring this box back using the screen options in the Help tab above)."

Will be doing a survey on wordpress.org blog to get broader user feedback on what would be most useful here for text/links (to be done during beta 1, so that beta 2 will have finished content), but in meantime, use this placeholder text.

::::::::::::::::::::::::::::::::::

Welcome to your new WordPress site!
Here are some things most people do when they set up a new WordPress site. To get started, use the links below and we'll give you some extra help with these tasks.

Col 1:

• Fill in your profile.
• Choose comment settings.
• Set your time zone.

Col 2:

• Edit your site tagline.
• Choose a theme.
• Add some widgets.

Col 3:

• Delete the default post and comment.
• Create your first post.
• Edit the sample page to be about you.

::::::::::::::::::::::::::::::::::

Note: if user clicks link from this box, there will be a pointer on the resulting screen to make it more obvious where to look.

[ocean90]

We also need one filter to disable all this welcome stuff please. Especially for Multisite.

[koopersmith]

In [19007]:

Welcome panel contents and functionality. see #11651.

[koopersmith]

In [19009]:

In welcome panel, move periods outside of links. see #11651.

[dougwrites]

Re: [19009] Do we even need the periods after each of the links?

[nacin]

In [19014]:

Move welcome panel link to a 'Show on screen' checkbox. see #11651.

[sbressler]

In Chrome 15 on Windows 7, I find the following:

• Login to dashboard
• Click "Welcome" checkbox
• Click on "Fill in your profile" link
• Go back in the browser

Expected:

• Welcome panel is still showing
• Welcome checbox is checked

Actual:

• Welcome panel is hidden
• But the welcome checkbox is indeed checked

I need to uncheck and recheck the checkbox to show the panel again.

This is clearly browser related (though can be reproduced in far more than just Chrome, but I'm not sure exactly what's going on here. In general, can this be resolved?

[sbressler]

Remove the periods after the links in the welcome panel

[sbressler]

Replying to dougwrites:

Re: [19009] Do we even need the periods after each of the links?

Agreed. Fixed in 11651.remove-periods.diff​

[sbressler]

Change the text that's included in the links for the welcome panel (includes 11651.remove-periods.diff​)

[sbressler]

Attached 11651.change-link-text.diff​ which moves some of the text of the panel out of the links. I think in general links make the most sense on the noun phrases of most of these sentences, rather than including the verbs as well. Just a thought of mine, though - it's fine to ignore if the general consensus feels otherwise.

[nacin]

In [19133]:

Show the welcome screen when one shows it from Screen Options, advances to a page, then uses the browser's back button to return. see #11651.

[nacin]

In [19134]:

Use a better method for [19133]. see #11651.

[nacin]

Replying to sbressler:

This is clearly browser related (though can be reproduced in far more than just Chrome, but I'm not sure exactly what's going on here. In general, can this be resolved?

The issue is that most browsers generally repaint the page and execute scripts, but keeps inputs filled in. So the checkbox is checked, but the fact that it was clicked to remove the hidden class is not reflected, and since the server isn't hit, the HTML doesn't reflect that it should be shown. [19133] runs some code on DOM ready to detect this.

[koopersmith]

In [19145]:

First half of new welcome panel formatting. props chexee. see #11651.

[koopersmith]

In [19163]:

Second half of new welcome panel formatting. Add .icon16, for menu icon reuse. see #11651.

[koopersmith]

In [19164]:

Blue theme styles for welcome panel and about pages. see #11651, 18742.

[ocean90]

11651.blue-icon16.patch​ adds blue icons.

[nacin]

Replying to ocean90:

11651.blue-icon16.patch​ adds blue icons.

Let's provide the same classes provided in [19163].

[ocean90]

Let's provide the same classes provided in [19163].

Done in 11651.blue-icon16.2.patch​.

[koopersmith]

In [19197]:

Blue theme improvements for welcome panel. Add .icon16 definitions. see #11651.

[ocean90]

Related: #19217

[jane]

New badge

[jane]

Added screenshot of new badge for this bit and for post-update screen. Whoever has time to sub it out let me know and I'll shoot you the PSD.

[jane]

Sent PSD to @ocean90. PS design props to @chexee on this.

[nacin]

In [19244]:

New WordPress badge for welcome panel and about screens. props chexee, ocean90. see #11651.

[jane]

Updated text. To use @chexee's nice spacing, but needs three columns. May need a different badge size to accommodate. Broke out to have settings, content, theme bits so we could put easier customization links, in the absence of pointers on resulting screens. @chexee can fiddle with layout.

[jane]

text didn't paste properly before, weird.

[Welcome to your new WordPress site!]

If you need help getting started, check out our documentation on <link>First Steps with WordPress</link>. If you'd rather dive right in, here are a few things most people do first when they set up a new WordPress site. If you need help, use the Help tabs in the upper right corner to get information on how to use your current screen and where to go for more assistance.

Basic Settings [settings icon]
Here are a few easy things you can do to get your feet wet. Make sure to click Save on each Settings screen.

• Choose your privacy setting
• Select your tagline and time zone
• Turn comments on or off
• Fill in your profile

Add Real Content [pages icon]
Check out the sample page & post editors to see how it all works, then delete the default content and write your own!

• View [sample page] and [post] on your site
• Delete sample page and post
• Create an About Me page
• Write your first post

Customize Your Site [appearance icon]
Use the default theme -- Twenty Eleven -- or [choose a new one themes.php]. If you stick with Twenty Eleven, here are a few ways to make your site look unique.

• [Choose light or dark themes.php?page=theme_options]
• [Set a background color themes.php?page=custom-background]
• [Select a new header image themes.php?page=custom-header]
• [Add some widgets widgets.php]

Already know what you're doing? <link>Dismiss this message</link>.

[ryan]

In [19327]:

First pass at Welcome Screen content. Props jane. see #11651

[ryan]

"Dismiss this message" needs love. The default theme stuff could change to mentioning the current theme. Then we could show links based on the capabilities of the current theme. If we stick with mentioning the default theme, we need to accommodate for WP_DEFAULT_THEME and will be unable to determine actual capabilities.

[ryan]

In [19336]:

Welcome Panel: Consult current theme capabilities. Remove trailing punc from list items. see #11651

[ryan]

In [19337]:

Welcome Panel: Add 'First Steps With WordPress' link. see #11651

[chexee]

Styles dismiss paragraph. replaces double hyphens with emdashes. fixes h3 line-height.

[ryan]

In [19339]:

Welcome Screen styling. Props chexee. see #11651

[chexee]

Updates column widths to show 3-col view on 1280 wide screens. Props helenyhou

[azaozz]

In [19341]:

Welcome Screen: update column widths to show 3-col view on 1280 wide screens. Props helenyhou chexee, see #11651

[chexee]

has columns break below badge and intro paragraph.

[koopersmith]

In [19342]:

Shift welcome panel columns below WP badge. Improve column grid. props chexee, see #11651.

[azaozz]

In [19345]:

Welcome Screen: remove white space, make the second dismiss link work, see #11651

[markjaquith]

In [19349]:

Start documenting under the hood features for WordPress 3.3. see #11651

[ocean90]

#19271

[sbressler]

Replying to ryan:

In [19336]:

Welcome Panel: Consult current theme capabilities. Remove trailing punc from list items. see #11651

Ouch, no props? 11651.remove-periods.diff​

Also, I added ux-feedback after adding 11651.change-link-text.diff​ 2 weeks ago, but never received any.

[jane]

@sbressler: I answered that somewhere else. Matt prefers links to include the action, not just be on the noun.

[sbressler]

I asked the question here, so it would be most useful (to me at least) to answer it here, since Trac is where I've been following this ticket. And as much as I respect Matt's opinion, why isn't the entire UX team making decisions like these rather than going by his opinion?

[johnbillion]

Under what circumstance is the welcome screen displayed? Setting up a fresh install from trunk at r19363 with all cookies cleared and an empty database, the welcome panel remains hidden when the admin user logs in for the first time.

[duck_]

Replying to johnbillion:

Under what circumstance is the welcome screen displayed?

Described on #19127, but not implemented yet.

[jane]

Replying to sbressler:

I asked the question here, so it would be most useful (to me at least) to answer it here, since Trac is where I've been following this ticket. And as much as I respect Matt's opinion, why isn't the entire UX team making decisions like these rather than going by his opinion?

I am the UX team.

[jane]

I meant that to sound funny, not harsh. I'll clarify: unlike the developer team, which has existed for many years and has appointed lead developers and commit-level developers, the UI group is smaller and has not yet been around long enough for lead designers or commit-level (or the equivalent) designers to be named (though I'd like to see that start happening in the next couple of releases if we continue with consistent contributors).

Matt used to sign off on all the UI stuff. He appointed me to take that role as he scaled back (but he still provides guiding vision and has veto power). I did debate the link nouns only vs link the whole action with him a few months ago. I decided I agreed with him. Lead devs did not raise an objection. In a situation where I or the core team disagreed with a suggestion by Matt, it would not jut be accepted blithely. In cases where part of the lead team disagrees with me on a ux issue, we debate it until we come to a resolution. If we can't convince each other and retain a split opinion, it's up to Matt to make the call. In cases where we all agree, we just move on.

[jane]

Just waiting on static badge replacement from @chexee to get around the bug in android etc that shows overlapping badges, then can close ticket.

[chexee]

static badge to fix android bug

[chexee]

Switches from CSS3 styling to static background image.

[nacin]

In [19366]:

Undo clever gradient backgrounds for the WP welcome badge. Doesn't degrade well in Android and possibly other browsers. props Chexee, see #11651.