 Today I want to talk to you about intent in software design, how your software communicates what should be done next. Software design isn't just about visual interface design, but also about the design of the API that powers it and anything that builds on top of it. By deliberately declaring and communicating the intent of our software design, we can write better code, create better user experiences, and keep our users happy. Let's back up and think about what intent really means. We experience this constantly in the form of physical objects and often describe objects as being intuitive. So take this teapot, for example. There's ancillary cultural knowledge, such as what T is, and there's physical knowledge of other objects as learned over time. Thanks to that knowledge, which together can be referred to as natural mapping, the intent is clear. Your hand goes in the big loop, which you likely understand to be a handle based on context, and you tip for liquid to come out of the spell. This also allows us to appreciate expressions of the absurd, like the coffee pot for masquists, because we understand the intended use of a teapot, hot liquid coming out of a spout. So we can understand that the intent of this teapot is for you to hurt yourself. You may recognize this object as being on the cover of Don Norman's The Design of Everyday Things, which is something I highly recommend reading if you haven't, even if you think of yourself as mostly code oriented. These same ideas apply to our software. Users bring some existing knowledge when using our software, but it's rarely anywhere near comprehensive, and it's important to clearly indicate what they should be doing or will be doing. It's also important to know that this clarity, known as a good user experience, doesn't just mean what an end user might do with a given visual interface. It's also what a developer might do while interacting with the API. An API is, after all, also an interface, an application program interface. Those user experiences, UX and DOX for developer user experience are critical to adoption and continued success of a software project. Good user experience relies on a user interface that clearly communicates its intent. What a given interface element is intended to be used for and what is intended for the user to do next. This ideal is what leads to the philosophy of decisions, not options. The challenge, though, comes when UI needs to change in order to be more intentional, especially through the removal of longstanding elements. So let's take a look at an example. We're going to ignore my thoughts about the existence of screen options in the first place. But its current implementation really falls short in a number of ways. Some of these inputs, in this case, the checkboxes for the columns to show on screen, they apply immediately, visually, using JavaScript and they save immediately over Ajax. But there is no feedback whatsoever that this is happening. There's no feedback that says this is saving right now and this has completed its save. The number of items per page input, on the other hand, has to be submitted through a full page refresh in order to apply. The apply button being in line with that input helps you understand that this apply button is related to the input. But there's another problem here that you can't see in the interface. There's a hook to add more options to give our developers flexibility, but it's below the per page option which itself doesn't always show. In looking at what plugin authors do, we saw three main approaches. Their inputs also save over Ajax or they add their own submit button or they just piggyback off of this now really poorly placed apply button if you can imagine more options showing up beneath it. None of that is good. By having this hook, we've said this is where we intend custom options to go and we intend for you to build them if you need them. But then we don't provide any sort of structure for the right experience for the users. During the development of the upcoming 4.4, I was guiding a contributor through moving view modes into screen options which would make for a more logical grouping, but we quickly realized that the apply button would require some changes. So when 4.4 comes out, hopefully in the next week or two, through some clever hook usage, developer can indicate that they need the apply button which Core also does when it does need that apply button which will then show at the bottom of the entire form. The problem is this still doesn't address the issue of mixed saving context, right? Some of these save over Ajax and don't actually need to be submitted over with the apply button and some of these then do need the apply button and it doesn't tell you which is which. So you haven't fixed that yet, but it is a step, it's a right step toward a developer API that isn't inherently going to produce bad results for end users. It's also a primary button now if you can see that. It's blue in this case because when the panel is open, that's the user's intended primary action to save their changes and also it causes a full page refresh. Another case study, over the course of a few releases we've removed the title attribute field from image and link insertion and WordPress because it's detrimental to a number of different types of users, something we often refer to as accessibility. This has understandably created blowback. Many content authors were using the title attribute for information that was considered important, such as for use in a lightbox, caption or browser provided tooltips the way XKCD does. Leaving that field there but not using it was not an option in our core software. Having a visible field tells the user that they should do something with it even if it's not required and silently not using the content of that field anywhere would be extremely confusing and a break in the user's trust in the software. By leaving it to a plugin or other custom code to add back a title attribute field, we require users which in this case are site administrators to intentionally choose to be using title attributes on a site. They must jump through hoops in order to create content that is not the best experience for their readers. An intentional API provides similar barriers in favor of a good default experience. Software that includes a visual user interface should provide solid experiences on both the development and end user fronts. The intersection of those fronts is an API that enables developers to create good user interfaces. By providing smart defaults and clear documentation, developers are encouraged to take the path of least resistance that will lead to a good default experience. Because of WordPress's prioritization of end user experiences and interfaces, many of our APIs require us to think about how intent is communicated or will be communicated on those different fronts to developers and end users. Let's take a potential fields API as an example. Code and inline documentation communicates to developers our intent for how the code should be written, but there's also our intent for the user interface that results from usage of the API. And the developer must take care to communicate the intent of that interface to the user. Creating a fields API then is necessarily labor intensive. Not only are we as core developers looking to create a unified developer experience across many different field contexts, saving contexts, visual contexts across the admin for WordPress. We want to enable them to provide users with a unified native feeling UI by having a comprehensive set of UI components and an API that defaults to using the appropriate interface for a given context. That's not to say that a developer won't be able to create interesting non-default experiences, but rather that they must do so deliberately and hopefully then with thoughtful consideration. We must also document thoroughly, both inline in the code and in examples of best practices for both code and user experience. Anytime our code is producing something that the user sees or interacts with, we have to think about what that interface is communicating to them. This would be things such as where fields should be placed, what kind of consideration goes into determining the right flow of action based on field placement and how best to implement your fields in code. From the earlier example of title fields, which we removed, form inputs themselves communicate intent. It's not just what the user can do, it's what the user should be doing. Many people in this room probably have their own website of some sort, but imagine the majority of people out there staring down at a comment form asking for a website URL that they don't have. Yeah, you say it's optional on these forms, but it's one more burden on the user upfront mentally and in many comment forms, including WordPress up until 4.4, it requires this field or asks for this field before they even get to the comment itself, which was the primary intent of what that user was doing in the first place. This is a fairly notorious joke. There are only two hard things in computer science, naming things, cache invalidation, and off by one errors. And I looked up the proper attribution for it. Naming things is really, it really is, it's really hard. And it's precisely because names are on the front line of communicating intent. So where are some times where we've had to think about this during core WordPress development. This is an example again from the upcoming 4.4 and also was tinkered with a bit in previous releases. This is the WP title function. The word title itself is really ambiguous in its meaning. WP title, the function was, I believe originally intended or it has been declared to be intended for use in the HTML title tag, but it's understandably been taken by developers to be used in other places, especially in a vacuum of alternative methods for getting the title of a page. So what else could we have called it to more clearly communicate that it was meant for just an HTML title tag? Why didn't the inline docs specify its intent? For reference, the top line of the inline doc for this function says, display or retrieve page title for all areas of blog, which is vague even to a native English speaker. So now that it's recommended, that theme's not called WP title directly themselves, but rather allow core and plugins to handle the title tag appropriately. What happens then when we say we want to deprecate its usage? It's being called outside of the context that core believes that it should be used in. Have we accounted for all of these other usages that have popped up over time? That's not to say that we can't deprecate it at some point, but rather that having that clearly communicated intent initially, it is now a burden on us to do the research and ensure that sane, future-friendly alternatives are documented before formal deprecation. CurrentUserCan is a great function, not just because it's so powerful and critical to how WordPress operates, but also because it clearly shows its intent, in this case, by reading almost like natural language. As a developer, you're asking WordPress if the current user can do X, whether that's editing posts in general or editing a specific post. It is also clear that this is to be used in a conditional check. What developers do with that conditional check itself may be suboptimal, but it's highly unlikely they'll be using the function itself incorrectly. Maming in HTML and CSS also matters. WPAdmin says, you're in the admin, so people have been using it not just as a CSS selector, but also in JavaScript, as a version of the PHP side function is admitted, whether or not that's really how we intended it for it to be used. When we decided in 3.5, or discovered in 3.5, I should say, that we needed to scope some CSS for things that could also be used on the front end, like WP Editor, the media modal, and buttons, we needed to introduce a new class name for scoping that was more obviously not meant for JavaScript use and wouldn't accidentally trigger a cluster of JavaScript that was not meant for the front end. Talking about what users and developers can do with our software is really exciting, as is making those possibilities happen. But when your software is used widely and extensively, the intent of those possibilities is critical for the long term. When you make a pledge to backwards compatibility, like we have in WordPress, it's easy to get back into a corner when intentions aren't communicated or even defined. The software is used and extended in ways it wasn't meant to be, and then often difficult accommodations must be made for those use cases where progress is otherwise inhibited. Backwards compatibility then is not just about accommodating the past, but also deliberately considering the future. As we continue developing WordPress and build upon it, it's important that we continuously and deliberately define our intentions. Not having or communicating intent does not mean that there isn't a poor way to do something, but rather that our hands are tied when we want to declare something as being wrong. Without adduping it right, there is no real doing it wrong. There's only gradients of acceptable. Be intentional. This was a phrase to my graduate school piano professor frequently said to everybody who played for her. These lessons I learned as a musician that continue to apply to me today as a lead developer for WordPress and not a pianist anymore were the subject of my talk at Workamp San Francisco last year. This particular lesson is something I've been thinking a lot about this past year in relation to how we develop software, not just WordPress core, but plugins and themes as well. How much better our software can and will be when we make sure to have the background information needed to be able to declare our intentions for UIs and APIs. Let's bring some focus to intent in our software design and create better user experiences as well as better experiences for current and future developers. Thank you. So there's plenty of time for questions, which is more or less deliberate. And you can ask about anything, I think, not just the contents of this talk. There's a microphone in the middle so you can walk up to it. Thank you. I'm really interested in what you talked about sort of optional fields and not having them show unless they're actually relevant to the user. I'm curious if you can share some strategies for how you can accomplish that. For example, getting rid of the URL field in the comments thing, what are the alternatives to having that show there by default? So alternatives for field placement and display. So in the case of comments in 4.4, what we've done is put the comment field at the top, which makes sense in a lot of ways and move the rest of the fields below. And I think that puts then the website one at the very bottom. So you go comment, name, email, all three of which are required and then a website which is not required. So that helps, it just sort of deprioritizes it rather than removing it completely because it is a thing that a lot of people use day to day. Sometimes you just have to remove it. Every once in a while there is a case to be made for having something like advanced options. I like to think that those would be rare. It's probably not true in practice, but that is also a thing that can be done. But I really do think that a lot of it is about logical grouping and prioritization of fields as they appear on a screen. I didn't really understand the part that you were talking about the deprecation of the title field and why that wasn't useful for people like screen readers because those are the impression that was read out by screen readers and could be used as context like the name of the site to which the link is going and the statement opens in a new window so that they know a new window is gonna open. Okay, so there is a good post, a really good post out there about how title tags are considered harmful. If you've read a million of those considered harmful blood posts. So title tags do a lot of things, both visually and with screen readers. A lot of screen readers now ignore them, especially because so many places out there use them for redundant information. So sometimes they're not read out either by default or people have them turned off in their screen readers. So it's no longer useful information there. And also if it's useful information, it should probably be shown somehow on the page rather than hidden behind something like that. Visually it displays as a tool tip which can be very confusing visually and distracting, especially for people who have problems visually processing information. And it also requires the use of hover. You don't get title text on touch devices. So in this world where we really need to be considering that title attributes are not a thing that we should be using basically at all. My question's more about something that you kind of touched on, the Fields API. I know, I think Scott Kingsley Clark's been working on that. What exactly is that? Is that so that plugin developers can better create their plugins or is that for people like us to create our own fields through core? So a Fields API. For reference, Scott Kingsley Clark is a co-worker of mine at TenUp and I also oversee the Fields API project as a core developer. The Fields API project, when you have something that is about entering content and saving it, inherently almost everything is a form field. So if you think about what a Fields API encompasses, it is essentially everything in the WordPress admin. So that means creating an API that we can use in WordPress and this will help things like, let's take the user profile screen as a prime example and it's the current first MVPE priority for the Fields API as a plugin. The user profile screen has a limited number of hooks for you to do custom things with. Sometimes you need to put something in a place that doesn't have a hook in order for it to logically make sense. It's hard to remove things, like actually remove them rather than just hiding them in CSS or punching in with JavaScript and removing them that way. So something like a unified Fields API would provide also a unified interface for you to add or subtract custom things from a core interface. And it also is something that, meta box libraries can build upon. I think it doesn't really replace them so much as provide them a unified base to build from. And a huge part of this also is creating the UI components that go with it. It's not just an API on the PHP side but it is also the visual components that go along with it so making sure that we have defined this is what all of these inputs look like and how they should behave and this is what they look like in these different contexts. So this is what this input looks like on a settings page and this is what this input looks like in a meta box. Those are two different contexts and they may need to look or behave a little differently based on that. So that's also a huge component of it. So this is, I think, pretty clearly an enormous project but I think it makes a big difference for WordPress. And I think to maybe be a little proactive and address something that I think has been on a lot of minds. By taking this approach where things are thought of as discrete components, we make our future safer for ourselves. If we look at something like how we might build WordPress in JavaScript or how we have things that are already built in JavaScript it's really important then that the output of a fields API not just be about an HTML page but also about JavaScript, templating, all of that kind of stuff. Don't worry, there won't be any standup here. You've poked at tooltips a bit. My particular question is about tooltips on settings pages because there does come that time when you might have to describe a setting a bit. What are your thoughts on tooltips? Should they be used? And if so, what would you, it's might be kind of a trick one but what are your thoughts on the design of them so that it's not well confusing to people because that's not the whole point of this talk is to make it as easy as possible for folks. Thank you. Sure, so tooltips as help I think is the center of that question. The most generalized thought process is that if you need to provide extra inline help there's something lacking in your interface to begin with. That's not to say that sometimes you don't need extra text but that you should be thinking about how you could maybe change that interface so that you don't need that extra text or that extra context rather than looking to add that context first. I think that I personally prefer having things inline. So we have this in core where you have a description class that you can add to a span or a paragraph or whatever that can show beneath or next to a field if you need clarification. And there are other methods out there but tooltips themselves are they're inherently hidden. They require a user to break the flow of what they're doing to take a look at them. They can interfere with something like keyboard navigation where it creates an extra stop that maybe is unnecessary for people and maybe isn't visually noticeable so you're tabbing through a form and you're wondering like why can't I get to this next input? And also again like on touch devices is just a terrible experience generally speaking. So there's just a lot of things about that that are very tempting for us to do because it allows us to provide this extra context that users seem to need. But instead I think we need to take it back to the point where we're thinking about why it is that they need that in the first place and what can we do to address that? Anything else? Hey, Alan. You and I have worked on a few projects together and I really appreciated that because I'm a real backend developer and that's what I'm more familiar with but we really communicated well together and we really achieved the goals. Could you give some basic advice at top three maybe for designers and backend developers to better cooperate? Wow, that's like a talk in itself I think. Is that inter-cooperation. So for background, I don't think of myself as being a designer first. I definitely operate as one in a lot of ways especially around interfaces and experience not graphically or visually. But I was a PHP at my SQL applications developer before I found WordPress. So that was my past and you know that because we've also worked on unkind things in list tables. So for designers and developers I think it's really important first and foremost to have at least some level of knowledge of what the other person does. That's why I think reading a book like the design of everyday things is critical for people who write code and don't think of themselves as designers but you are designing, you're designing your code and the intentions of your code. So I think that's really important is to understand that there are these basic aspects of this other thing and seeing that there are a lot of places where that actually interrelates and makes you more alike than you might think that you are. Besides that, I think there's a lot to be said also for being respectful of somebody and not saying that design is just the fancy pretty stuff or that coders are a bunch of insert whatever developer stereotype you want here. I think there really is a lot to be said for respect and I think that in WordPress we have come to do a much better job of that. I think generally it's always been very good but I think that there's been a lot of movement in terms of how we communicate and how deliberate we are and how we communicate that has made that relationship a lot better. That's only two things but I can't come up with a third. Thank you. I think that means you get an extended break, so thank you.