I live-tweeted a theme change and you’ll never guess what happens next

I summarize some thoughts, is what happens next. But you know what would be even better than that, is if we all looked at making these better and identifying even more problems. Some of the notes below seem like they probably translate into really good first/early contributions for both design- and development-oriented people.

  • Better ways of matching thoughts (keywords) with actual themes. Maybe that’s better tagging, or multiple screenshots to show more views that might match what I was looking for, etc.
  • There are no themes I found that did creative things with a mix of post formats, e.g. longer prose posts mixed with a bunch of photos in individual posts like on my blog. I didn’t expect to find anything that catered to that specifically, but wow did everything look the same. Somebody noted that there sure were a lot of good themes for showing off your phone.
  • The split between managing installed themes and adding new ones is really awkward in practice. Inline installing has helped a bit when adding new themes, but it’s not great. (This often applies to plugins, too.)
  • There’s no feature filter for installed themes, only a name search which is pretty useless if you don’t remember theme names.
  • Said feature filter could really use some microcopy and interaction work.
  • Adding themes in general has some UX oddities that could use work.
  • .org theme previews suck (this is widely known). .com’s are quite nice from what I’ve seen. The previews also help me narrow down thoughts about what I really want. I don’t want a theme that does it all, I want a fairly narrow theme that can strongly be what I need instead of doing it weakly or forcing me to do a lot of work to get it there.
  • .org themes should be able to have more than one associated author.
  • Widget area migration guessing is still awkward, although I guess still better than dumping all widgets out when switching a theme. Menus don’t migrate at all, which is strange considering that menus are generally more uniform in placement/use and are actually built as discrete groups.
  • Menu Locations with separately built menus are confusing in practice.
  • Some live previewing actions are REALLY slow and I have no idea why or what I’m waiting for.
  • There are still a bunch of dead ends in the customizer as it stands, and visual edit links for things like widgets would be so, so nice.
  • Post formats (un)structured data, I don’t want to talk about it.
  • Notices telling me to do XYZ to “finish” an update are slightly alarming and if that notice disappears when I click on whatever link it gave me, I probably won’t remember what it said.
  • Plugin and theme conflicts are awful and I have no idea how general users get through them.
I live-tweeted a theme change and you’ll never guess what happens next

Theme disconnect and discontent

Since I’ll be leading the 4.7 release cycle, I’ve been doing a lot of thinking about what it might look like. Really, I’ve been doing a lot of thinking about bigger projects and longer roadmaps in general, but 4.7 is pretty good motivation to kick things off.

One of the wishlist items I’ve heard throughout my five years of core contributing has been NUX – new user experience. So many abandoned sites, so much frustration in getting a site looking the way you want it to, so let’s fix it! Except that NUX is hugely broad (and itself can be thought of as N-UX and NU-X), and while individual bits have been worked on here and there (e.g. pointers), I wouldn’t exactly call it a unified effort toward a shared goal.

The part of NUX that I would like to start tackling in 4.7 is initial site setup, which also ties in with theme setup, whether that’s initially for a site or on theme switch. My premise here is that a user should be able to go from a fresh install of WordPress to being ready to show somebody else their site in a unified experience that allows for live, non-destructive previews. Initial questions that spring to mind are:

  • Where exactly do we define the start and stop of the setup phase to tackle right now?
    Perhaps post-theme selection through when you first feel comfortable sharing the site with somebody else, e.g. “check out what I’m working on”.
  • What might somebody have already in mind when they start the process of setting up a new site?
    These might be things like a general visual idea (typically inspired by a site or general trends), existing media (photography, videos), contact form, and so on.
  • How do different people conceptualize the structure of a website?
    When I taught digital portfolios for musicians, the most successful analogue was a hierarchical outline. Some people don’t think about it at all, and that’s okay, too.
  • What goes through somebody’s mind as they pick the next thing they want to change about their new site?
    For instance: I want the title of my site to look like this, now I want a logo next to it, now I want this image behind all of that, and then under that would be a menu that goes to pages with these titles, and then over there I want my contact info, etc.
  • What currently exists in WordPress that supports this goal?
    Customizer, site icon, site logo, custom header, custom background, featured images, nav menus, widgets, ???
  • What currently blocks users from accomplishing this in WordPress?
    Activating a theme might not make it look anything like the screenshot or demo you saw. Adding pages to nav menus currently requires you to leave the customizer, make a page (which confronts you with a content area that you may not be ready to think about yet), and then go back to add it. Or, add a fake link and remember to go back and change it later (and that’s for a user who understands custom links and making fake ones, etc.). Multi-part pages don’t have any sort of standard or even common editing experience. Shift-click to edit an element (which is over in a side panel) is a hidden feature with no visible hint.
  • What are other services/software projects doing in this regard? What’s working or not working for them and why?
    Time to do some market research.🙂

With 4.7 being the final release of the year, Twenty Seventeen is also on my mind, which aligns nicely with this focus area. I have some pretty strong personal feelings about what I want it to be like, but no matter what, here’s what I want it to represent and enable for others:

  • Theme demos on .org that actually best showcase that theme. This may be static home page, specific content, layout selections, and so forth.
  • Initial option/content/whatever setting upon theme activation, so that users get the look they saw and have some prompts for what kind of content might go where. This is super tricky for a number of reasons and I think we’d want to approach it in a restricted way so that best practices have time to develop before more creative approaches appear and get copied.
  • If some kind of multi-part page is present (seems highly likely in the current climate), at least an initial exploration of the best experience for editing that in various contexts.

One of the things that was really interesting in 4.6 was the response to the proposal for creating page stubs while editing nav menus in the customizer. A lot of concerns seem to center around mixing of content and appearance editing in the customizer, and the recurring theme of worrying that the customizer is eating WordPress‡.

In regards to the mixing of what’s being edited, I don’t believe that the majority of WordPress users or even a significant percentage of us make a distinction between “content” and what our sites look like. Essentially, for most there is but a singular “this is what’s on my website”. That’s not to say that there isn’t a difference technically, and certainly for developers it’s much more evident (although nav menus and widgets still seem to be a gray area). As always, I’m happy to be wrong, but I’m also confident that I’m not.

Bottom line, what I want is to close the gap between what a user is expecting a theme to look like and what it actually looks like on their own site. Someday soon I’d also like to close the gap between what a user has in their head and finding a theme to match. If this sounds like some things that Matt’s been saying, well, we do actually talk to each other🙂 I’ve got plenty of other things I want to have happen in 4.7, and I’m sure as things get rolling next month people will bring up tons of great ideas and bugs that need fixing, but actually planning some kind of product feature and roadmap seems like a good thing to start doing.

‡ As for the customizer eating WordPress: it’s not. But! I understand where that comes from. User trust is centrally important to WordPress – shared philosophies and its success alike. When it comes to what’s on a website (appearance and content), one of the best ways to gain and keep user trust is to provide non-destructive live previews. Right now in WordPress, TinyMCE can serve that for content, but that’s largely the area of the customizer, and that’s why things keep creeping into it – because that ability to try out changes without them showing up before you’re ready or otherwise being “punished” for them is incredibly important. But it might not be the customizer in its current form forever, and in fact, it probably shouldn’t be.

Theme disconnect and discontent

Development Philosophy: Confidence

It’s really easy to get caught up in implementation details. I do it and watch people do it all the time. When I’m working on things, and especially when I’m stuck in a rut, I think to myself: “How can this make a user feel more confident?” This is relevant even when there’s no UI involved – a user can be a lot of different things. For instance:

  • Local autosaves of post content help users feel confident that they can choose to write directly in the editor without fear of data loss. (You can still write somewhere else, that’s cool. I happen to like the WYSIWYG.)
  • Not having shared terms helps users of both code and UI feel confident that changes to one taxonomy term won’t unexpectedly affect another.
  • Widgets in the customizer remove the element of “save and surprise” on a live site. The customizer as a whole is grounded in easing that friction.
  • Embed previews help creators feel confident about the appearance and content of their site.
  • Automatic background updates help site owners feel confident about the security of their site.

Right now, I think new-to-WordPress-admin users never get a chance to build that confidence. What can we do for them, while not hindering those who already have that confidence? We want to surprise and delight – but that means delightful surprises, not jarring ones.

Development Philosophy: Confidence

The Good and The Not-Great #1: Media Library

Several music professors of mine had very similar rules about giving feedback in weekly group masterclass: lead off with something positive, always frame criticism in a constructive manner, and try to use “and” instead of “but” whenever possible. I’m going to give that a shot in the form of a post about WordPress, though this may never really become a series (it’s an optimistic post title).

One of my favorite things from 4.0 was the grid view for the media library, with the attachment detail view that came along with it. We’ve got lots of list tables in the admin (you know, the “all posts” list and so on), and media is technically attachments is technically a post type and so a list table is an easy path, if not a particularly visual one. Media handling in CMSes across the board is often not great – it can be resource intensive and includes a multitude of components (technical and conceptual), making it difficult to develop for the lowest common denominator. So where do we go with it?

There are two areas I use media heavily: for photo uploads and for audio files. For photos, I do two major things: on-the-go photo blogging on my personal blog via the iOS app, and a private site where we mass-upload pictures of the kid for family to view and download. With audio files, they are typically of performances and used on musicians’ websites. In all of these functions, I’ve found that the media improvements between 3.6 and 4.0 provide a far better experience – not just for me, but for everybody who uses the sites, whether they’re also browsing and uploading in the admin or getting to listen to audio samples in a seamless player on their mobile devices.

I didn’t go into leading 4.0 thinking “I’m going to make WordPress better for my own personal gain”, I promise. The media grid, as we tend to call it, was not something forced to play along with my own use-cases – these things I’ve discovered I love so much about it mostly happened once the release was over and I had a chance to breathe again. It also wasn’t a universally-loved progression. “What problem are we solving?”, some would say; “It’s still so bland” from others; or “What about the sidebar from the media modal?” from yet more. Perfectly good questions.

It’s funny – sometimes you solve problems nobody realizes they had until after they’ve used what’s new, and some of those pain points aren’t universal. That’s okay. We took a typically very visual content type and gave it a visual browsing experience – it’s not that the list table isn’t serviceable or even always a worse choice (for instance, it might still be better for document management), but rather that it could be better. The attachment detail overlay gives you large previews of images and working players for audio and video – no navigating away and losing your browsing spot necessary. It also addressed the sidebar difficulties which had become apparent in the media modal on small screens – when you’ve got limited horizontal space, there’s no side for the sidebar to go. Perhaps bringing a similar view to the media modal will come next – who knows? (Okay, so in reality that is probably more like further styling of the sidebar to “take over” more than it currently does, but I digress.)

The thing that I love the absolute most is something that wasn’t really looking to solve an existing problem, but rather something that would unify between another similar experience in the admin as well as aim for that “didn’t we always have that?” feeling. That thing is the previous and next item navigation in the attachment detail overlay, which was inspired by the same navigation in the theme browser from the previous release. You can quickly flip through your media, whether by clicking on the mouse or using the arrow keys (keyboard accessibility is for everybody!). In the case of our family photo repository, I realized that we don’t even need the front-end anymore. All you have to do is go to the media library, where you can filter it down by month and go through pictures as either thumbnails or in a bigger individual view, just like you would on your phone’s camera roll. For audio files, sometimes I need to quickly edit a bunch of ID3 data for files I’ve just uploaded (also relatively new functionality in WordPress, as of 3.6) – with that navigation, I can change a few fields quickly and move on to the next one.

Okay, so I love it. And I see it as a progression, not a final stop. There’s still so much more that can be done, and I hope we can continue to iterate instead of letting it sit as some sort of monument.

I would like to see better filtering. We kept the status quo – type and date filters. But I want more: tags (and all that comes with that), searching of more fields/meta. What else can and should media be filtered by? What does filtering look like?

Some media types could use better handling. One that has an interesting proposal already on Trac (#31050) is PDFs, specifically generating a thumbnail. Yes, please!

More bulk management options – not everything would make sense for core, but is anybody experimenting with extending them? Right now it’s just delete. What about bulk categorization? Bulk resize?

What’s browse, and what’s manage? What else do we need to do to marry the two together in one experience? How does that mesh with the further insert flow in the media modal, and where does editing come in? Is editing a subset of management?

Maintaining context and sense of place when you go into and out of the details overlay. The nice thing about the sidebar was that you always had a sense of where you were previously – visually anchored. Can we bring that feeling back? Would a small “film strip” of items across the bottom help? Would subtle animations make a difference?

More experiments in the design treatment. I think it looks nice, but in a very basic and utilitarian kind of way. The admin is rather like that across the board, so maybe we wouldn’t go too far, but I’d love to see more of what we don’t know we want.

One of the toughest parts of pulling this in as a feature in the first place was losing that experimentation. It existed as a very experimental plugin, we went hard and early with some of the basic concepts of that plugin as a patch, and eventually jumped to an attachment details overlay that was not exactly initially embraced. Pulling the feature in from something that didn’t present itself as “complete” has negative effects as well – further iteration dies off for a variety of reasons, and frustrations can arise when promising ideas are not implemented right away in core. Perhaps by unwinding some specific things I think could be interesting, somebody will want to continue to experiment. At the very least, I’ll feel better about not resting on my release laurels🙂

The Good and The Not-Great #1: Media Library

Coming back around

One of the funny things about having a louder voice is that sometimes it can feel stifled. I think a lot about WordPress, of course, but I shy away from saying much about the things I think could be neat because I don’t want it to be taken as a promise as it gets repeated and loses context. I talk about implementation details and project workflow on Trac all day long – where do I go to talk about all the things I think would be dreamy without them being something I’m working on right this second?

Right here, I think. Going to give shorter-form writing and musing a shot again.

Coming back around

I lit a communication fire

Today I inadvertently lit a fire during the weekly WordPress core development chat by mentioning a Skype chat that had been set up and thus far been used to say hi, link to a Google Doc, and alert five people to an IRC meeting. I’ve included the full transcript of the chat from beginning to end at the bottom, because I do value transparency. I’m telling you now that some of my messages sound meaner than my intent – that is, after all, what happens when I didn’t originally anticipate being held openly accountable for them. I also am often typing with a baby in one hand who’s struggling to mash keys and 15 other chats open, though that’s no real excuse, because I am generally very direct, anyway. Everybody else sounds like a decent human being🙂

Communication is hard. Everybody has a different style, and a different vehicle that best fits that style. When it comes to communicating within WordPress, especially with people I don’t know or have only met once or twice, I have two general thoughts: one, that it’s better to over-post something in different places (of course, preferably with one canonical post and the rest linking back to it), and two, that it’s important to find ways to marry different avenues of communication in order to include as many voices as possible.

The latter is difficult, and often I think to myself that it’s rather idealist and perhaps impossible. However, I see this in WordPress core and plugin development often: we have scheduled IRC chats, impromptu IRC chats, posts to a P2 with asynchronous discussion in the comments, Trac tickets with patches and comments, private pinging on Skype or HipChat or text message, using GitHub for developers and WordPress.org for users. Many people view this as a negative splintering of discussions, and I agree that if they are not interconnected and used appropriately, it can be. But I believe that with a little effort and pruning, we can make it work. I may be very much alone in this – disclaimer that this is my own opinion, etc. etc.

In Matt’s State of the Word at WCSF 2013, he revealed that the group working on the admin redesign plugin known as MP6 used a Skype group chat for a lot of their communication. I had the same initial reaction as many: “ugh, that sucks, it’s a closed loop and they’re making people feel like they’re excluded from the cool kids’ club.” While I still feel that way in some respects (and for full disclosure, yes, I was later added to the chat myself and promptly lit into something I didn’t like), I challenged myself to see the positives instead: that the group could now include people who had a hard time with IRC for one reason or another, messages sent while somebody was offline could be received as opposed to retrieved, and that without the pressure of knowing conversations are public they were able to be more direct and critical with discussion and feedback, especially when it came to design itself. We say code isn’t personal, but design is a different skill and feeling entirely.

I don’t enjoy spending my energy figuring out best communication channels, and people as a whole tend to feel more comfortable when there are parameters. Therefore, I am glad that in today’s instance, we’ve scheduled a weekly chat in IRC that appears to work for those who have voiced a desire to be actively involved in this particular initiative (bringing even more goodies to the media modal and TinyMCE). Perhaps the Skype chat will fade away, or perhaps we’ll discover that it serves as a good way to notify those who tend to have only Skype open that an IRC chat is scheduled or an impromptu one has broken out. I think it’s important to be open to these discoveries, and I value the chance to be more inclusive over accusations of being exclusive.

I also find it important to keep up with regular summaries on more static communication platforms like a blog/P2. IRC transcripts can be hard to read and parse, and commenting on them after the fact is awkward. This is also important for those who can’t make it to a chat – no time is perfect across all time zones, and people have life things happen, like getting sick or having an appointment or putting family first. I myself am especially empathetic toward those who get called away without much warning, and very much value the ability to consume and respond to information at my pace when needed, rather than that of others. I am very guilty of putting off writing summaries when I am in charge of them, and want to continue to work on bettering myself.

I sat here for a while pondering how to write some sort of “conclusion”, and I guess it’s this: I’m happy to cop to making a error in judgment earlier that led to me sending a message that I probably knew would not go over well, and I think it’s important to see these struggles as learning opportunities and use them to continue to make things better. I also think we should just go ahead and admit that sometimes real ideas come out of being dumb in private with somebody you’re friendly with – we have the .wp-core-ui scoping class in core because I responded to a text message bemoaning the bleeding of the buttons CSS on the front-end with (and this is a direct quote) “f*** it, let’s add the .wp-admin class!” I was kidding at the time, but he saw how it could actually work, and so far it’s been great. Perhaps especially because I relayed a censored version of the exchange later in IRC.🙂

Skype transcript as follows.

Continue reading “I lit a communication fire”

I lit a communication fire

MP6 + UI components

Going to just blog what’s on my mind/docket. Open source my brain or something.

Since I started contributed to core, I’ve thought about how we need to have UI components in core admin CSS (and used whenever an API outputs something in the admin). In 3.8, I would like to tackle Trac tickets #18909 and #16413. First, though, we need styling, and I think MP6 is a great place to do some rapid iteration.

In MP6, I’ve started a little initiative that serves several purposes – I call them test pages, and the intent is for them to serve as visual unit tests as well as the backbone for a style guide / UI docs. They’re hidden – to turn them on, define the MP6_STYLE_GUIDE constant to true somewhere, probably in your wp-config.php. These will definitely not become a part of core; when merge time comes, they would get split off into a separate plugin.

As of this writing, all you’ll get is a new top level menu item for a style guide, with one child page that serves up jQuery UI components, using their standard test page. It enqueues CSS from Google – namely, Smoothness, so it doesn’t look MP6. Yet. The goal (and this is open to anybody who wants to contribute) is to re-style jQuery UI components into something that looks and feels like WordPress+MP6. There are some technical considerations that probably have to be made – namespacing to avoid conflicts, possible conflicts with styles already in core/changing those places to use new styling, how styles are loaded and how color overloads work. But first: it needs to look and feel good.

Next up is a form test page. I’ll be using a few things as inspiration for the HTML: UIKit, Bootstrap, and perhaps Gumby Framework. I’m open to other suggestions as well. We’ll want to make form styling reusable (of course) and responsive. I’d love it so that no extra classes are needed when creating your extensions – forms “just work”, whether on a settings page or in a meta box. The test page should probably account for these various typical places of use.

There are lots more components we can look at over time – it perhaps shouldn’t be as thorough as a front-end framework like Bootstrap, but if we’re talking about refining WordPress as a platform, it needs to apply to the front-end side of building, too. Let’s just make sure we keep our eye on the iterative prize.

MP6 + UI components