Twitter should natively integrate blogging

Recently, I’ve been noticing that some people on Twitter have been posting strings of multiple related tweets about a single subject. Maybe these have caught your attention too. They’re like little blog posts where the authors can go beyond the 140 character brevity enforced by Twitter. It’s an interesting hack of Twitter’s restrictions that is both clever for helping you talk to your audience a little more in-depth, but it’s also annoying because a single author can dominate your feed.


The first thing I do after publishing a new post on my own blog is post a link to it on Twitter. A lot of my blog’s traffic comes from my followers and their retweets. Similarly, for me personally, Twitter is a wonderfully valuable resource for reading material. Twitter helps me stay up-to-date on the latest news about my favorite technologies, and it helps me keep my audience up-to-date about my personal projects.

A blog requires a certain amount of maintenance. If I install WordPress or something like it on my website, I need to keep it updated. Even if someone else hosts everything for me, I still feel an obligation to post often enough to keep a formal blog. All too frequently, blogs are set aside while we focus on the other work. After a while, we feel guilty, and it becomes too easy to abandon them because we’re a little embarrassed.

Today, I don’t blog as often as I did before Twitter was introduced. It’s easy to feel satisfied from sharing an informal opinion with a quick tweet. At least I said something – even if it’s only 140 characters long. Many of those tweets deserve to be expanded, with a deeper look at the subject, but a quick tweet or two is more convenient. I think these strings of tweets are scratching the blogging itch for many authors, while keeping things a little more informal.

Twitter is about bite sized content, though, and I can’t help but feel like the author is being rude by posting many tweets in succession (even if it’s interesting content that I would otherwise enjoy). It’s a little spammy when someone takes over my feed like that. Many people on Twitter follow many different sources, and we scan through a lot of dirt to find the gems. I love that I have the choice to dig in if I’ve been hooked by a good title or summary, but I can quickly bypass something that doesn’t sound interesting. Multiple tweets in a row from the same author force me to briefly dig in when I don’t necessarily want to.

Authors can benefit from staying within the Twitter ecosystem. That’s where their audience is finding content, so make it convenient for the audience to read your content. Twitter benefits from people staying within the Twitter ecosystem because those people aren’t going elsewhere. However, the 140-character format required by Twitter doesn’t work very well with the type of content that some authors want to write. I think that Twitter can fix this missing piece, though.

Embrace and encourage common behaviors

Twitter should embrace how people are posting strings of related tweets, and how bloggers share links to their posts on Twitter. People want to say more to their audience than Twitter allows, and it seems that some prefer not to leave in order to say it. The company should be asking itself how it can serve that content directly within the Twitter app and website. The more time people spend on Twitter, the more the company benefits.

How do people share interesting articles (their own or written by others) on Twitter? They usually post the title (or a quote) along with a link. How are blog post editors usually designed? Two separate text boxes. One for a title and the other for the body of the post. Wouldn’t it be easy to limit the title to 140 characters? That’s enough to fit into a tweet. All Twitter needs to do is give a blog post some kind of special decoration to show that this tweet includes more content. Anyone who is interested can simply tap or click to read it. A simple button at the beginning and/or end of the post can bring you back to the main feed where you left off.

How these blog posts integrate with Twitter as we know it today is important. The 140 character limit is also one of Twitter’s best features. The full body of a blog post wouldn’t appear on someone’s main feed. It wouldn’t take up more space than a regular tweet. What we see in our feeds are the titles, limited to 140 characters. It will be clear that there’s more to read, but you see the full text only if you want to read it. It becomes the best of both worlds.

Comments and retweets

Commenting is available for free, of course. Anyone would be able to reply to a blog post with a regular tweet. Twitter could go a step further and allow a reply to a blog post that is another blog post. Many people complain that Twitter only allows shallow discussions because you’re limited to 140 characters, and it’s hard not to speak bluntly. With a longer blog format, discussions can be more subtle and go into more depth.

Often, someone sharing an article wants to quote part of it that is especially relevant. Retweeting a Twitter blog post doesn’t necessarily have to be limited to the title that the original author chose. What if you could pick a quote in the middle and retweet that instead of the title? A retweet with a quote would still open up the same full-length blog post, but you’d be tailoring the article to more closely match your audience’s interests.

But what about…?

In the past, companies have tried to provide products that would let you post longer tweets. Obviously, they weren’t all that successful. However, if blog posts were natively integrated into Twitter, I believe that many would embrace them. By making it easy to share and discuss (with retweets and longer replies), and by making it easier to go back and forth between blog posts and back to the feed, the smoother and more engaging experience would allow Twitter to succeed where others couldn’t, in my opinion.

The main issue that Twitter would need to address is people abusing these new blog posts for short tweets that they’re too lazy to edit down to fit within 140 characters. A Twitter feed filled with a bunch of 150 character blog posts would get annoying real fast. Maybe a blog post would require a minimum number of characters, like 500-750. Enough that 4-5 regular tweets would have been needed to fit all of the text.

For a better Twitter

While I’ve frequently talking about keeping the main feed on Twitter looking mostly the same, I think that adding blogging would still change the way that Twitter is used overall. Some people today say that they don’t “get” Twitter. More in-depth content would help reveal the hidden value of this service. Discussions are currently artificially limited. They’re shallow and lack subtlety. I think that this change would encourage people to talk to each other more instead of simply promoting themselves. It would clear up common misunderstandings caused by Twitter’s communication barriers. For those of us that like blogging, I think it would encourage us to do it more. We’d feel less guilty when we don’t blog for a while because blogging would become a part of the same service we visit daily. We’re frequently on Twitter, so we haven’t abandoned anything.

Adding support for MXML in Feathers

A couple of weeks back, you may have seen my tweets suggesting that I was interested in adding support for MXML to Feathers. I spent an afternoon digging into the source code for the Apache Flex compiler, and it became clear to me that I know where and how to modify the compiler to add support for Starling and Feathers.

Earlier that day I made some changes to the Java code for the compiler, rebuilt the binaries, and dropped a modified Apache Flex SDK into Flash Builder. The compiler errors that were normally caused by attempting to use binding with Feathers components went away, and I verified the code generated with the -keep compiler argument. It still needed work, but it looked good. I knew that I could do this.

Feathers MXML logo

I understand that some developers have no interest in using MXML with Feathers. Others find it essential for the types of enterprise apps that they want to build. It’s important for me to find the right balance helping both types of developers. Not only at the technical level (keeping performance and backwards compatibility in mind), but also by managing my time fairly. With that in mind, I felt that working on MXML support needed to be a separate effort from my day to day work with the ActionScript UI components. I have some free time that normally goes to various side projects or consulting, but I’d love to spend extra hours making Feathers better. Those other projects help pay the bills, though, so some extra funding is important. That’s why I was looking for a sponsor, and I knew that many developers working on enterprise apps would see increase productivity with MXML support, so it seemed like the right approach.

A number of eager developers suggested Kickstarter. I’m totally open to crowdfunding advanced Feathers components and tools (I have more ideas for the future), but I wanted to see if a company would step forward — similar to Adobe — to become an official sponsor of Feathers. Not long after I posted those tweets, the folks at YETi CGI contacted me, and we set up a call. We quickly discovered that our shared desires to improve and promote the Flash and AIR ecosystem align very well.


Today, I’m happy to announce that it’s official: MXML support for Feathers is going to happen. I have lot of work ahead of me, and I’ll be sharing my progress in the coming months. Keep watching this blog, and follow me on Twitter for details. If you have any questions, check out the FAQ that I put together below. Thanks!

Frequently Asked Questions

What features of MXML will be supported?
You will be able to add components as children of containers, set properties, listen for events, add [Bindable] metadata, and use curly braces to bind data to properties.
What features of MXML will not be supported?
Currently, I have no plans to support adding custom states to components in MXML. However, I am always open to community feedback, and if adding custom states is something that a lot of people ask for, that’s something that I can work on after the first release is finished.
Modifying the compiler? This project sounds like a lot of work. As a lone developer, can you do this on your own?
This project is certainly not trivial. However, I have studied the relevant compiler source code in detail (and the ActionScript classes that are used for binding), and I know which parts need modifications. I already built some simple prototypes. I successfully modified the generated ActionScript to remove some compiler errors, and I switched some of the code to use Starling or Feathers APIs instead of Flex APIs. There’s still a lot that needs to be done. I won’t deny that. I expect to spend at least three months (part-time) getting it to a feature-complete beta stage. However, I’m very confident that the conversion from Flex to Feathers will go smoothly and at a steady pace.
Will you spend all of your time adding MXML support while the rest of Feathers gets ignored?
Adding MXML support to Feathers will not take time away from any other aspect of Feathers. I normally have free hours every month where I work on side projects that have nothing to do with Feathers. I wanted sponsorship for this project so that I can allocate some of those extra hours to Feathers instead. In other words, I will continue working on the Feathers ActionScript components just as much as I have in the past.
What if I don’t need MXML support? I just want to keep using Feathers the way that I do today with pure ActionScript.
Using MXML with Feathers will be completely optional. Your existing ActionScript code will not need to be changed at all.
Will using MXML have a performance impact? Will there be any kind of performance impact on projects that don’t need MXML?

First, let me be clear that if your project doesn’t require MXML, Feathers will behave and perform the same as it does today. If I couldn’t make that promise, I wouldn’t be interested in going forward with this project.

Most features of MXML are simply a convenient abstraction to avoid writing a lot of ActionScript. The ActionScript code generated behind the scenes by MXML for things like creating components, adding children to containers, setting properties, and listening for events will look very similar to what you would write when doing those things yourself. I don’t expect any performance impact from using these basic features.

Data binding can involve a lot of event listeners, and it may require some extra garbage collection when it gets used. This may have a small impact on performance, if you’re not careful, at least on mobile. However, data binding in Feathers may end up performing better than it does in Flex because we can take advantage of Starling’s event pooling.

Will there be any preview builds?
Yes. I expect to release one or more preview builds as progress is made. They will be available to anyone who wants to try them. These builds may be unstable, and some features may still be missing. However, anyone will have a chance to give them a try and offer feedback. Once MXML support is feature complete, I expect to release a beta build that a larger audience will be interested in. After all the major bugs are worked out, I’ll release the final stable version.
Who is sponsoring this project?
I’d like to thank YETi CGI for their generous support.

Have any other questions or concerns? Please feel free to ask in the comments.

Feathers 2.0 preview: Listening to your feedback to improve the Feathers architecture

The first version of Feathers isn’t without its architectural headscratchers. Some extra boilerplate here, a little manual hand-holding there to make the components do what you want. You can usually get the job done, but sometimes, it takes a little more work than you’d prefer.

blueprintImage Credit: Blueprint by Will Scullin

Over the last year or so, I’ve been listening carefully to all of the feedback posted to the forums and in the issue tracker. I frequently ask myself a number of questions. Where are the common pain points? What features do people seem to ask for help with the most? What can I address right now, and what needs to wait until later?

In many cases, I can improve documentation, fix bugs, and add minor features that won’t break the existing apps that you’ve developed. Other things need to wait until a new major version of Feathers because they’ll end up breaking too many things for too many people. Sometimes, I simply need time to understand the problem better, or I need to get more feedback. I hate telling people that something can’t be done, and I wish I could always fix issues sooner instead of falling back on technical explanations for why Feathers works a certain way. However, a better architecture can’t be built overnight.

Several months back, I decided that instead of working on Feathers 1.4, it was time to make the leap to Feathers 2.0. I felt like I’d put enough thought into a number of common requests, and I felt confident with my plans for addressing them architecturally. In some cases, if I waited much longer, I’d probably never bite the bullet and get it done. It was finally time to break stuff, but (hopefully) in a good way.

The beta of Feathers 2.0 is coming in the near future, after I wrap up some final details (including writing preliminary documentation for some of these bigger changes). Until then, here’s a little preview of just a few things that you can expect to improve in the next version of Feathers.

Less updateItemAt()

When you change a property on an item in a list’s data provider, you either need to have the item dispatch an event to notify the item renderer of the change, or you need to call updateItemAt() on the ListCollection to force the item renderer to update. Most people opt for calling updateItemAt(), since it is more convenient.

One place where things get a little hairy is when you want a list to display a new ListCollection, but some of the collection’s items are duplicated from the list’s previous ListCollection. In Feathers 1.x, if you changed some properties on those duplicate items, the item renderers wouldn’t detect those changes. You would need to call updateItemAt() on the new ListCollection for each of the duplicate items, which usually involved looping through the entire collection because it was too annoying to figure out the exact index of each duplicate item:

var collectionLength:int = collection.length;
for(var i:int = 0; i < collectionLength; i++)

In Feathers 2.0, that won't be required. When you pass in a different ListCollection, the list will automatically force all item renderers to update, even if they're asked to display the same item. This change shouldn't affect performance either. If the duplicate items haven't actually changed, the item renderers can update more quickly than they would if they were asked to render completely different items.

To be clear, if you don't change the dataProvider property, and you change a property on an item, you still need to call updateItemAt(). ActionScript doesn't have any way to observe a property to see if its value changes. This simply helps those cases when you want to pass in a completely new ListCollection, and the list can automatically assume that it should forcibly update its item renderers.

Validate components off the display list

Previously, a Feathers component needed to have access the stage before it could initialize and validate. Sometimes, though, you want to use a component in some way without adding it to a parent. For instance, you might want to get its dimensions, or maybe you want to draw it to a render texture.

In one odd case, the order that Starling dispatches Event.ADDED_TO_STAGE events made it so that components that were added to their parent in the parent's constructor couldn't validate right away, even though they were technically added to the stage already. Most people didn't run into this issue, but it was frustrating for those that were used to a workflow where they added children in the constructor.

In Feathers 2.0, you can call validate() on a component at any time. Even if it isn't on the stage yet. If it hasn't initialized, it will do so immediately, before it validates.

var button:Button = new Button();
button.label = "Click Me";
trace( button.width, button.height ); // output: 130 58

A new theme architecture

Feathers 1.x had a couple of pain points when working with themes. Themes can be a little burdonsome for some developers because once you opt into the theme architecture, you need to do all skinning inside the theme to avoid having it override your properties. On the other hand, avoiding themes entirely can be painful too because you need to do all of the skinning manually with very few helpful defaults.

With Feathers 2.0, themes are more tightly integrated into the framework, allowing more flexibility in important areas. However, themes remain completely optional. If you want to skin the components by setting properties directly, I will always support your ability to handle it your way. Requiring themes would make Feathers less modular, and more rigid, and that's the opposite of my goals for the project.

Skinning subclasses with themes

Over time, I discovered that a number of ActionScript developers prefer to subclass components to create specialized versions of these components with common property values. For an overly-simplified example, you might create a SubmitButton class, and in the constructor, you might set the label property to "Submit".

public class SubmitButton extends Button
	public function SubmitButton()
		this.label = "Submit";
		// you'd probably set more properties too

If you were using a theme in Feathers 1.x, you'd need to inform the theme that the SubmitButton class should use the same skins as the Button class. If you make subclasses like this often, updating the theme every time becomes annoying very quickly.

On the other hand, some subclasses need to have very different skins from their superclass. For instance, the Check component is a subclass of the Button component because it behaves the same. It doesn't look like a regular button, though. If you created a custom component in this way, you'd definitely need to tell the theme how to skin it.

Another workflow usually involves calling a function to set common properties on a component. A submit button might be created by calling a static function like CommonComponents.createSubmitButton() that just creates a regular Button and sets some properties before returning:

public static function createSubmitButton():Button
	var button:Button = new Button();
	button.label = "Submit";
	return button;

With this workflow, subclasses are basically only used for significant changes that result in a component that needs different skins. In other words, the theme needs to be informed about every subclass, but subclassing doesn't happen very often.

The original theme architecture was designed with the second workflow (the one that doesn't subclass much) in mind. This architecture places a high burden on the first workflow because I figured most developers tried to avoid inheritance, like I usually do. As Feathers reached a wider audience, I eventually determined that I needed to support the first workflow better. Not everybody follows or agrees on the same best practices.

With themes being more tightly integrated into the components, I made it so that theming is inherited by subclasses by default. If needed, subclasses can opt into requiring separate skins. Now, the SubmitButton subclass workflow rarely needs to worry about the theme while the CommonComponents.createSubmitButton() function workflow needs to add a couple lines of code inside subclasses as a hook for the theme, but it's an uncommon situation. A nearly insignificant burden on the second workflow eases a very large burden on the first.

Excluding a component from the theme

In an ideal world, all of the styles for an HTML page will go into a single, well-structured, external CSS file. In practice, that doesn't always work out perfectly. Styles seem to slip into the HTML or JavaScript much too commonly. Similarly, in that ideal world, a Feathers theme would contain all skinning code required for an app. However, sometimes, you just want to tell Feathers, "Hey, don't give the theme access to this component. I want to skin it myself."

In Feathers 1.x, you couldn't easily set skins on a component without the theme replacing them later. It forced people to immediately learn how themes worked internally instead of allowing them to ease into it.

All components in Feathers 2.0 will have something called a style provider. Think of a style provider as a component's link to the theme. When the component initializes, it asks the style provider to set the skins.

A component isn't required to have a style provider, though. The chosen theme provides one by default, but you can get rid of it before the component initializes. Telling a theme not to skin a button is as easy as setting the style provider to null:

var button:Button = new Button();

// no theme, please!
button.styleProvider = null;

// now set some skins!
button.defaultSkin = new Image( texture );

this.addChild( button );

Once you've done that, you can set any property that you want, and you'll be confident that the theme won't interfere.

Beyond Feathers 2.0

These changes should ease some of the biggest pain points people have with Feathers. That said, as you all get comfortable with the new changes, I don't doubt that different architectural issues will be uncovered now that I've cleaned up the bigger ones. I want to fix those issues too! Please, never hesitate to start a thread in the forums or to open an issue on Github. I may not be able to address every issue right away, but your feedback will not be forgotten. I want to make Feathers better for all Starling projects, including both games and apps.

A beta build of Feathers 2.0 will be available in the coming weeks. I'm looking forward to your feedback — both positive and negative. If you'd like an extra early peek at the new 2.0 source code, you can download the Feathers master branch on Github. Remember, this isn't a stable build that everyone should try. It's pre-beta code that may contain bugs. Use at your own risk, and have some fun!