Building WordPress Plugins in Context  ## Metadata - Author: [[Matt Cohen]] - Full Title: Building WordPress Plugins in Context - Category: #articles - Document Note: # Title: Considering Context and the Whole When Building WordPress Plugins - - - tags: #WordPress #plugin-development #user-experience #integration Author: Unknown Source: N/A Reference: N/A date created: 2022-09-15T09:00 - - - ## Table of Contents: N/A ## Index Creation: N/A ## 📝 Summary: The main takeaways from this article are the importance of considering the context in which a WordPress plugin will be used, integrating it seamlessly into the existing structure, and prioritizing user experience and benefit. The author emphasizes that a plugin should feel like a natural part of WordPress, and its features should align with existing patterns and conventions. The article also highlights the value of using WordPress UI components and UX patterns when designing plugin interfaces. ## 📖 Main Content: The author shares their experience and insights in building and reviewing WordPress plugins, emphasizing the need to prioritize the user's needs and aligning the plugin with the existing WordPress ecosystem. They highlight the importance of user experience and benefit, suggesting that if a plugin doesn't serve its core users well, it may need to be reevaluated, regardless of its code quality. The author references Donald A. Norman's principles of design to support their argument for considering both the user's knowledge and the design's constraints. The article provides practical examples of how to integrate a plugin into WordPress, such as fitting it neatly alongside other plugins and using existing code and APIs as defaults. The author suggests paying attention to the naming conventions of admin menus, screens, and taxonomy terms, following established patterns used within WordPress. They also recommend using familiar UI components and UX patterns from WordPress itself and other plugins as inspiration. The author emphasizes the importance of minimizing unnecessary CSS and JavaScript to reduce page load time, potential bugs, and user interface discrepancies. They also mention the upcoming redesign of WordPress and suggest that following existing UI and UX conventions will make it easier to adapt plugins to the new design when it is released. ### 🗒️ Notes - Consider the context in which a WordPress plugin will be used. - Integrate the plugin seamlessly into the existing structure of WordPress. - Prioritize user experience and benefit. - Plugins should align with existing patterns and conventions within WordPress. - Use existing code and APIs as defaults. - Pay attention to naming conventions for admin menus, screens, and taxonomy terms. - Utilize familiar UI components and UX patterns found in WordPress and other plugins. - Minimize unnecessary CSS and JavaScript to improve page load time and reduce bugs. - Be prepared to adapt plugins to the upcoming redesign of WordPress. ## 📖 References: N/A ## 🗣️ Paraphrase: "When building WordPress plugins, it is crucial to consider the parts as part of the whole. A plugin should feel like an integral part of WordPress, fitting seamlessly into the existing structures. User experience should be a priority, ensuring that the plugin meets the needs of its core users. If a plugin fails to benefit its users, even if the code is elegant, it may need to be revisited. Donald A. Norman's design principles highlight the importance of combining both external and internal knowledge and simplifying task structures. Existing WordPress UI components and UX patterns should be leveraged to avoid unnecessary customization. By following established naming conventions and integrating smoothly into admin menus and screens, plugins can achieve a seamless integration into WordPress. Minimizing the use of additional CSS and JavaScript is crucial for optimizing performance. Lastly, it is important to consider the upcoming WordPress redesign and the potential for future adaptation." ## 🧪 Hypotheses: - Hypothesis 1: Plugins that align with existing WordPress UI conventions will have higher user acceptance and adoption rates. - Hypothesis 2: Minimizing unnecessary CSS and JavaScript will result in faster page load times and improved user experience. - Hypothesis 3: Adapting plugins to the upcoming WordPress redesign will be easier for plugins that follow existing UI and UX conventions. ### 📊 Methodology: - Test Hypothesis 1 by conducting user surveys and analyzing plugin adoption rates. - Measure the page load times of plugins with and without unnecessary CSS and JavaScript to test Hypothesis 2. - Monitor the process of adapting plugins to the WordPress redesign and compare the effort required for plugins that follow existing conventions versus those that do not to test Hypothesis 3. ### 💡 Implications: The future research based on the current findings could advance the field of WordPress plugin development by providing evidence-based guidelines for maximizing user acceptance and integration. This research could also influence industry practices by promoting the importance of considering user experience and context when building plugins. The implications for policy include the potential for improved website performance and user satisfaction, leading to better overall digital experiences. ### 🔮 Future Research: - Investigate the impact of plugin integration on website performance and user satisfaction. - Explore the relationship between adherence to WordPress UI conventions and plugin adoption rates. - Conduct usability studies to identify areas for improvement in existing UI components and UX patterns. - Examine the challenges and opportunities of adapting plugins to the upcoming WordPress redesign. ### ❓ Implications: The potential implications of future research in this field include gaining a deeper understanding of user preferences and needs when it comes to WordPress plugins. This knowledge can inform the development of plugins that better meet user expectations and ultimately improve the overall user experience. Additionally, future research can shed light on the effectiveness of specific design principles and conventions in driving user acceptance and adoption of plugins. This information can guide developers in making informed design decisions and contribute to the advancement of the field. ### ✅ Logical validity: The main arguments presented in the article highlight the importance of considering the context and integration of WordPress plugins to ensure a seamless user experience. The author supports their points with practical examples and references to design principles from Donald A. Norman. The logical coherence of the arguments is sound, and no logical fallacies are evident in the article. The tone of the article is informative and reflective, providing insights based on the author's experience in building and reviewing WordPress plugins. ## Conclusion: In conclusion, when building WordPress plugins, it is crucial to consider the context, integrate seamlessly with the existing structure, and prioritize user experience. Plugins should align with established patterns and conventions within WordPress, utilizing existing code and APIs as defaults. Paying attention to naming conventions, utilizing familiar UI components and UX patterns, and minimizing unnecessary CSS and JavaScript are all key factors in building successful plugins. Additionally, being mindful of the upcoming WordPress redesign and its implications for plugin adaptation is essential. By following these principles, developers can create plugins that feel like an integral part of WordPress and provide a seamless user experience. - Summary: When building WordPress plugins, it is important to consider the context in which the product will fit. The plugin should feel like a natural part of WordPress and should integrate seamlessly with existing admin menus and screens. Pay attention to naming conventions and use existing code and APIs as defaults. By following these principles, plugins can execute their core idea with elegance and attention to detail. Additionally, building with the future of WordPress in mind can save time and effort when updates are required to fit into the redesigned platform. - URL: https://matty.blog/building-context-into-wordpress-plugins/  One particular recurring theme comes up for me regularly when building products -in particular WordPress plugins- is to consider the parts as part of the whole. Consider the context your product fits into. This one concept is critical to building successful products. I apply these concepts when building and reviewing WordPress plugins. To my mind, a WordPress plugin should feel like part of WordPress. This guiding principle has helped to inform how I consider decisions when building and reviewing WordPress plugins. #### User experience and benefit Your product should best suit it’s user’s needs, fitting into the existing structures as a default, and slightly bending those structures only when the benefit to the user is greater than the constraint offered by the context the product fits into. Admin menus in WordPress is a great example of this, which we’ll discuss further a few paragraphs ahead. If your product isn’t benefiting it’s core set of users, take it back to the drawing board, even if the code is elegant and beautiful. Donald A. Norman captures this well in his principles of design: > “Principles of design: > 1. Use both knowledge in the world and knowledge in the head. > 2. Simplify the structure of tasks. > 3. Make things visible: bridge gulfs between Execution and Evaluation. > 4. Get the mappings right. > 5. Exploit the power of constraints. > 6. Design for error. > 7. When all else fails, standardize.” > > ― Donald A. Norman, [The Design of Everyday Things](https://www.goodreads.com/work/quotes/18518) #### In practice I spend most of my day inside WordPress. I’ve spent most of my day inside WordPress since around 2007 (at the time of writing, 16 years and counting). I’ve reviewed hundreds of WordPress plugins, from features through to code and execution of the core idea of the plugin. I regularly apply these learnings to [a starter plugin project](https://github.com/mattyza/starter-plugin/) (patches welcome) I’ve been iterating on for several years. WordPress is very empowering and forgiving. One can build almost anything inside a WordPress plugin, and WordPress itself will receive that code with open arms. There is, however, a certain elegance which sets certain plugins apart from the thousands of plugins available today. Plugins which execute well on their core idea, with elegance and attention to detail. There are several unspoken details within WordPress which I’d like to highlight here as examples. #### Integration into admin menus When your plugin is installed, it should feel like part of WordPress that has always been there. It should fit neatly in alongside other plugins and alongside WordPress itself. Pay attention to the way admin menus and existing screens within WordPress are named. Pay attention to the patterns and conventions used. Use existing code and APIs as a default. For example, the “Posts” menu used to include an “Add New” menu. This menu is now called “Add New Post”. If your plugin has an “Add New” menu, change it to read “Add New [thing]” where [thing] is your content object being added. A post type menu which feels as part of the WordPress whole If your post type is hierarchical, place is below the “Posts” menu. If it sits as part of an entirely different function of your site (ecommerce, for example), consider placing the navigation menu alongside your other ecommerce menus, and adding separators above and below the group to denote a switch in context from “site” to “store”. WooCommerce admin menus in WordPress, grouped to indicate a context switch to “store” #### Naming of taxonomy terms and their admin menus It’s common to want to add categories, tags, or other taxonomies to your post types. There’s no need to set the admin menu text to be “[thing] Categories”. It’s already inside a menu called “[things]”. When naming the slug of the taxonomy itself, also keep the convention in line with WordPress. `[thing]-category` and `[thing]-tag` are fine. Note also that the slug is singular, rather than plural, in line with how WordPress names slugs for core taxonomies. #### Settings screens and headings There is no need to mention anything other than the purpose of the screen as a screen heading. “Special Settings for WooCommerce” can simply be “Special Settings”, if the screen is placed in the correct context. It’s also totally okay to place your screens in the most logical place within the admin menu. If your screen is for settings, give it an appropriate name and place it as a sub-menu under “Settings”. For tools, place the screen under “Tools”. This approach helps your plugin to feel directly integrated into WordPress, rather than a separate tool added on top of WordPress. A settings screen, integrated into the “Settings” menu WordPress provides easily used UI and UX flows which can be used in your own plugin code as well. Rather than re-inventing the user interface, use the pieces which already exist, especially if your admin screen is for settings, like many other screens are. If your screen is for something other than settings or adding a content type (as shown above), use WordPress UI components and UX patterns. Browse similar screens in WordPress itself and in other plugins to draw inspiration. A plugin’s WordPress settings screen, using a familiar WordPress settings interface Every piece of extra CSS or JavaScript increases the page load time for your users, and increases the opportunity for bugs and user interface discrepancies to creep in and interfere with the user experience. In the above screenshot, you see two settings tabs. When switching tabs, the page reloads. This is totally okay, as it is the same behavior as across most legacy settings screens. If you visit “Settings > Reading” and click “Save Changes”, the page reloads. #### Building with the future of WordPress WordPress is embarking on a full redesign. While there will no doubt be updates required for plugins to fit into this revised design, consider how much of the legwork is already done when a plugin follows the existing UI and UX conventions within WordPress today. The new components are made available via NPM packages, and can be reliably called upon within WordPress settings screens. Going from a completely custom screen into the new design will be a much larger task than moving from the existing design to the new design. For users of the product, there will also be less of a switching overhead involved, as the screens will all have continuity. There is of course a lot more which can be said about how to build sustainability into WordPress plugin development. What else have you observed when building WordPress plugins with the context and the future in mind? Please share your thoughts in the comments section, and lets discuss., Building WordPress Plugins in Context, Matt Cohen, 01hg6fwb512yqg0kvkzr4spmjr.