Smart defaults + no-JS

[helen]

The base bug that is prompting this development is that enormous dropdowns have performance issues, both in PHP (looping through all the items to build the output) and in the browser (attempting to render all those items). One or the other can crash, leaving the user stuck until they install a plugin or add some code that removes that dropdown entirely, not just hidden in screen options.

If we think of our no-JS philosophy as "don't leave the user stranded", we need to limit the dropdown anyway. A limited set is better than no set to choose from. This can be a fairly high limit, so we're not potentially limiting someone unless truly necessary. We should also be smart about which items are prioritized for inclusion - e.g. most recently edited pages, users with the most posts, or users most recently published.

I also feel that the use of a smart initial set (that is, populated in PHP) will create a better experience even when a JS helper library is in use - for new users, it will teach them what the UI is used to select and show some examples, and for experienced users it can be faster than always having to search.

[ericandrewlewis]

I don't understand our no-js approach, and would like to revisit our philosophy towards it. Let's define it and place it in the core handbook in the appropriate place.

Javascript is a fundamental part of the internet browsing experience, especially so for a content management system's user interface. We will invariably be developing features in the future that rely heavily on Javascript.

According to generic statistics, ~1% of users don't hit Javascript. WordPress' philosophy that we should provide "features that 80% or more of end users will use." If no-js is considered an end-user feature, we are supporting it for a small minority.

I personally do not see a reason to support no-js in the admin, and would love to hear everyone's opinion about this.

[boonebgorges]

I don't understand our no-js approach, and would like to revisit our philosophy towards it. Let's define it and place it in the core handbook in the appropriate place.

I agree strongly with this. We should be as explicit as possible.

As for the specifics of the philosophy, here are a couple of starting points that I personally find reasonable, and in keeping with what I take to be the recent unspoken ethos:

• We take all possible steps to maintain no-js support for existing functionality.
• We take all possible steps to maintain no-js support for functionality that is central to the WordPress user experience. It's one thing not to have a no-JS fallback for image editing. It's another thing to have no way to create and edit posts.
• For new features, we take reasonable steps to support no-js. That said, the growing importance of JS makes impossible to build modern interfaces without relying on JS.
• In cases where no-js is not supported, we strive to degrade gracefully, so that one non-functional feature does not break everything.

According to generic statistics, ~1% of users don't hit Javascript. Given WordPress' philosophy that we should provide "features that 80% or more of end users will use." If no-js is considered an end-user feature, we are supporting it for a small minority.

I see no-js as of a piece with (and in some cases overlapping with) accessibility concerns. Yes, it's a small majority of users. But I'd wager that few of them are tinfoil-hat h4x0rz who disable JS voluntarily. Most are using old browsers that they don't have the means to update, are subject to draconian IT policies, whatever.

[helen]

My thoughts about no-JS actually have almost nothing to do with accessibility concerns or people who have made the choice to disable JS - it is far more about what we do when JS gets broken on a page, whether through an error or a blocked load, which we have to face is often, and may become even more often as we and plugin and theme authors rely on it more and more. It's our old progressive enhancement argument all over again - here are two posts I've read in the past that provoked more thought on my part:

• http://jakearchibald.com/2013/progressive-enhancement-still-important/
• http://thatemil.com/blog/2013/07/02/progressive-enhancement-still-not-dead/

Practical examples in core:

• The customizer does not bother with a no-JS solution. Everything that can be done in the customizer can also be done elsewhere.
• The themes management screen does jump through hoops for no-JS, because a theme can break your JS. If JS were to be broken by a theme and we didn't implement a no-JS fallback, you would be stuck, short of getting in via FTP. That is not acceptable degradation of a UI.

Frankly, in this instance, I see no-JS as a convenient byproduct of something I think we should be doing either way - since there is an underlying select element, why not go ahead and populate it with likely items, since it provides so many benefits? While I agree that we should lay out what our thoughts are on no-JS overall for core (even if I think it's all of "don't trap the user, and we consider it on a case-by-case basis"), I don't think that's a blocker for development here.

[boonebgorges]

While I agree that we should lay out what our thoughts are on no-JS overall for core (even if I think it's all of "don't trap the user, and we consider it on a case-by-case basis"), I don't think that's a blocker for development here.

Yeah. It strikes me that here we have a feature that's not currently working anyway for very large sites - JS or no - building a new version of it that depends on JS (and maybe fixing the no-js solution so at least it doesn't crash your site by setting a hard limit on user count in the dropdown) seems like a win all around.

[markjaquith]

I personally do not see a reason to support no-js in the admin, and would love to hear everyone's opinion about this.

Some small part of this is accessibility, for people using non-JS browsers for accessibility reasons. Thus I think some core portions of our UI should be workable without JS. You should be able to publish on the web without JavaScript.

But in my mind, the line on that has been moving, because we're evolving past the original idea of JS as "progressive enhancement" and realizing JS-powered UIs that are their own beast — not an enhancement of a static page-based paradigm. Users are expecting these types of interactive UIs. People increasingly use apps to interact with the web, and our web apps need to step up their game or they're going to feel stale and slow and "dead".

That said, I also agree that the idea of progressive enhancement isn't completely dead. Remember when Twitter used hash URLs and a JS error on their site meant that no tweets would load? There are gremlins here. So maybe progressive enhancement just shifts from being small enhancements to a completely functional UI to big enhancements to a marginally functional UI. A UI that isn't a complete dead-end when JS goes wrong.

Codifying that is going to be difficult. We might need more experience with it first. But for the feature being discussed here, the current approach feels right. We're talking about an edge use case of WordPress (tons of authors) for a minor utility (reassigning the author). It's not tragic if this fails. Maybe that's our guide. Thinking through 1. how catastrophic it would be if the JS failed and 2. how the user might recover (for instance, deactivating the plugin causing the issue).

[helen]

So maybe progressive enhancement just shifts from being small enhancements to a completely functional UI to big enhancements to a marginally functional UI. A UI that isn't a complete dead-end when JS goes wrong.

:+1:

[leocaseiro]

Solution suggestions for non-js users:

The non-js scenario to develop a UI is not easy and I've been thinking in a good solution for the dropdown autocomplete for a few days. Most of my ideas always had been using JS. It is a tough one.

I don't want to start any discussion here, but is a good point remember that non-js users are not able to add feature Images. Even though is not the case here and the feature images are not able by default in new themes, I believe a good percentage of WordPress sites use this feature. Yeah, I know that images are optional and users are not...

I'm not 100% satisfied with those suggestions, but perhaps can be a good start. I hope you guys can improve those ideas.

1) INPUT TEXT when over 100 items (suggestion)

A possible solution for non-js could be the same used for tags.

Currently, to add tags, WordPress admin uses an autocomplete function. For non-js users, only the input-text appears. Depending on the value between comma, a tag is added or the value refers an existing tag.

A simple input text with a server-side validation could be a solution in this case. The WP would suppose the user knows the email/login/name of the author/page writing in a input text.

The server-side validation could suggest a list of authors in a select list(similar autocomplete result) if the value typed wouldn't exist on database.

2) SELECT + INPUT-TEXT when over 100 items (suggestion)

By default a select with few users (the limited could by a constant easily changed harcode). The algoritm could show the most-used users or something similar.

In this case, an extra input-text could replace the select if filled. So the user could write the email/login/name of the author/page if not listed on select.

The validation should prefer the input text filled, otherwise the select itself.

[ericandrewlewis]

Nacin also mentioned "Core updating and something (like an external lib or a major JS core change) breaking a plugin or theme is a very high possibility."

Coming around to agreeing with you all on this, good points here. Let's table the larger discussion and focus on the no-js execution.

The option of offering a limited set of users who can author a post reads to me as progressive enhancement, although also ungraceful degradation. If the author I want to assign the post to isn't in the limited result, then the feature is broken and would feel like a bug. Do we want offer users potentially half-working features?

[ericandrewlewis]

Helen said:

the use of a smart initial set (that is, populated in PHP) will create a better experience even when a JS helper library is in use - for new users, it will teach them what the UI is used to select and show some examples, and for experienced users it can be faster than always having to search.

Out-of-the-box, Select2 doesn't allow the mix of smart defaults and AJAX querying. Not impossible, but we'd need to dig in.

Smart defaults would also muddle UX/DX (developer experience) when using wp_dropdown_users( array( 'orderby' => 'name' ) ); as the first set of results wouldn't conform to that option.

[helen]

Not being able to mix smart defaults + Ajax in a sane way is a distinct possibility, for what it's worth. It can also be a further enhancement. I think I'd only want to do it for specific core places, anyway, not for any use of the function.

If we think of a no-JS fallback in this instance as being "barely functional", does a plain text input that takes an ID number count? I think it's a terrible experience (see: how lame the page order input feels), but given that this is a double edge case of large install plus no-JS and the alternative is content edit or import/export screens that never actually load at all, perhaps it is acceptable?

[ericandrewlewis]

We're between a rock and a hard place here. This issue will be seen anywhere a list breaks at scale which is essential to publishing workflow - thinking category metabox.

I don't think there's a great solution, but a limited <select> with the most popular authors is probably the lesser of degradations. I agree a plain input box, while fully functional, is rough UX. Hopefully a limited dropdown would work for 99.9% of users that ever get this experience, and can be considered a marginally functional UI, doesn't leave the user stranded. Perhaps we can introduce a nag for <noscript> users to warn them that they're not gonna have a good time.