| Comments

I’m an avid user of Twitter (join me on Twitter @timheuer) for things social, family and technical.  I use it to keep in touch with friends, learn things from technical sources, get news and otherwise interact with names I’ve never met in person.  My use of Twitter has changed much over the years and I’ve found myself just using the web site more and more while on the desktop where a full browser is available.  On my mobile I use native clients but presently not one of the ‘official’ Twitter mobile apps (I find them less full-featured than the 3rd party ones which also offer a better performing experience for me).  In my use of the web site I’ve noticed more and more links that say “view summary” in my feed. 

Twitter Summary Card sample

Sample Twitter Summary Card from dev.twitter.com

When expanding this, the twitter post (which is limited to 140 characters itself) basically provides more information about the post.  The most frequent I’ve seen is what Twitter calls a Summary Card, which reads metadata from the URL posted in the Tweet, effectively extending the 140 character limitation a bit (however summary descriptions are limited to 200 characters).  I post to Twitter most of my blog posts and thought it would be a great little enhancement to provide this summary data in the feed view (it isn’t expanded by default so users must explicitly click ‘view summary’ and thus there is no real risk of making your Twitter feed more noisy without you choosing to read more).

Learning about Twitter Cards

I recently learned more about these after a quick exchange with @JeffSand (former director at Channel 9, now at Twitter) about another implementation (more on that later) and thought I’d get into doing the Summary Card for my own personal use.  Twitter has some pretty decent documentation on this topic on their Dev center.  There are a few types of Cards available for content authors to leverage and the great thing is that you, the content author, really just have to add metadata to your content and that’s it.  Twitter feeds/apps do the rest by interpreting and displaying that data in a Card view in the feed.

Summary Cards seem to be the most popular to me but that could be just my own personal use.  The others that I could see add value are the App info/install and deep-linking ones.  These do presently, however, seem to add most value in the mobile space and not the desktop space.

  • App Cards – provide a link to mobile apps and product page information.  This is currently limited to iOS and Google Play store listings it seems.  There is also some documentation on App Install/Deep-linking techniques.
  • Photo Cards – provide a good representation of an image in-line.  You see this for images from Twitter, Flicker, SkyDrive, etc.  Sadly, Instagram chose not to pull this support for their usage last year (yay customers…grrr).
  • Player Card – seems great for podcast publishers!  You see YouTube usage of this most of the time as well.
  • Product Cards – I’ve not seen usage of this in my interactions but I would imagine we’ll see more of this in sponsored posts/ads as they become more prevalent

After reading about these, I set out to add this metadata to my own content on my site.

Modifying my blog engine

At present I use Subtext as my blogging engine of choice.  This is due to some choices made long ago using .Text and then migrating to Subtext when that transitioned the work.  Subtext has served me very well over the years but is showing its age more recently as I’ve been desiring to modernize some things and leverage the vast ecosystem of WordPress type themes and plugins.  Still, it is Open Source, written in ASP.NET and so I could modify things as I need.

I first went to the source of Subtext and thought I’d just upgrade.  The version I run is the latest stable/release build of Subtext and hasn’t really evolved since that version release a few years back.  The version on GitHub now is moving toward ASP.NET 4, which is good and I thought I’d just move to that.  I had an immensely painful time trying to do this upgrade and ultimately decided against it (blog post on my ASP.NET migration woes perhaps to come) as there wasn’t much return on my time investment at present to do that.

The first thing you have to do is set up your Twitter Card.  Twitter’s docs have a cool Cards validator tool (only works on Webkit browsers for some reason) to give you a display of your card so you can tweak settings.  Once you do this and have your metadata set up, you need to submit your URI to Twitter for validation.  This step is critical or they won’t show up.  This step is also not entirely clear in the process and you may think that just setting the META tags are sufficient…they are not.  Use the validator tool to see the second tab to “Validate & Apply” for your card view.  I did a basic Summary Card for my entire site to get through this process so I could test/validate my own logic for the per-post metadata later.

I wanted the data from each of my posts to be a unique Summary Card as I felt that has been the most valuable I’ve used in my feed.  Card data is implemented as META tags so your mileage may vary on how you need to implement this. 

If you are a WordPress user, there is an amazing ecosystem of plugin developers who have already done this for you and you just install a plugin.  It doesn’t seem that Twitter provides a directory of recommended plugins for popular CMS systems, so I can’t speak to which ones are reliable or not.  Twitter Cards for WordPress seems to have a lot of downloads so I’d check that one out first if you are a WordPress user.

Unfortunately the way Subtext is architected doesn’t easily let me jam new META tags into my site that are dynamic (there is a tool that allows me to easily add static ones without altering the page itself).  A few properties for my cards would indeed be static (creator, site, domain) so I just used the Subtext admin area to add those.  The title and description I wanted to be content-specific.  I didn’t modify the Subtext source, but rather created my own ASP.NET 3.5 control that did this.  I put the code on my GitHub repository for you to view…you’ll see it is a quick few lines of code.  My control basically gets the context of the request, pulls the title/body out and sets these META tags.  Now whenever I post a URL to Twitter, my Summary Card option will be there and provide some helpful information to the reader (hopefully).

Viewing the results on different platforms

Looking at the results, I’m happy with my quick hack.  Outside of the web site, the cards only show on Twitter official apps it seems.  Here are some examples based on my site content.  The red box is only there to illustrate what content is actually the card:

Twitter Summary Card web view

View on twitter.com when expanding ‘view summary’

Twitter Summary Card iOS

View on Twitter for iOS when viewing full Tweet detail

Twitter Summary Card on Windows

View on Twitter for Windows

Simple metadata additions providing some more content beyond the 140 characters Twitter allows in the post itself.  I chose to use my face in the image because my blog doesn’t associate a “poster” image per-post.  If yours does, you should use that if available and change the twitter:image value as needed.


This didn’t take me long to implement and adds some additional value on to the content I post on Twitter (I hope).  Again, this is optional for the user, they have to click “view summary” or view the Tweet in details view to see this, so there is no general feed noise here.  I have found that it appears to cache the results per URL so there may be an issue if you change title/description on a post.  I’ve found that my initial tests wouldn’t update the previous Cards I had which were just the blog summary data…that’s unfortunate, but now I know.

When I talked with @JeffSand he mentioned this would be nice to have the App cards for Windows Phone/Windows Store apps (ugh, we really have to do something about that name).  I think this is a great idea!  Unfortunately it looks like Twitter needs to do something to understand Windows apps as it only understands iOS/Google Play app stores.  I’ve started a conversation with Jeff’s team as of the date of this writing and hopefully we can understand what might be required and deliver some goodness here.

If you are a content publisher (hint: if you are a blogger you are) this is a subtle and helpful addition to your content in my opinion.  If you are podcaster, consider using the Player Card as well.  It was really easy to understand and implement and I like the results.

Hope this helps!

| Comments

I’ve made no hiding the fact that my blog is build on Subtext and that I’m very happy with it right now.  Lately though my wife has been blogging more (that’s another story) and she also started her own business.  Being curious about all the WordPress love, I decided to start checking it out.

Thankfully, the Web Platform Installer helped me get started on WordPress without any troubles at all and I was up and running on my Windows server (I didn’t want to start another hosting account anywhere).  I have to say, I really like what WordPress has done, especially with the extensibility points and the administration options. 

That being said, I started looking at the various plugins available and was curious about anything for Silverlight…to be able to easily put Silverlight content within a post like other plugins have enabled.  Sure, it isn’t a difficult task to begin with, but sometimes different hosts/tools make it difficult for us to add <object> type content.  After some searching in the WordPress plugin library, I found one that was built back in the Silverlight 2 beta days.  The link to the author was no longer valid so I decided to create one using that as a base.

NOTE: I totally failed my Internet duties to look via any search for one…I kept my searching to the official plugin directory.  Apologies to Peter Loebel for not recognizing he also did some work, but admittedly it was also during the beta days.  I’ve credited both Peter and Juergen Oberngruberin my readme.txt for the plugin as contributors.

So after a few minutes, I was able to get it working and created the Silverlight for WordPress plugin.  It’s simple and you basically can input into your post data:

   1: [silverlight: <app>, <width>, <height>, <initParams>, <minVer>]


  • app is the URI to your Silverlight application (XAP)
  • width/height should be obvious
  • initParams will map to the initParams of your application
  • minVer maps to the minRuntimeVersion required for your app

The only parameter required is <app> and all others are optional and have defaults which you can change via the plugin settings:

Silverlight for WordPress default settings

I’ve applied yesterday to put the plugin in the official WordPress plugin directory, but haven’t heard back yet and they don’t really have any SLA.  I’m hoping to get it in soon, because they have a good discovery model for updates, etc. and authors can install in one click.  For now, I’m also going to maintain a link to the current version with release notes on my site here: Silverlight for WordPress.

UPDATE: Silverlight for WordPress is now available in the plugins directory…just search on Silverlight.

Like I said, it’s simple (and perhaps dumb to some), but I look to your input.  Hopefully some WordPress authors may be able to use it.  I know my wife’s new photography site will :-).

Hope this helps!

This work is licensed under a Creative Commons Attribution By license.

| Comments

Hot off the press, a new drop of Windows Live Writer was just released.  Get it here.  This is one of my favorite tools from Microsoft and the update brings a few new changes.

First, I’m happy to report that Flickr4Writer and S3Browser still work fine and require no adjustments.  The other thing announced today from the Writer team is an updated SDK.  This new SDK includes a new type of plugin which enable plug-in activity for pre- and post-publish events.  Some of you following me on Twitter may have noticed something every so often that said “blogging: blah blah” and a link to the post.  This is done automatically for me from Writer using a plug-in.  It actually is one of the ones included in the updated SDK (along with another example for adding a Digg badget to your post).

Recently there’s been some discussion of people re-aggregating/posting blog content to other sites.  Even though I had a Creative Commons license on my blog’s footer, etc, it wasn’t in my content so when someone re-posted my stuff automatically, it wasn’t visible.  Using the new Writer SDK, I created a quick little plug-in that would add a notation about the Creative Commons license I was using to every post.  Again, automatically now and I don’t have to write anything.  I’m making this one available for free/test and you can get it here.  These plug-ins are accessed in the same way through the Tools…Options menu in Writer.  Here’s the configuration for mine:

If you click the Preview tab (a new feature in Writer preview – tabs instead of menu options to switch between Edit, Preview, Source), it will show you what it will look like as well.  These types of plugins can also be enabled per weblog so if you have more than one weblog defined for Writer, you can choose which one you want these post- and pre-publish event plug-ins to be turned on for. 

For some existing plugins out there, this is a more natural fit.  When I heard about this new model, I joined up with Alexander Groß who wrote the Now Playing plug-in which is awesome and flexible (he’s also involved in a great Graffiti template for user groups).  But it seemed a more natural fit to use this model of automatically appending the information instead of having the user remember to click the button to insert the information.  I’ve submitted my changes to Alexander and hope they make it into his next build of Now Playing.  It looks the same in config and here it is in preview mode in Writer:

I love the new Writer with the subtle changes it has made and the additional plug-in model.  Get your update today!

| Comments

This blog runs on SubText.  I heart SubText.  I know there are others out there but for me SubText has met most of my needs.  And when it hasn’t I modify it.  Which brings me to this post.  There was a thread on an email list I belong to about Windows Live Writer (I heart Live Writer too :-)) and categories (adding new categories on the fly).  This got me to crack open the source and hunt.  Alas, there was no support for this.  I’ve been ranting about WordPress API support for SubText on the developer list and I think if I rant one more time it will probably get assigned to me.  Please keep in mind that my modifications were solely intended to make Live Writer the best tool for me…these are targeted at Live Writer functionality and may/may not add value to other areas of functionality.  So on with the show…

The Slug

One of the features in SubText is the ability to auto generate URLs based on the title of the blog post.  Well, I didn’t like that.  I usually want my URLs to be a slight derivative of the URL.  My workflow, then, has been to post as draft, go to the web interface, change and then enable the syndication.  I am sick of doing that.  So let’s start with that first.  You see in blog terms the end part of your URL in called a “slug.”  SubText calls this a ‘friendly url’ and other engines may call it something else.  Here I’m going to call it a slug.  My colleague Jason Mauer has a custom blog engine he uses where he’s implemented almost every blogging API in his set.  I’ve been geekly jealous of his API for some time…now it is time to change that.

I’m not going to go into the philosophical reasons why I want a different URL slug and why I want different ones.  We can debate that over a Mt. Dew some time if you’d like.

SubText uses the MetaWeblog API by default.  The developers chose to implement the spec of MetaWeblog (as they should have) and thus the slug is not a part of the newPost spec and the Post struct used to identify the structure of a post.  So my modification was a few steps.  If you are familiar with the latest source (1.9.5b) of SubText, I’ll be referring to line numbers in there.  First, I had to modify that Post struct for the MetaWeblogAPI implementation.  Now some may shirk that this is a no-no…and I might agree…so if modifying something that isn’t going to conform to a spec that really isn’t full anymore, then move along.  I modified about line 63 and added the following:

public string wp_slug;

I actually could have used wp_slug or mt_basename, both of which mean the same thing and both of which are sent to the API by Live Writer…so I just picked one.  Now my struct has the information when it passes it along for creation/edit of the post via Live Writer.

The next step was to modify the implementation of the post.  In MetaWeblog.cs at about line 234 I added:

if (!string.IsNullOrEmpty(post.wp_slug))
    entry.EntryName = post.wp_slug;

I also added this to the editPost method to ensure compatibility on edit.

The final step was to modify my wlwmanifest.xml file to announce to Live Writer that I now support this feature.  This is done by adding to the <options> node of this manifest:


Then do a refresh of the account settings in Live Writer.  When you do that, in a new post click the little ‘up’ arrow just underneath the editing area and you should now see a Slug field:

Now I don’t have to post a draft and login to change!

New Categories

The thread actually started with wanting to create new categories during a post.  SubText is one of the engines that doesn’t expose this API directly just yet, so some altering had to be done.  Here’s what I did.  I chose to mirror the WordPress newCategory method to do this. 

First I added IWordPressApi.cs to Subtext.Framework.XmlRpc.  The complete code within it is:

using System;
using CookComputing.XmlRpc;

namespace Subtext.Framework.XmlRpc

    public struct WordpressCategory
        public string name;

    public interface IWordPressApi
            Description = "Adds a new category to the blog engine.")]
        int newCategory(
          string blogid,
          string username,
          string password,
          WordpressCategory category);

I then went into MetaWeblog.cs and implemented that interface with:

public int newCategory(string blogid, string username, string password, WordpressCategory category)
    LinkCategory newCategory = new LinkCategory();
    newCategory.CategoryType = CategoryType.PostCollection;
    newCategory.Title = category.name;
    newCategory.IsActive = true;
    newCategory.Description = category.name;

    newCategory.Id = Links.CreateLinkCategory(newCategory);

    return newCategory.Id;

I chose to ignore the slug/description fields (again, thus ignoring the spec which isn’t ideal) at this time, partly because I was getting errors and partly because I decided that I didn’t need them anyway.  I don’t use the description field in categories in SubText, so I just set the description to also be the title.  I also had to modify the wlwmanifest.xml file with:


and refresh my Live Writer account profile to pick up the changes.  The result is now my category options in Live Writer include an “add” feature:

Done with both of those.

Future Posting

This is something I started to look at and added the information to the MetaWeblog API, but it seems that SubText doesn’t filter out future posts in the UI – or at least my quick scan didn’t reveal it did.  I’ve moved on away from this one since I don’t future post right now, but I’ll come back to it in a while.  What I did do, however, to prevent me from thinking SubText supported this was modify my wlwmanifest.xml file to include this definition in the options:


This way at least if the idiot in me *thinks* I can do it, Live Writer will warn me.

So that’s it!  These little adjustments make my Live Writer + SubText experience AWESOME.  Live Writer truly is one of the best tools Microsoft puts out (aside from Silverlight of course).  I’m going to submit these modifications to the SubText team and see what sticks.  I assume none will since they are admittedly partial.  But I’ve been suggesting on the dev list that SubText expose a WordPress API and I have a feeling I’ll need to start working on that for the team.

Hope this helps some of you!

| Comments

recently i came across a feed entitled '.aspx considered harmful' and natural i paused.  for those who don't know .aspx is a known file extension for web pages generally using asp.net technology.  i think the title was a little misleading but it did the job -- got me to read it :-)

john had made a suggestion in conversation that a blog engine (must have been the topic of conversation) shouldn't produce urls that end in .aspx.  basically, in a nutshell john is pointing out that technology changes and while you might be .aspx one day you might be .php the next.  valid point.  where i think his argument breaks down for me is in the two reasons he points out why this is 'harmful': futureproofing and style.


let me take on futureproofing first.  john's assertion is:

"The technology that produces the name, never mind the version of that technology, is a variable that need not, and should not, be exposed. If links are pointing to foo.asp, and your upgraded blog engine produces foo.aspx, you broke those links. That’s unnecessary and avoidable."

for me that is a pretty big leap.  aside from the fact it puts a lot of weight on the technology implementers to forever future-proof their technologies (web ones being in question here).  i'm definitely not disagreeing that you need to do your best effort to future-proof information...that is what makes internet information so valuable...it's longevity.  i disagree with the assertion that file extensions are the cause of problems -- it is more like sloppy editors.  the point here is to respect the permalink.  i'm in the camp of 'who cares' when it comes to file extensions.  if an author of content is moving from one platform to another, it is their responsibility to respect the permalink to the information.  i may have bookmarks, etc. that i rely on.  don't 404 me bro!  john does point out that the new asp.net mvc pattern can help things like this for eliminating .aspx in the url.  i guess i'd be quick to point out that it doesn't solve the problem at all posed in the futureproofing note.  so now i have 'clean' urls...great, what if i now move to a framework that doesn't support mvc/rest-esque url patterns?  i'm just as screwed.  i'll say it again, respect the permalink

i'll take an example from one of my colleagues.  dave bost hosted his blog on an asp.net technology for a long time.  he built up a lot of those harmful .aspx things over time.  when dave decided to learn some new technologies, he decided to move to a php-based blog engine.  wow, those dangerous .aspx are going to leave some nasty end trails moving to php.  or not.  you see, this would be more of a move from an older microsoft technology to a newer one.  this is moving from microsoft to non-microsoft.  what would he do?  dave knew he had to respect the archive he had.  so users who may have bookmarked a url to http://davebost.com/blog/archive/2007/06/14/Gadgets-and-Snipping-Tool.aspx will not have lost the information.  see dave.  see dave respect the permalink.  thanks dave.  if you click that link above you'll notice that you'll end up at http://davebost.com/blog/2007/06/14/gadgets-and-snipping-tool which is the current url.  having .aspx wasn't harmful because the author of the content was responsible to ensure that permalink wasn't lost.  now i'm not saying it was drop-dead simple, in fact i don't know how dave decided to do it, but he did.  his readers (and search engine archives) will not be lost because he moved to a different technology.  it didn't matter what the endpoint extension of the url was.  didn't matter at all.


on the context of style, john writes:

"Names without extensions are cleaner and simpler. Why does that matter? I guess if you think of URLs as constructs generated by machines for machines, then it doesn’t, because machines don’t care about style. But I believe that even when they’re machine-generated, URLs are for people too. We read, cite, and exchange them. Their structure and content conveys meaning in ways that warrant thoughtful analysis. Elements that don’t convey meaning, and that detract from clarity, should be omitted."

again, here i'll disagree (of course, or what is the point on writing this post).  whenever i see comments like these i always slow down and defer to the mother-in-law factor.  you see, we in technology have a tendency to think that things must make sense.  users generally don't care.  they want things to work.  when they bookmark things they want them to be there.  when they search, they want to find.  etc.  with regard to style, i think it seems a bit nitpicky.  for me content is king.  why should i care what the url is as long as the content i'm looking for/reading/consuming somehow is valid to me.  does it make it less valid because the url looks technical?  look at facebook.  my profile page is http://www.facebook.com/profile.php?id=584375671.  sure, that url does nothing to tell me what profile i'm about to see.  it would be cool, i guess, to see http://www.facebook.com/profile/timheuer, but i don't really care.  you see i can easily ensure my content says view my facebook profile.  there, do you see the url muck?  no, you see a hyperlink to something that i've described.  and when you click it you know what you are getting...so who cares about the url?

john's note about 'elements that don't convey meaning, and that detract from clarity, should be omitted' is something i disagree with.  to *something* they have meaning.  look at yahoo.  this url http://news.yahoo.com/s/ap/20080118/ap_on_go_pr_wh/economy_stimulus goes to an article about president bush and some tax stuff.  should the url have been http://news.yahoo.com/Bush-wants-fast-tax-aid-to-boost-economy?  who knows.  i'm sure there is a content management system behind their solution that is at 'fault' for creating the url.  whatever the reason, i don't care -- the content is king.  i can see somewhat john's point that we can't always blame technology like i just did.  sure a content management system should be able to let me name whatever i want.  but i guess that is a technologist thinking again and not my mother-in-law...she just wants to read the article.

another piece of evidence to this is a commenter on john's blog:

"If I see a file of the form http://example.com/path/to/file.rss I expect the result to be an RSS feed." source

wow!?  i think i'm going to ask my dad tonight if he knows what .rss is.  that is a technologist thinking if i ever saw one.  another commenter notes that urls are brands:

"Absolutely. URLs are brands, permanently on display for every webpage. The user wants to know what the page is about, not what technology you’ve used to put it together." source

i agree with the first statement here.  it is why i blog on timheuer.com and not blogs.msdn.com -- this is my brand.  i would argue 'root brand' is important here.  the user wants to know *where* they are reading the information.  they will remember their own context of the content.  i'll take the yahoo link above as an example.  having news.yahoo.com is critical because it is their brand and reminds me of where it is.  but i won't take the time to really record the rest of the url.  i'll either bookmark it for later if it is interesting or in passing i'll mention to someone 'i read an article on yahoo about bush and tax aid, you should search for it.'  that is how we talk now.  'just google it' is a common phrase.  we use things like tinyurl, shrinkster, etc. to shorten urls for us to make them easier to send. 

urls aren't the only place where this is.  would john suggest that we do away with .exe, .app? 

you see to me, the technology isn't harmful.  the style of implementing human readable urls isn't harmful (or sometimes isn't even helpful), but respecting the permalink is critical...no matter what technology is used.  it matters not what the address bar says, but rather that i can find it when i search for it and when i save a reference to it.