Development has for realsies started on the new admin help feature plugin.
(hurrah!)
It resides here, if you haven’t been paying attention to these updates: https://github.com/jazzsequence/WordPress-Admin-Help
Currently we’ve got 2 settings that appear in the user profile page to enable/disable tooltips and/or the help overview but neither of those have been implemented yet (though the settings do, in fact, save).
What we have to work with
@ninnypants and @trishasalas both looked at core and currently core puts help in the header for the page you’re on, which is highly inefficient. What this means is that we’ll be doing a lot of forging our own paths with our plugin.
The Plan
So, what we’ll need to do is develop a system that can be easily extended by other plugin and theme developers to allow them to add their own help to their theme/plugin.
Documentation will ideally live in separate files for each page. There will be a function (or series of functions) to pull in the relevant documentation for the current page. We’re going to do as much as we can to include existing help documentation into this, but we’re going a completely different route in terms of handling and presenting it than WordPress core.
Hooks will be created that developers can hook into so they can add their own documentation for their stuff.
What’s next?
@ninnypants is going to work on building out the architecture/framework for the plugin and use grunt to try to pull in existing help content.
@trishasalas is going to work on pulling the help content into the places it needs to go
@trishasalas and @ubernaut will work on ui stuff once the content is pulled in
Concerns
Accessibility
@trishasalas is going to try to follow up with the a11y team and figure out what things we need to be thinking about in terms of accessibility (tests, what works, what doesn’t, resources, etc)
Internationalization
We, of course, need to make sure that all the strings we’re pulling in are properly i18nized. @jazzs3quence will be keeping an eye on that.
javascript disabled/back-compatibility
We need to look into what WordPress core does in js-disabled/non-js browser environments, how they handle it, and what we should do in those cases based on what core’s doing. Our approach is pretty js-centric and would be pretty useless if js was disabled and we didn’t have a fallback (but then, maybe core is the same…).
Pull requests, tickets, comments, etc. are welcome on the Github repo above. I’m usually on IRC though I may not always be at my computer. If I am, I will respond to pings (just say my nick in IRC and I’ll see it). The next meeting will be next monday 10:30 MST