#18693 closed task (blessed) (fixed)
New feature pointers
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (135)
#5
follow-up:
↓ 21
@
13 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?
#8
@
13 years ago
- The filter name for pointers should definitely be changed to
show_wp_pointer
with the pointer name as a parameter (instead ofshow_wp_pointer_admin_bar
as in the current patch). - Can we use 'p-{pointer}' (ie. 'p-admin_bar') as the user setting name instead of 'p0'? This'll make them more extensible.
- Are there plans to introduce some nice API methods so plugins/themes can add pointers?
#10
@
13 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.
#11
@
13 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).
#12
@
13 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
#13
@
13 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;}
#14
@
13 years ago
The admin bar pointer looks great and caught my attention as it should. Nice work.
#17
@
13 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?
#18
@
13 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.
#19
@
13 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
#20
@
13 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.
#21
in reply to:
↑ 5
@
13 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.
#23
@
13 years ago
@nacin, thanks! I'll make sure the post is up to date with this ticket, thanks for the heads up!
#24
@
13 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.
#26
@
13 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.
#28
@
13 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.
#29
@
13 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.
#32
@
13 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.
#33
follow-up:
↓ 35
@
13 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 :)
#36
@
13 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...
#39
follow-up:
↓ 41
@
13 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.
#45
@
13 years ago
- Keywords dev-feedback removed
18693.cursor.patch will add a pointer cursor to the close link.
#50
@
13 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.
#54
@
13 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.
#55
@
13 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.
#56
@
13 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.
@
13 years ago
Flag in a circle -- flag is transparent to enable the background color to change as desired.
#57
@
13 years ago
First draft of the styling ... there will likely be some degradation with IE7 due to lack of support for :before pseudo-elements.
#58
@
13 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?
#59
follow-up:
↓ 65
@
13 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
#60
@
13 years ago
Unlike 'wp-content', we do not support moving the 'wp-admin' directory, so don't worry about it.
#61
@
13 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. :)
#62
follow-up:
↓ 64
@
13 years ago
My question though would be why is wp-pointer in wp-includes anyway? Isn't it an admin-only feature?
#64
in reply to:
↑ 62
@
13 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.
#65
in reply to:
↑ 59
@
13 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.
#67
@
13 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.
#68
@
13 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:
- 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.
- 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.
- 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.
#71
@
13 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.
#72
@
13 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.
#75
in reply to:
↑ 73
@
13 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
#76
follow-up:
↓ 77
@
13 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.
#77
in reply to:
↑ 76
@
13 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.
#78
@
13 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.
#79
follow-up:
↓ 81
@
13 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.
#80
@
13 years ago
- 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
andmy
allowed too?
- Needs some attention. Should be
Thx duck_ and scribu.
#81
in reply to:
↑ 79
@
13 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!
#82
@
13 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. :(
#83
@
13 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.
#84
@
13 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.
#85
@
13 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.
#86
@
13 years ago
Some cleanups. Since we removed the flyout pointer, we now only show one pointer per screen.
#89
@
13 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
#90
@
13 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.
#92
in reply to:
↑ 91
;
follow-up:
↓ 98
@
13 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.
#97
@
13 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.
#98
in reply to:
↑ 92
;
follow-up:
↓ 99
@
13 years ago
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.
#102
@
13 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.
#103
follow-up:
↓ 104
@
13 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.
#104
in reply to:
↑ 103
;
follow-up:
↓ 105
@
13 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.
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.