Automatically open help panel

[ptahdunbar]

The help screen is highly inaccessible. Developers are not able to link to content in the help panels if you need to point users to specific directions for your plugin.

This patch is a quick stab at it to see if it's worth while.

What it does it allow direct links to the help panel. Upon pageload, it'll automagically open up to the correct panel.

Usage:

1. Install the patch
2. Click ​http://wordpress.dev/wp-admin/index.php#tab-panel-help-layout

Again, this is a quick stab. The concept could definitely be improve/abstracted and DRYed up.

Let me know your thoughts :-)

[ptahdunbar]

Don't forget to define( 'SCRIPT_DEBUG', true );

[nacin]

I really like this idea. Note that this should actually verify that the hash is a panel. So a simple match for ^tab-panel- would be a good start. I imagine others will want to weigh in more on the particular implementation.

[ptahdunbar]

verifies that the panel actually exists; bug fix when screen options panel is set; new: update the url when navigating between tabs.

[helenyhou]

+1 for the idea.

Initial observations:

• Seems like it'd be much more likely that the link would be to help located on the current screen, so it would need to work whenever, not just on page load.
• Scrolling back to the top is a bit wonky in Firefox (I know, I'm the holdout, and it's not going to change)
• Both the Screen Options and Help tabs are in the open state and are showing.

I wonder if this would work better if the tabs and panels were fixed to the top below the toolbar. I feel like this was attempted before but abandoned for one reason or another. Would like to discuss trying it again. I think it would be especially helpful on longer screens so that you don't have to go back up to the top to find help/screen options - in fact, I wonder if that's why they are so little noticed in the first place. We would have to contemplate what that means for screens that are too short to show the tab to close the panel back up again.

[helenyhou]

Oh, new patch while I was writing the previous comment. Ignore the last bullet point :)

Re: new patch - remove the hash when the panel is closed?

[ptahdunbar]

Replying to helenyhou:

Seems like it'd be much more likely that the link would be to help located on the current screen, so it would need to work whenever, not just on page load.

• I was just pointing out that it works when linking to help panels between pages. It works whenever.

Scrolling back to the top is a bit wonky in Firefox (I know, I'm the holdout, and it's not going to change)

• FF works smoothly on my mba. don't tell me ur on a winbox ;p

Re: new patch - remove the hash when the panel is closed?

• I can remove the hash, but the # is still there :/

P.S. The more patches I post the more ghetto my js gets. #phpdevftw :D

[ptahdunbar]

removes hash when closing help screen

[jane]

Replying to helenyhou:

I feel like this was attempted before but abandoned for one reason or another.

We did, I wanted to get the click targets up into the toolbar as icon + text, but we weren't able to get positioning we all agreed on before it was time to freeze/go beta. Definitely worth revisiting.

I like idea of auto-opening a same-page help tab on click contextually, but am not as sure about switching pages and opening a help tab, seems like it might be disorienting. Might be a situation where popping a modal with the relevant text might be a better experience than dumping them somewhere else to get instructions for something.

[ptahdunbar]

Replying to jane:

I like idea of auto-opening a same-page help tab on click contextually, but am not as sure about switching pages and opening a help tab, seems like it might be disorienting. Might be a situation where popping a modal with the relevant text might be a better experience than dumping them somewhere else to get instructions for something.

Well, the idea being that it could be linked from the plugin's row links on the plugins page for quick access after installation. It would be sweet, not a deal-breaker tho.

[helenyhou]

I agree with Jane - I think it's possible that it would be disorienting to a user to do it when the page loads. Imagine if they reload the page with the hash in it, or bookmark it that way. It will always happen, regardless of their intent, and for non-technical users who, in my experience, tend to bookmark something new once they get there and use that bookmark from that point on, having it scroll-and-slide-down every single time would surely be frustrating.

A much more common use case than the plugin row links in my mind would be for looking for guidance when on a screen, e.g. "What am I supposed to put in this field again and why?" When you think of using it that way, clicking a link to an anchor to slide open the available contextual help, which doesn't take you away from your current position on the page because it's fixed to the top, makes a lot more sense.

Thinking on it more, I suppose the question then becomes whether or not there should be something in core that makes it easy to specify that a link will open contextual help (binding an action), since technically you could do it now on your own. A class to use for the link, JS that looks for #tab-panel* in href's, or something else?

Replying to ptahdunbar:

Replying to helenyhou:

Seems like it'd be much more likely that the link would be to help located on the current screen, so it would need to work whenever, not just on page load.

• I was just pointing out that it works when linking to help panels between pages. It works whenever.

Does it currently or do you mean it could? I just tested again and it doesn't work when it's linking within the page, and the JS tells me it's just activating on document ready.

• FF works smoothly on my mba. don't tell me ur on a winbox ;p

Nope, also OSX. It appears to put the top corner at the real 0,0, which is behind the admin bar.

[ptahdunbar]

removed ability to open help from another page; removed hash updating; adding ability to link to help panel from current page;

[azaozz]

21273-5.patch is more or less based on 21273.3.diff and has some improvements. Also supports links on the same page with href="#tab-panel-*" to open the help on that tab or switch to the tab if the help is already opened.

[azaozz]

21273-6.patch is the merge of ticket.21273.4.diff and 21273-5.patch (as discussed with @ptahdunbar in #wordpress-dev).

Still thinking it's a good idea to be able to load a page with the Help panel open. Any confusion can be reduced (eliminated?) if the user can see the panel opening animation. Perhaps this would make some users notice that there's a Help panel :)

[nacin]

Going to punt this, given possible changes in #21583.

[helenyhou]

Talked to ptahdunbar in person about this, and some thoughts:

• #21583 isn't happening for 3.5, and has a lot of accompanying issues (click to open/sticky open state vs. the current toolbar interaction). Since that was the cause for punting this, it's good to make a note here.
• Aforesaid ticket would actually have been extremely helpful for implementing this, in that the panel would be fixed to the toolbar/top and thus would not cause the user to be scrolled back to the top and likely losing their place when clicking that link.
• I still hesitate when it comes to the issue of intent and adding the hash. I can see why you would want to link to a different page *and* open the panel, but I think this would actually be a much more successful interaction if it were to stay on the page. When directing to another page, there are actually still multiple areas of text viewable and thus it is not necessarily as clear what the user is meant to read based on what was clicked before. In any case, I think starting with just the on-page case first would be easier to really evaluate - can always expand usage from there.

[ubernaut]

adding an attachment as it pertains to this discussion:

​http://make.wordpress.org/docs/2013/09/23/admin-help-23-september-2013-meeting-recap/

[ubernaut]

adding another mockup image…

[desrosj]

Re-adding a milestone. I think this still a cool idea still holds up. That said, #21583 is still unresolved, and the approaches above will likely need to be reexamined within the context of more recent versions of WordPress.