Customization Meeting Notes: January 16, 2017

We had a meeting today in #core-customize to kick off the customization focus in 2017. Here’s a summary of what we chatted about:

    • Check out https://make.wordpress.org/design/2017/01/13/what-makes-a-great-customization-experience/ and https://make.wordpress.org/design/2017/01/11/what-makes-a-great-editor/ for some great discussion, and share your own thoughts.
    • What are your biggest customization pain points?
      • WordPress doesn’t help you setup your site according to your goals.
      • What’s a featured image? What’s a header image?
      • Moving (“dancing”) in and out of panels hunting for what you’re trying to edit is difficult.
      • Why can I click on one thing to edit it but not another thing?
      • User expectations from @ianstewart: https://wordpress.slack.com/archives/core-customize/p1484590206000728
      • If you can’t see it, how can you edit it?
      • We need an improved flow for content editing as part of customization that better ties that together with the surface-level tools.
      • Moving, adding, and deleting chunks of content and “features” in a design should be possible.
    • What if the customizer panel is blank, and stuff shows up only when the user clicks something in the preview? Would they be able to do everything they need?
      • We made a step towards this with Edit Shortcuts in 4.7.
      • But, Edit Shortcuts is a bandaid.
      • Need a balance of contextual tools and global controls.
    • How many tickets can we close by iterating on a whole flow?
    • What are the drawbacks of direct manipulation?
      • (Direct manipulation = I see it, I tap/click it to edit.)
      • Focused on what you see in front of you right now, rather than your whole site across multiple screen sizes.
      • It’s easy to mess up the site layout and design if you can control everything.
        • This is where “undo” could be handy.
        • Hard to tell if you’re customizing something locally or something globally.
      • Should we separate content, layout, and design?
    • @karmatosed is going to be leading user research and testing:
      • Have a series of posts on here on make/design asking for input, focusing on how people are using the Customizer to build sites for themselves and for clients.
      • Have people test the Customizer and report bugs to Trac.
      • Frequent Trac triage of Customization component.
      • Have a public “call for testing” for every new feature or flow iteration. Would be good to integrate these into local WordCamps and meetups as well.
    • We need to continue working on the technical architecture of the Customizer in preparation for future features and customization flows:
      • Changesets: #31089.
      • REST API for Changesets: #38900.
      • Customize Snapshots: GitHub PR.
      • Bigger features we know we want to support in the future need to be scoped and architected now, while we’re designing, so they’re ready to be implemented later.
        • I think it’s important to identify the big picture technical stuff, the things we’ll know we need for sure to support implementing the fuzzy design that will come clearer into view. It will take many months to implement. We can’t wait for design to be “finished” before we start development. It needs to be iterative. — @westonruter
    • Potential wins in the 3 months?:
      • Merging edited starter content on theme switch: https://core.trac.wordpress.org/ticket/38624.
      • Pain points with lost widgets and menus when switching themes.
    • Many of the features and flows we want to build out in the future (drafting changes, revisions, content blocks) need to be worked on in collaboration with the Editor team.

We also continued the discussion past the meeting time. The conversations were a bit too long to summarize, but you can catch up starting here.

If you’re interested in getting involved, please add your input to the “What makes a great customization experience?” thread and join us in Slack.

#customizer