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 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

Admin CSS back-compat possibilities

I continue to think about CSS back-compat, especially as we dive deep into the land of MP6. Given that we are talking about build processes as well, I had an idea. There are two steps to this idea: a section (or separate file, if/when we get into building concatenated/compressed CSS for core) for CSS that is being kept for backwards compatibility. Things would generally stay for a cycle or so, but subject to evaluation in some cases for history and wide usage, such as settings tables. After that cycle, rules would move to a deprecated.css that is registered but not enqueued – if a theme or plugin needs it, they should enqueue it on applicable screens.

This is all just an idea – I don’t know if there would be hard lines about how long CSS stays in back-compat or deprecated areas, or if this would even work at all. I have no idea if we could or should throw notices somewhere (console?) like PHP can, and now jQuery with jQuery Migrate. Thoughts?

Admin CSS back-compat possibilities

Scared of WordPress Core Trac, but want to give it a shot? Try Trac Gardening!

For 3.7, the biggest goal (at least in my mind) is to blow through Trac and close as many tickets as possible, either through committing a patch or because they aren’t relevant anymore. At close to 3800 open tickets, Trac just isn’t manageable for anybody anymore (except perhaps for Sergey). Casual and hopeful patch contributors are understandably intimidated and lost. Nobody wants to make a duplicate, and keywords often don’t accurately reflect the state of a given ticket, leaving people wondering how they can see tickets that need a body. We need to get this under control.

I consider Trac curation to be one of the most important but often overlooked areas of contributing to core. Other projects formally recognize them – for instance, Joomla! recognizes active members of their Bug Squad. There are efforts currently under way within WordPress to form core component teams, so I don’t currently have any real thoughts on what should be recognized and how, but I think something similar could be really nice.

In the community, some trusted contributors are given Trac privileges to do what’s called bug gardening. There isn’t really a whole lot about this that is different from what everybody else can do – it’s pretty much just that you can set the Milestone, which serves two purposes. One is that it prevents creep (of course everyone would want to put their pet ticket into the current milestone), and the other is that tickets that are closed still get some kind of review from somebody who’s been around, because the milestone needs to be cleared.

You don’t need to be given a little piece of Trac permissioning to do gardening, though! There’s a page in the handbook about bug gardening, but I thought I’d give a practical example based on how I do things. I’m sure it won’t work for everybody, but if it helps anybody, then it’s worth writing down.

I subscribe to what’s known as the Trac firehose: the wp-trac mailing list. It’s definitely not for everybody, and soon (seriously, soon) you’ll be able to subscribe to just certain components instead. However, I’d recommend that everybody give the firehose a shot, even just for a week or so. There are definite swings in activity, and I think it gives a great perspective as to the sheer number of tickets, comments, and patches that are clamoring for attention at once. If getting emails for when somebody is just cc-ing themselves to the ticket drives you insane, I have a handy Gmail filter for that: “added — Ticket URL:” → Trash. If you’re just doing it as a temporary thing, though, you might not want to filter those out. It’s a great barometer as to the level of interest in something, and it can often bring an old ticket back up for attention.

I try not to read these emails all day, but rather set aside a little bit of dedicated time to read them in chunks. I do make an effort to read everything, but if I’m overloaded and there’s a super active discussion on something I’m not tied into, like say using PDO, I might just delete it without reading. If I see something that’s been closed but the milestone hasn’t been cleared, I go check it out. Usually it’s been closed for a perfectly valid reason, like a duplicate or that it’s a plugin at fault, so I just clear the milestone and go on about my day. Other times I reopen it, or it sends me on a hunt for other duplicate tickets that can also be closed, etc. I might also add keywords if they’ve been left out when somebody adds a patch (has-patch) or somebody reports that a patch doesn’t work (needs-patch).

Many times, though, just seeing an email for a ticket triggers me to want to know more about it, and it often ends in a patch. As an example, take #17201: “dynamic_sidebar performance”. I saw that a newer gardener had closed it saying he didn’t see a performance issue, and the ticket title was vague, so I went to see what it was about. The complaint was that sanitize_title() was slowing things way down, and given that it’s something I’ve dinged people for using on display due to its heaviness in various code reviews, I thought that the ticket was probably perfectly valid after all. So I took a quick look at the function, saw that the usage of sanitize_title() is indeed there (and more than once in a call!), couldn’t reason out why exactly it’s even needed, and reopened the ticket with a comment saying as much. Now, I still haven’t figured out why it’s there, but it seems to me that a less expensive function could be used in its place. Maybe I’ll patch it. More likely, though, I’ll encourage somebody newer to patch it for experience. :)

There’s life beyond the firehose and messing with keywords and milestones, too. Reproducing bugs and testing patches in general are a huge help. There are various reports in Trac that can get you a picture of what’s going on in a given area – the most common ones people look at are 5 and 6 for the current release. You can also just pick a random open ticket, or look at a component, and go from there. If a bug report is just sitting there without any further comment, try reproducing the bug. If you can’t, ask the reporter for feedback (and leave the reporter-feedback keyword). If you can, leave a comment with the steps you used, as it helps for history and for further patch testing. From there, if so inclined, you can try writing a patch.

If a patch exists already, test it! If it doesn’t apply cleanly, you can mark the ticket with the needs-refresh keyword, and/or go ahead and refresh it yourself. If the patch doesn’t work, or doesn’t solve everything, leave a note saying so and add the needs-patch keyword. You can also, of course, iterate on the patch. If everything’s good, leave a comment saying that the patch works for you. If it’s a complicated process to testing the patch, it can help to leave your steps, much like with reproducing the bug in the first place. Refreshing and iterating on patches get you props just like a patch you wrote all on your own, so if the props are a good carrot for you, that’s something to note.

Don’t be afraid to do something “wrong”. Really, there is no wrong. Maybe somebody will reopen a ticket you closed, or maybe it’s not really a duplicate after all, but it’s not a big deal. Don’t take it personally or worry about it. Learn from it if there’s something to be learned, and keep going. Let’s clean up Trac, y’all.

Scared of WordPress Core Trac, but want to give it a shot? Try Trac Gardening!