Make WordPress Design

Tagged: widgets Toggle Comment Threads | Keyboard Shortcuts

  • designsimply 2:08 pm on February 20, 2014 Permalink
    Tags: , widgets   

    I’ve tested the Widget Customizer 0.14 plugin with the Twenty Fourteen theme on WordPress r27060.


    • No trouble adding, rearranging, or removing widgets
    • Widgets can be tough to spot if they are added “below the fold”
    • Widgets that require extra prep are easily dismissed

    (More …)

  • designsimply 2:25 pm on January 31, 2014 Permalink
    Tags: , widgets   

    User Testing the Widget Customizer 0.13 Plugin

    I’ve tested the Widget Customizer 0.13 plugin with the Twenty Fourteen theme on WordPress r26863.


    • No problems adding, reordering, or removing widgets
    • Content and Primary labels for widget locations weren’t clear to the user
    • Trouble with scrolling the slide-out, but it could have been a one-time user error</
    • Widgets can get a little lost if you add one to an already long list
    • ”Find widgets” search seems to obscure the last widget description
    • Feels messy to see all the widget controls stay open
    • Its not clear, at first, how to exit the customizer


    No trouble adding a text widget. She clicks “Save & Pubilsh” a lot—seems to assume it’s needed to see the changes. (0:23)

    No trouble reordering widgets, but again hesitates when looking for right vs left sidebar. (0:56)

    No trouble removing widgets. (1:01)

    Points of Confusion

    She has no idea what sidebar is which. The quick red glow seems to have helped a bit. (0:31)

    Scrollbar jumps back to the top, not sure what she did to trigger that. (0:12)

    She expected the new widgets to be added to the top. (0:18)

    Has some trouble reading the “Twenty Fourteen Ephemera” widget description at the bottom of the slide-out panel. (0:17)

    Other Insights

    It doesn’t seem to bother her that all the widget controls stay open — but boy does it feel messy. (0:19)

    Its not clear, at first, how to exit the customizer. But she gets it eventually. (0:33)

    If you’d like to see the full video, you can download it here: 2b86a9a1.mp4 (9:25)

    (For Reference) Tasks Used in the Test

    • Go to Appearance > Customize Add some text in a new widget at the top of the left sidebar.
    • Look through the widgets and pick two that you like. Add both of them to the sidebar and say why you picked them.
    • Rearrange the widgets so the bio appears at the bottom of the right sidebar.
    • Remove all of the widgets from the left sidebar except the text you added before and one other widget you think is the most important to keep.
    • Verify that the updates you’ve made are visible on the site separate from the live preview in the dashboard.

    User’s Computer Info

    • Operating System: Windows 7 6.1
    • Browser: Windows Firefox 26.0
    • Display: 1920

    Next up: a couple more tests with version 0.14 of this plugin.

    • shaunandrews 2:33 pm on January 31, 2014 Permalink | Log in to Reply

      Awesome. Thanks for doing these tests — they’re super insightful and helpful.

      She has no idea what sidebar is which. The quick red glow seems to have helped a bit. (0:31)

      That red glow has always been a sort of “placeholder” — we’ll work on making it more obvious, and slightly better looking.

    • Weston Ruter 9:58 pm on January 31, 2014 Permalink | Log in to Reply

      She expected the new widgets to be added to the top.

      Actually, widgets used to be added at the top. There was a dropdown SELECT to choose a widget, and then it got prepended to the list of widgets. @shaunandrews Should the “Add a widget” link move to the top?

      • Sheri Bigelow (designsimply) 2:00 pm on February 20, 2014 Permalink | Log in to Reply

        I could see it appearing at the top and bottom if there were a ton of widgets in use… but if I had to pick between one or the other, I’d probably leave the “Add a Widget” link at the bottom because that’s where new widgets get placed automatically in the live preview so it makes sense that the button would also be at the bottom of the widget list.

    • Weston Ruter 10:00 pm on January 31, 2014 Permalink | Log in to Reply

      Content and Primary labels for widget locations weren’t clear to the user

      Would this actually be an issue with the theme itself? These labels are defined by the Theme.

    • Weston Ruter 10:03 pm on January 31, 2014 Permalink | Log in to Reply

      It doesn’t seem to bother her that all the widget controls stay open — but boy does it feel messy. (0:19)

      We talked about automatically collapsing a widget control when another is opened, but I thought that maybe they’d want to have more than one open to make it easier to copy/paste between widgets, or to compare two widget controls. Also, the widgets admin page allows multiple widgets to be expanded at a time.

    • Weston Ruter 10:07 pm on January 31, 2014 Permalink | Log in to Reply

      “Find widgets” search seems to obscure the last widget description

      This seems to be a browser rendering bug, but I can’t reproduce on Firefox 26 on OS X nor on Chrome on OS X. @shaunandrews can you reproduce this bug?

    • Weston Ruter 10:09 pm on January 31, 2014 Permalink | Log in to Reply

      Widgets can get a little lost if you add one to an already long list

      What if we added the new widget icons to prepend the widget titles? We have them in the widget addition panel, but we’re not using them in the widget controls. The icons would help locate and differentiate between widgets in a long list. Specifically, I’m talking about adding the icon at .widget-title > h4:before. @shaunandrews?

  • designsimply 4:32 pm on November 20, 2013 Permalink
    Tags: , widgets   

    User Testing the Better Widgets 0.1 Plugin 

    Let’s keep going with the work on widgets! I’ve tested the Better Widgets 0.1 plugin with the Twenty Eleven theme on WordPress 3.7.1 and there is some interesting stuff in the results.


    • No problem at all rearranging or deleting widgets
    • Had trouble with the drag-and-drop target area at first
    • Suggests adding a way to add new widgets directly from the Widgets page
    • Uses the wrong widget area, completely misses the pre-expanded “Main Sidebar”
    • Customizer is slow


    No problem rearranging widgets:

    No problem deleting widgets:

    Points of Confusion

    Unsure where to go when asked to add a bio to the sidebar:

    Drag-and-drop misfires:

    Completely misses the pre-expanded “main sidebar” widgets (longest clip at 4:11):

    Other Insights

    Wants to know how to add more widgets from the Widgets screen:

    Reasons for picking search and calendar widgets:

    Unrelated to Widgets

    Slow customizer is slow, takes ~24s for this user to load it up:

    If you’d like to see the full video, you can download it here: Better Widgets v0.1

    (For Reference) Tasks Used in the Test

    • Add a bio to the bottom of the sidebar.
    • Look through the widgets and pick two that you like. Add both of them to the sidebar and say why you picked them.
    • Rearrange the widgets so the bio appears at the top of the sidebar.
    • Remove all of the widgets except the bio and one other widget you think is the most important to keep.
    • The test website is using the Twenty Eleven theme. It has a widget area called “Showcase Sidebar.” What do you think that’s for, and how would you go about figuring out how to set it up?

    User’s Computer Info

    • Operating System: Windows NT (unknown) 6.2
    • Browser: Windows Chrome 30.0.1599.101
    • Display: 1366

    My Observations & Suggestions

    • The drag-and-drop misses in this video are interesting, makes me wonder if having widget areas side-by-side is good or not—or perhaps arranging them more masonry style instead of in a grid would be better
    • Interesting that she didn’t connect “sidebar” and “widgets” right away, but getting into that label is tricky business and I’d like to watch that area with more users in order to spot trends
    • Love the suggestion to have an “Add New” button on the widgets page
    • Different sidebar areas for themes is tough, I think it’s pretty hard to tell what in the world the “Showcase Sidebar” is for if you’re not familiar with Twenty Eleven
    • It’d be great to focus on customizer performance speed

    Next up: same test, except run it on WP 3.8 trunk. What specifics are you interested in finding out from tests like these?

    • Weston Ruter 5:55 pm on November 20, 2013 Permalink | Log in to Reply

      Perhaps the slow loading for the customizer was just a network problem? It seems like an external script was blocking the page loading. In my experience the customizer loads very fast.

      • designsimply 7:27 pm on November 20, 2013 Permalink | Log in to Reply

        Could be. I’ve seen the problem show up more than once in tests, so I’ll keep watching to see if it continues to be a trend.

    • danhomer4 2:15 am on December 17, 2013 Permalink | Log in to Reply

      Windows NT 6.2 is Windows 8, for those confused

  • designsimply 8:04 pm on October 24, 2013 Permalink
    Tags: , widgets   

    User Testing Widgets+MP6 v1 Layout 

    I’ve analyzed user testing for two videos shaunandrews kicked off for v1 of Widgets + MP6. The clips represent the main points of interest and user confusion from the tests and range from 12 to 49 seconds, so they should be quick and easy to watch.

    Expects clicking “Save” will close the widget:

    Troubles with drag and drop:

    • Windows 7 6.1
    • Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
    • 1920 x 1080

    Hover tip proves useful when figuring out the Meta widget:

    No trouble with drag and drop to add a widget:

    Expects widget to close after saving:

    • Windows Vista 6.0
    • Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
    • 1280 x 800

    If you’d like to see the full videos, you can download them here: Widgets+MP6 001, Widgets+MP6 002.

    Key Observations

    • One user spotted the hover tips and the other didn’t
    • Both users said they expected the widget to close after saving
    • May need to increase sensitivity of the widget drop area, check Chrome 30 on Win7 for issues

    Just because a couple users mention they’d like to see a widget area close after saving doesn’t necessarily mean you should do that. Additional testing in situations where someone is working for a longer time with one particular widget and may want to save periodically would be good. Adding some other visual indicator to show when saving is finished might be sufficient, as opposed to closing the widget on save.

    • Ulrich 8:24 pm on October 24, 2013 Permalink | Log in to Reply

      I think the problem with the saving of the widgets is that there is no confirmation anywhere that the widget is saved.

    • Archetyped 8:28 pm on October 24, 2013 Permalink | Log in to Reply

      Save on close

      Another way to pose this is: why shouldn’t the widget button close on save?

      Or perhaps the better question is: Are the actionable options provided to the user the right ones?

      If you break it down, the actions available to users are basically:

      • Edit widget settings
      • Close widget without making any further changes
      • Delete widget

      Therefore, perhaps more appropriate user actions would be:

      • Done — Save widget and close
      • Cancel — Close widget without saving changes
      • Delete — Completely remove widget

      In the current UI, you could make the argument that the widget should not close on save because the user may just want to save their progress as they continue to work on the widget’s settings.

      But why should the user have to do this? This is a burden that the machine should be offloading from the user.

      Post progress is saved automatically as you edit a post, why shouldn’t widgets have the same intelligence?

      With the machine saving your progress, the UI no longer needs a “save” button. You can focus on your work until you’re done. Then you just have to decide what your final action will be– save or cancel your changes (or remove widget entirely).

      • Jon Brown 12:02 am on October 25, 2013 Permalink | Log in to Reply

        WordPress saving changes is confusing enough as it is (metadata/featured image on posts. I wouldn’t want incremental changes to widgets saving prior to clicking save. Especially if the widget settings are versioned and undo-able.

        The buttons should read “close” and then upon making changes the button should change “save” then after saving change back to “close”. While there were changes to save a link for cancel changes and close would replace the current link for close next to delete.

        Personally I don’t want the widget closing on save, I just want a stronger confirmation that my changes were actually saved. I often want two widgets open at the same time so I can copy settings between the two.

      • designsimply 12:30 am on October 25, 2013 Permalink | Log in to Reply

        Take user suggestions like this one with a grain of salt. Sometimes people say one thing and then turn around and do another. So you have to look at a group of tests and find trends, and even then I think there’s a little magic that goes into interpreting the tests. 🙂

        Post progress is saved automatically as you edit a post, why shouldn’t widgets have the same intelligence?

        I imagine it’s because you don’t always want your widget changes live until they are finished—if you auto-saved, your widgets would be all skewampus on the front end during editing.

        I’m not advocating for one solution over another btw. I think it’d be cool to test the different scenarios more.

      • designsimply 12:32 am on October 25, 2013 Permalink | Log in to Reply

        Thanks for the feedback btw!

      • shaunandrews 2:34 am on October 25, 2013 Permalink | Log in to Reply

        Post progress is saved automatically as you edit a post, why shouldn’t widgets have the same intelligence?

        The key difference here is that the auto-save functionality that you see in the post editor is saving a revision. Widgets don’t have the concept of revisions. So, if widgets auto-saved, they’d be pushing out new versions of your widget to your live site. Not ideal.

        Now, one day we may have the ability to save revisions of widgets — then auto-save makes a lot of sense. However, you’d still want a “Save” button, or perhaps a “Publish” button, to push your changes to your site.

      • Archetyped 7:03 am on October 25, 2013 Permalink | Log in to Reply

        Yes, I understand the data infrastructure that allows posts to autosave progress as revisions, etc. My point is that users should not need to care about any of that.

        Obviously nothing should be live until the user commits those changes. Apologies if it seemed the opposite was implied. I’m also not saying autosave should be implemented without the necessary infrastructure changes, but that infrastructure should conform to user needs, not other way around.

        Take user suggestions like this one with a grain of salt.

        Indeed. My comments are not based on a single user’s comments but rather based on the usability issues observed working with clients over the years.

        • designsimply 2:13 pm on October 25, 2013 Permalink | Log in to Reply

          Apologies if it seemed the opposite was implied.

          No worries, I think it’s just a current technical limitation that widgets are confined to for this iteration. Frustrating 🙂 so I think people like the ideas but are just explaining limitations.

          My comments are not based on a single user’s comments but rather based on the usability issues observed working with clients over the years.

          Awesome! i’m glad to read about your insights and that you’re participating.

    • shaunandrews 2:35 am on October 25, 2013 Permalink | Log in to Reply

      A huge thanks to @designsimply for going through these user tests and pulling out the highlights. Thanks, Sheri!

    • designsimply 9:06 pm on November 5, 2013 Permalink | Log in to Reply

      We reviewed all of the feedback from the comments on this post in our weekly THX chat today. RTL, back button, and escape to exit are going to be worked on. It’s too late in the project to change to an inline overlay layout for the details page, but anyone interested is encouraged to make a plugin showing how it could work if they would like to experiment with something like that. Feedback in yesterday’s core dev chat said that bulk edit wasn’t needed, and it’s not quite ready anyway so we took it out.The team talked about adding a trash icon to the main screen but decided against it because the delete in the modal is probably enough and users were able to find it pretty quickly in user testing.

      Thanks for all the feedback!

  • shaunandrews 2:07 pm on October 22, 2013 Permalink
    Tags: widgets   

    Widgets Update 


    The widgets team has been working hard! We’ve spent some time working with (and joining) the MP6 team to get a redesigned widgets screen into the latest version of MP6. If you haven’t seen it yet, download (or update) MP6, and you’ll get this beauty:

    We’ve also created a new plugin named Widget Area Chooser, which lets you click to add a widget to any of your sidebars:

    We’ve also made some great progress on the Widget Customizer plugin, which lets you manage your widgets from within the customizer:

    How can you help?
    This week, we’ll be focusing on getting the Widget Customizer plugin updated to let you add new widgets. If you want to join in, you can head over to GitHub and submit some patches, do some testing and add an issue, or just drop your ideas/thoughts. Or, you can just post a comment below and we’ll add you to our group Skype chat.

    Also, we’d love some code review on the Widget Area Chooser plugin.

    We’ll be meeting next week in #wordpress-ui at our normal time, October 28 @ 20:00 UTC.

    • Michael Arestad 2:08 pm on October 22, 2013 Permalink | Log in to Reply

      Group Skype chat. michael.arestad

    • jeffr0 8:16 pm on October 22, 2013 Permalink | Log in to Reply

      I’ve been using the new widget screens via MP6 and they are an improvement over what existed there. Out of curiosity knowing that you’ve been working on this area of the back-end for awhile, can you fill me in on why the performance of this particular page is so bad? That is, there appears to be a delay in doing anything on the widget management page. Click on a sidebar arrow and there’s a delay, click it again, another delay, click a widget to drag it to another sidebar and the delay/responsiveness is terrible.

      What is it that causes such a delay between me clicking on something and the reaction?

    • Andy Mercer 1:10 am on October 23, 2013 Permalink | Log in to Reply

      Looking great! I think I may have found a slight bug in the sizing. I’m running Firefox 24 on Windows 7 (classic theme; I think that makes a difference for the position bars). When playing around with sizing, I found that in what looks like the smallest mobile version, a slider bar is a bit too far to the right. It goes off the screen. Link to screenshot with the area in question circled: http://i210.photobucket.com/albums/bb80/Kelderic/Screen02_zpsdb08cf0b.png

  • shaunandrews 5:14 pm on September 24, 2013 Permalink
    Tags: widgets   

    Widgets Sept 23 Chat Notes 

    We had our weekly chat yesterday. If you weren’t there, you can always check out those cool log things.

    A few highlights:

    • We adopted the Widget Customizer plugin as our customizer prototype
    • I tossed out the idea of a “mission control” view for the tabbed prototype, which would let you see all your sidebars at once. The goal with this is to make it easier to move (and maybe copy) widgets between sidebars. Check out the video of this concept in action.
    • We pondered the question “Can the tabbed prototype and the customizer prototype coexist?” Turns out every one seems to agree that both interfaces can coexist. The tabbed prototype lends itself to more advanced functionality with lots of widgets, while the customizer plugin makes it super simple to edit (and perhaps add) widgets to the areas that are currently visible in the preview.
    • I brought up the idea of a way to preview widgets from the tabbed prototype. Turns out this is difficult (and maybe impossible) to accomplish since we won’t know what page the sidebar lives on, or if it even exists. I’d love to find a way to make this possible.
    • Weston got his temporary hooks included in 25580 — yay! This opens up a lot of possibilities for the customizer plugin.
    • We discussed a few ideas for how to add widgets from the customizer. I whipped up a quick sketch showing an extension to the customizer bar.
    • We discussed cleaning up the list of available widgets. The tabbed prototype has renamed a few widgets, and removed the descriptions.
    • Weston brought up the idea of preview thumbnails for widgets. The thumbnails would show a preview of how that widget would look in the current theme. This would require that all widgets have some “dummy” content. Perhaps we could extend this to existing widgets, as well. Having a preview of each widget in the tabbed prototype may help solidify the connection to their location on the front-end. Super cool idea.
    • We discussed the menu-like prototype briefly. I’ve chatted with jtsternburg about his progress. He and his his wife recently welcomed their third child (and future blogger) into the world — congrats! As his time is limited, he’s unable to continue work on the menu-like prototype. He’ll be sharing his code soon, so we can pick it up and get it to a testable stage.

    Our next steps:

    • Continued work on the customizer plugin, and lots more user testing.
    • Connect with the front-end team to see how we can collaborate with widget editing.
    • Pickup the menu-like prototype and get it to a testable stage.
    • Follow @lessbloat‘s lead and create a planning spreadsheet to help define tasks and roles.

    I’ll be out of town next week. While I encourage everyone to meet in IRC, our next official meeting will be in two weeks on October 7th, 2013 @ 20:00 UTC.

    • Weston Ruter 5:49 pm on September 24, 2013 Permalink | Log in to Reply

      Regarding widget thumbnail previews, the way I was thinking it could be done is when switching a theme or when a new widget is registered, WordPress could initiate a request to an ad hoc page containing just the widget, and take a screenshot (with some canvas tool) and then save the screenshot to the database. This request would have to be done in the background in some hidden iframe. It would be very cool, but it also seems like a horrible hack.

      Something more feasible would be if we introduced icons to WP_Widget. When instantiating a WP_Widget:

      function __construct() {
      		'my_text_widget', // Base ID
      		__('My Text Widget', 'text_domain'), // Name
      			'description' => __( 'So much better than text!', 'text_domain' ), 
      			'icon_url' => includes_url( 'images/widget-icons/text.png' ),

      This icon_url concept is used in add_menu_page(). The widget icons could then be displayed on the widgets page and anywhere else that widgets are managed, to allow them to be easily recognized quickly. The core patch to add support for icon_url would require adding a generic widget icon, and icons for all widgets bundled with WordPress.

      In addition to icon_url there could also be a screenshot_url argument. This would be analogous to themes which allow you to include a screenshot.png. Sure the widget screenshot would not be reflective of how it would exactly appear in the current theme, but it would give a good visual overview of what you’re going to get when you add the widget. To see how the widget will look exactly in your theme, the user can just go ahead and add it in the customizer and then can preview how it will look, and decide then whether they want it.


    • ntl0820 6:13 pm on September 24, 2013 Permalink | Log in to Reply

      Great prototypes Shaun! I love the tabbed interface, much easier I think and makes good use of the space.

      I think the idea of a preview is a great idea. Maybe you could have it automatically use the default template for a page, but then have a dropdown to select a specific page to see what it would look like on that specific page?

      I’d love to see a way to have existing widgets available in a list to be used on multiple sidebars.

    • Weston Ruter 9:00 am on September 26, 2013 Permalink | Log in to Reply

      Regarding the use of the customizer to manage widgets that appear only on select pages (as the ), I think the customizer is not currently displayed prominently enough in WordPress. When you’re looking at a post on the frontend, there should be a Customize link right next to the Edit link in the Admin Bar. Furthermore, when editing a post in the backend, the Preview button should open the post inside of the Customizer, not in a standalone page; the Back (Close/Cancel) button in the Customizer then can just close the window and bring focus back to the window opener. This makes it much snappier to go back to the post edit screen. Also, right now the document title of the customizer does not change based on what is currently being previewed: it always remains just “Customize Twenty Twelve — WordPress”. This is not helpful, and it should dynamically update to include the currently-loaded document title in the preview.

      I’ve put together a plugin which addresses the above wishlist items: https://github.com/x-team/wp-customizer-everywhere

    • Weston Ruter 6:15 am on September 30, 2013 Permalink | Log in to Reply

      Just released Widget Customizer 0.6: drag-and-drop widgets within customizer panel to preview changes to their ordering! https://wordpress.org/plugins/widget-customizer/

    • Paal Joachim Romdahl 9:54 am on October 5, 2013 Permalink | Log in to Reply

      Woo Themes have made a very nice plugin: https://wordpress.org/plugins/woosidebars/

    • Michael Arestad 3:44 am on October 22, 2013 Permalink | Log in to Reply

      Initial thoughts after our earlier discussion: Reorder widgets without dragging

    • jameskoster 9:19 am on October 22, 2013 Permalink | Log in to Reply

      I have an idea regarding widgets I’d like to share, not sure if this is the right place (maybe trac would be better) but here goes.

      A problem I run in to quite often is adding widgets to a region via Appearance > Widgets. Well, not adding them, rather finding them. When you have a couple of big plugins activated, or a theme which adds it’s own widgets (ick) the Available Widgets box gets very crowded. I normally end up using ⌘F to find the one I’m looking for.

      So maybe add a ‘quick add’ text field to each region. Something like http://cl.ly/image/20212D1M332J . Typing in this input would load a live search with results dropped down beneath the input. Click the appropriate result and it’s inserted. If no results are found you could even include a link to search the plugins repo on .org.

      Or maybe this is an edge-case and would be better as a plugin? thought I’d share the idea anyway..!

  • shaunandrews 2:00 pm on September 18, 2013 Permalink
    Tags: widgets   

    Widgets, Sept 16 Chat Notes 

    We had our weekly widgets chat in #wordpress-ui on Monday, check the logs for the full transcript.

    • More work on the tabbed prototype, with some more user testing.
    • RichardTape is feeling better, and ready to get to work on his prototype.
    • jtsternberg has the foundation for the menu-like prototype ready, and plans to make more progress this week.
    • Discussed the Widget Customizer plugin, and pinged the developers to join us. (Hi Weston and John!)

    Short and sweet. Lets keep the conversation going on the comments here, in skype, and in IRC. See you next week. Same bat time; Same bat channel.

    • shaunandrews 7:06 pm on September 18, 2013 Permalink | Log in to Reply

      I ran a user test using the Widget Customizer plugin. Since the plugin doesn’t support adding widgets (yet) the test is focused on updating a few widgets, and seeing how comfortable the person is navigation around the site from within the customizer:

      Things went very well. The biggest take away is that, even with the customizer, there’s still a disconnect between the “sidebars” presented in the customizer and the widget-ized areas in the page. We’ve discussed this a bit on Skype, and there are plans to highlight the widget area thats being edited.

      • Weston Ruter 7:32 pm on September 18, 2013 Permalink | Log in to Reply

        Wow. This is really valuable. Thanks for doing this @shaunandrews! Lots to glean from this.

        Notice he clicked on the text he wanted to update, but it did nothing. Then he had to hunt through the customizer sections and controls to finally find the right control that edited that area. When clicking on a widget, the corresponding section and control should automatically show. We have actually already captured this feature in issue #5.

        But there is also a key improvement needed for the Theme Customizer in general. There should be an onunload event handler which throws you a confirmation when you try to navigate away from the page when you have unsaved changes. That, along with a more prominent “changes pending” indicator would be great, like the “Save & Publish” could have an animated glowing effect.

        This was his first time ever using the customizer, so his impressions were especially important. It would be interesting to also see a user’s reaction if they had used the customizer a lot in the past.

      • Weston Ruter 8:53 am on September 23, 2013 Permalink | Log in to Reply

        I’ve just released a new version of the Widget Customizer plugin (0.5) which addresses the primary issue uncovered by the user test: difficulty to discover which sections and controls in the customizer panel correspond to widgets in the preview window. So now in the new version, hovering over widgets in preview highlights corresponding customizer sections and controls in panel. Clicking a widget in preview opens the widget form in the panel and focuses on first input. Interacting with widget form highlights widget in preview. See screenshots on issue #5.

        The specific highlight style used (the red box-shadow) is really just a proof of concept. Any suggestions for improving the visual indicators would be much appreciated. Pull requests welcome.

    • John Regan 7:32 pm on September 18, 2013 Permalink | Log in to Reply

      That was great to see. I think that highlighting the widget area being edited is a great idea!

  • shaunandrews 4:59 pm on September 9, 2013 Permalink
    Tags: widgets   

    Widgets Chat Today 

    Hi everyone — I’ll be in the middle of some in-person user testing today, and won’t be available for our chat this afternoon. Please feel free to meet without me, and I can catch up via the logs. I’ll be testing the tabbed prototype today, along with the existing widgets UI. If you can’t (or don’t want to) make it to IRC this afternoon, please leave any notes you have as a comment below. I’d love to hear how things are coming along with the other prototypes. Thanks!

    • shaunandrews 2:01 pm on September 11, 2013 Permalink | Log in to Reply

      Here’s the results of Monday’s user test with Ben Giordano. Lots of great insight and feedback about the tabbed prototype:

      One of the biggest take-aways is the use of the modal. Ben found it extremely annoying. He didn’t like the fact that it hid the widget area that he was working on — he also showed one of his common use cases with widgets: copy/pasting the contents between widgets in different areas. This isn’t very easy to do with the current tabbed interface.

      Based on Ben’s feedback, I’ve updated the tabbed prototype. I’ve added a list of available widgets to the right of the current widget area, replacing the modal. This feels a lot better:

      • Matt McLaughlin 3:20 pm on September 11, 2013 Permalink | Log in to Reply

        The fact that he’s trying to copy a filled in widget got me thinking… There’s really two distinct things on the current widget page – widget templates (widgets with no content in them) and widget documents (widgets that have been given a title and some content). For lack of a better paradigm I’m falling back on the template/document distinction since it’s common and understood from word processing.

        All of the “Available Widgets” are actually templates. Widgets in a sidebar or the inactive widgets area are actually documents.

        What if we make the distinction explicit? What if we simply combine the list of available templates with the list of available documents and mark the distinction through color and/or titling.


        Then rather than have to copy the contents of a widget into another instance of that template, you can simply drag the widget document to mulitple widget areas.

      • Matt McLaughlin 3:33 pm on September 11, 2013 Permalink | Log in to Reply

        I continue to be concerned that the wireframes and design direction seems aimed at sites with an extremely limited number of widget areas. The main site I manage is a multi-user community site that has over 40 sidebars. I’d really love to see some strategic design consideration aimed at sites like that.

        • shaunandrews 3:12 am on September 12, 2013 Permalink | Log in to Reply

          We haven’t decided on any direction yet, and I haven’t forgotten about sites with more than a few sidebars. That being said, the tabbed prototype would have no problem expanding the list of sidebars to 10 or 15 — 20+ sidebars would be a little unwieldy, but I think that’d be the case for any design.

      • Weston Ruter 11:09 pm on September 16, 2013 Permalink | Log in to Reply

        Hi everyone. I’m new here, and was just invited to the party (thanks @helen). I remember seeing the Widgets UI Refresh being one of the Features as Plugins projects, but I forgot about it when I had the revelation that the Theme Customizer could be easily leveraged to preview changes to widgets, which currently have to be edited blind. After a hackathon the Widget Customizer plugin was born (also on GitHub). It’s remarkably small, as all the pieces were there in Core already, but they just had to be connected together. It works quite well right now, but we’ve got lots of ideas for making it even better. I’ll reference those issues below.

        I’m increasingly of the opinion that if some change cannot be previewed in WordPress, then the change is dangerous, and users will be discouraged from playing and experimenting because they could blow up their site—for example, placing a widget that is not compatible with a certain sidebar area, or changing some text in a widget instance only to find that it breaks the layout on the frontend. So as much as possible, everything should be previewable. Sorry if this is rehashing things you’ve already discussed in depth:

        I think widgets should be addable or removable from the Theme Customizer (see #3). It would be great if the great new widgets UI you’re working on could be embedded within in a lightbox window that appears over the entire window when using the customizer (just like when you open the media manager). Widgets could then be dragged into the relevant customizer sections in the customizer panel (each sidebar could have its own section), and the preview window could then update to show the user what the site looks like with that widget added.

        The widgets in the sidebar customizer sections could also be re-ordered simply by dragging the customizer controls up or down (see #1).

        Is this the canonical repo on GitHub for contributing? https://github.com/shaunandrews/widgets-widgets-widgets

        Excited to contribute!

        • shaunandrews 12:30 am on September 17, 2013 Permalink | Log in to Reply

          Glad to have you on board!

          If you haven’t already, you can catch up on the project by reading our past updates: https://make.wordpress.org/ui/tag/widgets/

          I’ve checked out your plugin, and it fits perfectly with one (out four) of the prototypes we’re building. I’m really digging the direction you’ve described, and would love to work with you to get it ready for some user testing. Lets connect sometime this week; I’m on skype (shaun.andrews) and usually in IRC (all the time) as shaunandrews.

          Is this the canonical repo on GitHub for contributing? https://github.com/shaunandrews/widgets-widgets-widgets

          This is the tabbed prototype, one of four: tabbed, customizer, menu-like, and front-end. Your more than welcome to contribute to any and all prototypes. We (like more plugin-as-features teams) are lacking developers, so it’d be very helpful to have you (and the rest of your team) available to get things out the door.

          • Weston Ruter 6:32 am on September 18, 2013 Permalink | Log in to Reply

            Thanks. I’ve invited you on Skype. Which of the prototypes fits perfectly with the Widget Customizer? I assume that is the Customizer prototype that @richardtape is heading up? Is there a repo for that? If not, I’d happily volunteer the Widget Customizer plugin to serve as the base for the Customizer prototype, and to use the GitHub repo and WordPress.org plugin for collaboration and distribution.

            • shaunandrews 2:10 pm on September 18, 2013 Permalink | Log in to Reply

              Yup, the customizer prototype is what I was referring to — having your plugin as the basis would be lovely! Thanks!

              I hope you can make our weekly chats in #wordpress-ui on 20:00 UTC. I’ve added you on Skype, and added you to our group chat.

            • Richard Tape 4:10 pm on September 18, 2013 Permalink | Log in to Reply

              Welcome, Weston. I played around with your plugin last night and it’s just going to work significantly better for user-testing than my static prototype ever would. I strongly suggest we move ahead in that direction.

    • shaunandrews 4:08 am on September 12, 2013 Permalink | Log in to Reply

      Ran another user test on the modal-less tabbed prototype. Things went very well: (beware the loud cough at the beginning)

      The want to drag widgets into place is thoroughly engrained, it seems.

      • PeterRKnight 12:01 am on September 14, 2013 Permalink | Log in to Reply

        Very interesting. I think drag and drop doesn’t give a great user experience in all situations (mobile, small screens, with lousy trackpads/mice) but it’s not as bad when you don’t have to do too much gymnastics to perform, like reordering collapsed widgets here. I actually like the workflow in this prototype.

  • shaunandrews 7:14 pm on September 3, 2013 Permalink
    Tags: widgets   

    Widgets, Sept 2 Chat Notes 

    The Widgets team had a short chat yesterday: IRC logs

    bobravo2 shared his research into Joomla’s handling of “widgets:” https://docs.google.com/presentation/d/1u7NXNNNdU7dt1jE1GA4bjnfz9BQymIlavRd2PUHI95E/edit?usp=sharing

    PaalJoachim shared another mockup for a more visual way of managing widgets: http://easywebdesigntutorials.com/wp-content/uploads/Widgets-area.jpg

    Work continues on the four prototypes described in the previous meeting, with the goal of having them all ready for user testing (hopefully) in the next week or so.

    In Attendance:

    • shaunandrews
    • bobbravo2
    • helen
    • PaalJoachim
    • Paal Joachim Romdahl 7:49 pm on September 3, 2013 Permalink | Log in to Reply

    • Jon Brown 8:04 pm on September 3, 2013 Permalink | Log in to Reply

      Great work Shaun! I’m happy you all are looking at other systems for what they do well and poorly.

      I’ve said this elsewhere but I’m a fan of standardized UIs and hence something similar to the media manager and menu manager (even if in general I still am uncomfortable with the revised menu manager).

      However… I love the visualizer mockup and am a far greater fan of the idea of having some sort of visual map to the widget areas.

      One thing I’ve brought up before that concerns me though is how any of these UIs work on mobile and it just occured to me that the widget area map I love has the additional problem that it might change responsively. I, and I assume others, have used widget areas to delineate content that gets reordered via flexbox on a page according to media queries. Asking theme devs to provide widget area maps of breakpoints might be asking a lot, it might make sense, just needs to thought about.

  • shaunandrews 7:06 pm on August 28, 2013 Permalink
    Tags: widgets   

    Widgets, Widgets, Widgets Meeting – Aug 26, 2013 

    Team Widgets3 held it’s second meeting this past Monday (Aug 26) in #wordpress-ui. Feel free to check out the IRC logs.

    Spurred by the results of our initial survey results, we discussed the benefits and failings of drag-and-drop. The consensus seems to be that drag-and-drop works well for re-ordering existing widgets, but its less than ideal for placing new widgets.

    We reviewed the concepts that have been brought up so far:

    The plan right now is to build a simple prototype of each of these concepts. Keep in mind that a prototype doesn’t have to consist of working code — a clickable wireframe is a perfectly acceptable prototype, and can provide just as much data as a working plugin.

    • shaunandrews will focus on the tabbed concept
    • RichardTape will focus on the customizer concept
    • jtsternberg will focus on the menu-like concept
    • The front-end editing concept will use the plugin as the prototype

    We’ll test each prototype (and the current UI) against the same set of tasks and see which one performs best against our goals. By simply building the prototypes we’ll hopefully learn which ones “feel right” and which ones don’t. And, by performing user tests on each, we’ll hopefully see where each succeeds and fails with regards to our goals.

    This information combined will help us take the next step and either drop a concept, or rethink it and test again. We’ll continue with this process until we have something that feels “right.”

    Or next meeting is schedule for Monday, September 2, 2013 at 20:00 UTC in #wordpress-ui.


    • shaunandrews
    • melchoyce
    • helen
    • jtsternberg
    • gregpabst
    • RichardTape
    • ipstenu
    • coreymcollins
    • gregpabst 3:07 pm on August 29, 2013 Permalink | Log in to Reply

      During this week’s widget meeting I shared screenshots of how Virb handles widgets. Shaun Andrews asked if I could detail the workflow for how Virb handles widget ordering, updating and additions seen below.

      Widgets listing page: http://cl.ly/image/003N0u0e0w29

      • Listing of all active widgets shown in the order they appear on your website.
      • Each widget has an identifying icon on the left along with a title and a short description.
      • When you hover over each item the icon on the left changes to an icon indicating that the item is draggable. The user can click and drag the widget to the position they would like it in.
      • There is a delete icon on the right allowing the user to remove the widget completely.
      • You can click a widget to go to a widget customization screen.
      • There is a button at the top that allows the user to add a new widget.

      Widgets customization view: http://cl.ly/image/2O1I1Q3n0M1x

      • When a users clicks the widget on the widgets main listing page they are taken to a customization page.
      • The customization page features all the unique settings for the widget.
      • “Back to widgets” button – Takes user back to the widgets listing page and does not save.
      • “Save” button – Saves changes but leaves you on the customization page.
      • “Save & Close” button – Saves changes and returns user to widgets listing page.

      Widgets addition modal: http://cl.ly/image/2q222R310r2T

      • When a user click the “New Widget” button on the widget listing page a modal opens with available widgets.
      • Once a widget is chosen the user is taken directly to the new widget’s customization page.

      I think Virb has a good flow and being that drag & drop is only used to order widgets and addition I think this work well paired with a vertical tab menu so you are only edit one “widget area” at a time.

    • shaunandrews 3:06 am on August 31, 2013 Permalink | Log in to Reply

      Here’s the (semi-working) tabbed prototype if anyone would like to play with it: https://github.com/shaunandrews/widgets-widgets-widgets

    • Paal Joachim Romdahl 2:01 pm on September 3, 2013 Permalink | Log in to Reply

      Here is another mockup of the widgets area:
      Bottom line: visualizing the widget locations showing the full page. Using drag&drop And a + Add widget button. Multiple Widget Layout areas. Favorite Widgets. Etc.

    • Weston Ruter 6:57 am on September 18, 2013 Permalink | Log in to Reply

      Regarding the Customizer concept, I think that the “Select a template to add widgets to” area may not work out because:

      1. What if there are no pages that have the selected template? Or what if multiple pages do? Which one is picked to preview?
      2. How would WordPress be able to come up with those nice visual representation thumbnails for where the sidebars are located in the template layout?
      3. What if templates conditionally render sidebars based on some other criteria, like if the page is a child of another page?
      4. What about templates that aren’t page templates at all, but category templates, tag templates, etc? I guess I’ve been assuming the list of icons corresponds with the list of page templates available in the theme.
      5. Themes can have many more layouts than just just 4.
      6. Two templates may have the same layout, but they use different sidebars in the same area.

      So I think the only reliable way to select a template to add widgets to, is to just navigate to the page that has the sidebar currently rendering on it. Since you can navigate the site within the preview window, the user can just navigate to the place where the sidebar appears. In the Widget Customizer plugin, we have a customizer section for each registered sidebar, but the sidebar customizer section only appears if the currently-loaded page in the preview window actually has that sidebar rendered within it. As you navigate the site within the preview window, the user can see the customizer sections for the sidebars show and hide based on whether or not the current page has the sidebar.

      Unfortunately, the way that dynamic_sidebar() works, is that it fires an action each time it iterates over the widgets that are populating it (see example). So if a sidebar is empty, I don’t believe there is currently a way in core to determine if dynamic_sidebar() was ever called on the page. So the addition of another dynamic_sidebar* action that fires regardless of whether or not there are widgets populating the sidebar seems to be something we need added to core.

      Sorry if I’m re-hashing old things.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar