Today we’re rolling out a new and improved flow for creating repositories on GitHub.

Remember when I said this, shortly after GitHub released GitHub for Mac:

If Git is easy to use more people will use it and therefore more people will sign up and pay for GitHub.

It is just as important for Github to make git easier, so that its potential customer base expands beyond us geeks, as it is to promote best practices (like including a .gitignore file with one’s repo). This is why the GitHub website with its ease of use, documentation, training, etc. is really such a great business.

You see, GitHub isn’t just in the business of giving people access to git. They’re in the business of helping people to use git the right way. They’re creating some of the most loyal customers you’ll find anywhere online.

/via Kyle Neath on Twitter.

“Broken windows are the reason most large software projects suck to work on. A little technical debt here, a few shortcuts there, and pretty soon you’ve got a codebase so full of broken windows that no one even cares if they throw another pile of broken glass on the heap.

But just as broken windows are contagious, so is a dedication to quality. Carve out a little piece of a messy codebase and clean it up. Sharpen the edges, polish the surface and make it shine.”

This bubbles all the way up to the top of the product too. The code of a not-so-great feature can be gorgeous but it is still a feature that isn’t quite right. Focusing on the quality of the product from the engineering to the coding to the marketing is also contagious.

“Eventually, I (well, many of us) decided that better native clients (OSX, Windows, Linux, Eclipse, Visual Studio, etc) was the best way to grow GitHub.”

Boom.

Kyle is doubting the usefulness of Microformats, and is also saying that he thinks the learning curve is too hard because of the documentation making things “too hard”. First I’ll address his comments on the documentation being much too difficult to follow:

“Maybe it’s just me — but I feel like the microformats crew are actively trying to make this an elitest club. I’m not very stupid (I don’t think) but when I first started researching microformats it took me ages to really understand it. It turned out to be dead simple.

You can see the documentation (featured to the right) is quite brief for simple formats like hCard. Wait a second… are you serious? This page is reeee-diculously (and needlessly) long and really needs to be cleaned up. It’s like a giant newbie-scaring-machine. hCard is dead simple to implement; a couple of paragraphs should suffice with two or three examples.”

I could not agree more with Kyle on this. The documentation for Microformats, in reality, is all spec information. There is a definitive need for someone with any type of documentation experience to get on the Microformats Wiki and really make some “Microformats for Dummies” type of documentation.

Someone on Kyle’s comments suggested just getting Jeremy Keith to spear-head the effort. Well, Jeremy is already a microformats “evangelist”, but I can see their point. He has the ability to make things that seem difficult, dead simple. Perhaps he could take some time to edit the heck out of the wiki and/or just add a series of pages explaining each Microformat in human language.

Onto Kyle’s other gripe; the usefulness of Microformats. I disagree with Kyle on this point. Microformats can be, will be, and already are extremely useful. I feel a little weird saying this since I have yet to really take full advantage of Microformats on my site here – but it is definitely in my plans. Kyle didn’t really expound on his reasons why he thinks Microformats are not useful until one of the very last comments that he wrote (he doesn’t have permalinks on his comments so I will copy it here):

“But… again, you seem to have proved my own point with “We haven’t figure out how exactly that will help us” — that’s my entire point. I’ve been following microformats since Tantek was talking about them years ago. An yeah, Tantek is a cool dude… but is it enough of a reason to use them?

I honestly haven’t found it.

I use web standards because it helps me work faster produce more maintainable code and standardize my practices. I can’t say the same for microformats. The best I could say is: “I use microformats so that the extreme minority of my browsers, who have an extension installed, who are looking for specific metadata, who have scripts installed to interact with their other data management applications can more easily add me to their address book.”

Oh, and for those pushing hAtom… the last thing we need in this world is more syndication formats ”

His argument here is really way off. When he says “we haven’t found ways” he really means himself. I think if you ask the folks at Technorati, and the people that have invested millions of dollars into them, they’d disagree with Kyle too. Microformats is just really starting to take off (if people do not use them, they are indeed useless but as more people use them, companies like Technorati can really build useful tools). There is no one definite useage for each Microformat, however each have their own implementation. The biggest advantage I see? One content delivery system for almost any type of data. I don’t need to create a vCard for my about page, I just need to add a few classes to the information that is already there. This brings me to his second point that falls short.

His argument that “…and for those pushing hAtom… the last thing we need in this world is more syndication formats”. Perhaps he hasn’t delved into hAtom much, but it isn’t another syndication format, it literally takes the place of Atom (which is becoming increasingly popular and is starting to become the syndication format of choice of some of the larger companies that have tons of data to syndicate [ see Nail Kennedy's article about feed syndication formats and their usage]). Also something to remember is the hAtom is currently in draft format, but imagine if if you had a blog and you didn’t need to serve an HTML version, RSS 0.92, RSS 2, and Atom version of your site. You could just serve the HTML version and all of the data you wish to syndicate – to different applications and services, could be parsed from that single delivery system. This is the biggest advantage of Microformats in my opinion.

The documentation does need a serious look, and update, to make it a much less steep learning curve. Broader usage will come of that, and in turn more uses will reveal themselves from a growing user base. I suppose Kyle’s post really cuts right down to the root of the Microformats problem – explain them better, and they’ll be used.

[tags]microformats, kyle neath, tantek Çelik, jeremy keith, hcard, hatom, rss, atom, feeds, syndication, technorati, html[/tags]
[slug]re-microformats-useful[/slug]