Bernhard Kau 10:43 pm on March 23, 2017
Tags: feature-request ( 5 ), WordCamps ( 241 )

Improvements to the attendees shortcode

With large WordCamps like WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe and WordCamp US, the current implementation of the attendees shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. becomes a problem. Showing more than 2000 attendees on a single page is not only bad for performance, but also for UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. (like scrolling such a long page on a mobile and loading all the attendees including images).

Current performance optimizations

The current implementation of the shortcode has some tricks to increase the performance. For longer attendees lists, they are loaded in batches of 200. The generated HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. of all attendees is cached in a transient for 1 hour (24 hours after the WordCamp).

To help with the attendees GravatarGravatar Is an acronym for Globally Recognized Avatar. It is the avatar system managed by WordPress.com, and used within the WordPress software. https://gravatar.com/. images, a lazy loading mechanism was implemented. This is very useful not only on desktop, but also helps on mobile saving bandwidth.

Improvements with the new shortcode

For the new default theme the WordCamp Europe team is working on, “CampSite 2017”, we first thought about implementing an archive page for the attendees page. But this would be inflexible and it would also only help the new default theme. The current shortcode also offers some attributes to show content gathered from attendees through additional questions. This would not be as easy with an archive page template. So we instead are trying to improve the shortcode.
Adding pagination to the shortcode
Although the current shortcode has an posts_per_page attribute, this does not add a pagination to the shortcode, but only reduces the number of visible attendees. So that doesn’t help. But we changed this attribute to enable pagination links, if present:

Attendees list with pagination links

The pagination use function paginate_link with accessible links.

Adding a search for attendees

One benefit of having all attendees on a single page is an easy search for them using the browser search. On a paginated page, a search makes it also easy to search for friends and colleagues on the attendees list. Adding the search field can be done with the new with_search attribute set to true:

The search result is also paginated with the same number of attendees per page.

Keeping backward compatibility

As changing the shortcode will affect any WordCamp site, we implemented the new features in a way, that they are only active, if the attributes posts_per_page and/or with_search are set. We also kept the image lazy loading and we still cache the resulting HTML (per page/search) in a transient.

Feedback

For the upcoming WordCamp Europe (June), we would really like to see this new feature available as soon as possible. Please feel free to give us your feedback on the new functionality so we can move forward.

#wordcamps #feature-request

Ulrich 6:36 am on March 24, 2017

I think these are two good steps.

The problem with numbered pagination is that you don’t know where a certain letter starts. It would be interesting to see if the names could be grouped by letters.
- Bernhard Kau 9:47 am on March 24, 2017
  
  I first thought about that, too. But grouping by letter is not as easily integratable in the current implementation.
  
  But that’s also why we tought about adding a search, so you can still find friends and colleagues easily in the list.
- Samuel Sidler 3:33 pm on April 21, 2017
  
  Grouping by letter can also be non-ideal for non-Latin-based languages.
Corey McKrill 8:52 pm on March 24, 2017

Here’s a MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket with similar ideas to what you’re proposing:

https://meta.trac.wordpress.org/ticket/2282

The key difference is that in the ticket, all of the attendees markup would still be loaded onto one page, and the searching/filtering and pagination would be facilitated by JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/., while in this proposal, the search and pagination would (presumably) be facilitated by server-side processing of URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org query parameters.

There are pros and cons for each. I tend to lean towards the JavaScript solution, because then you don’t have to wait for another browser request/page load before seeing different results. The basic markup for the attendees, even if there are 2 or 3 thousand, doesn’t add a lot of page weight, especially if it only needs to be loaded once.
- Bernhard Kau 8:57 am on March 27, 2017
  
  Cool! I didn’t know that there was already a ticket for that. Have you tried to wrote a patch for that?
  
  To be honest, I am not really a fan of the “show more – infinite scrolling” solution. A pagination makes it a lot easier to quickly jump to the end of the list.
  
  Some 2 or 3 thousand rows of HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. are not the main issue in terms of performance. It’s the rendering a browser has to do. For WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe we played around with some nice CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. styling for the page and even on some powerful notebook, the page became very slow with the full list.
- Ian Dunn 9:29 pm on March 28, 2017
  I think we need to understand the different use cases for the Attendees page first. Without knowing that, it’s we’ll just be guessing at what tools will help visitors the most.
  
  Here are the ones I can think of, and what I think would help the most in those cases:
  - Looking any anybody they know: I would guess that this is the most common use case. It’s a hard one for any tool to solve, but I think filtering might help the most. They could narrow down the list to people from their region/country, to employees of companies they know, to people who have Gravatars (because scanning images is faster than scanning names), etc. The list could still be pretty long even after narrowing it down, though, so maybe JS-based pagination would be a useful addition?
  - Looking for a particular individual. If they know the person’s name, then I think search is going to be the fastest and give the most relevant results.
  - Looking for people who fit certain criteria (company, location, has a gravatarGravatar Is an acronym for Globally Recognized Avatar. It is the avatar system managed by WordPress.com, and used within the WordPress software. https://gravatar.com/., has twitter account, etc): filtering seems like the obvious choice here
  Am I missing any use cases? Does anyone you see any better tools for any of of the use cases?
- Ian Dunn 10:44 pm on March 28, 2017
  
  in [#2282], all of the attendees markup would still be loaded onto one page, and the searching/filtering and pagination would be facilitated by JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.,
  
  Should we still have PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. render the markup, and then have JS parse it in order to search/filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output./etc?
  
  I think it’d probably be cleaner to have PHP just output the raw data in a JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. array, and then render the markup client-side. Off the top of my head, I don’t think that’d break back-compat, but I haven’t fully thought it through.
  - Bernhard Kau 10:48 pm on March 28, 2017
    
    I would prefer that solution as well, if we decide to go with a full list filtered by JS, as it would decrease the size of the DOM a lot and boost rendering performance.
    - Corey McKrill 10:57 pm on March 28, 2017
      
      Yes! I’m all for it.
Ian Dunn 9:31 pm on March 28, 2017

we implemented the new features in a way, that they are only active, if the attributes posts_per_page and/or with_search are set.

I can’t think of any ways that a new search bar or pagination would break back-compat for older sites. Did you come across any?

If there aren’t, then I think we’d want the new features to be on for all sites.
- Bernhard Kau 10:01 pm on March 28, 2017
  
  I implemented in this way, as some WordCamps have more than one shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. on a single pate (like US with regular attendees and streaming tickets). Always having a pagination on those pages would be a problem.
  
  But other than these cases, we could implement it as a default. It would also make the code a lot smaller.
  - Ian Dunn 10:11 pm on March 28, 2017
    
    Ah, that’s a good point. It should be pretty easy to programmatically detect if there are multiple shortcodes on the page.
    
    It might be easier to just manually use a feature-flag to disable the new stuff on the older sites that have multiple shortcodes, though. I don’t think newer sites would need multiple shortcodes anymore, since we’ll be able to provide filtering by ticket type, etc.
    
    Can you link to the code you’ve written so far?
    - Bernhard Kau 10:18 pm on March 28, 2017
      
      I havent’t created a ticket, yet. But this is the change I made on our staging: https://gist.github.com/2ndkauboy/17791dceb1f4728400e196139ab4ea0a
Ian Dunn 9:40 pm on March 28, 2017

I think pagination tends to be a bad user experience. There are a lot of reasons, but in general:

Users have better experiences with scrolling than clicking. The mouse wheels, touchpads and touchscreens of today make scrolling faster and easier than clicking. To get to the next page in a pagination, the user has to find the link target, hover the mouse over it, click it and wait for the new page to load. That’s a lot of work when you break it all down. Imagine the user having to do that over and over because of short pages. To scroll, all the user has to do is flick their finger on the mouse wheel, touchpad or touchscreen. There is no wait time and new content comes to them with minimal effort. Stop making your pages so short and allow users to scroll for more content instead of clicking.

It does allow jumping to sections of the data, but that doesn’t seem very useful in this situation, because the user has to guess where to jump to. If they’re looking for Jane Doe, she could be on page 8, 9, 10, 11, etc. It also wouldn’t help at all in cases where the visitor is looking for all the Human Made employees, or everyone from Spain, etc, because they’d have to look through every single attendee.

If the pagination were done with PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php., it would add a ton of waiting time to the session. It could be done in JS to make loading fast, but the overall process would still be slow and tedious for the user.

I think it might still be a useful backup in some use cases, but I wouldn’t want to rely on it as a primary navigation mechanism.
- Bernhard Kau 10:11 pm on March 28, 2017
  
  In my opinion, a pagination has some advantages, an infinite scrolling page has not. On a paginated page, you can easily jump to the very end (like for names at the end of the alphabet). On an infinite scrolling page, you have to scroll several times to the end, wait, (maybe having the page jump a bit,) scroll again, wait again, etc. Let’s say we show 100 “per page”, than for large WordCamps like US and EU, a user has to scroll to the end 20 – 30 times, before reaching the end.
  
  And then there is a even bigger issue in terms of performance. We currently have a lazy loading in place. If a user has to scroll through the page, to trigger the infinite scroll, he basically also triggers the download of every single image. On a mobile device, this would mean that thousand of images are being loaded.
  
  Most websites with long lists have a pagination rather than an infinite scrolling mechanism. It make loading those pages faster and finding things is usually easier (even if you have to guess for the correct page once or twice).
  
  And regarding the searches. I haven’t seen a single attendees list, yet, that shows countries or companies (although possible with the “questions” parameter). So having a fulltext search on name (and maybe email and Twitter) should be enough.
  - Ian Dunn 10:30 pm on March 28, 2017
    
    In my opinion, a pagination has some advantages, an infinite scrolling page has not.
    
    I don’t like infinite scrolling either, so I’m definitely not suggesting we use it 🙂
    
    At the moment, though, filtering seems like a better solution than pagination, like discussed in #2282. Or at the very least, we might want filtering and pagination. I don’t think pagination alone is very useful on larger sites.
    
    Developers and power users might be comfortable guessing, but I don’t think the average user is. It’s also impossible to guess where to go if you’re looking for something other than names.
  - Ian Dunn 10:33 pm on March 28, 2017
    
    I haven’t seen a single attendees list, yet, that shown countries or companies (although possible with the “questions” parameter). So having a fulltext search on name (and maybe email and Twitter) should be enough.
    
    I’ve seen camps use it. We could also consider enabling some whitelisted questions by default, although that might be too complicated when we factor in privacy concerns, etc.
    
    I think the search function should check all visible fields. It shouldn’t check email, since that’s privacy and disclosing attendee’s email addresses (even partially or indirectly) would violate WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/’s privacy policy.
    
    I agree that search + pagination (or just search alone) would be enough if the only use case we were considering was the one where you’re looking for a single person and you know their name. That’s not the only use case, though.
    - Bernhard Kau 10:45 pm on March 28, 2017
      
      Sorry, I meant website, not email. Showing them (or even enabling search on them), would be indeed a bad idea. All visible fields make sense. Let me try to think of a clever solution on a filtering in them (maybe using JS which might be combined with pagination).
      - Corey McKrill 11:00 pm on March 28, 2017
        
        List.js can be configured to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output./search off of specified keys:
        
        http://listjs.com/examples/data-attributes-custom-attributes/
        
        So we could have it so that all visible data fields get keyed.
- Bernhard Kau 10:16 pm on March 28, 2017
  
  Also a good note from the post you mentioned and something I really hate with infinite scrolling pages:
  
  There are only a few instances where infinite scrolling is effective. When your content opens in a new tab or modal window, infinite scrolling is a useful technique. But if your content opens on the same page, infinite scrolling can frustrate users.
  When the user clicks to go back, they’ll lose their place and progress in the content stream and will have to scroll from the top of the page again. Opening content in a new tab or modal window allows users to keep their place and progress and continue scrolling without restarting or refreshing the page.
  - Ian Dunn 10:39 pm on March 28, 2017
    
    <aside>
    Forcing links to open in new tabs is awful UX. Instead, I think infinite scroll implementations should just use pushState() to create deep links to the pages.
    
    I think it’s even better is just avoid infinite scroll altogether, though 🙂
    </aside>
    - Bernhard Kau 10:42 pm on March 28, 2017
      
      Good to see, I am not the only one against infinite scrolling 🙂
- Corey McKrill 10:24 pm on March 28, 2017
  
  Infinite scroll definitely has downsides as well, and it was just a suggestion in the MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. ticket as a way to mitigate the length of the attendees list. I agree with @iandunn that implementing pagination via PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. is not desirable, but there are other alternatives.
  
  The JS script I mentioned in the Meta ticket, List.js, actually can do pagination as well:
  
  http://listjs.com/examples/pagination/
  
  The script has a compatible MIT license, so we could use it for both filtering/searching and for pagination. Relying on a 3rd party library has downsides as well, but since it covers so many of our use cases, I think it would be worth it.
  - Bernhard Kau 10:27 pm on March 28, 2017
    
    I’ll look implementing that solution as well and test it on our staging. But to be honset, I don’t quite understand why pagination with PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. is not desired. It’s already there and we use it one most other contents as well.
    - Ian Dunn 10:53 pm on March 28, 2017
      
      I’d recommend waiting until we come to a consensus on what tools should be used, since anything you write before that might not end up being used.
      - Bernhard Kau 8:10 am on March 29, 2017
        
        But seeing it live would probably help to find a good solution 😉