Mediacaster tackles podcasting and videocasting in a radically different manner form existing WordPress plugins. The underlying idea was to make it simple simple simple. And simple it became.

With Mediacaster, you upload media files from the WordPress admin interface. And you're done!

Special thanks go to Paul Colligan, Colin Collard and Sherman Hu for their invaluable input.

Enjoy.

• New layouts and skins for the two and three col themes.
• Skin, nav menu and caption editors via slick admin screens for all Semiologic based themes
• Fuzzy recent and subscribe me admin screens to edit what appears in your sidebar
• Many many more changes under the hood (in essence, over 95% of the code has been rewritten and cleaned up)

You'll notice that some features, namely the new theme skin editor, were planned for v.3.1 and got into v.3.0.

Others, namely graphics and the new version of Ad Spaces, were planned for v.3.0 and will only make it into a later version. I've a Pro package update that is planned by the end of December. It might occur earlier depending on when WordPress 2.0 is released.

Anyway… Of interest to Pro package users is the patch version for the pro package. If you are running 2.6.x or 3.0 beta blogs, simply upload the files in the patch.

Detailed changelog:

Semiologic plugins

Ad Spaces

v.1.4 (updated)

• Tweaked to make it more v.3 compatible.
• Takes advantage of the new ad css class.
• v.2 scheduled end of December.

Admin Menu

v.2.5 (new/updated)

• Replaces existing admin menu

Admin Simplified

v.2.2 (updated)

Blogpulse link

v.2.0 (updated)

Cosmos link

v.2.0 (updated)

Dofollow

v.2.0 (updated)

External links

v.1.4 (new/updated)

Extract terms

v.2.0 (updated)

• More flexible API

Terms2posts

v.2.0 (updated)

• Performance increase

Terms2search

v.2.0 (updated)

Terms2tags

v.2.0 (updated)

Fancy excerpt

v.2.0 (updated)

Frame buster

v.3.0 (updated)

Google Analystics

v.1.0 (new)

Opt-in front page

v.2.0 (updated)

Fuzzy recent comments

v.4.0 (updated)

• Now with an admin screen

Fuzzy recent posts

v.4.0 (updated)

• Now with an admin screen

Fuzzy recent updates

v.4.0 (updated)

• Now with an admin screen

Search reloaded

v.2.0 (updated)

• Performance increase

Smart link

v.2.1 (updated)

• More flexible API

Static front page

v.2.0 (updated)

• Now with caching

Subscribe me

v.2.2 (updated)

• Now with Google Reader and an admin menu

Semiologic CMS

v.3.0 (updated)

• New and improved API
• Now with a skin manager
• Now with a nav menu manager
• Now with a caption editor
• Now with send by email links

Archive, calendar, category, link and page tiles

v.2.0 (updated)

Sidebar tile

v.2.1 (updated)

• Now with caching

Unfancy quote

v.2.0 (updated)

Semiologic themes

Semiologic 2 col

v.3.0 (new/updated)

Semiologic 3 col

v.3.0 (new/updated)

Strawberry cream

Discontinued (obsolete).

Don't forget…

The new themes feature a skin switcher and allow you to define a custom.css to override default settings.

It will be useful to pretty much any user, and it is of course a 1-click installable tile on any WordPress theme.

Enjoy.

I had been considering a switch from /projects/ to /software/ for all of the software on semiologic.com and eventually took care of it today. Had it not been for smart links, I would have needed to revisit essentially every post on this site to locate every relevant link. Smart link turned this into a no-brainer:

• I added a couple of lines to my .htaccess file in order to redirect /projects/* and /downloads/* to /software/*
• Smart link took care of updating every internal link on the site

Download smart links.

The current relevance criteria is simplistic to say the least, but still more relevant that a date. Moreover, the search reloaded plugin searches in pages in addition to posts, and ignores html tags.

Do spread the word on your blog and invite your readers to do so as well… This tool is times more powerful that anything Google's pathetically outperformed search engine and interface will let you do. It deserves the blogosphere's full attention.

Via the New York Times.

The key features would be:

• Hassle-free, do-nothing setup and upgrade
• A couple of pre-built themes
• Built-in spam protection
• Built-in caching
• Built-in stats
• Wysiwyg editor
• Image gallery
• Poll manager, survey manager
• Newsletter manager
• Subscribe to comments
• Recent posts, updates, comments
• Add to Bloglines, MyYahoo, MyMSN buttons
• AdSense integration
• Amazon affiliation
• Simple shopping cart
• And more, all as one click installs

I'd be curious to know how much you, as a business blogger, would be willing to pay (install fee and recurring fee) for any or all of the above features.

My email is sales "@" semiologic.com. Thanks in advance for your time.

I'm aware this may sound silly to many a developer. Typically, they put the 'freedom to decide' or a 'learning curve' forward and miss the fact that they should be the ones who should need to make the extra step to use the tool in 'expert mode'. Open source developers are generally hardly concerned with UI design issues. Even though there may be a lot of money to be made in the field of open source usability.

I've these thoughts because Matt Mullenweg, the lead developer of WordPress, triggered a lengthy thread in the WordPress hackers mailing list:

I'm curious how the list thinks the community could be improved to avoid the concerns voiced in comments like this

I found this amusing, in some ways. WordPress is possibly the most powerful distributed conversation tool there is, and this topic ends up in a mailing list. Sad.

This remark set aside, what have we got when we take a closer look at the critics?

1. Users don't want to look for plugins or themes
2. Users are not even remotely interested in changing a simple php tag in their template files
3. Users wouldn't care much if someone tried to explain how to do this in a forum

In short: Users want a packaged product, with best defaults, and buttons. Incidentally, that is something akin to the CMS theme I am working on. Using it, Caroline could have added a feature such as 'recent comments' to her web site in one click. Not 'add the following tag here' (why not a relevant do_action?) or 'replace this tag by this new one' (why not add_filter?). Just one click in the plugin menu.

There's not much more to usability besides best defaults and buttons. I should probably mention cancel buttons too. Cancel buttons don't have to do anything, but it is basic usability to always provide a cancel buttons — Users are scared to death when none is around. Everything
beyond this is about auto-correcting common mistakes and making things look as usual, because errare humanum est and users spend 99% of their time somewhere else.

Consistent with these ideas, I suspect the following usability basics would be more interesting than trivial and/or meaningless details such as resizing the excerpt box and reorganizing the admin menu:

1. Deliver a packaged WordPress install with a collection of plugins and pre-built themes that auto-detect said plugins on a if(function_exists('plugin_blah_blah')) basis like the Semiologic theme and CMS — That way, a user can customize his theme in a mere few clicks and start blogging immediately.
2. Deliver a hosted version of WordPress — Users pay to blog. The button should read 'Buy a hosted WordPress', not 'Download WordPress'. Let the default class of users — the ones who pay for their hosting — buy their hosted version of WordPress as the default means of getting the software. Odds are very strong a host will be willing to sponsor WordPress bandwidth and more in exchange for this strategically placed button.
3. Add a Preview button — Yes, I'm aware you can mimic this. But add the Preview button — that's how it's called. This, the spell checker and the wysiwyg editor are like the most basic features for a publishing tool. No credible usability expert should miss any of these three points in an audit.
4. Add a spell checker — Yes, it's bloat. Include the plugin and enable it by default.
5. Hide all the HTML markup via a wysiwyg editor with a built-in image uploader — A debugged version of HTML Area should be present and enabled by default, and Markdown should be the default text rendering engine (textile is not intuitive enough) when HTML Area is disabled. And a hook should make these plugins mutually exclusive.
6. Include inline post, comment, category and link editors in the default themes, i.e. a bit like WordPress Touched. Add a readily available new post, new category, and new link buttons, right-click blog components such as 'Just Blog-it' for Firefox for each of the main browsers, as well as a
   decent search feature on the blog. And there's hardly any need to go to the scary looking admin area anymore.
7. Add an onunload event on editors to trigger a confirmation request when the user leaves without explicitly saving — I can't be the only one who is losing drafts on Ctrl+w…. An autosave feature would of course be better, but it should not be an option unless you feel like programming a multiple undo button and storing the stack of changes since the post's creation.
8. Replace user levels with user groups — It is more natural and easier to understand. Suggestion: Administrator (may do everything), Editor (may publish and edit posts), Contributer (may submit drafts), Moderator (may edit comments), Registered User (has a login) and Guest (no login).
9. Use natural language rather than URIs to insert links — No normal user in his right mind I know of spontaneously writes about <a href="http://wordpress.org">wordpress</a>. URIs look like throw-up and taste like throw-up. This is because they are throw-up. I suspect users may spontaneously link to [WordPress->] if it results — as does on this web site — in a link to WordPress. My smart links plugin should be available with the release of WordPress 1.5.1.
10. Get rid of trackbacks and pingbacks, and use an auto-discovery service instead — I've previously discussed what could be a credible alternative to trackbacks and pingbacks on this blog. Said post sucks, but the points remain.

Obviously, there would be a lot to add. Especially if you enter the realm of more complex UI matters. Like contextual help that changes links to the documentation based on what the user is doing, i.e. the context, in addition to being positioned where appropriate. Or posts that auto-discover related posts based on a graph analysis. But I guess the above straightforward and simple points are a good enough start for WordPress, and require little or no effort.

My $.02.

Update: Revisiting this three years after the post, many of these points have been implemented since.

Their perspective from looking beyond the "fundamental conflict" more or less summarizes the whole issue:

• Usability is about making it easier to get desirable results
• Security is about making it harder to get undesirable results

If you are a newbie to blogging, the purpose of trackbacks and pingbacks is to let a web site automatically link back to you when you mention it a story. As in: If I write a post on my blog and cite a post on your blog, your blog automatically mentions and links to my post.

My first concern about the two protocols is mainly related to trackbacks, in fact. Basically, you need to manually enter the urls you want to send trackback pings to, unless of course both ends feature trackback auto-discovery. When they do, pingbacks and trackbacks mostly differ in the protocol they use (simple http post on the one side, xml-rpc on the other). A proper, usable protocol should require no user input whatsoever, except for the manual insertion of an anchor.

Then, there is link spam. A trackback or a pingback will let link spammers insert links toward their customers' web sites. As I mentioned in a previous column, the rel=nofollow attribute will not stop spam, but it will damage the web. Thus, end users have very limited choices here: Either they've decent spam-protection tools or they're turning trackbacks and pingbacks off. A proper protocol should include supervised and unsupervised machine learning features that auto-reject unwanted pings.

Dead or irrelevant links also pose problems. Trackbacks and pingbacks should wither when the links die or are no longer relevant. Quite frankly, I'm amazed spammers still haven't used this to promote their customers' sites. You could imagine someone hiring a throng of chinese web surfers to trackback tens of blogs with more or less relevant comments. And redirect all these comments to doorway pages once the trackback pings are moderated. If anything, a proper protocol should auto-check and auto-wither links every once in a while.

Worse still, cloaking could make this problem even more nasty. You could imagine a spammer pretending to track your story, with a more or less relevant post. Then, memorize, say… the 10 first IP's who click from your blog. Obviously, you're likely to be in the lot. Any of these 10 IP's will get a normal-looking web site, while everyone else would get, say… a porn site. A proper protocol should be cloak-proof.

Protocol-wise, there is the stateful nature of the trackback and pingback protocols, which generate unfriendly — not to say buggy — interfaces when it comes to post publishing. I've seen WordPress take minutes to publish posts several times, only to discover it did not manage to send every ping it was meant to send. A proper protocol should be stateless and should catch these faults with no user intervention.

Moreover, the active nature of the trackback and pingback protocols' auto-discovery process is not relevant. If you publish a post, link to a site, and six month later the site implements pingbacks, a ping should occur at that time. Likewise, if you publish a post, and your web site fails to properly ping the web site you mention but stores you pinged it nevertheless there's no easy way to correct this. A proper protocol should allow passive auto-discovery in addition to active auto-discovery.

Lastly, a proper protocol should process the related referrals and sort them by relevance. Referral spam set aside, the more traffic a link brings to your website, the greater the odds it is a relevant link. Assuming you only display the top-10 trackbacks, for instance, you wouldn't care at all if a casino tracked your site. And you would eventually locate unauthoritative tracks, because they would bring you no traffic. Thus, a proper protocol should take a link's authoritativeness into account at the very least.