Do shortcodes spell the end for widgets?

Impatient readers need only read the summary.

SUMMARY of the CHALLENGE
If WP came bundled with a core of shortcodes, including column divs, and all widgets were implemented as shortcodes, any user could design any post or page in any format they desired. Therefore the idea of specific areas of the page that are ‘widegtized’ would go away, freeing WP users to design their websites in even more creative ways.

EXAMPLE: Using a theme with a full width page template (why are there any themes without one?) and a few plugins already available, I can design any post or page with say, a featured slider, a text introduction area, any number of recent posts filtered by tag or category (which is really just the core blog loop on steroids), and a footer with various common attributes I wish to display for each page. All this without knowing any html or css, which I submit should be the WP goal. Remember, we are dealing with 10s of millions of users now.

Envision though, the amount of work an end user must go through to get this done. She must spend days getting to know WP, then days more perusing themes and plugins, or spend dollars to acquire it if she knows what she wants. Even freezing a post on the top of the blog is a difficult thing to do for a novice. And the plugin repository interface alone will stand in her way (no categories or tags to facilitate search, only one rating to gauge quality and popularity, etc.).

SOLUTION
To accomplish what WP can already do, the opportunity is to redesign its interfaces and back-end so this functionality is easily available to novice users out of the box!

Following is a proposal to make the interfaces simpler to use, faster to load, and more powerful all at the same time. It would allow unique page layouts and ‘sidebars’ on every page and post (if desired) while increasing WP speed. I suggest this is absolutely doable using modular programming techniques.

The simple LIFO blogging format would then act as the default template for novice users who only wish to get started. It would then act as a teaching example to learn ones way around what has become a delightful but mind boggling (especially for the novice) cornucopia of choices on how to set up a WP website. In fact, several templates could be included so users could wrap their heads around the idea of categories, tags, ‘plugin’ capabilities, etc.

What are the modules I am talking about? Well, there is a title, description, metadata, content, SEO, text resizing, social sharing, printing, cache, backup and restore, menus, etc. These are components that all ‘themes’ should have, but many do not. Why not? And with the advent of the shortcode API, the potential to insert default WP functionality or plugin code snippets into any part of the header, content or footer is very real.

OBJECTIONS
A popular objection to this approach may be that I am suggesting WP become Blogger. Respectfully, that is foundationally untrue. First, the functionality of WP and its community make that not true.

More foundationally, WP inherently allows engineers to crawl under its hood in ways Blogger does not allow. I am not suggesting that would end. I am suggesting ways to more clearly and securely facilitate that creativity while simplifying the user interface at the same time.

The goal of the suggestion is to provide a powerful platform that leaves Blogger even further behind (as it already does); it is just complicated to get there right now. In the end, it is possible to have clarity and complexity at the same time. As the author said, “Sorry for writing a long letter. I didn’t have time to write a short one.”

Another objection may be that the proposed design would provide less freedom or less work for designers. This is also untrue. Great design is always in vogue, as is great programming. If anything, a more robust design will free both up to do what they do best with greater productivity. After all, we are talking about an interface and engine limited only by imagination as opposed to the Blogger interface, which is inherently structurally confined, as are Google sites.

At its most basic, the Blogger objection is moot. Since this functionality is already available as shown in the example above, designers will either provide it on top of the WP engine (with all the inefficiency that implies), or WP can design that functionality into its interface and provide the leaps in usability that implies.

And yes, I realize there are frameworks, themes and plugins that already mimic some of the functionality I propose. Many of them slow WP down because they are built on top of, instead of inside WP. But they are the forefront of WP, and I submit that the shortcode API hastens the day when WP embraces the concept in its core design. The following common frustrations voiced by engineers and users are clues that that day is arguably already here.

DETAILED PROPOSAL
As of today, the 3-6 plugins that allow such freedom from WP’s preconceived framework restraints are inserted via shortcodes (including a plugin that allows widgets in posts) that are implemented within existing php templates. IOW, since the code is not modular, a certain amount of code running in WP for any given post or page is unneeded code bloat. That is why plugins inevitably slow WP down. It is loading code and javascript on pages it does not need to.

MODULAR EXAMPLE: The Query Postsplugin (Isn’t everyone a huge Justin Tadlock fan?) could be a shortcode / drag and drop module in the WP post screen that becomes part of its own HTML template as the user designs it. There should be NO CORE WP LOOP. It is a ‘plugin’ that should only be called if the page needs it.

First, the input screen.
It is both too clumsy and and too restrictive. Why not provide modularized access to its functionality on a design screen (yes, like Blogger)? ‘Plug-ins,’ would be added to default WP functionality in the appropriate module. Very creative plugins would engender a whole new module, or remain in a ‘miscellaneous’ module until an appropriate one is provided (The idea of a sidebar could technically go away). It is the design screen where most ‘plugins’ should be doing their work.

Some engineers, like the author of the DynamiX theme on Themeforest, have made shortcode generators part of their themes. WP is hurtling towards this reorientation of the input screen because of shortcodes, and it will be common practice soon. The WP team can be out in front of it. Other designers have produced frameworks like Pagelines and Headway to accomplish a version of this idea.

Why not set up a design screen to encourage it? Users would then drag and drop their choices of either the WP components or authored ‘plugins’ into the area of the page or post they wish. Those saved design screens would then become post / page templates, chosen on the edit screens or defaulted according to current WP template hierarchy.

Plugins should not be fighting with template code, they should be using WP functionality to provide modular code snippets to write it.

Plugins.
Plugins already represent a thorny rose for users. Regardless of whether the WP interface is redesigned or not, plugins are out of control. Their number alone is unmanageable without some maintenance at www.remarpro.com. Suggestions:

• Outdated plugins should be retired.
• There must be a designated, acceptable method of interfacing with WP for plugin development. Plugins that conform to these rules should be tagged. Others, good or bad are inherently more risky.
• Rate plugin authors for overall quality in addition to rating plugins. It would aid in choosing plugins.
• A tag for plugins that completely uninstall. This is a huge issue, especially for users who like to experiment, and a major source of WP speed and bug issues over time. BTW, WP must develop maintenance capability to deal with this.
• Categorization of plugins. See above.

Images and other Media
Perhaps WP’s biggest weakness is the way it handles images and other media. The latest version of thumbnail integration is a testament to the ongoing attempt to address these text ‘attachments.’ I submit the approach is incorrect.

Let me illustrate. I can change the default body text across my whole website in 2 minutes. Why not images, which I must size individually? Please do not confuse having to store different versions with end user design. Further, generating versions (e.g., thumbnails) of the image should be a batch exercise if I choose, to avoid continual manipulation of the original image, which significantly slows down page delivery.

IOW, WP treats images and video much differently than text. Why? It is an identifiable entity, just like body text. Please allow me to treat it as such so that changing themes does not break my website. And do not force me to host the original image or video on my server to do it.

SUMMARY
Due to its community, WP is evolving in incredible and breath taking ways. Is it the right time to envision the next foundational iteration? Some designers are already instituting these ideas into their themes. Doing so in the WP interface would further leverage the size and creativity of its community, which is its largest strength. A migration plan would need to be designed, but I believe it poses less of a problem than first envisioned.

Finally, I would like to take the opportunity to thank the WP community and the Automattic team. I want to humbly thank you for the incredible environment you have all created.

Signed,
A huge fan of WP and the idea of emergence:)