WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#18693 closed task (blessed) (fixed)

New feature pointers

Reported by: jane Owned by: koopersmith
Milestone: 3.3 Priority: normal
Severity: normal Version: 3.3
Component: UI Keywords:
Focuses: Cc:

Description

When a new user-facing feature is included in a core update, display a new feature pointer that highlights the new feature a la facebook, gmail, etc.

Attachments (27)

18693.diff (2.2 KB) - added by nacin 3 years ago.
18693-2.patch (5.2 KB) - added by WraithKenny 3 years ago.
Pointers API
18693.2.diff (1.9 KB) - added by nacin 3 years ago.
18693.cursor.patch (428 bytes) - added by ocean90 3 years ago.
18693.no-arrow-ie8.png (12.4 KB) - added by SergeyBiryukov 3 years ago.
18693.no-arrow-ie9.png (14.8 KB) - added by SergeyBiryukov 3 years ago.
show_wp_pointer.18693.diff (945 bytes) - added by scribu 2 years ago.
Screen shot 2011-11-10 at 12.24.38 PM.png (22.5 KB) - added by jane 2 years ago.
New pointer style 11/10
18693.prelim-css.diff (2.3 KB) - added by georgestephanis 2 years ago.
Preliminary styling changes for pointer boxes. Requires two images (forthcoming).
icon-pointer-flag.png (791 bytes) - added by georgestephanis 2 years ago.
Flag in a circle -- flag is transparent to enable the background color to change as desired.
18693.revised.diff (4.5 KB) - added by georgestephanis 2 years ago.
Minor styling and JS changes to match design.
18693.koop.diff (6.2 KB) - added by georgestephanis 2 years ago.
For koop to explain something …
arrow-pointer-blue.png (959 bytes) - added by georgestephanis 2 years ago.
Arrow sprite image
arrow-pointer-blue.2.png (959 bytes) - added by georgestephanis 2 years ago.
Gah, maybe this one will carry through.
18693.left-right-arrow-alignment.patch (522 bytes) - added by chexee 2 years ago.
aligns left and right pointers to the lower side
18693.more-pointers.patch (5.4 KB) - added by ocean90 2 years ago.
18693.more-pointers.2.patch (6.2 KB) - added by ocean90 2 years ago.
18693.more-pointers.3.patch (6.4 KB) - added by ocean90 2 years ago.
18693.more-pointers.4.patch (6.1 KB) - added by ocean90 2 years ago.
Don't allow to set pointers onto all screens.
18693.more-pointers.5.patch (6.0 KB) - added by koopersmith 2 years ago.
reset-pointer.php (577 bytes) - added by koopersmith 2 years ago.
A handy plugin for resetting pointers.
18693.3.diff (2.3 KB) - added by nacin 2 years ago.
18693.more-pointers.6.patch (6.0 KB) - added by koopersmith 2 years ago.
18693.more-pointers.7.patch (5.9 KB) - added by koopersmith 2 years ago.
18693.4.diff (2.1 KB) - added by nacin 2 years ago.
18693.remove.hyphens.pointers.diff (2.6 KB) - added by koopersmith 2 years ago.
18693.5.diff (2.5 KB) - added by nacin 2 years ago.

Download all attachments as: .zip

Change History (134)

comment:1 jane3 years ago

Koop will be uploading initial patch with functionality. Actual pointer text will be added in before freeze. For 3.3 we will have pointers to the new admin bar/header and the new uploader.

comment:2 johnbillion3 years ago

  • Cc johnbillion@… added

comment:3 ocean903 years ago

  • Cc ocean90 added

comment:4 koopersmith3 years ago

In [18707]:

Add pointers feature, and pointer to admin bar, props nacin for PHP bits, see #18693.

comment:5 follow-up: azaozz3 years ago

Looking at [18707]: not sure where wp-pointer.js comes from and why it's not in wp-includes/js/jquery together withe the other UI pieces or in wp-admin/js if it's ours. Also why wp_pointer_enqueue() has the $hook_suffix arg?

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

comment:6 defries3 years ago

  • Cc remkus@… added

comment:7 kovshenin3 years ago

  • Cc kovshenin@… added

comment:8 johnbillion3 years ago

  1. The filter name for pointers should definitely be changed to show_wp_pointer with the pointer name as a parameter (instead of show_wp_pointer_admin_bar as in the current patch).
  2. Can we use 'p-{pointer}' (ie. 'p-admin_bar') as the user setting name instead of 'p0'? This'll make them more extensible.
  3. Are there plans to introduce some nice API methods so plugins/themes can add pointers?

comment:9 johnbillion3 years ago

Oh and the admin bar pointer looks great by the way :)

comment:10 kovshenin3 years ago

FYI, what we managed to do with Twenty Eleven: http://theme.fm/2011/09/introducing-pointers-in-wordpress-3-3-2407/ Not sure about usage on the front end though.

comment:11 jane3 years ago

Since we're rushing the pointer in right before freeze and didn't do it as a widespread plugin first, I'd like to make it core only for v1 and add more extensibility in 3.4. That way if once it's in the wild we realize we should have done it differently, we can fix it without having to worry about breaking plugins. In general I think we should be doing this (or starting more features as plugins), because we are backed into corners with a number of features that are being used by plugins/themes that makes it less appealing to improve them bc of backwards compat (widgets, menus, etc).

comment:12 JohnONolan3 years ago

Should the pointer have a more distinct look and feel? Being white/grey *like everything else in WordPress* seems a little counter-intuitive to its purpose

comment:13 JohnONolan3 years ago

  • Cc john@… added

One option:

Similar styling to WordPress message boxes (confirmation of updating post/plugin/whatever) - http://cl.ly/AFLt/o

Changes:

.wp-pointer-content {
border: 1px solid #E6DB55;
border-radius: 3px;
background: #FFFEF4;
}
.wp-pointer-top .wp-pointer-arrow {border-bottom-color: #E6DB55;}
.wp-pointer-top .wp-pointer-arrow-inner {border-bottom-color: #FFFEF4;}

comment:14 DrewAPicture3 years ago

The admin bar pointer looks great and caught my attention as it should. Nice work.

comment:15 sbressler3 years ago

  • Cc sbressler@… added

comment:16 swissspidy3 years ago

  • Cc hello@… added

comment:17 kovshenin3 years ago

@koopersmith: In http://core.trac.wordpress.org/browser/trunk/wp-includes/js/wp-pointer.dev.js?rev=18707 on line 16, an anchor element is being opened but a div element is being closed, is this intentional?

comment:18 Ipstenu3 years ago

Probably should have put this here and not #18197 ... My bad!

Admin Bar pointer has no functional close button on IE 8. I know, IE 8 is out of date, but this would be really annoying really fast.

http://f.cl.ly/items/2d2N051e2C0p0I331h2l/IE7-pointers.jpg

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

comment:19 rvoodoo3 years ago

Made a comment in passing here http://wpengineer.com/2272/how-to-add-and-deactivate-the-new-feature-pointer-in-wordpress-3-3/

And was referenced here. On my completely bare test install with no plugins, using IE7, the pointers appear, however the close button is plaintext, and I have no way to make the pointers go away.

I had thought IE7 was going the way of the dinosaur (I only use it at work, no choice) so I wasn't worried to much. Just wanted to bring it up in case it's an issue

comment:20 nacin3 years ago

I had a conversation with koopersmith and we plan to switch closing to an XHR call and avoid the user settings API.

kovshenin, first, you had a great write up. Second, it'd be great for both you and wpbeginner.com to update your tutorials when we're done. We don't want the user settings API to start getting used all over the place.

User settings are cool and simple, but bad for one-off features like this, especially when plugins may then extend it. The issue is that the cookie holding that data can only hold so much data (4kb). It's also why we kept the setting name so short ("p0"). Of course, wpbeginner.com then uses p1, as if we'd never want to use that ourselves? Who knows.

comment:21 in reply to: ↑ 5 nacin3 years ago

Replying to azaozz:

Looking at [18707]: not sure where wp-pointer.js comes from and why it's not in wp-includes/js/jquery together withe the other UI pieces or in wp-admin/js if it's ours. Also why wp_pointer_enqueue() has the $hook_suffix arg?

wp_pointer_enqueue() is attached to admin_enqueue_scripts, which passes us a $hook_suffix. While constructing the API I left that in, as future pointers may have page-targeted pointers.

wp-pointer, as indicated by the prefix, is ours. wp-includes/js/jquery should probably be reserved for external scripts. wp-includes/js was chosen because there's nothing stopping this from being used on the frontend, either in a walkthrough or by a plugin.

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

comment:22 dougwrites3 years ago

  • Cc heymrpro@… added

comment:23 kovshenin3 years ago

@nacin, thanks! I'll make sure the post is up to date with this ticket, thanks for the heads up!

comment:24 BandonRandon3 years ago

Looks cool, my only comment is I would like a way to turn this off. I'm assuming I can unhook it (like the admin bar) but a setting would be nice. I looked around a bit and couldn't find one if there is one let me know.

comment:25 BandonRandon3 years ago

  • Cc BandonRandon added

nacin3 years ago

comment:26 nacin3 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

18693.diff is a rough cut at killing off user settings.

Ideally pointers get registered to a singleton object, rather than what we have here. That can then encapsulate the required JS and what not. Unfortunately, it's pretty clear these are going to get immediate use by plugins, so I'd really like to close up the JS right away and encourage a PHP-based API now.

I opted to store everything as a serialized array for now. It could also be comma-separated, or stored as separate meta values. Perhaps westi or ryan can affirm the current approach.

I discussed with koop the idea of allowing blog-level pointer controls. We may wish to hold off on that, if only to avoid the inevitable usermeta bloat.

comment:27 hd-J3 years ago

  • Cc jeremy@… added

comment:28 joostdevalk3 years ago

Loving this feature and already toying with it in some plugins. I agree with @JohnONolan though, it needs to stand out a lot more... It's too bland now.

comment:29 mbijon3 years ago

Both for functionality (API & adding step-by-step) and appearance, I think this Guiders.js is worth a look: https://github.com/jeff-optimizely/Guiders-JS

Guiders is Apache licensed though & not fully compliant with GPL2. It could be worth talking to the authors about dual-license, since they seem to have released it for some promo value.

comment:30 mbijon3 years ago

  • Cc mike@… added

comment:31 nbachiyski3 years ago

  • Cc nbachiyski added

comment:32 nbachiyski3 years ago

Today I played with a PHP API for an hour and here is the result:

https://gist.github.com/1261486

It doesn't have implementation details, although most of it should be obvious.

The hard thing here is to find a balance for extending it via PHP and/or JS. This also depends on the JS library we use and its methods of extension. Even for a simple guided tour I wanted to deviate from the default behaviour in a dozen different ways (show notes on Next, different logic depending on whether the user completed the previous step, do not allow going to the next one if the current step isn't completed, grow beard at unexpected places, go to a different page before showing a pointer).

I am more and more inclined towards a JS-only API with some PHP helpers. I will play with that one, too and report here.

comment:33 follow-up: joostdevalk3 years ago

I agree with @nbachiyski, I did a first implementation for my WP SEO plugin using PHP ( http://plugins.trac.wordpress.org/browser/wordpress-seo/trunk/admin/class-pointers.php ) but I didn't really like how it worked. In some cases you'd actually want to do several consecutive pointers on one page which would be a heck of a lot easier with a JS API I guess, on the other hand, you'd also want to do these things across pages, for which you'd probably need a PHP helper... Just some thoughts :)

comment:34 volcanicpixels3 years ago

  • Cc chatfielddaniel@… added

comment:35 in reply to: ↑ 33 johnbillion3 years ago

Replying to joostdevalk:

several consecutive pointers on one page

*shudder*

comment:36 WraithKenny3 years ago

A suggestion based on Nacin's patch:

Instead of dismissed_wp_pointers wp should store the pointers left to queue: queued_wp_pointers. Core, Plugins, and Themes should register/enqueue once per pointer, say on activation, upgrade, on user input (as in "show me the walk-thru" btns), or via callback in case of series. user_meta will keep the pointer data until it's displayed and dismissed at which time it'll be deleted (via ajax like in Nacin's patch). (Alternatively, they can be deleted on shutdown during the run in which they were displayed. Function argument to chose?)

This has the benefit of having one array of data stored in user_meta and after all pointers have been shown to the user, that array would be empty. Also, it'd require only one get_user_meta for all code using pointers, called by one core function that also handles the scripts/css. Pointer data can be organized by screen name (or whatever current page is called) and/or plugin slug (for multiple pointer on same screen from different sources) and contain a callback reference (called when dismissed) so that series of pointers on subsequent pages can be handled in that way.

As for a series of consecutive pointers on a single page load, I like GuidedTour as a name :) Perhaps the class implementation can wrap a group of pointers to be stored in a single slot in queued_wp_pointers array and whatever output function can check for a flag.

Just some midnight ideas...

WraithKenny3 years ago

Pointers API

comment:37 alexrabe3 years ago

  • Cc alter.ego@… added

nacin3 years ago

comment:38 nacin3 years ago

In [18937]:

Use AJAX request and usermeta rather than user settings for dismissing admin bar pointers. see #18693.

comment:39 follow-up: TobiasBg3 years ago

Just spotted in [18937]: _wp_pointer_print_admin_bar is missing L10n/i18n.
Also, nonce handling seems to have been left commented out, but that might be on purpose.

comment:40 Ipstenu3 years ago

"New Admin Bar" pointer still won't go away on older versions of IE (7/8).

http://f.cl.ly/items/2d2N051e2C0p0I331h2l/IE7-pointers.jpg

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

comment:41 in reply to: ↑ 39 SergeyBiryukov3 years ago

Replying to TobiasBg:

Just spotted in [18937]: _wp_pointer_print_admin_bar is missing L10n/i18n.

That was a deliberate change in [18708]. Those strings can be changed in RC.

comment:42 koopersmith3 years ago

In [18969]:

Simplify pointer API with smarter positioning. see #18693.

comment:43 koopersmith3 years ago

In [18970]:

Fix incorrect closing tag in pointers JS. see #18693.

comment:44 koopersmith3 years ago

In [18971]:

Tweak pointer styles. see #18693.

ocean903 years ago

comment:45 ocean903 years ago

  • Keywords dev-feedback removed

18693.cursor.patch will add a pointer cursor to the close link.

comment:46 azaozz3 years ago

In [18987]:

Pointers: add default width (400px) that fixes positioning in IE7, add href attrib to the Close link, see #18693

comment:47 azaozz3 years ago

In [18989]:

Pointers: more airy drop shadow, see #18693

comment:48 SergeyBiryukov3 years ago

In IE, the pointers have no arrow (see the screenshots).

comment:49 scribu2 years ago

  • Cc scribu added

comment:50 scribu2 years ago

The 'show_wp_pointer_admin_bar' filter seems wrong to me. It should either match the pointer id, 'wp330-admin-bar', or be replaced with a general filter, and pass the pointer id as a parameter.

Also, plugins should be able to overwrite the user option, even if only for debugging purposes.

See show_wp_pointer.18693.diff.

comment:51 nacin2 years ago

In [19015]:

Strip out the show_wp_pointer_admin_bar for now. see #18693.

comment:52 ocean902 years ago

Related: #19021

comment:53 ocean902 years ago

  • Status changed from new to assigned

jane2 years ago

New pointer style 11/10

comment:54 jane2 years ago

Worked with @chexee on pointer styling. Attached image shows the new style (which uses the same color/gradient as the progress bars being updated by @azaozz). Icon is a placeholder, will ask Ben to make one that is like a little alert flag unless someone has a better metaphor. New contributor @GeorgeStephanis volunteered to turn this into CSS this weekend. Note: the width in the mockup is not real. Use the regular width already in code. The Dismiss x is the same graphic from bulk edit.

comment:55 georgestephanis2 years ago

Yup. Commenting so that I don't lose track of the thread. I'll have something preliminary together on Saturday, polished on Sunday/Monday.

comment:56 azaozz2 years ago

Looking at the behavior of the pointer divs, perhaps it would be better to remove position:fixed as an option for them. Absolute positioned divs would work better as they can be added below the fold on the screen and still point at the right places.

georgestephanis2 years ago

Preliminary styling changes for pointer boxes. Requires two images (forthcoming).

georgestephanis2 years ago

Flag in a circle -- flag is transparent to enable the background color to change as desired.

comment:57 georgestephanis2 years ago

First draft of the styling ... there will likely be some degradation with IE7 due to lack of support for :before pseudo-elements.

georgestephanis2 years ago

Minor styling and JS changes to match design.

comment:58 georgestephanis2 years ago

Just added a new rev on the CSS/JS changes for the styling.

One thing to take note of ... to get to the xit.gif file in the wp-admin/images/ folder from the wp-pointer css in the wp-includes directory, I had to do url('../../wp-admin/includes/xit.gif') -- which will break if a user moves their wp-admin folder for security purposes. It's a relatively minor break (xit.gif not showing up) -- but I've never been entirely comfortable with hard-coding directories that the user may elect to move.

Is it possible to host wp-pointer css/js in the wp-admin directory to avoid this issue, or is it in wp-includes as it might be used on the front-end of the site?

comment:59 follow-up: georgestephanis2 years ago

Also, based on usage, as it seems we're only ever using it with the 'up' pointer, I removed the wp-pointer-arrow div from the js-generated-html, we could probably use about half the CSS if we removed that modularity from it (the end bit of wp-pointer.dev.css -- as we don't have the generated images for it anyways).

-George

comment:60 scribu2 years ago

Unlike 'wp-content', we do not support moving the 'wp-admin' directory, so don't worry about it.

Last edited 2 years ago by scribu (previous) (diff)

comment:61 georgestephanis2 years ago

Oh, groovy. Thanks for the heads up! I'm just natively a tad bit paranoid when it comes to making -any- assumptions about what users will and won't do. Unlike Tron, I do not fight for the user. :)

comment:62 follow-up: scribu2 years ago

My question though would be why is wp-pointer in wp-includes anyway? Isn't it an admin-only feature?

comment:63 georgestephanis2 years ago

It could theoretically point to the admin bar on the front-end of the site?

comment:64 in reply to: ↑ 62 nacin2 years ago

Replying to scribu:

My question though would be why is wp-pointer in wp-includes anyway? Isn't it an admin-only feature?

It was architected to be something that can be available on the front-end.

I'd like to move or copy xit.gif to wp-includes. While we don't support moving wp-admin or wp-includes, it's not something we otherwise do. wp-admin could be locked down, for one.

comment:65 in reply to: ↑ 59 jane2 years ago

Replying to georgestephanis:

Also, based on usage, as it seems we're only ever using it with the 'up' pointer, I removed the wp-pointer-arrow div from the js-generated-html, we could probably use about half the CSS if we removed that modularity from it

Hi George. You don't need to sign your comments, your name is displayed with them. Bad assumption, we will have arrows in other directions depending on feature placement. Side arrows will likely be used often; the graphic was done illustrating a top arrow only because it seemed unnecessary to mock up pointers in all four directions.

comment:66 georgestephanis2 years ago

Alrighty, sounds good. I'll change it over. Thanks!

comment:67 georgestephanis2 years ago

Actually -- no, that's not feasible with what you've previously given me.

The arrow, currently on the top, would need to be regenerated based on its vertical positioning if on the sides, and changed to white if on the bottom. I'll need a mockup for each to slice it properly for either instance.

If it's on the sides, I'll also need to know what the vertical positioning is, as that will have to be fixed, so that the gradient works properly and isn't offset incorrectly.

comment:68 koopersmith2 years ago

  • Status changed from assigned to accepted

George has a point — the arrows in the mockup will not appear properly on the left, right, and bottom sides. There are several cases we should look out for:

  1. Arrows that do not overlap the title block (i.e. arrows on the bottom and mid-lower sides). These should likely be white, and are a fairly easy case to solve.
  1. Arrows that are on the upper sides. We'll need to make sure that the background of these arrows align with the vertical gradient, which will require some CSS trickery.
  1. Arrows on the sides that overlap the edge of the title and the content. These will be the hardest to implement.

After talking with George in #wordpress-ui, I think that we should focus on getting the mockup styles into core and worry about the edge cases at a later point. Case 1 (white arrows) could be an easy win, but I think we should probably punt cases 2 and 3 until 3.4.

georgestephanis2 years ago

For koop to explain something ...

comment:69 koopersmith2 years ago

In [19269]:

New pointer styles. Arrows are currently optimized to point upward. props georgestephanis, chexee. see #18693.

comment:70 koopersmith2 years ago

In [19271]:

Add pointer images for [19269]. props georgestephanis, chexee. see #18693.

comment:71 georgestephanis2 years ago

Oh fudgemonkeys -- the wrong one went up it seems. Koop -- I'm posting the correct arrow image sprite now. The one you've got only has one of the four directions.

georgestephanis2 years ago

Arrow sprite image

georgestephanis2 years ago

Gah, maybe this one will carry through.

comment:72 georgestephanis2 years ago

Okay, use arrow-pointer-blue.2.png -- the first one, when I tried to replace the previous image, silently failed and kept the previous image.

comment:73 follow-up: ocean902 years ago

IMO the headline is a bit too big.

comment:74 koopersmith2 years ago

In [19274]:

Update pointer arrow sprite. props georgestephanis. see #18693.

chexee2 years ago

aligns left and right pointers to the lower side

comment:75 in reply to: ↑ 73 chexee2 years ago

Replying to ocean90:

IMO the headline is a bit too big.

The extra padding ensures that if the text is one-line, there is enough room for the icon.

One line variant: http://chx.mx//dy/g5qbpsi8oc8oc.png

comment:76 follow-up: scribu2 years ago

Does each and every user in a WP install need to see the pointers?

IMO, it should be only admins who see it, since they're the only ones who can perform an update.

Also, in the case of the pointer to the admin bar specifically, regular users will notice it anyway when they try to use the admin bar.

Last edited 2 years ago by scribu (previous) (diff)

comment:77 in reply to: ↑ 76 jane2 years ago

Replying to scribu:

Does each and every user in a WP install need to see the pointers?

IMO, it should be only admins who see it, since they're the only ones who can perform an update.

Also, in the case of the pointer to the admin bar specifically, regular users will notice it anyway when they try to use the admin bar.

The point is to make new features less disorienting, which is why it should be shown to all users, not just admins.

comment:78 jane2 years ago

If someone other than Koop wants to drop in text and positioning, here are the pointers:

New Feature: Toolbar
We've combined the admin bar and the old Dashboard header into one persistent toolbar. Hover over the toolbar items to see what's new.
If Multisite, add: Network Admin is now located in the My Sites menu.
Placement: on Dashboard Home, under toolbar, mid-right side.

New Feature: Flyout Menus
Instead of clicking to open and close navigation sections, just hover over a menu item and the submenu will "fly out" to the side, allowing single-click access to any screen.
Placement: on Dashboard Home, to right of left-hand menu, just above mid-level so it doesn't feel crowded with admin bar pointer.

Updated Media Uploader
The single media icon now launches the uploader for all file types, and the new drag and drop interface makes uploading a breeze.
Placement: on Add New Post or Add New Page, pointing at the icon, can be placed below or to the right, whichever is easier/looks better.

New Feature: Saving Widgets
If you change your mind and revert to your previous theme within 30 days, we'll put the widgets back the way you had them.
Placement: on Themes after activating a new theme, pointing up at the 'go change your widgets' alert from below, aligned with left edge of widget alert text. Note: would be fine leaving this one off if it's too complicated to tie it to the alert instead of just opening the screen.

comment:79 follow-up: ocean902 years ago

18693.more-pointers.patch is my concept how we could handle more pointers.

  • Save pointers into an array pointer_id => hook_suffix
  • Get dismissed pointers => array_diff()
  • Print pointers
    • Before: Check if $hook_suffix is the right one
    • Callback function would be _wp_pointer_print_{pointer ID ( s/-/_/}

To avoid code duplication I added _wp_pointer_javascript() which accepts 4 args.

comment:80 ocean902 years ago

18693.more-pointers.2.patch

  • remove enqueue flag
  • flip the $pointer array:
    	$pointers = apply_filters( 'wp_pointers', array(
    		hook_suffix => pointer_id, // Too show pointer on a special screen
    		'all' => 'foo_bar' // Too show pointer on each screen
    	) );
    
  • _wp_pointer_javascript(): $position arg can be a string
    • Needs some attention. Should be at and my allowed too?

Thx duck_ and scribu.

comment:81 in reply to: ↑ 79 DrewAPicture2 years ago

Replying to ocean90:

18693.more-pointers.patch is my concept how we could handle more pointers.

  • Save pointers into an array pointer_id => hook_suffix
  • Get dismissed pointers => array_diff()
  • Print pointers
    • Before: Check if $hook_suffix is the right one
    • Callback function would be _wp_pointer_print_{pointer ID ( s/-/_/}

To avoid code duplication I added _wp_pointer_javascript() which accepts 4 args.

Nice work ocean90!

comment:82 ocean902 years ago

Nice work ocean90!

Thanks.

18693.more-pointers.3.patch will fix some notices, more or less my final patch.


Btw: We shouldn't forget RTL. :(

ocean902 years ago

Don't allow to set pointers onto all screens.

comment:83 koopersmith2 years ago

I've posted an updated patch based on our discussions in IRC. Changes from the last iteration:

  • Removed the wp_pointers filter. We can use remove_action to hide all/individual pointers. Until we have a more robust API (3.4), using wp-pointer.js should be a manual affair.
  • Use json_encode for arguments passed to the pointers JS. Merges $content and $position, removes position parameter parsing.

koopersmith2 years ago

A handy plugin for resetting pointers.

nacin2 years ago

comment:84 nacin2 years ago

18693.3.diff (untested) adds dismissed_wp_pointers as a global site option, as well as initial_db_version.

In this case, we're only using dismissed_wp_pointers, but we could also just as well use initial_db_version. I have patched both as we will very likely want the flexibility of both pieces of information in future iterations of our new user experience.

We would have to manually add to dismissed_wp_pointers in future upgrade_xyz() handlers. It handles adding to wp_options of the main site even when running multisite, I suppose in case you revert back to single-site.

I'm not a big fan. While dismissed_wp_pointers would be flexible, it's also something we could add later without penalty. We can probably run with initial_db_version only and be better off, and save a few sanity points.

Last edited 2 years ago by nacin (previous) (diff)

comment:85 koopersmith2 years ago

I'm for running with initial_db_version.

My latest patch encapsulates the 3.3 pointers into a final WP_Internal_Pointers class, to make it clear that the current implementation is not a public API.

comment:86 koopersmith2 years ago

Some cleanups. Since we removed the flyout pointer, we now only show one pointer per screen.

nacin2 years ago

comment:87 koopersmith2 years ago

In [19388]:

Add new 3.3 pointer content, encapsulate 3.3 internal pointers in a final class. props ocean90, see #18693.

comment:88 nacin2 years ago

In [19389]:

Remove old dismissed pointers as the IDs have changed. Switch to underscores that way we don't need to translate them for method names. Avoid an empty pointer in the array. see #18693.

comment:89 nacin2 years ago

[19389] also triggers the media pointer on a post editing screen. It's whatever comes first, as once it is dismissed, it's gone everywhere.

Props to the peanut gallery in IRC for the development over the last hour and a half here.

https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2011-11-21&sort=asc

nacin2 years ago

comment:90 nacin2 years ago

18693.5.diff introduces initial_db_version and leverages it here. We'll need to update the final DB version in the pointers code before release.

comment:91 follow-up: scribu2 years ago

In Firefox, the media upload pointer doesn't point to the icon, but above it.

http://i.imgur.com/r3D5t.png

comment:92 in reply to: ↑ 91 ; follow-up: DrewAPicture2 years ago

Replying to scribu:

In Firefox, the media upload pointer doesn't point to the icon, but above it.

I can confirm this, though on mine (FF 8.0.1) it's not quite as exaggerated a difference. Not quite right regardless.

http://i.imgur.com/USiCV.png

comment:93 markjaquith2 years ago

In [19410]:

Introduce initial_db_version and leverage it so that pointers only get shown to updated installs, not new 3.3 installs. props nacin. see #18693

comment:94 markjaquith2 years ago

In [19411]:

Fix "wp_db_current_db_version" typo. see #18693

comment:95 JohnONolan2 years ago

  • Cc john@… removed

comment:96 koopersmith2 years ago

In [19416]:

Center left/right pointer arrows, so arrows appear correctly cross-browser. see #18693.

comment:97 koopersmith2 years ago

  • Keywords has-patch removed
  • Resolution set to fixed
  • Status changed from accepted to closed

Please open any pointer bugs in a new ticket. We still need to fix RTL — see #19335.

comment:98 in reply to: ↑ 92 ; follow-up: kurtpayne2 years ago

DrewAPicture, scribu:

In Firefox, the media upload pointer doesn't point to the icon, but above it.

I can confirm this, though on mine (FF 8.0.1) it's not quite as exaggerated a difference. Not quite right regardless.

I couldn't replicate these results. I am testing on Win7-64 and have tested under the following browsers:

  • IE 7
  • IE 8
  • IE 9
  • FF 3.6
  • FF 8
  • Safari 5
  • Opera 11
  • Chrome 15

In each one, the pointer was, more or less, at the mid-line of the icon.
http://i.imgur.com/0Xsvx.png

I tested with all plugins disabled, with the nav bar collapsed and uncollapsed, and with SCRIPT_DEBUG enabled and disabled. I could not reproduce the same results.

comment:99 in reply to: ↑ 98 ; follow-up: scribu2 years ago

Replying to kurtpayne:

Did you test before or after [19416]?

Last edited 2 years ago by scribu (previous) (diff)

comment:100 in reply to: ↑ 99 ; follow-up: kurtpayne2 years ago

Replying to scribu:

Replying to kurtpayne:

Did you test before or after [19416]?

After.

comment:101 in reply to: ↑ 100 koopersmith2 years ago

Replying to kurtpayne:

Replying to scribu:

Replying to kurtpayne:

Did you test before or after [19416]?

After.

Fantastic. That means the fix worked.

comment:102 johnbillion2 years ago

The text in the new admin toolbar pointer says:

"Hover over the toolbar items to see what’s new."

Is "hover" a well known term outside of web development? The term is also used in several other places, eg. the About screen.

comment:103 follow-up: johnbillion2 years ago

The "Dismiss" link in the feature pointers doesn't call preventDefault() on the click event, causing the page to jump back to the top and a hash to appear in the document location.

comment:104 in reply to: ↑ 103 ; follow-up: nacin2 years ago

Replying to johnbillion:

The "Dismiss" link in the feature pointers doesn't call preventDefault() on the click event, causing the page to jump back to the top and a hash to appear in the document location.

New ticket? Bug reports get lost on closed task tickets.

comment:105 in reply to: ↑ 104 johnbillion2 years ago

Replying to nacin:

New ticket? Bug reports get lost on closed task tickets.

Yep, sorry. #19361

comment:106 nacin2 years ago

In [19469]:

Move multisite-specific upgrade code from upgrade_330() to upgrade_network(). see #18693.

comment:107 stephenh19882 years ago

  • Cc stephen@… added
Note: See TracTickets for help on using tickets.